Spring Roo
  1. Spring Roo
  2. ROO-2911

Make DBRE naming package/class/field naming strategies pluggable

    Details

    • Type: Improvement Improvement
    • Status: Open
    • Priority: Minor Minor
    • Resolution: Unresolved
    • Affects Version/s: 1.2.0.M1
    • Fix Version/s: None
    • Component/s: PERSISTENCE
    • Labels:
      None

      Description

      Is it possible to override the naming strategy that Roo dbre uses when creating Roo_DbManaged ITDs?

      For example, we have a database which uses 2 char prefixes on column names to indicate the datatype, e.g. TX_EMPLOYEE_NAME, which by default maps to txEmployeeName - I would like it to map to employeeName.

      Also, ID_EMPLOYEE maps to idEmployee, whereas I would rather it was employeeId.

      Same thing goes for the package names DBRE generates which are just lowercase version of the schema names.
      Our schema names have a 2 char prefix, which denotes the app name, so our schema names are like XX_AUDIT, XX_CONFIG, XX_RUNTIME etc.. where XX is a 2 char code for our app.

      Ideally what I would like is something along the lines of the Hibernate DelegatingReverseEngineeringStrategy:
      http://docs.jboss.org/tools/2.1.0.Beta1/hibernatetools/html/reverseengineering.html#custom-reveng-strategy

      In the short term, I have achieved this by getting the Roo source and hacking the DbreTypeUtils class to meet our requirements.

        Activity

        Hide
        Andrew White added a comment -

        Another enhancement that would be nice to see is to be able to override the default type mappings, for example to map a CHAR(1) to Boolean. In the short term I have modified the Column.init() method.

        Show
        Andrew White added a comment - Another enhancement that would be nice to see is to be able to override the default type mappings, for example to map a CHAR(1) to Boolean. In the short term I have modified the Column.init() method.
        Hide
        Alan Stewart added a comment -

        I'd rather not go down the Hibernate path, but if you think DbreTypeUtils can be changed to allow user-pluggable implementations, I would be interested to see what you suggest here. Perhaps you can provide a patch?
        Thanks

        Show
        Alan Stewart added a comment - I'd rather not go down the Hibernate path, but if you think DbreTypeUtils can be changed to allow user-pluggable implementations, I would be interested to see what you suggest here. Perhaps you can provide a patch? Thanks
        Hide
        Laurie Chan added a comment - - edited

        I have an attempt at part of this here: https://github.com/chorrylan/spring-roo/tree/ROO-2911-dbre-tablenaming
        (I'm new to roo,dbre, git and github so it's pretty crude)

        The particular use cases and issues I had to deal with are:
        1) plural tablenames (which results in plural entity names and then weird double-pluralization of subsquent bits)
        3) prefixes on table names that have no meaning to the domain model (eg MV_ for materialized views)
        4) legacy schema with mixed and inconsitent naming conventions (but difficult to change)
        5) problems renaming entities if the ui tier has already been generated and modified so would like to get them right the first time

        Dealing with plural table names is by arbitrarily singularizing all table names on the assumption that it's harmless if the name is already singular or that there's not already a table with a clashing name (the dbre code then suffixes one of them to resolve the clash but it could be confusing) .

        Schema and site-specific configuration is through an extra arg --tableNameMapper <file> for dbre reverse engineer
        This can be a property file in classic or xml format with mapping rules of the form oldname=newname
        eg

        # clean up a specific materialized view
        MV_EMPLOYEES=EMPLOYEE
        # or a regex to clean them all up
        (?\:MV_)(.*)=$1
        

        or a groovy script that implements whatever logic is neccessary in a method of the for String getName(String)
        eg

        String getName(String str) {
        // strip off MV_ prefixes from materialized views
         str = str.replaceFirst(/^MV_(.*)/,/$1/)
        // expand abbreviations
         str = str.replaceAll(/((?:_)|(?:^))(ATTRIB)((?:_)|(?:$))/,/$1ATTRIBUTE$3/)
        // etc
         return str
        }
        

        The groovy script option obviously has the most potential and I was a bit surprised that it worked (as it conflicts with aspectj in the generated application) but as roo itself doesn't use aspects it seems to be ok.

        Show
        Laurie Chan added a comment - - edited I have an attempt at part of this here: https://github.com/chorrylan/spring-roo/tree/ROO-2911-dbre-tablenaming (I'm new to roo,dbre, git and github so it's pretty crude) The particular use cases and issues I had to deal with are: 1) plural tablenames (which results in plural entity names and then weird double-pluralization of subsquent bits) 3) prefixes on table names that have no meaning to the domain model (eg MV_ for materialized views) 4) legacy schema with mixed and inconsitent naming conventions (but difficult to change) 5) problems renaming entities if the ui tier has already been generated and modified so would like to get them right the first time Dealing with plural table names is by arbitrarily singularizing all table names on the assumption that it's harmless if the name is already singular or that there's not already a table with a clashing name (the dbre code then suffixes one of them to resolve the clash but it could be confusing) . Schema and site-specific configuration is through an extra arg --tableNameMapper <file> for dbre reverse engineer This can be a property file in classic or xml format with mapping rules of the form oldname=newname eg # clean up a specific materialized view MV_EMPLOYEES=EMPLOYEE # or a regex to clean them all up (?\:MV_)(.*)=$1 or a groovy script that implements whatever logic is neccessary in a method of the for String getName(String) eg String getName( String str) { // strip off MV_ prefixes from materialized views str = str.replaceFirst(/^MV_(.*)/,/$1/) // expand abbreviations str = str.replaceAll(/((?:_)|(?:^))(ATTRIB)((?:_)|(?:$))/,/$1ATTRIBUTE$3/) // etc return str } The groovy script option obviously has the most potential and I was a bit surprised that it worked (as it conflicts with aspectj in the generated application) but as roo itself doesn't use aspects it seems to be ok.

          People

          • Assignee:
            Unassigned
            Reporter:
            Andrew White
          • Votes:
            1 Vote for this issue
            Watchers:
            1 Start watching this issue

            Dates

            • Created:
              Updated: