Hibernate ORM
  1. Hibernate ORM
  2. HHH-8217

Make generated constraint names short and non-random

    Details

    • Type: Improvement Improvement
    • Status: Closed
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: None
    • Fix Version/s: 4.2.2, 4.3.0.Beta3
    • Component/s: None
    • Labels:
      None
    • Last commented by a user?:
      true

      Description

      HHH-1904 cause non-explicitly named constraints to use randomly generated hex characters. Instead, it would be better to go back to a scheme that uses the table and column names, allowing naming consistency and control over the name length.

      Concat the table and column names, md5 it, then convert the hex to base 35 (full alphanumeric). This guarantees a < 30 character hash.

        Issue Links

          Activity

          Hide
          Aurelien DROUARD added a comment -

          Michail Nikolaev look at HHH-8269 fixed in 4.2.3
          workaround for long FK : don't use union-subclass mapping.

          Show
          Aurelien DROUARD added a comment - Michail Nikolaev look at HHH-8269 fixed in 4.2.3 workaround for long FK : don't use union-subclass mapping.
          Show
          Brett Meyer added a comment - https://bugzilla.redhat.com/show_bug.cgi?id=979098 https://bugzilla.redhat.com/show_bug.cgi?id=979103
          Hide
          Nick Pratt added a comment -

          While I noted that backwards compatibility was mentioned in the bugzilla entries, this is a real pain. Now if mappings are updated on a pre-existing DB, Hibernate generates a new form of the FK constraint name, fails to drop it (because it doesnt exist) and then fails to execute the new add constraint since an existing constraint exists on the same columns, just by a different name.

          Show
          Nick Pratt added a comment - While I noted that backwards compatibility was mentioned in the bugzilla entries, this is a real pain. Now if mappings are updated on a pre-existing DB, Hibernate generates a new form of the FK constraint name, fails to drop it (because it doesnt exist) and then fails to execute the new add constraint since an existing constraint exists on the same columns, just by a different name.
          Hide
          Brett Meyer added a comment -

          Nick Pratt, HHH-8224 will eventually help with this – the ability to define your own naming strategy for constraints. However, the situation you describe is exactly why I prefer to explicitly name my constraints in the mappings. Otherwise, we have to rely on something unique for the generated names, and realistically the table and column mappings themselves are the only solution.

          Show
          Brett Meyer added a comment - Nick Pratt , HHH-8224 will eventually help with this – the ability to define your own naming strategy for constraints. However, the situation you describe is exactly why I prefer to explicitly name my constraints in the mappings. Otherwise, we have to rely on something unique for the generated names, and realistically the table and column mappings themselves are the only solution.
          Hide
          Nick Pratt added a comment -

          Understood - but this functionality had been in place for a long time, and while I appreciate the move to a reliably generated name, it would have been really helpful to have some way to migrate the old names to the new ones (even a dialect override) - I'm faced with the task of manually finding and dropping hundreds of "old" constraints and then using SchemaUpdate to update the constraints (since some have been changed - additional cols added to some unique constraints etc.) as well as fixing the names. While Steve Ebersole very kindly pointed out that this is an unsupported tool, it's highly useful in the dev process and is widely used early in the dev process.

          Show
          Nick Pratt added a comment - Understood - but this functionality had been in place for a long time, and while I appreciate the move to a reliably generated name, it would have been really helpful to have some way to migrate the old names to the new ones (even a dialect override) - I'm faced with the task of manually finding and dropping hundreds of "old" constraints and then using SchemaUpdate to update the constraints (since some have been changed - additional cols added to some unique constraints etc.) as well as fixing the names. While Steve Ebersole very kindly pointed out that this is an unsupported tool, it's highly useful in the dev process and is widely used early in the dev process.

            People

            • Votes:
              0 Vote for this issue
              Watchers:
              8 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved:

                Development