On Saturday, September 14, 2013 9:21:21 PM UTC, GregD wrote:
>
>
>
>
>> Now for the other problem and it is with a test but along the same
>> reasoning. If we add a foreign key in a database that requires explicit
>> commands to do so, then we need to add the constraint prior to adding the
>> foreign key. This could be making a column not nullable or adding a unique
>> constraint on a composite key. Maybe other DBs will do this for you
>> implicitly, but I can not imagine all do so. So, in order to get a add
>> composite foreign key to work, I had to make sure that a unique constraint
>> existed and create it if you add a composite key. This caused the
>> following test to fail because it was adding the unique constraint prior to
>> adding the key.
>>
>> in integration/schema_test.rb about line 549
>>
>> @db.alter_table(:items) do
>> add_unique_constraint [:item_id, :id]
>> <--- this is causing the grieve
>> add_foreign_key [:id, :item_id], :items, :key=>[:item_id, :id]
>> <--- because of the checking, this will also add the constraint for a
>> db that requires it do.
>> end
>>
>>
>> My thought is this test was set up for a database that requires explicit
>> commands and other test were mostly set up for database that will
>> implicitly do things for you if they are not there.
>>
>
> If your add_foreign_key is also adding a unique or NOT NULL constraint to
> the referenced table, I think that is what needs to change.
> alter_table(:foo){add_foreign_key :column, :bar} should never do anything
> starting with ALTER TABLE bar. If there needs to be a unique or NOT NULL
> constraint on the referenced table, then the user should add that manually.
>
>
> Then this is breaking the other test. Hence my dilemma. In the other
> test, it is only adding a foreign key (composite key) without creating the
> unique constraint like this one is. This makes SqlAnywhere throw an
> exception. So either, this test needs to change or the other. Either
> force the creation of a unique constraint or not, but it must be
> consistent. Based on your response, I say the test that is adding a
> foreign composite key must add the unique constraint prior to adding the
> foreign key like this test is. Add based on your response, I guess I'm
> violating this by altering columns in the referencing table to be not null
> when adding a single foreign key column to prevent SqlAnywhere from
> throwing an exception and those tests should be changed to make those
> explicit not nulls, etc.
>
I agree that the other test should change so that the unique constraint is
added manually (even if that isn't necessary on other databases).
Definitely altering the referenced table implicitly when adding the foreign
key is not good. Modifying the tests to use explicit NOT NULL is fine too.
Thanks,
Jeremy
--
You received this message because you are subscribed to the Google Groups
"sequel-talk" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To post to this group, send email to [email protected].
Visit this group at http://groups.google.com/group/sequel-talk.
For more options, visit https://groups.google.com/groups/opt_out.
