[Hibernate-issues] [Hibernate-JIRA] Commented: (HB-540) SchemaExport drop fails if constraint names change

[<leg...@at...>]

The following comment has been added to this issue:

     Author: Tim McCune
    Created: Wed, 10 Dec 2003 5:01 PM
       Body:
So...
Do you have an alternative fix in mind, do you believe this is not a bug, or is it just impossible to fix? :)  If cascading drops only work on certain versions of Postgres, it seems like the dialect could figure that out and support it in the appropriate versions.
---------------------------------------------------------------------
View the issue:

  http://opensource.atlassian.com/projects/hibernate/secure/ViewIssue.jspa?key=HB-540


Here is an overview of the issue:
---------------------------------------------------------------------
        Key: HB-540
    Summary: SchemaExport drop fails if constraint names change
       Type: Patch

     Status: Closed
   Priority: Major
 Resolution: REJECTED

    Project: Hibernate2
 Components: 
             toolset
   Versions:
             2.1 rc1

   Assignee: 
   Reporter: Tim McCune

    Created: Wed, 10 Dec 2003 1:06 PM
    Updated: Wed, 10 Dec 2003 5:01 PM
Environment: Linux, JDK 1.4, Postgres

Description:
Hibernate doesn't use a cascading drop to drop tables.  Instead, it tries to remove constraints and then drop the table.  However, it seems to be getting the wrong constraint names.  Maybe it's trying to drop the constraints with the name that it's about to generate instead of inspecting the database meta data to get the list of existing constraint names?

I have table foo with foreign key constraint fk124fae0f5c6729a (hibernate-generated).

Running schema export produces this:

alter table foo drop constraint FK124FAE0F5C6729A;
drop table foo;
drop sequence hibernate_sequence;
create table Foo (
   id INT8 not null,
   bar VARCHAR(255) not null,
   primary key (id)
);
ERROR - Unsuccessful: create table Foo (id INT8 not null, bar VARCHAR(255) not null, primary key (id))
ERROR - ERROR:  Relation 'foo' already exists

Notice that the constraint name that SchemaExport is trying to drop doesn't even exist.  SchemaExport should either get the constraint names from the database metadata or just do a cascading drop.  I'm attaching a patch to do the cascade, which is what I'm using locally.


---------------------------------------------------------------------
JIRA INFORMATION:
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

If you want more information on JIRA, or have a bug to report see:
   http://www.atlassian.com/software/jira