Torque
  1. Torque
  2. TORQUE-168

Use Objects instead of Strings for Column constants in Peers and Criteria

    Details

    • Type: Improvement Improvement
    • Status: Closed
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: None
    • Fix Version/s: 4.0-beta1
    • Component/s: None
    • Labels:
      None

      Description

      Currently, column constants in Peers are Strings, and Criterias are constructed by using String column names.
      This means that code to parse column information (remove/add database/schema name, table name, remove SQL functions etc) is distributed across the code which is not very maintainable.

      Instead, column constants should be objects, which hold at least the following information

      • unqualified column name
      • table name (or reference to table)
      • database/schema name, if any, or reference to default database/schema name, if any
      • sql expression (in case it is different from [database/schema.]tableName.columnName, e.g. "cast id as varchar2(30)" in oracle)

      There should be a constructor taking a string input, which then tries to parse the given tsring and extract the above information from the string.

        Activity

        Hide
        Thomas Fox added a comment - - edited

        Implementation plan:

        • create an interface Column with the methods getColumnName(), getTableName() and getSqlExpression()
        • replace all occurances where String column names are used by the column interface. This will e.g. be the add, and, or ... methods in Criteria, the key in the ColumnValues object.
        • make ColumnMap implement the Column interface. This is straightforward, the default schema name can be retrieved from database.getSchema()
        • create a simple implementation of the Column interface with the needed getters and corresponding setters. This can be used if users want to create their own Column instance.

        The question remains open how to access the correct ColumnMap instances from the peer classes to fill the column constants.

        Show
        Thomas Fox added a comment - - edited Implementation plan: create an interface Column with the methods getColumnName(), getTableName() and getSqlExpression() replace all occurances where String column names are used by the column interface. This will e.g. be the add, and, or ... methods in Criteria, the key in the ColumnValues object. make ColumnMap implement the Column interface. This is straightforward, the default schema name can be retrieved from database.getSchema() create a simple implementation of the Column interface with the needed getters and corresponding setters. This can be used if users want to create their own Column instance. The question remains open how to access the correct ColumnMap instances from the peer classes to fill the column constants.
        Hide
        Thomas Fox added a comment -

        The column maps will be accessed as follows:

        • Each generated tableMapBuilder will have constants exposing the column maps. The names for the constants will be the same as the names for the column constants in the peer classes.
        • Each generated tableMapBuilder will have a static initializer block to initialize the column constants (i.e builds the database map). This removes the need for caching the map builders in the TorqueInstance.

        Further implementation details:

        • remove the getMapBuilder, getMapBuilders and registerMapBuilder methods from the Torque and TorqueInstance classes because they are no longer needed.
        • For the ease of exception handling in the static initializer block, remove the "throws TorqueException" from the two methods TorqueInstance.getDatabaseMap(String) and the delegate method in Torque. Replace the Torque Exception which is thrown on passing null in TorqueInstance.getDatabaseMap(String) by a NullPointerException.
        • Currently the primaryKeyMethodInfo in the TableMap is set by querying the id method type from the database adapter. This is problematic since this needs Torque to be initialized to perform the query. The solution is to put a map of id method types to primaryKeyMethodInfos into the Table map, so querying the id method type can be done when it is really necessary.
        • create a DatabaseMapBuilder for each database which contains all tables in the database
        • implement an "append" strategy for exsiting target files in the generator for building the DatabaseMapBuilder from more than one schema file
        • the table map builders do no longer implement the MapBuilder interface
        • remove the MapBuilder interface since it is no longer needed
        Show
        Thomas Fox added a comment - The column maps will be accessed as follows: Each generated tableMapBuilder will have constants exposing the column maps. The names for the constants will be the same as the names for the column constants in the peer classes. Each generated tableMapBuilder will have a static initializer block to initialize the column constants (i.e builds the database map). This removes the need for caching the map builders in the TorqueInstance. Further implementation details: remove the getMapBuilder, getMapBuilders and registerMapBuilder methods from the Torque and TorqueInstance classes because they are no longer needed. For the ease of exception handling in the static initializer block, remove the "throws TorqueException" from the two methods TorqueInstance.getDatabaseMap(String) and the delegate method in Torque. Replace the Torque Exception which is thrown on passing null in TorqueInstance.getDatabaseMap(String) by a NullPointerException. Currently the primaryKeyMethodInfo in the TableMap is set by querying the id method type from the database adapter. This is problematic since this needs Torque to be initialized to perform the query. The solution is to put a map of id method types to primaryKeyMethodInfos into the Table map, so querying the id method type can be done when it is really necessary. create a DatabaseMapBuilder for each database which contains all tables in the database implement an "append" strategy for exsiting target files in the generator for building the DatabaseMapBuilder from more than one schema file the table map builders do no longer implement the MapBuilder interface remove the MapBuilder interface since it is no longer needed

          People

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

            Dates

            • Created:
              Updated:
              Resolved:

              Development