Details

    • Type: Bug Bug
    • Status: Closed
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: 3.2.0.cr2
    • Fix Version/s: 4.3.0.Beta1, 4.2.1
    • Component/s: None
    • Labels:
      None
    • Bug Testcase Reminder (view):

      Bug reports should generally be accompanied by a test case!

    • Last commented by a user?:
      true

      Description

      I'm following up form HHH-355, basically, foreign keys with names that go well beying 30 chars of lenght.
      I know how to reproduce the problem, and if required I can provide a test case, but let me point you to
      the code path that generates the problem first (and see if that's enough).

      I do have a hierarchy mapped with the table per class approach, with intermediate abstract classes.
      Leaf classes of this hierarchy are apparently managed in hibernate usign the DenormalizedTable class. The code that generates the foreign keys for this class is:

      public void createForeignKeys() {
      includedTable.createForeignKeys();
      Iterator iter = includedTable.getForeignKeyIterator();
      while ( iter.hasNext() ) {
      ForeignKey fk = (ForeignKey) iter.next();
      createForeignKey(
      fk.getName() + Integer.toHexString( getName().hashCode() ),
      fk.getColumns(),
      fk.getReferencedEntityName()
      );
      }
      }

      As you can see, it gets the foreign key name of the contained class, and appends another hexstring. This name can become really long if the
      hierarchy has many levels. In my case I get names as long as: FK14F780C41886F83e63ff56e238e868d73630607.

      Let me know if this is enough or if you need more information.
      Ah, another problem is that the appended foreign parts do not pass thru the naming strategy, and as you can see they're not
      uppercase in my sample (my naming strategy does uppercase everything)

        Issue Links

          Activity

          Hide
          Dirk Lachowski added a comment -

          Any news on this?

          Show
          Dirk Lachowski added a comment - Any news on this?
          Hide
          Santiago Ennis added a comment -

          Faced the same problem last night...

          DenormalizedTable#createForeignKeys() generates longer and longer ForeignKey names; which results in "identifier is too long" ERROR while schema export. I think the method generated longer names when there are three or more entities in the inheritance hierarchy and the InheritanceType is TABLE_PER_CLASS. If there are three or more entities in the inheritance hierarchy but the InheritanceType is NOT TABLE_PER_CLASS, SchemaExport does not show any errors.

          See the output of SchemaExportTest.java (test-case attached) :-
          ===============================================================
          SchemaExport:262 - exporting generated schema to database

          SchemaExport:415 - drop table employee cascade constraints
          SchemaExport:415 - drop table organization cascade constraints
          SchemaExport:415 - drop table software_developer cascade constraints
          SchemaExport:415 - drop table users cascade constraints

          SchemaExport:415 - create table employee (id varchar2(255 char) not null, organization_entity_id varchar2(255 char) not null, user_name varchar2(255 char) not null, first_name varchar2(255 char), last_name varchar2(255 char), primary key (id))
          SchemaExport:415 - create table organization (entity_id varchar2(255 char) not null, name varchar2(255 char) not null unique, primary key (entity_id))
          SchemaExport:415 - create table software_developer (id varchar2(255 char) not null, organization_entity_id varchar2(255 char) not null, user_name varchar2(255 char) not null, first_name varchar2(255 char), last_name varchar2(255 char), core_skill varchar2(255 char), primary key (id))
          SchemaExport:415 - create table users (id varchar2(255 char) not null, organization_entity_id varchar2(255 char) not null, user_name varchar2(255 char) not null, primary key (id))

          SchemaExport:415 - alter table employee add constraint FK4692D487849C3FF6a68e084722e6ae foreign key (organization_entity_id) references organization
          SchemaExport:386 - Unsuccessful: alter table employee add constraint FK4692D487849C3FF6a68e084722e6ae foreign key (organization_entity_id) references organization
          SchemaExport:387 - ORA-00972: identifier is too long

          SchemaExport:415 - alter table software_developer add constraint FK4692D487849C3FF6a68e084722e6aea409f32 foreign key (organization_entity_id) references organization
          SchemaExport:386 - Unsuccessful: alter table software_developer add constraint FK4692D487849C3FF6a68e084722e6aea409f32 foreign key (organization_entity_id) references organization
          SchemaExport:387 - ORA-00972: identifier is too long

          SchemaExport:415 - alter table users add constraint FK4692D487849C3FF6a68e08 foreign key (organization_entity_id) references organization

          SchemaExport:281 - schema export complete
          ==========================================================

          One more thing...

          Though the SchemaExport completed with errors, the log says, "schema export complete" and the level of log is INFO.
          IMHO, the message should be "schema export complete WITH ERRORS" and the log level should be ERROR(or WARN).

          Show
          Santiago Ennis added a comment - Faced the same problem last night... DenormalizedTable#createForeignKeys() generates longer and longer ForeignKey names; which results in "identifier is too long" ERROR while schema export. I think the method generated longer names when there are three or more entities in the inheritance hierarchy and the InheritanceType is TABLE_PER_CLASS. If there are three or more entities in the inheritance hierarchy but the InheritanceType is NOT TABLE_PER_CLASS, SchemaExport does not show any errors. See the output of SchemaExportTest.java (test-case attached) :- =============================================================== SchemaExport:262 - exporting generated schema to database SchemaExport:415 - drop table employee cascade constraints SchemaExport:415 - drop table organization cascade constraints SchemaExport:415 - drop table software_developer cascade constraints SchemaExport:415 - drop table users cascade constraints SchemaExport:415 - create table employee (id varchar2(255 char) not null, organization_entity_id varchar2(255 char) not null, user_name varchar2(255 char) not null, first_name varchar2(255 char), last_name varchar2(255 char), primary key (id)) SchemaExport:415 - create table organization (entity_id varchar2(255 char) not null, name varchar2(255 char) not null unique, primary key (entity_id)) SchemaExport:415 - create table software_developer (id varchar2(255 char) not null, organization_entity_id varchar2(255 char) not null, user_name varchar2(255 char) not null, first_name varchar2(255 char), last_name varchar2(255 char), core_skill varchar2(255 char), primary key (id)) SchemaExport:415 - create table users (id varchar2(255 char) not null, organization_entity_id varchar2(255 char) not null, user_name varchar2(255 char) not null, primary key (id)) SchemaExport:415 - alter table employee add constraint FK4692D487849C3FF6a68e084722e6ae foreign key (organization_entity_id) references organization SchemaExport:386 - Unsuccessful: alter table employee add constraint FK4692D487849C3FF6a68e084722e6ae foreign key (organization_entity_id) references organization SchemaExport:387 - ORA-00972: identifier is too long SchemaExport:415 - alter table software_developer add constraint FK4692D487849C3FF6a68e084722e6aea409f32 foreign key (organization_entity_id) references organization SchemaExport:386 - Unsuccessful: alter table software_developer add constraint FK4692D487849C3FF6a68e084722e6aea409f32 foreign key (organization_entity_id) references organization SchemaExport:387 - ORA-00972: identifier is too long SchemaExport:415 - alter table users add constraint FK4692D487849C3FF6a68e08 foreign key (organization_entity_id) references organization SchemaExport:281 - schema export complete ========================================================== One more thing... Though the SchemaExport completed with errors, the log says, "schema export complete" and the level of log is INFO. IMHO, the message should be "schema export complete WITH ERRORS" and the log level should be ERROR(or WARN).
          Hide
          Santiago Ennis added a comment -

          TestCase too generate "identifier too long" error.

          Show
          Santiago Ennis added a comment - TestCase too generate "identifier too long" error.
          Hide
          Brett Meyer added a comment -

          I posed the following questions to the hibernate-dev mailing list – figured I'd try here as well:

          I've been working a bit on HHH-1904 [1] – truncating identifiers based on a maximum length provided by the Dialect. As an example, a quick test that has a variety of uniques produced the constraint names in [2].

          My initial strategy took metamodel's ObjectName and modified it to automatically handle name segments and quoting. For example, `UK_FooClass_1` would be broken down into "UK", "FooClass", and "1" segments, "_" would be the delimiter, and quoting would be added back in whenever necessary.

          I'm trying to find a decent strategy for truncating the name, either as a whole or with each segment. The problem that I keep running into is that it's going to be difficult to dynamically ensure that naming collisions are avoided. For example, if embedded classes are used as entities, you could have 2 constraint names like "UK_OuterClass$InnerClassA_1" and "UK_OuterClass$InnerClassB_1". If the middle segment is truncated at or before the "$", it won't work.

          Should we try to enforce a rule that the "unique bits" be in a specific segment or position? Alternatively, "truncate" by hashing the name (as we do with FK names now – of course, no human readability)? Any other ideas?

          Admittedly, I may be overthinking it. It's primarily the Hibernate-generated constraint names that we need to worry about...

          [1] https://hibernate.onjira.com/browse/HHH-1904
          [2] https://gist.github.com/brmeyer/bfbc78c770904cc6fca8

          Show
          Brett Meyer added a comment - I posed the following questions to the hibernate-dev mailing list – figured I'd try here as well: I've been working a bit on HHH-1904 [1] – truncating identifiers based on a maximum length provided by the Dialect. As an example, a quick test that has a variety of uniques produced the constraint names in [2] . My initial strategy took metamodel's ObjectName and modified it to automatically handle name segments and quoting. For example, `UK_FooClass_1` would be broken down into "UK", "FooClass", and "1" segments, "_" would be the delimiter, and quoting would be added back in whenever necessary. I'm trying to find a decent strategy for truncating the name, either as a whole or with each segment. The problem that I keep running into is that it's going to be difficult to dynamically ensure that naming collisions are avoided. For example, if embedded classes are used as entities, you could have 2 constraint names like "UK_OuterClass$InnerClassA_1" and "UK_OuterClass$InnerClassB_1". If the middle segment is truncated at or before the "$", it won't work. Should we try to enforce a rule that the "unique bits" be in a specific segment or position? Alternatively, "truncate" by hashing the name (as we do with FK names now – of course, no human readability)? Any other ideas? Admittedly, I may be overthinking it. It's primarily the Hibernate-generated constraint names that we need to worry about... [1] https://hibernate.onjira.com/browse/HHH-1904 [2] https://gist.github.com/brmeyer/bfbc78c770904cc6fca8
          Hide
          Brett Meyer added a comment -

          ForeignKeys and UniqueKeys are now created using random characters and a prefix. Regardless of the Dialect, the length will not exceed 30. Of course, explicitly-given constraint names trump all of this.

          Show
          Brett Meyer added a comment - ForeignKeys and UniqueKeys are now created using random characters and a prefix. Regardless of the Dialect, the length will not exceed 30. Of course, explicitly-given constraint names trump all of this.
          Hide
          Brett Meyer added a comment -

          Heads up: we're rethinking the randomly-generated name decision in HHH-8217. We'll still ensure that identifiers are short enough.

          Show
          Brett Meyer added a comment - Heads up: we're rethinking the randomly-generated name decision in HHH-8217 . We'll still ensure that identifiers are short enough.
          Show
          Brett Meyer added a comment - https://bugzilla.redhat.com/show_bug.cgi?id=979098 https://bugzilla.redhat.com/show_bug.cgi?id=979103

            People

            • Votes:
              6 Vote for this issue
              Watchers:
              9 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved:

                Development