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.