>However, it would >mean moving some model logic into the manager, making Model.delete() >defer to the manager to collate and remove objects. Would this rub >anyone the wrong (or right) way?
Actually I think sooner or later we will need objects to keep track of the manager they came from - for example think about situations where a model class has two managers, both pointing to different database connections, where you would need the resulting objects to point back to their manager to be able to use the same connection where they came from. Actually I think it would even be best if all actual database access stuff was moved to the manager - and the object itself just delegating back. The selecting is already done in the manager anyway, so why not move the .save() and .delete() handling (the actual SQL generating and executing code, that is) into the manager? So I am +1 on that change, it would make many interesting things (like application-level replication or application-level load distribution) much easier, while not really breaking outside APIs, as the objects will still provide their database accessing functions. And if that makes the database code more simple by allowing better code reuse, I am even more for it. bye, Georg
