From derby-user-return-1798-apmail-db-derby-user-archive=db.apache.org@db.apache.org Thu Aug 25 14:26:55 2005
Return-Path:
Delivered-To: apmail-db-derby-user-archive@www.apache.org
Received: (qmail 34711 invoked from network); 25 Aug 2005 14:26:55 -0000
Received: from hermes.apache.org (HELO mail.apache.org) (209.237.227.199)
by minotaur.apache.org with SMTP; 25 Aug 2005 14:26:55 -0000
Received: (qmail 59948 invoked by uid 500); 25 Aug 2005 14:26:53 -0000
Delivered-To: apmail-db-derby-user-archive@db.apache.org
Received: (qmail 59917 invoked by uid 500); 25 Aug 2005 14:26:52 -0000
Mailing-List: contact derby-user-help@db.apache.org; run by ezmlm
Precedence: bulk
list-help:
list-unsubscribe:
List-Post:
List-Id:
Reply-To: "Derby Discussion"
Delivered-To: mailing list derby-user@db.apache.org
Received: (qmail 59904 invoked by uid 99); 25 Aug 2005 14:26:52 -0000
Received: from asf.osuosl.org (HELO asf.osuosl.org) (140.211.166.49)
by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 25 Aug 2005 07:26:52 -0700
X-ASF-Spam-Status: No, hits=0.4 required=10.0
tests=SPF_HELO_FAIL
X-Spam-Check-By: apache.org
Received-SPF: neutral (asf.osuosl.org: local policy)
Received: from [32.97.110.130] (HELO e32.co.us.ibm.com) (32.97.110.130)
by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 25 Aug 2005 07:27:07 -0700
Received: from westrelay02.boulder.ibm.com (westrelay02.boulder.ibm.com [9.17.195.11])
by e32.co.us.ibm.com (8.12.10/8.12.9) with ESMTP id j7PEQHuD306736
for ; Thu, 25 Aug 2005 10:26:27 -0400
Received: from d03av01.boulder.ibm.com (d03av01.boulder.ibm.com [9.17.195.167])
by westrelay02.boulder.ibm.com (8.12.10/NCO/VERS6.7) with ESMTP id j7PEPit4398634
for ; Thu, 25 Aug 2005 08:25:44 -0600
Received: from d03av01.boulder.ibm.com (loopback [127.0.0.1])
by d03av01.boulder.ibm.com (8.12.11/8.13.3) with ESMTP id j7PEQGGD018514
for ; Thu, 25 Aug 2005 08:26:16 -0600
Received: from [127.0.0.1] (sig-9-48-114-88.mts.ibm.com [9.48.114.88])
by d03av01.boulder.ibm.com (8.12.11/8.12.11) with ESMTP id j7PEQFr9018245
for ; Thu, 25 Aug 2005 08:26:16 -0600
Message-ID: <430DD4F5.7030805@debrunners.com>
Date: Thu, 25 Aug 2005 07:25:57 -0700
From: Daniel John Debrunner
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.3) Gecko/20040910
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Derby Discussion
Subject: Re: Ability to create a unique index on the same column, doc bug
or "bug" bug?
References: <20050824233332.81997.qmail@web81305.mail.yahoo.com> <200508241947.11516.msegel@segel.com> <430D31FB.1020207@bristowhill.com> <200508250822.09759.msegel@segel.com>
In-Reply-To: <200508250822.09759.msegel@segel.com>
X-Enigmail-Version: 0.90.0.0
X-Enigmail-Supports: pgp-inline, pgp-mime
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
X-Virus-Checked: Checked by ClamAV on apache.org
X-Spam-Rating: minotaur.apache.org 1.6.2 0/1000/N
Michael J. Segel wrote:
> On Wednesday 24 August 2005 21:50, Jean T. Anderson wrote:
> *WARNING*
> 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?
Dan.