Spring Roo
  1. Spring Roo
  2. ROO-1902

allow DBRE with multiple relationships between same tables

    Details

    • Type: Improvement Improvement
    • Status: Closed
    • Priority: Major Major
    • Resolution: Complete
    • Affects Version/s: 1.1.0.RELEASE
    • Fix Version/s: 1.1.1.RELEASE
    • Component/s: PERSISTENCE
    • Labels:
      None
    • Environment:
      MySql(InnoDB)

      Description

      allow DBRE with multiple relationships between same two tables where in resulting model class there should be more than one collection field with the same generic types, such as:
      private Set<TypeGroup> typeGroups1;
      private Set<TypeGroup> typeGroups2;

      I described detailed problem description and proposed solution for the problem in the forum thread http://forum.springsource.org/showthread.php?t=100398

      Best regards,
      Ats

        Activity

        Hide
        Alan Stewart added a comment -

        I do support multiple relationships between two tables (fields are suffixed with an incremented number to avolid clashes) so I am curious to see why any errors are produced. For me to proceed, would you please attach your MySQL DDL so I can attempt to replicate any problem.

        Show
        Alan Stewart added a comment - I do support multiple relationships between two tables (fields are suffixed with an incremented number to avolid clashes) so I am curious to see why any errors are produced. For me to proceed, would you please attach your MySQL DDL so I can attempt to replicate any problem.
        Hide
        Ats U. added a comment -

        Hello,

        I'll try to describe how to reproduce this problem and explain the database structure that produces following error message:
        Field 'typeGroups' already defined in ITD (ITD target 'roo.issue1902.domain.Type_Roo_DbManaged)'

        To reproduce this problem you need to do following:
        1) create database structure(I used mysql):
        See the attachment ROO-1902_demo.zip/roo_1902-issue-base.sql
        (if you have MySqlWorkbench installed, then see the graphic representation of the DB structure from the attachment roo_1902-issue-base.mwb. roo_1902-issue-base.sql is generated by MySqlWorkbench based on this model).

        I'll also try to describe DB structure with few sentences for those that don't want to look into attachments:
        For the demostration of this problem I created following tables: "type", "type_group", "type_group_has_type"(used only to represent many-to-many relation) and "other".
        The key relations between those tables regarding reproducing this problem are following:
        type --< type_group
        type > - < type_group (in reality modelled with intermediate table: type – < type_group_has_type > – type_group)

        2) create roo project using following roo commands:
        project --topLevelPackage roo.issue1902 --projectName roo_issue_1902 --java 6
        persistence setup --database MYSQL --provider HIBERNATE --userName root --password mySqlRootPass --databaseName roo_1902 --hostName localhost
        database reverse engineer --package ~.domain --schema roo_1902

        ------------------------------------------------

        Here are the changes that if made independently would allow DBRE to complete successfully:

        1) Removing "other" table (all other tables not related to type and type_group). It doesn't mater if this "other" table was related to rest of the tables or not, problem can be reproduced even if it just exists.

        2) If I removed either one-to-many or many-to-many relation and left everything else the same, then also DBRE completes successfully.

        However one strange thing that would allow DBRE complete successfully would be to use a number after a dot in the name of the package - unfortunately this is not a valid Java package identifier so that project can't be compiled.
        If topLevelPackage is roo.issue.1902 or roo.1902issue or roo.1902issue.test and everything else remains the same based on "base situation" then I managed to complete DBRE (and of course failed on building the project).

        Ats

        Show
        Ats U. added a comment - Hello, I'll try to describe how to reproduce this problem and explain the database structure that produces following error message: Field 'typeGroups' already defined in ITD (ITD target 'roo.issue1902.domain.Type_Roo_DbManaged)' To reproduce this problem you need to do following: 1) create database structure(I used mysql): See the attachment ROO-1902 _demo.zip/roo_1902-issue-base.sql (if you have MySqlWorkbench installed, then see the graphic representation of the DB structure from the attachment roo_1902-issue-base.mwb. roo_1902-issue-base.sql is generated by MySqlWorkbench based on this model). I'll also try to describe DB structure with few sentences for those that don't want to look into attachments: For the demostration of this problem I created following tables: "type", "type_group", "type_group_has_type"(used only to represent many-to-many relation) and "other". The key relations between those tables regarding reproducing this problem are following: type --< type_group type > - < type_group (in reality modelled with intermediate table: type – < type_group_has_type > – type_group) 2) create roo project using following roo commands: project --topLevelPackage roo.issue1902 --projectName roo_issue_1902 --java 6 persistence setup --database MYSQL --provider HIBERNATE --userName root --password mySqlRootPass --databaseName roo_1902 --hostName localhost database reverse engineer --package ~.domain --schema roo_1902 ------------------------------------------------ Here are the changes that if made independently would allow DBRE to complete successfully: 1) Removing "other" table (all other tables not related to type and type_group). It doesn't mater if this "other" table was related to rest of the tables or not, problem can be reproduced even if it just exists. 2) If I removed either one-to-many or many-to-many relation and left everything else the same, then also DBRE completes successfully. However one strange thing that would allow DBRE complete successfully would be to use a number after a dot in the name of the package - unfortunately this is not a valid Java package identifier so that project can't be compiled. If topLevelPackage is roo.issue.1902 or roo.1902issue or roo.1902issue.test and everything else remains the same based on "base situation" then I managed to complete DBRE (and of course failed on building the project). Ats
        Hide
        Alan Stewart added a comment -

        Do you see any stack traces or errors? With the latest Roo code from Git your script completes successfully for me. Would you please try the latest code as there have been substantial changes since 1.1.0.RELEASE.

        When you first execute the database reverse engineer command, you will will have to install the MySQL driver, but typing addon install --bundleId 01 ( there will be a help message for you)

        Show
        Alan Stewart added a comment - Do you see any stack traces or errors? With the latest Roo code from Git your script completes successfully for me. Would you please try the latest code as there have been substantial changes since 1.1.0.RELEASE. When you first execute the database reverse engineer command, you will will have to install the MySQL driver, but typing addon install --bundleId 01 ( there will be a help message for you)
        Hide
        Ats U. added a comment -

        While was(and still am) having this problem with 1.1.0.RELEASE this problem didn't occur with development branch. I didn't see any stack traces or errors with 1.1.0, just the UNDO lines and the error message I described.

        tnx

        Show
        Ats U. added a comment - While was(and still am) having this problem with 1.1.0.RELEASE this problem didn't occur with development branch. I didn't see any stack traces or errors with 1.1.0, just the UNDO lines and the error message I described. tnx
        Hide
        Alan Stewart added a comment -

        I was able to verify that 1.1.0.RELEASE does indeed have this issue, however the problem has been subsequently fixed and will be available in the impending 1.1.1.RELEASE

        Show
        Alan Stewart added a comment - I was able to verify that 1.1.0.RELEASE does indeed have this issue, however the problem has been subsequently fixed and will be available in the impending 1.1.1.RELEASE

          People

          • Assignee:
            Alan Stewart
            Reporter:
            Ats U.
          • Votes:
            0 Vote for this issue
            Watchers:
            1 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Time Tracking

              Estimated:
              Original Estimate - 7h
              7h
              Remaining:
              Remaining Estimate - 7h
              7h
              Logged:
              Time Spent - Not Specified
              Not Specified