well a decision needs to be made on what the order of UPDATE and DELETE statements should be. hibernate orders INSERT statements by the order that new entities were save()d, but it doenst say much about the order of individual UPDATE/DELETE statements.
what would be easy to implement is to order the UPDATE/DELETE statements by primary key when they are grouped together. so i have committed a change in 1684 that will perform this sort before UPDATE/ DELETE statements are made for entity updates/deletes as well as many- to-many table deletes. so we can say that the order of flush() is now totally deterministic, i.e. that for a row A in table X and a row B in table Y, all UPDATE/ DELETE statements within the span of a flush() will always place X.A and Y.B in the same order. although there are no tests set up to help confirm that this is the case, and im also not sure if theres a way to "prove" it (others might know); so this is currently theoretical. however, if you declare your own transaction, and make two flush() calls within it, one which affects only Y.B and another which affects only X.A, then you still can have a Y.B execute before an X.A within one transaction. im not exactly sure how that could be prevented. On Jul 3, 2006, at 3:51 AM, Tzahi Fadida wrote: > I am committed to python, i already switched from ruby. > Java, is too slow for my user interface and in general just a > wasteful beast. > > I bet from the pace you are setting in SQLAlchemy, in 2-3 months it > will be in > beta. I am not worried at all. > Can you point me to the ticket of the DELETE/UPDATE ordering so > I'll know when > it is more "guaranteed" :), though i am staying with SQLAlchemy, > for now if i > see that order might matter i can just issue a flush after a delete/ > update. > > I have another question that follows my last: I need to read tuples > from the > database in the form of objects, hence ORM, and serialize them and > send them > to the client. Now, an object in ORM contains pretty much all the > information > including the ID and possibly redundant information to the actual > usage. One > possibility is to just strip from the object the attributes using > python > methods etc... Another, more efficient method, would be to ask > SQLAlchemy to > only populate certain fields. Is it possible to do the latter? > > On Monday 03 July 2006 07:09, you wrote: >> i think your best bet is to try it out and watch how it organizes >> statements. if youre really building something with zero tolerance >> for failures, something like Hibernate is much more mature; as SA is >> hardly even beta, i cant say very much is "guaranteed" about it right >> now. > > -- > Regards, > Tzahi. > -- > Tzahi Fadida > Blog: http://tzahi.blogsite.org | Home Site: http://tzahi.webhop.info > WARNING TO SPAMMERS: see at > http://members.lycos.co.uk/my2nis/spamwarning.html > > Using Tomcat but need to do more? Need to support web services, > security? > Get stuff done quickly with pre-integrated technology to make your > job easier > Download IBM WebSphere Application Server v.1.0.1 based on Apache > Geronimo > http://sel.as-us.falkag.net/sel? > cmd=lnk&kid=120709&bid=263057&dat=121642 > _______________________________________________ > Sqlalchemy-users mailing list > Sqlalchemy-users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/sqlalchemy-users Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 _______________________________________________ Sqlalchemy-users mailing list Sqlalchemy-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/sqlalchemy-users
