OpenJPA
  1. OpenJPA
  2. OPENJPA-430

Automatically remove hungarian notation from column names.

    Details

    • Type: New Feature New Feature
    • Status: Closed
    • Priority: Minor Minor
    • Resolution: Fixed
    • Affects Version/s: 1.1.0
    • Fix Version/s: 1.1.0
    • Component/s: None
    • Labels:
      None

      Description

      Add a flag to switch on/off automatic truncation of hungarian fields when automatically generating column names.

      Fields such as mFoobar and strBarFoo would become columns named* foobar and barfoo respectivly.

      *Current naming DBDictionary rules would still apply.

      1. OPENJPA-430-DOCS.patch
        3 kB
        Ben Short
      2. OPENJPA-430.patch
        9 kB
        Ben Short

        Activity

        Hide
        Ben Short added a comment -

        A patch that adds this feature.

        Switch on using property removeHungarianNotation=true

        Show
        Ben Short added a comment - A patch that adds this feature. Switch on using property removeHungarianNotation=true
        Hide
        Kevin Sutter added a comment -

        Documentation updates as well? This is especially important when adding new properties. Thanks!

        Show
        Kevin Sutter added a comment - Documentation updates as well? This is especially important when adding new properties. Thanks!
        Hide
        Ben Short added a comment -

        Can the current patch be removed and I'll replace with one that updates the documentation?

        Show
        Ben Short added a comment - Can the current patch be removed and I'll replace with one that updates the documentation?
        Hide
        Patrick Linskey added a comment -

        I already submitted the old patch; just update your environment and add docs (in the openjpa-project dir) and add the new diff.

        Thanks for the work on this feature, btw.

        Show
        Patrick Linskey added a comment - I already submitted the old patch; just update your environment and add docs (in the openjpa-project dir) and add the new diff. Thanks for the work on this feature, btw.
        Hide
        Ben Short added a comment -

        Patch that provides documentation for this feature.

        Show
        Ben Short added a comment - Patch that provides documentation for this feature.
        Hide
        Patrick Linskey added a comment -

        FTR, this was addressed in r592319 originally. That svn commit did not get associated for some reason.

        Show
        Patrick Linskey added a comment - FTR, this was addressed in r592319 originally. That svn commit did not get associated for some reason.
        Hide
        Albert Lee added a comment -

        This feature intended to remove/truncate fields using the Hungarian notations to the form as described in the original append. However the following changes seems to do more than just transforming a field, i.e. " name = dict.getValidColumnName(name, local);"

        — openjpa/trunk/openjpa-persistence-jdbc/src/main/java/org/apache/openjpa/persistence/jdbc/PersistenceMappingDefaults.java 2007/11/06 07:33:44 592318
        +++ openjpa/trunk/openjpa-persistence-jdbc/src/main/java/org/apache/openjpa/persistence/jdbc/PersistenceMappingDefaults.java 2007/11/06 07:36:55 592319
        @@ -181,6 +181,12 @@
        if (target instanceof Column)

        { if (elem) name = vm.getFieldMapping().getName(); + + if (isRemoveHungarianNotation()) + name = removeHungarianNotation(name); + + name = dict.getValidColumnName(name, local); + col.setName(name + "_" + ((Column) target).getName()); }

        }

        This change has some undesired consequence that broke some previous application. Specifically, if the field is a keyword (e.g. identity), a digit is appended to the name so a foreign key column is changed from, e.g. identity_id to identity0_id. If an application already has a table defined and no automatic synchronize mapping is specified, the application will fail. This name augmentation is not warranted because even though identity is a keyword but the combined foreign key column identity_id is NOT a keyword.

        My question is what is the intended purpose of this name transformation and how does it play into the "remove Hungarian Notation" feature?

        As Patrick mentioned in his last note, some function in Kodo test also failed. Can this name transformation be removed ?

        Albert Lee.

        Show
        Albert Lee added a comment - This feature intended to remove/truncate fields using the Hungarian notations to the form as described in the original append. However the following changes seems to do more than just transforming a field, i.e. " name = dict.getValidColumnName(name, local);" — openjpa/trunk/openjpa-persistence-jdbc/src/main/java/org/apache/openjpa/persistence/jdbc/PersistenceMappingDefaults.java 2007/11/06 07:33:44 592318 +++ openjpa/trunk/openjpa-persistence-jdbc/src/main/java/org/apache/openjpa/persistence/jdbc/PersistenceMappingDefaults.java 2007/11/06 07:36:55 592319 @@ -181,6 +181,12 @@ if (target instanceof Column) { if (elem) name = vm.getFieldMapping().getName(); + + if (isRemoveHungarianNotation()) + name = removeHungarianNotation(name); + + name = dict.getValidColumnName(name, local); + col.setName(name + "_" + ((Column) target).getName()); } } This change has some undesired consequence that broke some previous application. Specifically, if the field is a keyword (e.g. identity), a digit is appended to the name so a foreign key column is changed from, e.g. identity_id to identity0_id. If an application already has a table defined and no automatic synchronize mapping is specified, the application will fail. This name augmentation is not warranted because even though identity is a keyword but the combined foreign key column identity_id is NOT a keyword. My question is what is the intended purpose of this name transformation and how does it play into the "remove Hungarian Notation" feature? As Patrick mentioned in his last note, some function in Kodo test also failed. Can this name transformation be removed ? Albert Lee.
        Hide
        Pinaki Poddar added a comment -

        This feature should be removed because

        A) MappingDefaults is inappropriate place for introduction of a rather specific naming semantics. An extended user-defined (or pre-packaged) plug-in should do it.
        B) It broke my code several times Especially when Column names matched database reserved words.

        Show
        Pinaki Poddar added a comment - This feature should be removed because A) MappingDefaults is inappropriate place for introduction of a rather specific naming semantics. An extended user-defined (or pre-packaged) plug-in should do it. B) It broke my code several times Especially when Column names matched database reserved words.

          People

          • Assignee:
            Unassigned
            Reporter:
            Ben Short
          • Votes:
            0 Vote for this issue
            Watchers:
            0 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Development