Torque
  1. Torque
  2. TORQUE-44

Column names in generated classes are uppercase

    Details

    • Type: Bug Bug
    • Status: Closed
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: 3.1, 3.1.1, 3.2
    • Fix Version/s: 3.3
    • Component/s: Generator
    • Labels:
      None

      Description

      The generator creates constants for the column names in tables. The content of this constants uses upper cases.

      For example if you have a table like:

      <table name="address">
      <column name="class" javaName="aClass" primaryKey="true" required="true" size="2" type="CHAR"/>
      <column name="id" primaryKey="true" required="true" size="30" type="VARCHAR"/>
      <column name="position" primaryKey="true" required="true" type="INTEGER"/>
      <column name="name1" size="50" type="VARCHAR"/>
      <column name="name2" size="50" type="VARCHAR"/>
      <column name="name3" size="50" type="VARCHAR"/>
      <column name="street" size="50" type="VARCHAR"/>
      <column name="zipcode" size="25" type="VARCHAR"/>
      <column name="city" size="60" type="VARCHAR"/>
      <column name="phone" size="40" type="VARCHAR"/>
      <column name="phone2" size="40" type="VARCHAR"/>
      <column name="country" size="200" type="VARCHAR"/>
      <column name="state" size="200" type="VARCHAR"/>
      <column name="fax" size="40" type="VARCHAR"/>
      <column name="email" size="150" type="VARCHAR"/>
      </table>

      The generator creates in the corresponding BaseAddressPeer the following constants.

      ...
      static
      {
      CLASS = "address.CLASS";
      ID = "address.ID";
      POSITION = "address.POSITION";
      NAME1 = "address.NAME1";
      NAME2 = "address.NAME2";
      NAME3 = "address.NAME3";
      STREET = "address.STREET";
      ZIPCODE = "address.ZIPCODE";
      CITY = "address.CITY";
      PHONE = "address.PHONE";
      PHONE2 = "address.PHONE2";
      COUNTRY = "address.COUNTRY";
      STATE = "address.STATE";
      FAX = "address.FAX";
      EMAIL = "address.EMAIL";
      ....

      but this variables should be for example "address.email".
      The AddressMapBuilder.doBuild() method creates the same uppercase mapping:

      public void doBuild() throws TorqueException {
      ...
      dbMap.addTable("address");
      TableMap tMap = dbMap.getTable("address");

      tMap.setPrimaryKeyMethod("none");
      tMap.addPrimaryKey("address.CLASS", "" );
      tMap.addPrimaryKey("address.ID", "" );
      tMap.addPrimaryKey("address.POSITION", new Integer(0) );
      tMap.addColumn("address.NAME1", "", 50 );
      tMap.addColumn("address.NAME2", "", 50 );
      tMap.addColumn("address.NAME3", "", 50 );
      tMap.addColumn("address.STREET", "", 50 );
      tMap.addColumn("address.ZIPCODE", "", 25 );
      tMap.addColumn("address.CITY", "", 60 );
      tMap.addColumn("address.PHONE", "", 40 );
      tMap.addColumn("address.PHONE2", "", 40 );
      tMap.addColumn("address.COUNTRY", "", 200 );
      tMap.addColumn("address.STATE", "", 200 );
      tMap.addColumn("address.FAX", "", 40 );
      tMap.addColumn("address.EMAIL", "", 150 );
      }

      1. Torque-44.zip
        50 kB
        CG Monroe
      2. patch.txt
        1 kB
        Thoralf Rickert

        Activity

        Hide
        Thomas Fox added a comment -

        Applied Greg's patch.

        Show
        Thomas Fox added a comment - Applied Greg's patch.
        Hide
        Thomas Fox added a comment -

        reopened because this needs to be made configurable

        Show
        Thomas Fox added a comment - reopened because this needs to be made configurable
        Hide
        CG Monroe added a comment -

        Change Log for "New and Improved" Torque-44 patch.

        Overview

        This patch will make Torque OM Peer class column constant use values with the
        exact same case as the XML name= attribute.

        However, the original upper case column name constants can be produced by
        adding the following build property to your generator property settings:

        torque.deprecated.uppercasePeer = true

        In addition, all references in the templates to Peer column constants have been
        converted to use a new getPeerJavaName method in the Column generator object.
        This was done for several reasons:

        To allow columns to be named TABLE_NAME or DATABASE_NAME (Column constant
        names for these are modified to _TABLE_NAME and _DATABASE_NAME)

        To lay some ground work for future support of delimited columns

        To centralize the naming convention into an easily overridable class rather
        than spread over several different templates.

        Also, the templates use the existing getFullyQualifiedName method to set the Column
        constant values. (So it can be overridden by in the class if desired).

        Finally, the properties reference and Database Layout How To have been updated.

        File mods:

        Column.java

        Added getPeerJavaName() method with handling for renaming TABLE_NAME and
        COLUMN_NAME columns.

        properties-reference.xml

        Added torque.deprecated.uppercasePeer property at the bottom of the Template
        variables section

        database-layout-howto.xml

        Added some info about problems using delimited column names and the special
        handling of TABLE_NAME and DATABASE_NAME columns.

        MapBuilder.vm, Object.vm, ObjectWithManager.vm, Peer.vm

        Peer name references updated.
        Some unused SET statements removed.
        Support for new and old methods in generation

        Show
        CG Monroe added a comment - Change Log for "New and Improved" Torque-44 patch. Overview This patch will make Torque OM Peer class column constant use values with the exact same case as the XML name= attribute. However, the original upper case column name constants can be produced by adding the following build property to your generator property settings: torque.deprecated.uppercasePeer = true In addition, all references in the templates to Peer column constants have been converted to use a new getPeerJavaName method in the Column generator object. This was done for several reasons: To allow columns to be named TABLE_NAME or DATABASE_NAME (Column constant names for these are modified to _TABLE_NAME and _DATABASE_NAME) To lay some ground work for future support of delimited columns To centralize the naming convention into an easily overridable class rather than spread over several different templates. Also, the templates use the existing getFullyQualifiedName method to set the Column constant values. (So it can be overridden by in the class if desired). Finally, the properties reference and Database Layout How To have been updated. File mods: Column.java Added getPeerJavaName() method with handling for renaming TABLE_NAME and COLUMN_NAME columns. properties-reference.xml Added torque.deprecated.uppercasePeer property at the bottom of the Template variables section database-layout-howto.xml Added some info about problems using delimited column names and the special handling of TABLE_NAME and DATABASE_NAME columns. MapBuilder.vm, Object.vm, ObjectWithManager.vm, Peer.vm Peer name references updated. Some unused SET statements removed. Support for new and old methods in generation
        Hide
        CG Monroe added a comment -

        Not preserviing case probably was a poor choice from a long time ago. But it is the DEFACTO Torque API standard. IMHO, forcing changes in a point revision that dictate major API changes and demostrated breaking of existing application code is a major NO-NO. A point revision changes like this should follow the physician credo of "Do no harm".

        You might say, well it's just my code... but a lot of folks don't/won't use dev level code, so what happens when it gets released? Is this standard for Torque to tell folk they have to rewrite code that's worked with every version of Torque since before 3.0?

        One thing to consider is that the SQL Standard clearly states that column names are to be case insensitive unless delimited. So keeping the upper case as the DEFACTO standard only effects SQL servers that are non-standard or in the case of some server, not configured to support the standard.

        Yes, supporting more DB server modes is good. Yes, maintaining case from XML is probably a good thing in some situation (but not all). The point is that this fix has problems and needs to be re-thought/re-done to "do no harm".

        Show
        CG Monroe added a comment - Not preserviing case probably was a poor choice from a long time ago. But it is the DEFACTO Torque API standard. IMHO, forcing changes in a point revision that dictate major API changes and demostrated breaking of existing application code is a major NO-NO. A point revision changes like this should follow the physician credo of "Do no harm". You might say, well it's just my code... but a lot of folks don't/won't use dev level code, so what happens when it gets released? Is this standard for Torque to tell folk they have to rewrite code that's worked with every version of Torque since before 3.0? One thing to consider is that the SQL Standard clearly states that column names are to be case insensitive unless delimited. So keeping the upper case as the DEFACTO standard only effects SQL servers that are non-standard or in the case of some server, not configured to support the standard. Yes, supporting more DB server modes is good. Yes, maintaining case from XML is probably a good thing in some situation (but not all). The point is that this fix has problems and needs to be re-thought/re-done to "do no harm".
        Hide
        Thomas Fox added a comment -

        I do not agree that one should not use the internal constants; they are exported as public constants and are thus part of the API. However, I still think that keeping the case from the schema.xml is good because it enlarges the set od supported databases. On the other hand, there is no logical reason for transforming the constants to uppercase, except for that "it was like this in the past".

        I am afraid that in order to create a consistent framework, one sometimes has to make changes that may impair backward compatibility. As there are easy workarounds in this case (like changing all affected names in the schema.xml to uppercase), I thought that this change would be ok in a minor version change. Given that we probably will not have am ajaor version change in another year, I still think this decision was ok.

        Show
        Thomas Fox added a comment - I do not agree that one should not use the internal constants; they are exported as public constants and are thus part of the API. However, I still think that keeping the case from the schema.xml is good because it enlarges the set od supported databases. On the other hand, there is no logical reason for transforming the constants to uppercase, except for that "it was like this in the past". I am afraid that in order to create a consistent framework, one sometimes has to make changes that may impair backward compatibility. As there are easy workarounds in this case (like changing all affected names in the schema.xml to uppercase), I thought that this change would be ok in a minor version change. Given that we probably will not have am ajaor version change in another year, I still think this decision was ok.
        Hide
        Thoralf Rickert added a comment -

        I think, the uppercase table names was a bug. It looks like a copy&paste error. So, if you wish to have a switch, it should be the other way round - enable the switch to have uppercase table names.

        But I'm not sure if it is useful to have such a switch - we have a lot of them. Where is the problem in your example? If you compare torque table name constants with a database table cell content you can use methods to make the constants uppercase (in SQL or in Java). Of course - you have to change your code. But I think, you shouldn't use the internal Torque table name constants. I think, they are just for generating appropriate SQL query statements.

        Show
        Thoralf Rickert added a comment - I think, the uppercase table names was a bug. It looks like a copy&paste error. So, if you wish to have a switch, it should be the other way round - enable the switch to have uppercase table names. But I'm not sure if it is useful to have such a switch - we have a lot of them. Where is the problem in your example? If you compare torque table name constants with a database table cell content you can use methods to make the constants uppercase (in SQL or in Java). Of course - you have to change your code. But I think, you shouldn't use the internal Torque table name constants. I think, they are just for generating appropriate SQL query statements.
        Hide
        CG Monroe added a comment -

        I recently updated my local copy of Torque with the SVN head and started testing with it. This update causes a lot of grief in my my application.

        Specifically, I have a table that allows site admins to defines what columns of a user information table will be
        display (and in what order) to the site users. E.g. Name,Title, E-mail, and the like.

        Changing the case of the Peer column names means the column names generated with the OLD Peer names don't match the New peer names.

        IMHO, Changes like this that change the base stuff in Torque should be optional generation and not standard.

        Show
        CG Monroe added a comment - I recently updated my local copy of Torque with the SVN head and started testing with it. This update causes a lot of grief in my my application. Specifically, I have a table that allows site admins to defines what columns of a user information table will be display (and in what order) to the site users. E.g. Name,Title, E-mail, and the like. Changing the case of the Peer column names means the column names generated with the OLD Peer names don't match the New peer names. IMHO, Changes like this that change the base stuff in Torque should be optional generation and not standard.
        Hide
        Thomas Fox added a comment -

        Committed patch to svn; also changed test cases for setByPeerName methods and for checking preservation of xml order.

        Show
        Thomas Fox added a comment - Committed patch to svn; also changed test cases for setByPeerName methods and for checking preservation of xml order.
        Hide
        Thomas Fox added a comment -

        The patch would change case changes in the arguments for the generated setByPeerName() method. However, as this was recently added, I would think this ok.

        Show
        Thomas Fox added a comment - The patch would change case changes in the arguments for the generated setByPeerName() method. However, as this was recently added, I would think this ok.
        Hide
        Thomas Fox added a comment -

        Just for the record: The problem occured using sybase, which is case sensitive on column names.
        I have checked that the generator preserves case in the sql scripts, so ut should also preserve case in the java constants.

        Show
        Thomas Fox added a comment - Just for the record: The problem occured using sybase, which is case sensitive on column names. I have checked that the generator preserves case in the sql scripts, so ut should also preserve case in the java constants.
        Hide
        Thoralf Rickert added a comment -

        The problem is that the generator uses the variable $cup=$col.Name.toUpperCase() for the name of the constant and for the content of it. The patch changes the Peer and the MapBuilder template. Hope it works.

        Show
        Thoralf Rickert added a comment - The problem is that the generator uses the variable $cup=$col.Name.toUpperCase() for the name of the constant and for the content of it. The patch changes the Peer and the MapBuilder template. Hope it works.

          People

          • Assignee:
            Thomas Fox
            Reporter:
            Thoralf Rickert
          • Votes:
            0 Vote for this issue
            Watchers:
            0 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Development