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

  • #16
    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

    Comment


    • #17
      I think the best option is to create the project in the traditional way.

      creating the entity, the fields ...



      Thanks for your help

      Comment


      • #18
        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?

        Comment


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

          Comment


          • #20
            I did and it worked

            Thanks!




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

            Comment


            • #21
              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 ?

              Comment


              • #22
                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.

                Comment


                • #23
                  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, 07:40 AM.

                  Comment


                  • #24
                    In 1.2.0.M1, DBRE supports multiple schemas. Try:

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

                    Comment


                    • #25
                      Thank you for the clue Alan !

                      I'll try this next time

                      Comment


                      • #26
                        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).

                        Comment


                        • #27
                          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

                          Comment


                          • #28
                            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

                            Comment

                            Working...
                            X