Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [e4-dev] Merging EMF models

Remy,

Comments below.


Remy Suen wrote:

Hi Ed, thanks for your response.

On Thu, Dec 3, 2009 at 1:59 PM, Ed Merks <ed.merks@xxxxxxxxx> wrote:
> > Consider a stack that has two parts, A and B, with a generated id of
> > partContainer.0.
>
> Are you talking about URI fragments here? E.g., //@partContainer.0

Right. I didn't want to make it specific [to URIs] but yeah, same idea. I was generalizing it to make it clear that a third-party could implement their own model reconciler and have it injected into an e4 application if they so desire.

> Index-based references are fragile in this way, but that's an issue
> primarily when the references are cross resource and the referenced resource
> can change on its own. I wonder if in your scenario something as simple as
> calling EcoreUtil.resolveAll would force all proxies to resolve before you
> start applying changes would avoid the problem....

I tried to write some code with that method added but it didn't seem like it made any difference. Though perhaps I am using it incorrectly and/or our ecore file isn't setup right to leverage this feature.

Yes, I'm not really sure how the broken references issue arises so not sure if eager resolving would help.


> Specializing XMIResourceImpl to override useUUIDs to return true will ensure
> that a UUID is associated with the object as soon as it's attached to that
> resource; these UUIDs are preserved if you move the object from one resource
> to another UUID-enabled resource. They won't change over time, but take a
> lot of space to maintain...

Thanks for the tip, Ed. This certainly resolves the auto-generation problem. It seems to me that all the id information would be lost when a "completely" new model (add a new part for my v2 application) is deployed, correct?

They're universally unique so yes, if there is a new model, then they're new objects with different/new IDs.

I think the memory issue can become a scalability problem but hm...

If we set the memory issue aside, I think what I need is a way to flag a field as being an identifier and non-null/empty.

Setting EAttribute.isID to true and marking it as required, i.e., lower bound 1 will do that.  It must be unique in the entire resource...

If the a new object is instantiated through the EMF editor (i.e. I right-click on a 'Window' and I go 'New Child' > 'Children Part'), the tooling should detect this and automatically generate an id for it on the fly and assign it so it shows up in the 'Properties' view.

You could modify the generated item providers to do such a thing.  The validator will check the constraints above.

The non-null/empty requirement should be validated via the EMF editor and/or at runtime in case the person uses a text editor to edit the model. This ensures that there are minimal changes between the new and old models during a layout change between updates of the application. This would be similar to overriding 'useUUIDs' to return true except that that seems to be a purely programmatic approach for ensuring identifiers are generated and cannot be tied in with existing EMF tooling. Perhaps I'm wrong here?

It seems to accomplish the same thing actually.


Of course, the idea above is not fool-proof since if I'm the designer and I accidentally deleted a part then I added it back by hand (instead of using undo), the generated id would be incompatible with the previous version.

When an object is removed from a resource, the UUID is remembered and if it's added back, the same ID is associated with it.

I suppose I could add code to consider these cases and handle them "intelligently" though this seems to imply an excessive amount of conditional statements, "guessing", handwaving, and pixie dust that is not within my budget.

Pixie dust is a valuable commodity!


> Is there any existing attribute on a
> partContainer that might act as a key (unique within that one reference) or
> as an ID (unique within the whole resource)?

We have an MApplicationElement that defines a java.lang.String 'id' attribute (though not every model object in the e4 model extends that interface, MKeyBinding would be one example). It's intended to be unique but since it's a modifiable attribute a conflict could occur in theory but I suppose if you're going to go ahead and change the identifier then you probably know what you're doing (or so I hope). If you had two workbench windows then I suppose it's not unique globally as it would not be unheard for the user to have the same view open in both windows. Nonetheless, it should be unique within that container anyway.

It would have to be unique within a resource to be an ID. It might make a useful key as well.


> Oops, I did all the commenting in line like it was a newsgroup question.
> Sorry.

I guess we'll just do the talking here then. :P

Regards,
Remy

----------
Remy Suen
Eclipse Platform/UI Committer
IBM Ottawa
613-356-5162


_______________________________________________ e4-dev mailing list e4-dev@xxxxxxxxxxx https://dev.eclipse.org/mailman/listinfo/e4-dev

Back to the top