Spring Roo
  1. Spring Roo
  2. ROO-3144

MySql unique indexed ignored on foreign key columns by reverse engineering with generated integration tests failing

    Details

    • Type: Bug Bug
    • Status: Resolved
    • Priority: Blocker Blocker
    • Resolution: Works as Designed
    • Affects Version/s: 1.2.1.RELEASE
    • Fix Version/s: None
    • Component/s: @ CORE, PERSISTENCE
    • Labels:
    • Environment:
      Linux Mint 12
      java version "1.6.0_29"
      Java(TM) SE Runtime Environment (build 1.6.0_29-b11)
      Java HotSpot(TM) Server VM (build 20.4-b02, mixed mode)

      Description

      If a column has the unique index and the column is also a foreign key, then the unique index feature of the column seems ignored by the reverse engineering process.

      To replicate the issue simply create a MySql database containing two tables, one having a foreign key constraint on the other, like:

      create table if not exists user ( id int unsigned not null auto_increment, version int unsigned not null, name varchar(20), primary key (id), unique (id) ) type = INNODB;

      create table if not exists teacher ( id int unsigned not null auto_increment, version int unsigned not null, admin_id int unsigned not null, user_id int unsigned not null, index(admin_id), unique(admin_id), index (user_id), foreign key (user_id) references user(id), unique (user_id), primary key (id), unique (id) ) type = INNODB;

      Then open the roo.sh shell and type in the following commands:

      project --topLevelPackage com.learnintouch.jira --java 6 --packaging jar
      jpa setup --provider HIBERNATE --database MYSQL
      database properties set --key database.username --value myuser
      database properties set --key database.password --value mypassword
      database properties set --key database.url --value jdbc:mysql://localhost:3306/roo_jira
      database properties list
      database introspect --schema roo_jira
      database reverse engineer --package ~.domain --schema roo_jira --testAutomatically --includeNonPortableAttributes
      perform tests

        Activity

        Hide
        Stephane added a comment -

        Hello Alan,

        Thanks for the comment. I understand the necessity of having no data in a schema before running any integration tests.

        But in fact, the reverse engineering and integration test is done against a totally empty database named db_integration.

        This database is being used by another Maven project, this one a hand coded Spring Hibernate based old fashioned Dao, with a lot of integration tests that pass all fine against that very same database.

        I created that database for the sole and express purpose of running these integration tests.

        Now, before raising a JIRA and to be sure of what was happening, I created a dummy simple schema with only two tables. With it I created a database named roo_jira. This is this schema that I use for this JIRA so as to make it easier for the developer.

        Of course, this schema is also totally empty. In fact, it never saw any data at all.

        I'm surprised that you cannot replicate the issue, knowing you have the schema and the full Roo script I used.

        Or is there anything wrong in my environment..

        Kind Regards,

        Show
        Stephane added a comment - Hello Alan, Thanks for the comment. I understand the necessity of having no data in a schema before running any integration tests. But in fact, the reverse engineering and integration test is done against a totally empty database named db_integration. This database is being used by another Maven project, this one a hand coded Spring Hibernate based old fashioned Dao, with a lot of integration tests that pass all fine against that very same database. I created that database for the sole and express purpose of running these integration tests. Now, before raising a JIRA and to be sure of what was happening, I created a dummy simple schema with only two tables. With it I created a database named roo_jira. This is this schema that I use for this JIRA so as to make it easier for the developer. Of course, this schema is also totally empty. In fact, it never saw any data at all. I'm surprised that you cannot replicate the issue, knowing you have the schema and the full Roo script I used. Or is there anything wrong in my environment.. Kind Regards,
        Hide
        Stephane added a comment -

        Hello,

        I don't know if you had time to read my last comment and possibly give a try to the Roo script ?

        Kind Regards,

        Show
        Stephane added a comment - Hello, I don't know if you had time to read my last comment and possibly give a try to the Roo script ? Kind Regards,
        Hide
        Stephane added a comment -

        I just tried again after installing Roo 1.2.2.RELEASE [rev 7d75659] but the generated tests still fail even with the updating of <property name="hibernate.hbm2ddl.auto" value="create"/>

        I just attached the surefire report.

        Show
        Stephane added a comment - I just tried again after installing Roo 1.2.2.RELEASE [rev 7d75659] but the generated tests still fail even with the updating of <property name="hibernate.hbm2ddl.auto" value="create"/> I just attached the surefire report.
        Hide
        Stephane added a comment -

        And the project Roo log file.

        Show
        Stephane added a comment - And the project Roo log file.
        Hide
        Stephane added a comment -

        After a reply on my thread at http://forum.springsource.org/showthread.php?129045-Generated-tests-still-failing-on-latest-Roo-on-simple-two-tables-schema I now understand that Roo does not yet take care of entity relationships when generating its tests.

        On an existing database schema with lots of entities and relationships enforced by foreign key security constraints, the reverse engineering and tests generation still leaves the developer with a lot of work to hand code the data mocking.

        What is also problematic is that this hand coding would have to happen in all the Roo managed _DataOnDemand.aj files. Not something the developer should be too happy to do.

        In the meantime, all the generated tests running against the entities protected with foreign key security constraints are in error.

        Unless my understanding of the issue is wrong I don't see how the developer can use the Roo generated tests in a scenario of a domain model reversed engineered from an existing database schema.

        Show
        Stephane added a comment - After a reply on my thread at http://forum.springsource.org/showthread.php?129045-Generated-tests-still-failing-on-latest-Roo-on-simple-two-tables-schema I now understand that Roo does not yet take care of entity relationships when generating its tests. On an existing database schema with lots of entities and relationships enforced by foreign key security constraints, the reverse engineering and tests generation still leaves the developer with a lot of work to hand code the data mocking. What is also problematic is that this hand coding would have to happen in all the Roo managed _DataOnDemand.aj files. Not something the developer should be too happy to do. In the meantime, all the generated tests running against the entities protected with foreign key security constraints are in error. Unless my understanding of the issue is wrong I don't see how the developer can use the Roo generated tests in a scenario of a domain model reversed engineered from an existing database schema.

          People

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

            Dates

            • Created:
              Updated:
              Resolved: