Hi, how about delegating _all_ DB-IO to the manager with magic removal? Currently all class-based selects are handled by the manager, while object-based selects and updates/inserts are handled by the objects themselves.
How about internally delegating updates and object-based selects to the manager? This would allow classes to define multiple managers that use _different_ database connections and so solve one of our bigger problems in Django: class Polls(models.Base): title = models.CharField() write_objects = models.Manager() read_objects = models.LoadBalancingManager([list_of_connections]) This (can't say wether it uses the actual names of classes, but you should get the idea) would define a model that has a manager used for writing (of course the programmer has to make sure) that will use the default database connection. The LoadBalancingManager would be one that only handles selects and gets a list of connections to use for that. Internally the objects of class Polls would still have their own .save() and .get_list() and friends - but those would just delegate to the manager that actually fetched the object. So to update an object, one would just use the write_objects manager (should be actually a read_write_manager ;-) ) to fetch the object and change it. But view functions that only need to get data and present them would use the read_objects manager and so get connection dispatching for free. Additionally we could allow an optional parameter to the .save() method to give a different manager, so that objects that are already read from some manager don't need to be reread just to set some flag or something like that - with defaulting of that parameter to the object-selecting manager. Pure read managers like a LoadBalancingManager could just raise an error when the user tries to call .save() on them. Additionally the manager could have a .save() method itself that not only saves one object with it's associated objects, but would save all objects that are currently marked as "dirty" - that way users could define the scope of a transaction themselves. Either they .save() on the object and so the transaction would include the object and all subsequently added/changed objects that were dependend on that "lead" object, or they call .save() on the manager to update all outstanding changes (and therefore have a big transaction including all stuff). This wouldn't fully solve #9, as it doesn't include a full manual transaction support, but it would solve many situations where the programmer either has one object with related stuff or multiple loosely related objects. Comments? bye, Georg
