db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mike Matrigali <mikem_...@sbcglobal.net>
Subject Re: [jira] Updated: (DERBY-3456) Allow removing not null from collumns particpating in unique constraint.
Date Wed, 27 Feb 2008 18:27:51 GMT
could you add the following tests:

o) just cover all the create index cases to make sure all the format id 
btree code gets exercised. Some cases may not be affected by your code 
but would be good to verify.  Also by having all these cases I think
it will cover all the stored format paths for the new format stuff in 
the btree container.

    1) create and use unique index (nullable and non-nullable), 
non-unique index (nullable and non-nullable), non-null constraint  in 10.3.
    2) create and use unique index (nullable and non-nullable), 
non-unique index (nullable and non-nullable), non-null constraint
       in 10.4 soft upgrade.
    3) create and use unique index (nullable and non-nullable), 
non-unique index (nullable and non-nullable), unique constraint 
(nullable and non-nullable)
       in 10.4 hard upgrade, verify their null handling is as expected.
    4) In 10.4 soft upgrade, access and use those indexes created in step
       1, verify their null handling is as expected.
    5) In 10.4 hard upgrade, access and use those indexes created in step
       1, verify their null handling is as expected.
    6) In 10.4 hard upgrade, access and use those indexes created in step
       2, verify their null handling is as expected.

hopefully one routine can be reused for all of the above and just add 
calls for each case, but with different index names for each case.  By 
verify expected behavior I mean:
unique nullable index - only one null allowed
unique non-nullable index - no null allowed
non-unique index (nullable) - multiple nulls allowed
non-unique index (non-nullable) - no nulls allowed
non-nullable constraint - no nulls allowed
nullable constraint - multiple nulls allowed

I don't know if the upgrade framework supports this, but you should at 
least by hand test at least once that you can access all the above after
you shutdown the database and then access it again.  Some of the upgrade
code only will get exercised if the index is accessed for the first 
time, as the contain information is otherwise cached.  It is important 
to test that the new formatid stuff is being read from DISK correctly.

Also how have you been testing your retry code?



Anurag Shekhar (JIRA) wrote:
>      [ https://issues.apache.org/jira/browse/DERBY-3456?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
> 
> Anurag Shekhar updated DERBY-3456:
> ----------------------------------
> 
>     Attachment: upgradetests.diff
> 
> This patch has upgrade tests for unique constraint.
> 
> 
> under soft upgrade
> 1. Setting columns from unique constraint to null able - should fail
> 2. creation of unique constraint over nullable columns - should fail
> 3. creation of unique constraint over not null column - should pass
> 
> under post soft upgrade
> test unique constraint created in soft upgrade phase.
> 
> under hard upgrade
> 1. Tests unique constraint creation prior to upgrade
> 2. Tests unique constraint over null able columns - should pass
> 3. Test setting column from unique constraint to null able - should pass
> 
> 
>> Allow removing not null from collumns particpating in unique constraint.
>> ------------------------------------------------------------------------
>>
>>                 Key: DERBY-3456
>>                 URL: https://issues.apache.org/jira/browse/DERBY-3456
>>             Project: Derby
>>          Issue Type: Sub-task
>>          Components: SQL, Store
>>    Affects Versions: 10.4.0.0
>>         Environment: all
>>            Reporter: Anurag Shekhar
>>            Assignee: Anurag Shekhar
>>         Attachments: derby-3456v1.diff, upgradetests.diff
>>
>>
> 
> 


Mime
View raw message