>default manager works fine for the simple case, but how do propose to >choose the 'correct' manager if there are multiple managers involved?
The objects do have some meta data - just plug a "source" meta data in there that points back to the manager from where the object was loaded? Or maybe just keep the source in a _source_manager attribute on the objects loaded from a manager. The only problem are _new_ objects, where we would have to provide a non-default manager so it knows where to save it. This could be done with an optional parameter to the .save() method - this would just store the object with the help of that manager and keep that manager in the objects' ._source_manager attribute (so subsequent changes and .save() without explicit manager will go to the same manager it was saved to, first). This would change nothing in those situations where you just use a default manager for saving and some overloaded managers for restricted selects. But it would open up easy multiple-manager-handling with just one little change - the optional parameter to .save(). The next step would be to allow non-default database connections in managers and this would get us easy multiple-database-handling without too much change to the API. bye, Georg
