Announcement Announcement Module
Collapse
No announcement yet.
dbre mysql 'Foreign key table for foreign key' 'must not be null' Page Title Module
Move Remove Collapse
X
Conversation Detail Module
Collapse
  • Filter
  • Time
  • Show
Clear All
new posts

  • dbre mysql 'Foreign key table for foreign key' 'must not be null'

    Given the following mysql database definition for user 'sa' and no password:
    Code:
    -- DROP SCHEMA IF EXISTS rootest;
    
    -- CREATE SCHEMA rootest DEFAULT CHARACTER SET utf8;
    
    -- USE rootest;
    
    DROP TABLE IF EXISTS TeamPlayer;
    DROP TABLE IF EXISTS Player;
    DROP TABLE IF EXISTS Team;
    DROP TABLE IF EXISTS PlayerStatusType;
    DROP TABLE IF EXISTS User;
    
    -- =================================
    
    CREATE TABLE User
      (
        id 	bigint auto_increment PRIMARY KEY
      )
     ENGINE = InnoDB;
    
    -- ================================
    
    CREATE TABLE PlayerStatusType
      (
        type  varchar(63) PRIMARY KEY
      )
     ENGINE = InnoDB;
    
    -- ===============================
    
    CREATE TABLE Team
      (
        id       bigint auto_increment,
        city     varchar(127)   not null,
        name     varchar(127)   not null,
        version  int,
    
        primary key(id),
        unique(city, name)
      )
     ENGINE = InnoDB;
    
    -- ================================
    
    CREATE TABLE Player
      (
        id         bigint auto_increment,
        firstName  varchar(63),
        lastName   varchar(63)   not null,
        birthdate  date          not null,
        statusType varchar(63)   not null,
        version    int,
    
        primary key(id),
        
        foreign key(statusType) references PlayerStatusType(type)
      )
     ENGINE = InnoDB;
    
    -- ===================================
    
    CREATE TABLE TeamPlayer
      (
        teamId    bigint,
        playerId  bigint,
        fromDate  date,
        toDate    date,
        version   int,
    
        primary key(teamId, playerId, fromDate),
    
        foreign key(teamId) references Team(id),
        foreign key(playerId) references Player(id)
      )
     ENGINE = InnoDB;
    
    -- ===================================
    and the following roo project scripts:
    Code:
    // Create project
    
    project --topLevelPackage com.roodbtest
    
    // Setup database
    
    persistence setup --provider HIBERNATE --database MYSQL
    database properties set --key database.url --value jdbc:mysql://localhost:3306/rootest
    database properties set --key database.username --value sa
    
    database properties list
    edit persistence.xml changing hibernate.hbm2ddl.auto value to 'validate'
    Code:
    // database reverse engineer
    
    ///////////
    
    database reverse engineer --schema rootest --package ~.domain --testAutomatically
    the following output results:
    Code:
    Created SRC_MAIN_RESOURCES/dbre.xml
    Updated ROOT/pom.xml
    Updated SRC_MAIN_RESOURCES/META-INF/persistence.xml
    Created SRC_MAIN_JAVA/com/roodbtest/domain
    Created SRC_MAIN_JAVA/com/roodbtest/domain/Player.java
    Created SRC_MAIN_JAVA/com/roodbtest/domain/PlayerStatusType.java
    Created SRC_MAIN_JAVA/com/roodbtest/domain/Team.java
    Created SRC_MAIN_JAVA/com/roodbtest/domain/TeamPlayerPK.java
    Created SRC_MAIN_JAVA/com/roodbtest/domain/TeamPlayer.java
    Created SRC_MAIN_JAVA/com/roodbtest/domain/User.java
    Undo create SRC_MAIN_JAVA/com/roodbtest/domain/User.java
    Undo create SRC_MAIN_JAVA/com/roodbtest/domain/TeamPlayer.java
    Undo create SRC_MAIN_JAVA/com/roodbtest/domain/TeamPlayerPK.java
    Undo create SRC_MAIN_JAVA/com/roodbtest/domain/Team.java
    Undo create SRC_MAIN_JAVA/com/roodbtest/domain/PlayerStatusType.java
    Undo create SRC_MAIN_JAVA/com/roodbtest/domain/Player.java
    Undo create SRC_MAIN_JAVA/com/roodbtest/domain
    Undo manage SRC_MAIN_RESOURCES/META-INF/persistence.xml
    Undo manage ROOT/pom.xml
    Undo create SRC_MAIN_RESOURCES/dbre.xml
    Foreign key table for foreign key 'player_ibfk_1' in table 'Player' must not be null in determining a one-to-one relationship
    Script required 2 second(s) to execute
    Script execution aborted
    Created SRC_MAIN_JAVA/com/roodbtest/domain
    Created SRC_MAIN_JAVA/com/roodbtest/domain/Player_Roo_Entity.aj
    Deleted SRC_MAIN_JAVA/com/roodbtest/domain/Player_Roo_Entity.aj
    This is a very simple database structure.
    Why does roo have a problem?
    Is this a roo defect?
    Am I missing a step or doing something incorrect?

    I am using roo 1.1.4.

  • Cedric.Vidrequin
    replied
    Unfortunatly, it seems it is not possible to do something like this :
    database reverse engineer --schema "schema1 schema2" --package com.compagny.project.bo --includeTable schema2.class1 schema2.class2
    The problem for me is that there are a lot of tables in schema1, a lot of table in schema2, and I need all the tables of schema1 and only few of schema2 ... so if I have to include/exclude all the expected tables, I'll have to write a huuuuudge list ...

    Anyway, thanks for attention and clues

    Leave a comment:


  • Alan Stewart
    replied
    You can still use the --includeTables and --excludeTables options, however they are not schema specific, so if a table called "foo" exists in both schemas, both will either be included or excluded depending on what option(s) you specify

    Leave a comment:


  • Cedric.Vidrequin
    replied
    Hello again Alan,

    I thought about what you proposed before ... If I add several schemata in the command, I suppose the reverse engineering will generate all the BO of all the tables of all the schemata, won't it ?

    Well, I'd like it to generate only a few of them in schema2 and all of them in schema1 (for example).

    Do you know if it is possible without specifying all the expected table (they are numurous on schema1 and only few on schema2).

    Leave a comment:


  • Cedric.Vidrequin
    replied
    Thank you for the clue Alan !

    I'll try this next time

    Leave a comment:


  • Alan Stewart
    replied
    In 1.2.0.M1, DBRE supports multiple schemas. Try:

    Code:
    database reverse engineer --schema "schema1 schema2" --package com.compagny.project.bo

    Leave a comment:


  • Cedric.Vidrequin
    replied
    Hello Alan,

    I didn't have restricted the tables reversed ... here is my command :
    roo> database reverse engineer --schema mySchema --package com.compagny.project.bo
    EDIT: I found a way to solve my problem :
    I work in the schema S. I have some tables that belongs to differents schemata. I create copies of those tables structure into S and connected the PK/FK to those copies. Then I do the reverse engineering without trouble.
    Then I re-link the PK/FK to the original tables and delete the copies.
    Last edited by Cedric.Vidrequin; Sep 19th, 2011, 08:40 AM.

    Leave a comment:


  • Alan Stewart
    replied
    This warning is displayed if you have foreign key relationships but have restricted the tables reverse engineered with either the --includeTables or --excludeTables options. if your database has all the correct FK relationships you should not see this problem.

    Leave a comment:


  • Cedric.Vidrequin
    replied
    Again and again

    Each time I need to do a reverse engineering I face the same problem ...

    But this time I didn't manage to solve it just by restarting SpringRoo ...

    When I try to do my reerse engineering, I always have this error :
    Foreign key table for foreign key X in table Y must not be null in determining a one-to-one relationship
    Please, can anyone tell me where does this error come from ?

    Leave a comment:


  • Karina
    replied
    I did and it worked

    Thanks!




    Anita Karina Acosta Aguirre
    Estudiante Ingeniería en Informática

    Leave a comment:


  • Alan Stewart
    replied
    Dbre will only delete a @RooDbManaged class if the table has been dropped. Put the table back and it will be recreated

    Leave a comment:


  • Karina
    replied
    I didn't and I can't because the class is deleted immediately..
    what you mean with
    just push-in all the fields and methods you want and remove the @RooDbManaged annotation
    ?
    please Can you explain?

    Leave a comment:


  • Karina
    replied
    I think the best option is to create the project in the traditional way.

    creating the entity, the fields ...



    Thanks for your help

    Leave a comment:


  • Alan Stewart
    replied
    With the @RooDbManaged applied the type will be managed when the database reverse engineer command is run . If the table has been dropped from your db, the type will be deleted after the command is executed. If you want to keep the java class and all the fields and methods that get generated after the table has been dropped, just push-in all the fields and methods you want and remove the @RooDbManaged annotation. But it seems you have already done this before, because DBRE doesn't remove the annotation, and never would

    Leave a comment:


  • Karina
    replied
    Thanks for you Reply,

    And How I can fix this?
    I need help

    What I have to do for that not delete the class . java and the others?

    for example:
    Code:
    Created SRC_MAIN_JAVA\com\...
    Created SRC_MAIN_JAVA\com\...
    Created SRC_MAIN_JAVA\com\...
    Deleted SRC_MAIN_JAVA\com\...
    Deleted SRC_MAIN_JAVA\com\...
    Deleted SRC_MAIN_JAVA\com\...
    Last edited by Karina; Aug 30th, 2011, 07:58 AM. Reason: m

    Leave a comment:

Working...
X