Thanks Mike for looking at the issue. I will update the upgrade
testcases with the tests you have suggested.
I am not sure what you mean by retry code. Do you mean the situation
where rescanning of BTree is required to identify the slot to insert ? I
was testing it with 2 ij windows. I have also written a test case for it
and attached to DERBY-3473
(https://issues.apache.org/jira/browse/DERBY-3473).
anurag
Mike Matrigali wrote:
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
