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 -- 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.
