You are viewing a plain text version of this content. The canonical link for it is here.
Posted to derby-dev@db.apache.org by "Daniel John Debrunner (JIRA)" <de...@db.apache.org> on 2005/08/26 05:15:10 UTC

[jira] Created: (DERBY-543) DatabaseMetaData.getIndexInfo provides misleading/confusing information for indexes backing constraints.

DatabaseMetaData.getIndexInfo provides misleading/confusing information for indexes backing constraints.
--------------------------------------------------------------------------------------------------------

         Key: DERBY-543
         URL: http://issues.apache.org/jira/browse/DERBY-543
     Project: Derby
        Type: Improvement
  Components: JDBC  
    Versions: 10.1.1.0, 10.0.2.1, 10.0.2.0    
    Reporter: Daniel John Debrunner
    Priority: Minor


getIndexInfo returns a row for a index backing a constraint that has no obvious relationship to the constaint. This has confused users (including myself) and is behind the DERBY-539 bug. The output when displayed in GUI tools or other mechanisms gives the appearance of an extra index existing.

Possible solutions are:

1) Include the name of the constraint in the generated name of the index. E.g if the constraint is called ORDERS_PK then the name of the backing index could be SQL20050826121455_ORDERS_PK rather than just SQL20050826121455. This is somewhat easier now all identifer names can be 128 characters. If the SQLXXX name plus the constraint name is greater than 128 characters then simple truncation should suffice.
This would provide an instant clue to developers/users where the index came from.

2) Do not display backing indexes through getIndexInfo, only user defined indexes.

1) is probably a good thing to do no matter what, 2) is probably debatable.



-- 
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


[jira] Commented: (DERBY-543) DatabaseMetaData.getIndexInfo provides misleading/confusing information for indexes backing constraints.

Posted by "Kathey Marsden (JIRA)" <de...@db.apache.org>.
    [ http://issues.apache.org/jira/browse/DERBY-543?page=comments#action_12427512 ] 
            
Kathey Marsden commented on DERBY-543:
--------------------------------------

In DERBY-1577 Jorg mentioned that the information is not only misleading but also  does not allow for differentiation between a normal index, a primary key or a foreign key.  I don't know if either of the solutions above address this issue.   


> DatabaseMetaData.getIndexInfo provides misleading/confusing information for indexes backing constraints.
> --------------------------------------------------------------------------------------------------------
>
>                 Key: DERBY-543
>                 URL: http://issues.apache.org/jira/browse/DERBY-543
>             Project: Derby
>          Issue Type: Improvement
>          Components: JDBC
>    Affects Versions: 10.1.1.0, 10.0.2.1, 10.0.2.0
>            Reporter: Daniel John Debrunner
>            Priority: Minor
>
> getIndexInfo returns a row for a index backing a constraint that has no obvious relationship to the constaint. This has confused users (including myself) and is behind the DERBY-539 bug. The output when displayed in GUI tools or other mechanisms gives the appearance of an extra index existing.
> Possible solutions are:
> 1) Include the name of the constraint in the generated name of the index. E.g if the constraint is called ORDERS_PK then the name of the backing index could be SQL20050826121455_ORDERS_PK rather than just SQL20050826121455. This is somewhat easier now all identifer names can be 128 characters. If the SQLXXX name plus the constraint name is greater than 128 characters then simple truncation should suffice.
> This would provide an instant clue to developers/users where the index came from.
> 2) Do not display backing indexes through getIndexInfo, only user defined indexes.
> 1) is probably a good thing to do no matter what, 2) is probably debatable.

-- 
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