On Aug 12, 10:09 pm, russm <[email protected]> wrote: > Hi Jeremy, > > I reckon there's a bug with the CTI plugin overwriting model object > PKs in at least sqlite (perhaps all adapters for databases that don't > support "insert ... returning ..." ?) > > A minimal testcase is this schema and model -http://gist.github.com/522288 > > In sqlite, the model id values are overwritten to what an integer id > would be when creating CTI subclass objects. Without the > skip_create_refresh plugin this causes creation to fail when Sequel > tries to refresh the object, or using skip_create_refresh the DB rows > are correctly inserted but the object has had its id changed after > #save is called. > > ru...@alcazar:~/zzz/sequel-cti$ rm foo.db > ru...@alcazar:~/zzz/sequel-cti$ sqlite3 foo.db < foo.sql > ru...@alcazar:~/zzz/sequel-cti$ sequel -L . sqlite://foo.db > Your database is stored in DB...>> o1 = C1.create > > => #<C1 @values={:kind=>"C1", :id=>#<UUID:0x811c849c > UUID:d0ccf15e-3af9-4a78-8ebd-b7f21a7fee99>}>>> o2 = C2.create > > => #<C2 @values={:kind=>"C2", :id=>2}>>> o2d = C2.first > > => #<C2 @values={:kind=>"C2", :id=>"18c0c972-656a-45a7- > abd8-28e85d0a608f"}> > > >> ^dru...@alcazar:~/zzz/sequel-cti$ > > The correct values are inserted into the database (examining the > database directly confirms this is the case) and querying the database > with Sequel returns the expected objects, but freshly-created objects > are broken when Sequel returns them. > > In postgres, everything works as expected. > > ru...@alcazar:~/zzz/sequel-cti$ createdb foo > ru...@alcazar:~/zzz/sequel-cti$ psql foo < foo.sql > NOTICE: CREATE TABLE / PRIMARY KEY will create implicit index > "c1s_pkey" for table "c1s" > CREATE TABLE > NOTICE: CREATE TABLE / PRIMARY KEY will create implicit index > "c2s_pkey" for table "c2s" > CREATE TABLE > ru...@alcazar:~/zzz/sequel-cti$ sequel -L . postgres://localhost/foo > Your database is stored in DB...>> o1 = C1.create > > => #<C1 @values={:kind=>"C1", :id=>"022fefd5-ea3c-42d3- > a0da-35be07f1e1b3"}>>> o2 = C2.create > > => #<C2 @values={:kind=>"C2", :id=>"1cddcb94-4097-4e62- > ab11-48f00ec262c8"}>>> o2d = C2.first > > => #<C2 @values={:kind=>"C2", :id=>"1cddcb94-4097-4e62- > ab11-48f00ec262c8"}> > > >> ^dru...@alcazar:~/zzz/sequel-cti$ > > I've started looking for the cause of this, and am wondering if it's > the update of @values[primary_key] with the result of the CTI table > inserts at the end of > Sequel::Plugins::ClassTableInheritance::InstanceMethods#_insert in > cases where the database doesn't do "insert ... returning ..." > > If that's it, I'm not sure what the solution should be so as to not > break cases where the id is assigned by the database as a column > default. In my case the PK will always be provided by the model > (sometimes a random UUID, sometimes a SHA1 name-based UUID), so I'm > planning on working around the issue by saving my PK in a > before_create hook and restoring it in after_create, but this isn't a > general solution. Perhaps changing that assignment to > > @values[primary_key] ||= iid > > so the update only occurs if the model hasn't provided its own PK > value? (I've not thought through the possible side-effects of that > change though). > > cheers > > Russell
Excellent analysis of the problem, which made it fairly easy to fix: http://github.com/jeremyevans/sequel/commit/698945991e61d679c4a1e91402d9351800f14a70 Thanks for you help, Jeremy -- You received this message because you are subscribed to the Google Groups "sequel-talk" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/sequel-talk?hl=en.
