Details

    • Type: New Feature New Feature
    • Status: Resolved
    • Priority: Minor Minor
    • Resolution: Complete
    • Affects Version/s: 1.1.0.RC1
    • Fix Version/s: 1.2.0.M1, 1.2.0.RC1
    • Component/s: PERSISTENCE
    • Labels:
      None

      Description

      At the moment we allow only one database schema per project in DBRE.
      What is the problem to support multiple? For instance:

      database reverse engineer --schema SCHEMA_1 --package ~.model.schema1
      database reverse engineer --schema SCHEMA_2 --package ~.model.schema2
      

      At the moment second script command wipes out all generated artifacts created by first command.

        Issue Links

          Activity

          Hide
          Alan Stewart added a comment -

          Entities names are derived from their tables names as Roo doesn't provide an interactive wizard like Eclipse does, however, if you select all the defaults in the Eclipse wizard the entities are also named after their tables. So there is nothing else I can do, reliably anyway. I don't know what you would suggest different. It would not be practical to attempt to provide up front a list of entity names to try to match to their tables. A DBA could remove a table or rename it and you would be stuck. It would be a maintenance nightmare. DBRE can now cope with database refactorings quite easily.

          In the all the large enterprises I have worked in, the development schema, when requirements and design are done, is replicated through test and production. We also have to support other ORMs besides Hibernate.

          Please be reminded that DBRE is there to make your life easier when dealing with existing schemas. You are free to rename your entities as you see fit, move them to other packages or refactor them as any other Roo entity.

          Show
          Alan Stewart added a comment - Entities names are derived from their tables names as Roo doesn't provide an interactive wizard like Eclipse does, however, if you select all the defaults in the Eclipse wizard the entities are also named after their tables. So there is nothing else I can do, reliably anyway. I don't know what you would suggest different. It would not be practical to attempt to provide up front a list of entity names to try to match to their tables. A DBA could remove a table or rename it and you would be stuck. It would be a maintenance nightmare. DBRE can now cope with database refactorings quite easily. In the all the large enterprises I have worked in, the development schema, when requirements and design are done, is replicated through test and production. We also have to support other ORMs besides Hibernate. Please be reminded that DBRE is there to make your life easier when dealing with existing schemas. You are free to rename your entities as you see fit, move them to other packages or refactor them as any other Roo entity.
          Hide
          Javier Beneito Barquero added a comment -

          Thank you very much for your time and your response, specially the last paragraph.

          It seems I became paranoid in some moment of my life regarding the unexpected changes that you can find out in the Production environment.

          Show
          Javier Beneito Barquero added a comment - Thank you very much for your time and your response, specially the last paragraph. It seems I became paranoid in some moment of my life regarding the unexpected changes that you can find out in the Production environment.
          Hide
          Alan Stewart added a comment -

          is a little more tedius but, what if you use something like:

          database reverse engineer --schema "s1 s2 s3" --includeTables "s1.table1_1 s1.table2_1 s3.table3_1"

          It will be difficult to provide a reliable way of including and excluding tables in specific schemas. The example you give where the schema and table names are separated by a period will not work for tables that have periods in their name. Different databases allow many strange characters in their table names and there may not be a delimiter to that can be used for all database variations. At the moment, if one has a table with the same name in two different schemas, both tables will be included or excluded.

          I will check in the code I have now and you can test it out. I will leave the ticket open or a while

          Show
          Alan Stewart added a comment - is a little more tedius but, what if you use something like: database reverse engineer --schema "s1 s2 s3" --includeTables "s1.table1_1 s1.table2_1 s3.table3_1" It will be difficult to provide a reliable way of including and excluding tables in specific schemas. The example you give where the schema and table names are separated by a period will not work for tables that have periods in their name. Different databases allow many strange characters in their table names and there may not be a delimiter to that can be used for all database variations. At the moment, if one has a table with the same name in two different schemas, both tables will be included or excluded. I will check in the code I have now and you can test it out. I will leave the ticket open or a while
          Hide
          Alan Stewart added a comment -

          Support for multiple schemas committed in Git ID 159b5838704ee5016a3c0e20b8f68066702475e9.

          For existing reverse-engineered single schemas, this commit maintains backward compatibility with the dbre.xml structure.

          Show
          Alan Stewart added a comment - Support for multiple schemas committed in Git ID 159b5838704ee5016a3c0e20b8f68066702475e9. For existing reverse-engineered single schemas, this commit maintains backward compatibility with the dbre.xml structure.
          Hide
          Alan Stewart added a comment -

          Fixed package name creation based on schema names in Git ID 33e9c37c0fb00d3e787e744c7b16e7f6aac6c575

          Show
          Alan Stewart added a comment - Fixed package name creation based on schema names in Git ID 33e9c37c0fb00d3e787e744c7b16e7f6aac6c575

            People

            • Assignee:
              Alan Stewart
              Reporter:
              Roman Kuzmik
            • Votes:
              18 Vote for this issue
              Watchers:
              9 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved: