youve got relationships defined on your mappers which are essentially "view only". particularly when you specify a primaryjoin that crosses two tables, the unit of work cant do anything with that. if you look at the flush plan (using create_session(echo_uow=True)), youll see that in the first test the Algorithm object is getting saved twice. what you cant see (unless you add some print statements to the SA code like i did) is that its because theres essentially two sets of circular relationships between Node/Version/Project (which is something ive never even seen before...not that it isnt buggy behavior on the part of SA, but its very edge case....) and its just getting confused. so i added for you a "view_only=False|True" flag you can add to your relation()s. add that to all the "start_version"/"end_version" stuff since that stuff has nothing to do with what it needs to save items. after that, the "polymorphic_identity" column is not getting assigned on insert for some reason. you need to break this example down into a much simpler thing first, get it to work completely, then slowly add complexity to it. when you can isolate exactly where something stops working (like the polymorphic_identity problem), then you can send it to the list. there is way too much going on in the current example for me to isolate how many places the mappers are getting tripped up. On Sep 26, 2006, at 4:29 PM, Hogarty, David A. wrote:
|
------------------------------------------------------------------------- Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys -- and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________ Sqlalchemy-users mailing list Sqlalchemy-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/sqlalchemy-users