Automatic environment filtering for DB queries

2014-11-12 Thread Menno Smits
Team Onyx has been busy preparing the MongoDB collections used by Juju to support data for multiple environments. For each collection that needs to store data for multiple environments we have been adding the a "env-uuid" field to each document and prefixing the environment UUID to the document id,

Re: Automatic environment filtering for DB queries

2014-11-17 Thread John Meinel
I've had this around to think about for a bit. I think it is ok, though sniffing an input parameter to change behavior seems brittle. Mostly because the object isn't really design to work that way. Could we wrap the objects so that we just have Find/FindId do the right thing to start? I suppose th

Re: Automatic environment filtering for DB queries

2014-11-17 Thread Tim Penhey
Wrapping the collection objects that are returned from the `getCollection` method shouldn't be too hard and it could wrap the Find and FindId calls. It would have fixed this missed call below: // aliveUnitsCount returns the number a alive units for the service. func aliveUnitsCount(service *Servi

Re: Automatic environment filtering for DB queries

2014-11-18 Thread Menno Smits
Thanks John and Tim. I really like these ideas, especially because it means the team doesn't need to learn a new way of working (and remember to keep using the new way). In most cases, the thing returned by getCollection() will be able to be used in the same way as before, even though it'll actuall

Re: Automatic environment filtering for DB queries

2014-11-19 Thread Jesse Meek
Just something to think about, if the new Find and FindId funcs were mockable, it would make supporting old schemas during upgrade steps much easier easier. For example, if I could mock out Find at the beginning of MigrateUnitPortsToOpenedPorts (a 1.21 upgrade step) to not filter by env uuid an