Yeah I confirmed set collections don't actually fix it, I guess setting a rollback point is required. Is there any chance this is a difference between the way mysql does table locking and postgres? The collections in question have lazy="dynamic" set so I'm wondering if previously it wasn't a problem because the DB was locking the whole table?
On Monday, March 17, 2014 8:49:57 PM UTC-7, Michael Bayer wrote: > > > On Mar 17, 2014, at 10:38 PM, Morgan McClure > <mcclure...@gmail.com<javascript:>> > wrote: > > > I'm trying to make a many-to-many relationship using sqlalchemy 0.9 and > postgres > > > > If I put a unique constraint on the join table, and I add a duplicate, I > get an integrity error. > > If I change the collection class to set, it won't double commit, however > a set prevents me from using things like order_by. > > > > In my scenario, I'm massively multi-threaded and so the check-before > commit methodology won't work (proven it breaks with 24 processes). > > Is it possible to get a nice elegant solution to this without defining a > custom collection_class? > > > > I believe this is a regression (enhancement?) from version 0.8, but on > 0.8 I was using mysql and now I'm using postgres. > > im not seeing how this is any kind of change from version 8 to 9, or even > from version 7, 6, or 5; a list will certainly allow duplicates that will > give you integrity errors, and a set certainly won’t. using many > processes of course you can’t coordinate those in memory with a set, only > the database knows the right answer. > > the approach here unfortunately is to use traditional means of adding new > rows while checking for an existing one. which means either emitting a > SELECT first and ensuring adequate coordination between these 24 processes > using transaction isolation or locks, or using a simple optimistic approach > where you start a savepoint (begin_nested()), attempt the operation, catch > IntegrityError and then continue with the row now known to be already > present. -- You received this message because you are subscribed to the Google Groups "sqlalchemy" group. To unsubscribe from this group and stop receiving emails from it, send an email to sqlalchemy+unsubscr...@googlegroups.com. To post to this group, send email to sqlalchemy@googlegroups.com. Visit this group at http://groups.google.com/group/sqlalchemy. For more options, visit https://groups.google.com/d/optout.