in

The ORM Foundation

Get the facts!

Reverse Engineering from PostgreSQL/ODBC

Last post Thu, May 14 2020 21:10 by Matthew Curland. 3 replies.
Page 1 of 1 (4 items)
Sort Posts: Previous Next
  • Thu, May 14 2020 4:21

    Reverse Engineering from PostgreSQL/ODBC

    As I work with another person with this program quite often, we have ran into an issue with our source control. The main issue being that any attempts to merge the ORM files (or anything that comprises it) results in the file being unable to be opened.

    I was wondering if there had been any work at this point on allowing ODBC or PostgreSQL servers to act as a data source for an ORM Import. An ideal scenario for us would be to enable the ORM file to be generated from the same SQL files that it can generate. If that functionality doesn't exist or cannot be done for one reason or another, could someone please point me in the right direction for extending the software to allow the previously mentioned data sources?

    Thanks

  • Thu, May 14 2020 9:47 In reply to

    • Ken Evans
    • Top 10 Contributor
      Male
    • Joined on Sun, Nov 18 2007
    • Stickford, UK
    • Posts 794

    Re: Reverse Engineering from PostgreSQL/ODBC

     "merge the ORM files "

    Please explain what you mean by this.
    To which "ORM files" are you referring?   
    What are you trying to merge with what?

    "ORM Import"

    There are several problems with the generators and the reverse engineering functions.
    I'll send you a separate email about this.


    Ken 

  • Thu, May 14 2020 10:56 In reply to

    Re: Reverse Engineering from PostgreSQL/ODBC

    'To which "ORM files" are you referring?'

    The files being referred to here are:
    filename.orm
    filename.DCIL.xml
    filename.DDIL.xml

    "What are you trying to merge with what"

    Our development process involves making changes to the schema design via the NORMA extension for visual studio, committing those changes to a git repository and merging the changes into the main branch. The merge itself is handled by any standard merge conflict resolution tool (the one I use is built into my git client, gitkraken). The merge is happening between two differing versions of the same schema and always results in an error that makes the file unable to be used.

    Hope that gives some context.

    Tye

  • Thu, May 14 2020 21:10 In reply to

    Re: Reverse Engineering from PostgreSQL/ODBC

    Hello Tye,

     So, the difficulty on merging these files is that either a large part of these files (x.orm) or all (x.dcil.xml, x.ddil.xml) are generated, which makes merging difficult. The generated sections of .orm files also have non-stable identifiers, which makes them exceedingly difficult to merge.

    It doesn't really matter if the last two files merge cleanly or not. You can simply right-click the .orm file in the Solution Explorer and choose 'Run custom tool' to recreate them from scratch (or simply open and save the .orm file in the ide). The trick is getting the .orm file merged cleanly and in a consistent state.

    The stable (non-generated) sections of the .orm file are all the pieces in orm:ORMModel and ormDiagram:ORMDiagram elements in the XML. If these merge cleanly then the ORM model itself should be OK, which leaves the generated pieces to deal with. Of these, the oialtocdb:MappingCustomization and orm:GenerationState sections should also be stable. Pretty much everything else is generated.

    For a clean mapping you can do the following. However, this is guaranteed to leave the relational view with unresolved shapes.

    1. oial:model: delete contents, leave element
    2. rcd:Schema: delete contents, leave element
    3. rvw:RelationalDiagram: leave element, delete contents
    4. ormtooial:Bridge: leave AbstractionModelIsForORMModel, delete all other elements
    5. oialtocdb:Bridge: leave SchemaIsForAbstractionModel, delete all other elements
    6. In orm:GenerationSettings you'll see three attributes with 'AlgorithmVersion' in the name. Drop the last digit in the version by one on each of these (1.009 -> 1.008, 1.004 ->1.003, 1.014->1.013). This forces the algorithms to regenerate everything on a file reload.
    This isn't a great answer, especially if you care about the relational view layout (which you may on on a large model). Hand merging the bridge elements would be painful because duplicates will likely throw on model load. If you have no customizations (name generator settings, subtype mapping customization, etc.) then you just pick one model to keep the generated elements for and tweak the algorithm version. Reload the document, save to regenerate, and your other files (dcil, ddil) will regenerate correctly.
     
    There are other approaches here. For example, if you know which elements have been modified or added in the file you're merging in you can simply rename one file, open it, and drag the new/updated elements from one file to the other. This may actually be easier than the above process.
     
    I wish I had a better answer here. I know these are very difficult merges. I generally take the last approach (look at the XML diff, find the changed/new/delete elements in the target file, and drag/drop or hand apply the changes.) Obviously, if you can get the non-master branched merged or rebased on master before pushing up you'll be in much better shape because you'll be able to fast-forward the pull into master.
     
    -Matt
     

Page 1 of 1 (4 items)
© 2008-2020 The ORM Foundation: A UK not-for-profit organisation -------------- Terms of Service