Does performance suffer for more field queries

Flow Production Tracking
3

Oh boy, this thread might be a can-o-worms. But hey, it’s THERAPEUTIC, amirite?

Things to worry about (11am edition)

  1. The “Home” page that comes ootb filled with widgets for five or so ‘perspectives’ …is a real pain point if you end up with a lot of query fields. Users cry, “can’t we just have a nice page with everything on it?”

  2. If you get spinners (which are usually query fields going nuts) you can close the browser and… your server will still be working on that horrible query… for minutes sometimes. Um, maybe I shouldn’t have mentioned that.(*)

  3. Adding a field to an entity – “to one project” as it’s advertised – merely HIDES it from all the other projects. You still end up with 1,600 fields on the Shot entity after doing this for ten years.

  4. Reports get written by coordinators or producers by exporting CSV, and then using Excel to massage that data into client-cleanliness, even though all day long they’re in Shotgun using what looks like a spreadsheet. After all, you don’t want to add another field for “Cut duration in M:S:F less handle at FPS-per-shot”-willy-nilly.

The up-side

We’re all in this together. Collaboration…

  1. Is the most important part of any endeavor

  2. In our field it will start to dwarf everything else as time goes on.

  3. Shotgun Software has the unlimited resources of AutoDesk backing them, so they can rewrite Shotgun on top a new backend in all their spare time. They might even use a graph database this time. Neo4j… just go ahead, buy it. You know you want it.

  4. They might solve the performance and shifting-schema problems while they’re at it.

  5. Shotgun gets it, they, along with all of us, need to move forward together (since they can’t solve everybody’s problems individually.) That’s why this community matters.

(*) Please send a Shotgun Engineer a free beer.

4 Likes