db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jeff Levitt (JIRA)" <derby-...@db.apache.org>
Subject [jira] Commented: (DERBY-539) Update the Create Index statement in the Derby documentation with additional information
Date Tue, 14 Mar 2006 20:38:56 GMT
    [ http://issues.apache.org/jira/browse/DERBY-539?page=comments#action_12370408 ] 

Jeff Levitt commented on DERBY-539:
-----------------------------------

Can someone take a look at the most recent patch so it can commit if it looks good?  Thanks!

> Update the Create Index statement in the Derby documentation with additional information
> ----------------------------------------------------------------------------------------
>
>          Key: DERBY-539
>          URL: http://issues.apache.org/jira/browse/DERBY-539
>      Project: Derby
>         Type: Improvement
>   Components: Documentation
>     Reporter: Susan Cline
>     Priority: Minor
>  Attachments: derby539-take2.diff, derby539.diff, rrefsqlj20937.html
>
>  In the 'Create Index' statement documentation of the 10.1 Reference Guide (derby/docs/10.1/ref/rrefsqlj20937.html)
> this statement is made about creating indexes and constraints:
> Indexes and constraints
> Unique, primary key, and foreign key constraints generate indexes that enforce or "back"
the constraint (and are thus sometimes called backing indexes). If a column or set of columns
has a UNIQUE or PRIMARY KEY constraint on it, you can not create an index on those columns.
Derby has already created it for you with a system-generated name.
> This is true, but I think it can be expanded upon to be clearer.  A suggestion for this
is below:
> Indexes and constraints
> Unique, primary key, and foreign key constraints generate indexes that enforce or "back"
the constraint (and are thus sometimes called backing indexes).
> If a column or set of columns has a PRIMARY KEY constraint on it, you can not 
> create an index on those columns.  If a column or set of columns has a UNIQUE constraint
on it, you can not create an index on those columns, but you can create
> a PRIMARY KEY constraint on it.  Addtionally, if this is the case, a backing index
> will be created for the PRIMARY KEY constraint so two indexes will now exist on the column
or set of columns that had the UNIQUE constraint on it.
> This issue came up when I noticed that I could create a unique index on a column, then
create a PK on that column.  When I used a tool to generate DDL for the table I noticed one
constraint and two indexes on the column which didn't make sense at first when reading the
existing documentation.  With the additional information above I think it explains the real
behaviour better. 

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira


Mime
View raw message