in

The ORM Foundation

Get the facts!

Multiple ORM definition file support

Last post Mon, Sep 28 2009 7:38 by Anonymous. 2 replies.
Page 1 of 1 (3 items)
Sort Posts: Previous Next
  • Wed, Aug 12 2009 8:56

    • Steve Miller
    • Top 50 Contributor
      Male
    • Joined on Thu, Jan 1 2009
    • Portland, Oregon USA
    • Posts 18

    Multiple ORM definition file support

    Greetings,

    The ORM model I have created has close to 700 tables.  I would like to use external types to basically develop subportions of the model in separate ORM files and like them through the external definitions.  I see in the Brown Book that this isn't support (at least at the time of the book's publish date), but I also can't find anything in the property defintions that would allow this, either.  Is this feature still on the wish list.

    What I am trying to do is create models in the data access layer (modules that would be separate installed features of my application) so some implementations would have a given set of tables while others would not.  This would allow me also to incrementally build the DAL.  Right now, trying to implement this using WCF/Entity Framework, my diagrams are overwhelming even when I select just a subset of tables.

    Thanks in advance for any pointers.

    Steve Miller

  • Tue, Sep 8 2009 20:08 In reply to

    Re: Multiple ORM definition file support

    Hi Steve

    Unfortunately, NORMA does not yet support reuse of externally defined subschemas, but this is one of the features that we do plan to add, along with much better support for relational schemas (e.g. multi-page diagrams, column order control, and incremental change support).

    Cheers

    Terry

  • Mon, Sep 28 2009 7:38 In reply to

    Re: Multiple ORM definition file support

     Steve,

     I cannot help with NORMA supporting multiple submodels, but the ability to merge ORM2 models (expressed in plain text using my Constellation Query Language) is a fairly short-term goal of mine - i.e. before the end of the year. CQL is much more manageable in a large project than NORMA, because it uses plain text that makes it easy to apply differential revision management and other tools.

    Even without the ability to break a definition into many separate models (CQL calls them vocabularies), it's possible of course to break one model into many files, and concatenate them before processing. I believe that I have a number of O(n^2) or worse algorithm loops which I may need to locate in order to make it feasible to effectively process a model of this size, but with your help, I'd certainly like to try. The SQL schemas I generate are of a generally comparable standard to those of NORMA, as of the release I have.

    There's no need for you to write the CQL by hand; my tools can generate it from the NORMA files. If you wish to contact me privately, I'd be happy to receive a copy of your model (in confidence, of course) to see how my tools perform, and for you to see how effective CQL may be as an alternate representation of your model. The conversion to CQL requires that some simple rules are followed with respect to the existence and structure of fact type readings and role names, but the rules are not onerous.

    The CQL tools are free open source software, and I can help you get started in using them.

Page 1 of 1 (3 items)
© 2008-2024 ------- Terms of Service