Mike Matrigali wrote:
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.
Old indexes will continue to behave like a unique index because they
would have not null constraint (requirement for unique constraint as of
10.3) which effectively makes even the
new indexes behave like a unique constraint. But it will now be possible
to drop null constraint on a field participating in unique constraint
and in that case application will experience new behavior.
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.
Shall I do selective upgrade, only for backing indexes of unique
constraints ?
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.
I have already coded for this functionality. In case of soft upgrade
null checking is performed while creating unique constraint and also the
new attribute is ignored while persisting B2I and IndexDecriptorImpl so
the data base remains in the older format. Only after hard upgrade
checking for null while creating unique constraint is skipped
additionally user will be allowed to drop null constraint from the
fields participating in unique constraint (to achieve new behaviou from
the existing constraints) .
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.
