The ORM Foundation

Hi,

Not sure what the procedure is for requesting a new feature.

So here goes: Is it possible to create a new file when selecting a page - maybe make it an option.  The main reason is because sometimes the main model doesn't need to change, but adding to a page may require lots of small changes.  That way it wouldn't need to update the main model page which can cause delays.

Also since the main model is almost set in stone then updates to the model at the page level should be more efficient as far as time delays saving to a large abstract orm model if instead it updates a single file at the page level.  Also, sometimes at the page level you might just want to keep its as a candidate update and not update the main model.  Only when you honed it to exact specs you want then you might push it to the main model.  But being able to revert back would be priceless. 

Anyway just ideas.

Thanks,

Marc 

 Hi Marc,

I'm fairly sure that each .orm file is stored as a single xml file - regardless of how big the .orm file is or how many pages are used to display it on the drawing surface.

So one solution is to save the model before you add another page and then save the new model with a different name - a crude "versioning" method.

If you search this site using the term "merge" you will find several discussions on various aspects of merging models.  

I have asked Matt to reply to your request.

In the meantime, it would be helpful if you tell us more about the problem you have with what you call "time delays"

Ken

 Hi Ken,

Ken>So one solution is to save the model before you add another page and then save the new model with a different name - a crude "versioning" method.

 Yes that is what I'm doing now.  I'm using it in an Oracle 11g and 12c environment right now and a single SCHEMA can really have ton of tables in it.  Since I'm updating at the page level it can take some time for it to save the new model parameters when the orm xml file is large.  So that forces me to prune the Object Model a lot if I want it to be more responsive.  I wish it showed only the root entities, but if I really have to do that fast there is always deleting directly from the xml which isn't that hard and doesn't require XSLT or XPATH all the time by gathering lists of objects ids I want to keep and then dropping all the ones I don't want to keep.

Ken>If you search this site using the term "merge" you will find several discussions on various aspects of merging models.

 That could definitely be useful, but using your point as only a reference I would need to make a split first from the main model using my use case.  Maybe make shards from the main model where a transform looks at a page and derives a new orm model from that page and only the most relevant orm models survive to that new orm file maybe where objects that survive are only objects on that one page.  Then the merge might be useful if I wanted to apply the updated model from the shard back to the main model.  That's still iffy, though, considering the complexities involved but I think it is definitely doable. I think there is a reason to do this, its basically when you have an unwieldy large orm model that this might be advantageous as a subset would definitely be easier to work with.

Ken>In the meantime, it would be helpful if you tell us more about the problem you have with what you call "time delays"

The time delays are caused when the orm model is generated from an existing database schema and that schema contains many tables and constraints where there are greater than 100 individual tables and some of the tables can be 250 different columns.  So the hurdles are when the client needs a fix fast and there are some IDE delays.  These IDE delays are caused b/c the .orm file which is an xml file has to be updated, or re-written over.  Unfortunately the process is not always perfect and hardly ever fast for large models when deadlines are looming.

Also what I like about having the main ORM model browser is being able to edit directly on the model browser or the ORM Entity browser.  I can start typing and go directly to an entity, see it in the concept model, and quickly make updates, changes, notes etc..   But the problem with the ORM model browser is it has a limit feature set, so I can start updating it directly from the orm model browser but get stuck if I want to do something slightly clever. If I could add fact types, or modify fact types, or rename things or filter, then that would make life so much easier.  But again for that to work it needs to work on large numbers of orm models for it to be really useful (responsive) for those types of use cases. 

What I don't like about the Orm Model browser is that there can be a ridiculous number of value types and they may closely resemble the entity name and get in the way trying to find the main entity.  So it would be very useful to have better filters to search only main entities and ignore values types or certain fact types why typing in a name at the ORM Model Browser.  This is exponentially compounded when you do merges where you trick the schema name into becoming the first part of every value type like myschemaname_thevaluetypename.

Again these are Just ideas that would help me, not sure if it would benefit anyone else.

Regards, 

Marc 

Hi Marc,

Thanks for your comprehensive explanation.
I have asked Terry & Matt to comment.

One thing that stands out from your post is the idea of tables with 250 columns.

Whilst in your case, there may be a good reason for 250 column tables, in general, I have found that this a symptom of a schema design that has not been properly thought through at the conceptual level.

What I have done in such cases is to use the report generator to print out the reverse engineered database model, show the print out to the "domain experts" and ask them "Is this what the database is supposed to mean"?

As a test, generate a report for just one or two of the 250+ column tables and see what the domain experts say.

One response that you may get is:
"OK - the schema design needs to change, but if we do that then we would have to change lots of code that is written against the existing schema."

Then you need to explain to the project sponsors that the lifetime cost of making frequent changes to a flawed schema is likley to be much greater than getting the schema right and proceeding from there.

Ken