db-derby-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Daniel John Debrunner <...@debrunners.com>
Subject Re: Ability to create a unique index on the same column, doc bug or "bug" bug?
Date Thu, 25 Aug 2005 14:25:57 GMT
Michael J. Segel wrote:

> On Wednesday 24 August 2005 21:50, Jean T. Anderson wrote:
> This post may require the readers donning flame retardant clothing. ;-)

It seems to me that Susan and Michael are discussing different aspects
of constraints and maybe that is where the confusion is coming in.

Here's my perception of what the two of them are talking about.

Susan is talking about the mechanics of constraints where a backing
index is automatically created. Susan noticed some inconsistency in the
way that Derby tries to ensure the user/application does not create an
index that will be redundant due to the backing index.

Michael is talking about the behaviour of constraints and is stating
that if a constraint is added to a table with rows (using ALTER TABLE)
then the constraint will be added successfully even if there are rows
that do fail the constraint.

I actually fail to see where any conflict is, Susan's discussion and
proposed text doesn't seem to have anything to do with constraints on
existing tables with failing rows.

I know that this disallowing of creating an index in such a case is only
for performance reasons, not any behaviour reasons. We wanted to avoid
having multiple physical index on the same columns, thus wasting space
and slowing DML.

Michael, I do think you need to step back, and re-read the e-mails, you
are challenging Susan's understanding on the issue you are talking about
and as far as I can tell, Susan hasn't even discussed that issue.

Also Michael, you are challenging Susan to run tests on other databases
to prove your assertion, but that's not her 'itch to scratch', so she
has no reason to do such a thing. In fact you assertion seems incorrect
and is not the way Derby behaves. Having a constraint that cannot be
guaranteed seems to be of little value to applications. Thus if you want
to show that Derby is wrong here, or not in line with other databases,
or some standard, then that's your 'itch to scratch' and you should be
running the tests on other databases to back up your assertion.

Am I missing something?


View raw message