On Sep 21, 2011, at 11:03 AM, Ben Ford wrote: > I've now tried a make_transient so my code looks like this: > > obj = <some object created by adding to a parent's collection> > ses = object_session(obj) > if not ses: > make_transient(obj) > ses = Session() > ses.add(obj) > ses.commit() > > I still get the same exception. > > I guess my other option now is to do: > > state = attributes.instance_state(obj) > state.detach() > > Would that work do you think? BTW would this be considered a bug, should I > raise a bug report on this?
I think you're hitting an edge case here that's the result of trying to use objects across sessions where you're just allowing sessions to fall out of scope. I'm not sure the behavior as is is how it should be. The source to _attach() implies that "implicit detachment" was how this worked at some point, or intended to work but there's no tests - I was under the impression that the object is in fact implicitly detached, but that doesn't occur here without a small change. http://www.sqlalchemy.org/trac/ticket/2281 sums up the behavior. The questions I'd start with, and keep in mind this is towards establishing a use case that would drive the desired behavior, is what is preventing you from keeping a Session in place, or calling close() on it when completed, or using new objects for a new Session instead of recycling those which are hanging around from some previous operation ? That said I'm leaning towards that patch, but probably only in 0.7 as it is a slight behavioral change. -- 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.
