On Feb 19, 2007, at 12:16 AM, David Bolen wrote:
> > 1. I have a simple "add" operation which does the basic object > allocation, session.save() and session.flush(). The issue was when > I tried to add an object with a SQL violation (duplicate value on > unique column). No problems with the SQLError exception, and > rollback in the session transaction. But what caught me a bit by > surprise was the fact that the "bad" object was still in the > session. So a subsequent attempt to "add" a new (valid) object > through the same session failed on the earlier object - still > apparently in the UOW scope - before even getting to the valid > object. This seemed common enough that I expected to find easy > references to it, but I've had trouble finding information on it. > > My "fix" was to trap the exception and explicitly session.expunge() > the faulty object. It works, but seems a little fragile - I'm not > sure how this would extrapolate to a larger UOW (e.g., how do I > discover the object at fault), or if I need to be doing this in a > blanket except: clause - e.g., are there other sorts of failures > that can leave a persistently failed object in the identity map. I > saw a prior note on this list about flush exceptions sometimes > occurring instead of SQLError and am not sure if conditions > resulting in the Flush version of the exception could cause the > same problem. > best practice when an error during flush() occurs is to clear the session using session.clear() and start over. this is also the advice of the hibernate camp which is what we've based our Session on. SA does not make any assumptions whatsoever what youd like to do with the objects in your session if a flush failed. > 2. I'm unclear what (if anything) to expect with respect to my object > instances in memory post-save for primary key or default value > columns. My initial expectation - particularly with the warning > about flush() in the docs and related objects - is that the > instance I had saved() to the session would be untouched and I'd > have to retrieve it from the database again. But in a quick test I > saw the primary key and defaults seemed to have information after > the flush() without any further steps. column-based attributes get populated with newly generated primary key, default, and foreign key values. object-based attributes (those configured via relation()) do not change. a related doc is at http://www.sqlalchemy.org/docs/ unitofwork.myt#unitofwork_api_flush_whatis although i am amazed that it is not more explicit about the column-based attributes being populated. > > Of course, then it bit me later when I found that my DateTime > columns > (with a default of func.current_timestamp()) of my instances had > string values and not datetime as I expected. use func.current_timestamp(type=DateTime) > > 3. I was implementing an archive of deleted objects, sharing the > object definition with two mappers - one primary and a second to a > "deleted" table with a different entity name (basically an audit > table for deleted instances). > > I was excited to see the entity_name availability with alternate > mappers, and figured it would be an elegant way to handle the > archive. I hoped there would be an easy way to delete an object > through the primary mapper and then save it to the alternate > mapper, while using the same object instance (to avoid having to > manually duplicate the object). But SQLAlchemy was very good at > knowing I was playing with an instance that it already had > associated with the first mapper. In the end, rather than poke too > much at artifically clearing SA state fields, I just copied my > object (all non-"_" prefixed attributes) to a new instance, and > saved that to the alternate entity_name. you might be the first person to have actually used the "entity_name" feature. > Anyway, I was wondering if there was a clean way to use a single > object instance in this way, or even a supported way of clearing an > instance so SA doesn't think it used to be associated somewhere. havent put much thought into it, the easiest way is to just change the "_entity_name" attribute to whatever, and if you remove "_instance_key" then SA will see the instance as "pending" or "transient" (meaning it will do an INSERT next time it tries to persist it). just play around with dir(myobject) a little to see what SA sticks on there. --~--~---------~--~----~------------~-------~--~----~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sqlalchemy?hl=en -~----------~----~----~----~------~----~------~--~---
