On Jan 17, 2009, at 1:46 PM, Darren Govoni wrote:
> > Hi, > Thanks for the suggestions. In my system, it is a federation of > databases using SQLA as the "object layer". There are message queues > that move detched data around as needed. My goal is to keep the > application as OO as possible with respect to interacting with the > database, queuing etc. In these cases, objects are retrieved from some > databases and need to be saved to others. > > there's a real benefit to not mixing and matching strategies since its > real nice how SQLA already mitigates the complexities of SQL under > complex objects. > > That said, could it be a humble feature request down the road to have > implicit __deepcopy__ implemented in the instrumented SQLA code > injected > into objects such that it provides this capability. and something > intuitive to exercise it like. > > copiedobjectinnewsession = session.migrate(currentobject) > > This could require some interface support on the objects if need be. > > Since SQLA is already capable of managing the object graph and state > it > would seem logical to re-use those mechanics to implement this? > > Or am I one foot off my rocker? It's a use case that comes up now and then, so I'd implement it as a SQLA extension and it would perhaps call into the attributes API directly to set the appropriate instance state for the new copies. It would likely be a mixin that implements __deepcopy__(). --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "sqlalchemy" group. To post to this group, send email to sqlalchemy@googlegroups.com To unsubscribe from this group, send email to sqlalchemy+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sqlalchemy?hl=en -~----------~----~----~----~------~----~------~--~---
