In what situation will it be necessary to run hard upgrade. My
understanding was that only new software would create these "new"
types of indexes. All old index behavior was to remain the same
and thus would not need the new functionality. So all existing
unique indexes should continue to throw errors for multiple nulls.
New unique constraints on nullable columns should be the only indexes
that use the new code.
Why are you upgrading all existing conglomerates? If at all possible
I believe we should avoid an upgrade process that touches all
conglomerates at upgrade time. We have not ever done that in the past.
What I was expecting for hard upgrade code was code that only allowed
use of the new feature if the database was upgraded. Because derby
supports soft upgrade the software already has to recognize and function
with existing conglomerates without change. So with similar changes
to yours in the past store usually just continues to read the old
format. Under hard upgrade when the store decides it is necessary to
write the new format then it can write the new format if db has been
hard upgraded, or it must write the old format if it is still soft
upgrade.
Anurag Shekhar (JIRA) wrote:
[
https://issues.apache.org/jira/browse/DERBY-3330?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Anurag Shekhar updated DERBY-3330:
----------------------------------
Attachment: derby-3330v6.diff
This patch includes hard upgrade (Upgrade test from 10.3.1.4 and 10.1.3.1runs
without fails).
Description of Hard upgrade
Hard upgrade makes following changes
1. Updates B2I class by adding extra attribute (uniquewhenNotNull)
2. Updates format id.
3. Updates ConglomerateDescriptor of all updated Conglomerates to
user new version of IndexDescriptorImpl
Unique index meant to be backing index of UniqueConstraint is updated to
become UniqueWhenNotNull index (nUniqueColumn is set to nKeyFields - 1
and uniquewhen not null is set to true). For other indexes uniqueWhenNotNull
attribute is set to false.
Hard upgrade is initiated from DataDictionaryImpl.upgradeConglomerate
(new method). This method calles another newly intoroduced method
getAllConglomerates to get the list of conglomerate and updates them
by calling TransaCtioncontroller.updateUniquenessOfConglomerate
which internally calls Conglomerate.updateUniqueness to
conglomerate attributes.
I will be posting one more patch after introducing multipage page
scan while checking for duplicates.
provide support for unique constraint over nullable columns
-----------------------------------------------------------
Key: DERBY-3330
URL: https://issues.apache.org/jira/browse/DERBY-3330
Project: Derby
Issue Type: New Feature
Components: Store
Affects Versions: 10.4.0.0
Environment: all
Reporter: Anurag Shekhar
Assignee: Anurag Shekhar
Attachments: BTreeController.diff, derby-3330-testcase.diff,
derby-3330.diff, derby-3330v2.diff, derby-3330v3.diff, derby-3330v4.diff,
derby-3330v5.diff, derby-3330v6.diff, FunctionalSpec_DERBY-3330-V2.html,
FunctionalSpec_DERBY-3330.html, UniqueConstraint_Implementation.html
Allow unique constraint over nullable field. Right now derby support unique
constraint only over not null columns.
