[hibernate-issues] [Hibernate-JIRA] Commented: (HHH-3532) schema update task should look for foreign key signature

Dan Allen (JIRA) noreply at atlassian.com
Mon Mar 30 20:15:39 EDT 2009


    [ http://opensource.atlassian.com/projects/hibernate/browse/HHH-3532?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=32739#action_32739 ] 

Dan Allen commented on HHH-3532:
--------------------------------

I tested the change and it works. It would be a good idea to have a test for this, but I'm not familiar enough with the Hibernate test suite to do this in a reasonable amount of time.

Here's what needs to be done.

Create two tables, one with a foreign key to another. Use a named foreign key which would guarantee under the old behavior where the UpdateSchema task creates a duplicate foreign key. Run the UpdateSchema task. Verify that an extra foreign key is not created.

Here is a sample schema (hsqldb)

create table Person (        
    username varchar(10) not null,
    name varchar(100) not null,
    primary key (username),
    unique (username)
)   
    
create table Vehicle (
    state varchar(2) not null,
    registration varchar(8) not null,
    year integer not null,
    make varchar(50) not null,
    model varchar(50) not null,
    ownerUsername varchar(10),
    primary key (state, registration)
)   
    
alter table Vehicle
    add constraint owner
    foreign key (ownerUsername)
    references Person

> schema update task should look for foreign key signature
> --------------------------------------------------------
>
>                 Key: HHH-3532
>                 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-3532
>             Project: Hibernate Core
>          Issue Type: Improvement
>          Components: metamodel
>    Affects Versions: 3.3.1
>            Reporter: Dan Allen
>            Priority: Critical
>             Fix For: 3.2.x, 3.3.x
>
>         Attachments: HHH-3532-3.2.x.patch, HHH-3532.patch
>
>   Original Estimate: 1 hour
>  Remaining Estimate: 1 hour
>
> When the schema update task runs, it attempts to locate a foreign key in the database that matches the name provided in the Hibernate mapping information for that particular association. (The name of the foreign key is specified either in the foreign-key attribute in a mapping file or the @ForeignKey annotation). That much works fine. It's when a foreign key name is not provided, common in the case when standard JPA mappings are used, that problems arise.
> When a foreign key name is not provided, Hibernate generates a key name as follows:
> "FK" + hash code of referenced entity name + hash codes of columns
> The chances of an existing foreign key in the database using this generated name is slim to none (every DBA has their own conventions that they follow). Thus, as soon as the scheme update task hits a database under these conditions, duplicate foreign key definitions appear all over the place.
> If a foreign key name is not provided in the mapping, Hibernate should be looking instead to see if the signature of the foreign key matches that which is required to fulfill the mapping. In fact, I would even argue that the name is irrelevant and should only be used when actually *creating* the foreign key.
> Here is the existing logic in the generateSchemaUpdateScript in Configuration:
> ForeignKey fk = (ForeignKey) subIter.next();
> boolean create = tableInfo == null || tableInfo.getForeignKeyMetadata( fk.getName() ) == null;
> It should be like this instead:
> ForeignKey fk = (ForeignKey) subIter.next();
> boolean create = tableInfo == null || tableInfo.getForeignKeyMetadata( fk ) == null;
> getForeignKeyMetadata should retrieve based on the fk signature rather than the fk name.

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

        



More information about the hibernate-issues mailing list