Home » Modeling » EMF » Setting a "local ID" for objects
| Setting a "local ID" for objects [message #554405] |
Sun, 22 August 2010 20:24  |
 Volker Wegert
Messages: 182
Registered: July 2009 |
Senior Member |
|
|
Hello,
I need to implement the creation of a kind of "local object ID". The
requirements are:
- Somewhere in my object tree, I've got a sub-model (DataModel) that may
contain DataFields (abstract class). A DataField is either a
SimpleDataField (e. g. a String) or a TableDataField. A TableDataField may
again contain DataFields. Consequently, every SimpleDataField is
contained inside a DataModel, either directly or indirectly via a
TableDataField.
- Every DataField (both TableDataFields and SimpleDataFields) need to carry
an ID. The ID must an integer value less than 10.000 (*sigh*) and should be
generated starting from 1 without gaps. It must be unique within the
DataModel. The ID may not change when saving and reloading the
DataModel. It may not change if the DataField is moved inside the DataModel
(i. e, the order of fields is changed). It may not change if a DataField is
cut from the DataModel into the Clipboard and pasted back into the same
model. However, it has to be changed to a new ID if the DataField is pasted
into a different DataModel or pasted as an additional copy into the same
DataModel.
I am unsure about the way to implement this. I can easily have the DataModel
check for the highest ID present and return the next free ID, but I'm not sure
about where to set the ID. Up to now, I've used eInverseAdd, but during the
update to Helios, I realized that I was relying on an EMF weakness there that
apparently has been fixed. (My old meta-model had an opposite relationship to
the containment of DataModel --> DataField as well as a containment
TableDataField --> DataField - this never did work correctly, but nobody
noticed until now :-)).
I'm thinking about
- adding a secondary field to the DataField so that it is able to "remember"
the DataModel it originally belonged to
- having the DataModel watch out for inserted DataFields into either its own
containment feature or the TableDataFields, check for the "original"
DataModel and re-set the ID if necessary.
Do you think I'm on the right track? Also, I'm unsure on how to prevent the
DataModel from setting new IDs while the model is being loaded. Do you have
any suggestions there?
Thanks in advance
Volker
--
* Volker Wegert * http://www.volker-wegert.de/contact *
141 Reasons why you can't find your system administrator: 111. Trying to
*avoid* being in a meeting
|
|
|
| Re: Setting a "local ID" for objects [message #554408 is a reply to message #554405] |
Sun, 22 August 2010 20:39  |
Ed Merks
Messages: 33140
Registered: July 2009 |
Senior Member |
|
|
Volker,
You've modeled this as an EAttribute with isID true? Do you need the
model to do these things for you or is it sufficient that it happens
when editing? Certainly things like createAddCommand could be
specialized to set an ID that's computed from the context. The
InitializeCopy command could avoid copying the ID... Deserialization
should only set the ID exactly as it was serialized; isn't that what
you're wanting?
Volker Wegert wrote:
> Hello,
>
> I need to implement the creation of a kind of "local object ID". The
> requirements are:
>
> - Somewhere in my object tree, I've got a sub-model (DataModel) that may
> contain DataFields (abstract class). A DataField is either a
> SimpleDataField (e. g. a String) or a TableDataField. A TableDataField may
> again contain DataFields. Consequently, every SimpleDataField is
> contained inside a DataModel, either directly or indirectly via a
> TableDataField.
>
> - Every DataField (both TableDataFields and SimpleDataFields) need to carry
> an ID. The ID must an integer value less than 10.000 (*sigh*) and should be
> generated starting from 1 without gaps. It must be unique within the
> DataModel. The ID may not change when saving and reloading the
> DataModel. It may not change if the DataField is moved inside the DataModel
> (i. e, the order of fields is changed). It may not change if a DataField is
> cut from the DataModel into the Clipboard and pasted back into the same
> model. However, it has to be changed to a new ID if the DataField is pasted
> into a different DataModel or pasted as an additional copy into the same
> DataModel.
>
> I am unsure about the way to implement this. I can easily have the DataModel
> check for the highest ID present and return the next free ID, but I'm not sure
> about where to set the ID. Up to now, I've used eInverseAdd, but during the
> update to Helios, I realized that I was relying on an EMF weakness there that
> apparently has been fixed. (My old meta-model had an opposite relationship to
> the containment of DataModel --> DataField as well as a containment
> TableDataField --> DataField - this never did work correctly, but nobody
> noticed until now :-)).
>
> I'm thinking about
> - adding a secondary field to the DataField so that it is able to "remember"
> the DataModel it originally belonged to
> - having the DataModel watch out for inserted DataFields into either its own
> containment feature or the TableDataFields, check for the "original"
> DataModel and re-set the ID if necessary.
>
> Do you think I'm on the right track? Also, I'm unsure on how to prevent the
> DataModel from setting new IDs while the model is being loaded. Do you have
> any suggestions there?
>
> Thanks in advance
> Volker
>
>
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
|
| Re: Setting a "local ID" for objects [message #555200 is a reply to message #554408] |
Wed, 25 August 2010 19:25 |
Volker Wegert
Messages: 182
Registered: July 2009 |
Senior Member |
|
|
Ed,
answers below.
Ed Merks <Ed.Merks@gmail.com> writes:
> You've modeled this as an EAttribute with isID true?
Not yet, no. AFAIR I didn't do this because the ID is only unique for all
DataFields and subclasses within the model. Instances of other classes might
have other ID fields with the same values.
> Do you need the model to do these things for you or is it sufficient that it
> happens when editing?
That would be enough.
> Certainly things like createAddCommand could be specialized to set an ID
> that's computed from the context.
I've been trying to find this - it looks like a method of the ItemProvider,
but the only reference I could find was in help.eclipse.org/help33 - that
would be a bit outdated.
> The InitializeCopy command could avoid copying the ID...
From what I can see, that is instantiated by the CopyCommand, so I'd have to
override that, too - or did I moss something?
> Deserialization should only set the ID exactly as it was
> serialized; isn't that what you're wanting?
Exactly - if I move the ID generation out of the model classes, I won't have
to deal with this any longer.
Cheers
Volker
--
* Volker Wegert * http://www.volker-wegert.de/contact *
"You need the computing power of a Pentium, 16 MB RAM and 1 GB Harddisk to run
Win95. It took the computing power of 3 Commodore 64 to fly to the
Moon. Something is wrong here, and it wasn't the Apollo."
|
|
|
| Re: Setting a "local ID" for objects [message #555227 is a reply to message #555200] |
Wed, 25 August 2010 23:06 |
Ed Merks
Messages: 33140
Registered: July 2009 |
Senior Member |
|
|
This is a multi-part message in MIME format.
--------------060809050002070103090200
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Volker,
Comments below.
Volker Wegert wrote:
> Ed,
>
> answers below.
>
> Ed Merks <Ed.Merks@gmail.com> writes:
>
>> You've modeled this as an EAttribute with isID true?
>>
>
> Not yet, no. AFAIR I didn't do this because the ID is only unique for all
> DataFields and subclasses within the model. Instances of other classes might
> have other ID fields with the same values.
>
>
>> Do you need the model to do these things for you or is it sufficient that it
>> happens when editing?
>>
>
> That would be enough.
>
>
>> Certainly things like createAddCommand could be specialized to set an ID
>> that's computed from the context.
>>
>
> I've been trying to find this - it looks like a method of the ItemProvider,
> but the only reference I could find was in help.eclipse.org/help33 - that
> would be a bit outdated.
>
It's in every version of the Javadoc which is available from the
documentation page for all the EMF versions.
>
>> The InitializeCopy command could avoid copying the ID...
>>
>
> From what I can see, that is instantiated by the CopyCommand, so I'd have to
> override that, too - or did I moss something?
>
The item provider is a factory for all the different commands, so you
can override creation there. You should set breakpoints and watch how
things work...
>
>> Deserialization should only set the ID exactly as it was
>> serialized; isn't that what you're wanting?
>>
>
> Exactly - if I move the ID generation out of the model classes, I won't have
> to deal with this any longer.
>
> Cheers
> Volker
>
>
--------------060809050002070103090200
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
Volker,<br>
<br>
Comments below.<br>
<br>
<br>
Volker Wegert wrote:
<blockquote cite="mid:84k4nelckx.fsf@zak.home.volker-wegert.de"
type="cite">
<pre wrap="">Ed,
answers below.
Ed Merks <a class="moz-txt-link-rfc2396E" href="mailto:Ed.Merks@gmail.com"><Ed.Merks@gmail.com></a> writes:
</pre>
<blockquote type="cite">
<pre wrap="">You've modeled this as an EAttribute with isID true?
</pre>
</blockquote>
<pre wrap=""><!---->
Not yet, no. AFAIR I didn't do this because the ID is only unique for all
DataFields and subclasses within the model. Instances of other classes might
have other ID fields with the same values.
</pre>
<blockquote type="cite">
<pre wrap="">Do you need the model to do these things for you or is it sufficient that it
happens when editing?
</pre>
</blockquote>
<pre wrap=""><!---->
That would be enough.
</pre>
<blockquote type="cite">
<pre wrap="">Certainly things like createAddCommand could be specialized to set an ID
that's computed from the context.
</pre>
</blockquote>
<pre wrap=""><!---->
I've been trying to find this - it looks like a method of the ItemProvider,
but the only reference I could find was in help.eclipse.org/help33 - that
would be a bit outdated.
</pre>
</blockquote>
It's in every version of the Javadoc which is available from the
documentation page for all the EMF versions.<br>
<blockquote cite="mid:84k4nelckx.fsf@zak.home.volker-wegert.de"
type="cite">
<pre wrap="">
</pre>
<blockquote type="cite">
<pre wrap="">The InitializeCopy command could avoid copying the ID...
</pre>
</blockquote>
<pre wrap=""><!---->
From what I can see, that is instantiated by the CopyCommand, so I'd have to
override that, too - or did I moss something?
</pre>
</blockquote>
The item provider is a factory for all the different commands, so you
can override creation there. You should set breakpoints and watch how
things work...<br>
<blockquote cite="mid:84k4nelckx.fsf@zak.home.volker-wegert.de"
type="cite">
<pre wrap="">
</pre>
<blockquote type="cite">
<pre wrap="">Deserialization should only set the ID exactly as it was
serialized; isn't that what you're wanting?
</pre>
</blockquote>
<pre wrap=""><!---->
Exactly - if I move the ID generation out of the model classes, I won't have
to deal with this any longer.
Cheers
Volker
</pre>
</blockquote>
</body>
</html>
--------------060809050002070103090200--
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
|
| Re: Setting a "local ID" for objects [message #555792 is a reply to message #555227] |
Sat, 28 August 2010 20:19 |
Volker Wegert
Messages: 182
Registered: July 2009 |
Senior Member |
|
|
Ed Merks <Ed.Merks@gmail.com> writes:
> Volker Wegert wrote:
>> Ed Merks <Ed.Merks@gmail.com> writes:
>>> Certainly things like createAddCommand could be specialized to set an ID
>>> that's computed from the context.
>>
>> I've been trying to find this - it looks like a method of the ItemProvider,
>> but the only reference I could find was in help.eclipse.org/help33 - that
>> would be a bit outdated.
> It's in every version of the Javadoc which is available from the documentation
> page for all the EMF versions.
OK, found it, and it's working now - thanks for the pointer.
>>> The InitializeCopy command could avoid copying the ID...
>> From what I can see, that is instantiated by the CopyCommand, so I'd have to
>> override that, too - or did I moss something?
> The item provider is a factory for all the different commands, so you can
> override creation there. You should set breakpoints and watch how things
> work...
Thanks again, I think I understand things a little better now. I still have
one question related to the handling of copying and pasting objects. From what
I can see, the InitializeCopyCommand is used to copy the attributes and
references when copying an object from the model into the
clipboard. Naturally, this operation cannot copy the container
reference. Unfortunately, I need to know the container the original model
object was or is contained in when pasting an object. The reason for this is:
When cutting and pasting an object from/to the same container once, the ID may
not change. When pasting the object for a second time or if the object was
copied instead of cut, the ID has to be regenerated. When pasting the object
to a different container, the ID has to be changed. In other words: If the
source container is identical to the target container and the target container
still contains the original object, I need to regenerate the ID.
This means I can only decide whether I need to regenerate the ID when pasting
the object, and I need to have some details about the original object to do
so. I haven't found a way to carry this information from the
InitializeCopyCommand to the PasteFromClipboardCommand - is there any?
Thanks
Volker
--
* Volker Wegert * http://www.volker-wegert.de/contact *
"INTEL inside" - The world's most widely used warning label.
|
|
|
| Re: Setting a "local ID" for objects [message #555816 is a reply to message #555792] |
Sun, 29 August 2010 04:39 |
Ed Merks
Messages: 33140
Registered: July 2009 |
Senior Member |
|
|
This is a multi-part message in MIME format.
--------------020003070101090802080000
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Volker,
Comments below.
Volker Wegert wrote:
> Ed Merks <Ed.Merks@gmail.com> writes:
>
>> Volker Wegert wrote:
>>
>>> Ed Merks <Ed.Merks@gmail.com> writes:
>>>
>>>> Certainly things like createAddCommand could be specialized to set an ID
>>>> that's computed from the context.
>>>>
>>> I've been trying to find this - it looks like a method of the ItemProvider,
>>> but the only reference I could find was in help.eclipse.org/help33 - that
>>> would be a bit outdated.
>>>
>> It's in every version of the Javadoc which is available from the documentation
>> page for all the EMF versions.
>>
>
> OK, found it, and it's working now - thanks for the pointer.
>
>
>>>> The InitializeCopy command could avoid copying the ID...
>>>>
>>> From what I can see, that is instantiated by the CopyCommand, so I'd have to
>>> override that, too - or did I moss something?
>>>
>> The item provider is a factory for all the different commands, so you can
>> override creation there. You should set breakpoints and watch how things
>> work...
>>
>
> Thanks again, I think I understand things a little better now. I still have
> one question related to the handling of copying and pasting objects. From what
> I can see, the InitializeCopyCommand is used to copy the attributes and
> references when copying an object from the model into the
> clipboard.
Yes.
> Naturally, this operation cannot copy the container
> reference.
No, because the container would have to refer back to the contained
thing, which would modify it, and copying should not modify existing
objects.
> Unfortunately, I need to know the container the original model
> object was or is contained in when pasting an object.
Perhaps related to https://bugs.eclipse.org/bugs/show_bug.cgi?id=157074
> The reason for this is:
> When cutting and pasting an object from/to the same container once, the ID may
> not change.
On could argue that cut and paste isn't the same as cut and undo...
> When pasting the object for a second time or if the object was
> copied instead of cut, the ID has to be regenerated.
When pasting after a cut, the existing ID wouldn't conflict with any ID
existing in the tree...
> When pasting the object
> to a different container, the ID has to be changed. In other words: If the
> source container is identical to the target container and the target container
> still contains the original object, I need to regenerate the ID.
>
So it sounds like you should update the ID during the add, rather than
during the copy creation....
> This means I can only decide whether I need to regenerate the ID when pasting
> the object, and I need to have some details about the original object to do
> so.
None of the conditions you spelled out sounded like you should need to
know something about the original object. It sounds more like if you
copied the ID and then when you pasted it you changed it to be unique if
it conflicted, you'd be fine.
> I haven't found a way to carry this information from the
> InitializeCopyCommand to the PasteFromClipboardCommand - is there any?
>
Nothing jumps to mind, no...
> Thanks
> Volker
>
>
>
--------------020003070101090802080000
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
Volker,<br>
<br>
Comments below.<br>
<br>
<br>
Volker Wegert wrote:
<blockquote cite="mid:84pqx232yk.fsf@zak.home.volker-wegert.de"
type="cite">
<pre wrap="">Ed Merks <a class="moz-txt-link-rfc2396E" href="mailto:Ed.Merks@gmail.com"><Ed.Merks@gmail.com></a> writes:
</pre>
<blockquote type="cite">
<pre wrap="">Volker Wegert wrote:
</pre>
<blockquote type="cite">
<pre wrap="">Ed Merks <a class="moz-txt-link-rfc2396E" href="mailto:Ed.Merks@gmail.com"><Ed.Merks@gmail.com></a> writes:
</pre>
<blockquote type="cite">
<pre wrap="">Certainly things like createAddCommand could be specialized to set an ID
that's computed from the context.
</pre>
</blockquote>
<pre wrap="">I've been trying to find this - it looks like a method of the ItemProvider,
but the only reference I could find was in help.eclipse.org/help33 - that
would be a bit outdated.
</pre>
</blockquote>
<pre wrap="">It's in every version of the Javadoc which is available from the documentation
page for all the EMF versions.
</pre>
</blockquote>
<pre wrap=""><!---->
OK, found it, and it's working now - thanks for the pointer.
</pre>
<blockquote type="cite">
<blockquote type="cite">
<blockquote type="cite">
<pre wrap="">The InitializeCopy command could avoid copying the ID...
</pre>
</blockquote>
<pre wrap="">From what I can see, that is instantiated by the CopyCommand, so I'd have to
override that, too - or did I moss something?
</pre>
</blockquote>
<pre wrap="">The item provider is a factory for all the different commands, so you can
override creation there. You should set breakpoints and watch how things
work...
</pre>
</blockquote>
<pre wrap=""><!---->
Thanks again, I think I understand things a little better now. I still have
one question related to the handling of copying and pasting objects. From what
I can see, the InitializeCopyCommand is used to copy the attributes and
references when copying an object from the model into the
clipboard. </pre>
</blockquote>
Yes.<br>
<blockquote cite="mid:84pqx232yk.fsf@zak.home.volker-wegert.de"
type="cite">
<pre wrap="">Naturally, this operation cannot copy the container
reference.</pre>
</blockquote>
No, because the container would have to refer back to the contained
thing, which would modify it, and copying should not modify existing
objects.<br>
<blockquote cite="mid:84pqx232yk.fsf@zak.home.volker-wegert.de"
type="cite">
<pre wrap=""> Unfortunately, I need to know the container the original model
object was or is contained in when pasting an object. </pre>
</blockquote>
Perhaps related to <a
href="https://bugs.eclipse.org/bugs/show_bug.cgi?id=157074">https://bugs.eclipse.org/bugs/show_bug.cgi?id=157074</a><br>
<blockquote cite="mid:84pqx232yk.fsf@zak.home.volker-wegert.de"
type="cite">
<pre wrap="">The reason for this is:
When cutting and pasting an object from/to the same container once, the ID may
not change.</pre>
</blockquote>
On could argue that cut and paste isn't the same as cut and undo...<br>
<blockquote cite="mid:84pqx232yk.fsf@zak.home.volker-wegert.de"
type="cite">
<pre wrap=""> When pasting the object for a second time or if the object was
copied instead of cut, the ID has to be regenerated. </pre>
</blockquote>
When pasting after a cut, the existing ID wouldn't conflict with any ID
existing in the tree...<br>
<blockquote cite="mid:84pqx232yk.fsf@zak.home.volker-wegert.de"
type="cite">
<pre wrap=""> When pasting the object
to a different container, the ID has to be changed. In other words: If the
source container is identical to the target container and the target container
still contains the original object, I need to regenerate the ID.
</pre>
</blockquote>
So it sounds like you should update the ID during the add, rather than
during the copy creation....<br>
<blockquote cite="mid:84pqx232yk.fsf@zak.home.volker-wegert.de"
type="cite">
<pre wrap="">
This means I can only decide whether I need to regenerate the ID when pasting
the object, and I need to have some details about the original object to do
so. </pre>
</blockquote>
None of the conditions you spelled out sounded like you should need to
know something about the original object. It sounds more like if you
copied the ID and then when you pasted it you changed it to be unique
if it conflicted, you'd be fine.<br>
<blockquote cite="mid:84pqx232yk.fsf@zak.home.volker-wegert.de"
type="cite">
<pre wrap="">I haven't found a way to carry this information from the
InitializeCopyCommand to the PasteFromClipboardCommand - is there any?
</pre>
</blockquote>
Nothing jumps to mind, no...<br>
<blockquote cite="mid:84pqx232yk.fsf@zak.home.volker-wegert.de"
type="cite">
<pre wrap="">
Thanks
Volker
</pre>
</blockquote>
</body>
</html>
--------------020003070101090802080000--
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
|
| Re: Setting a "local ID" for objects [message #555870 is a reply to message #555816] |
Sun, 29 August 2010 20:08 |
Volker Wegert
Messages: 182
Registered: July 2009 |
Senior Member |
|
|
Ed,
Comments below.
Ed Merks <Ed.Merks@gmail.com> writes:
>> Unfortunately, I need to know the container the original model
>> object was or is contained in when pasting an object.
> Perhaps related to https://bugs.eclipse.org/bugs/show_bug.cgi?id=157074
Definitely, thanks for the link. I've CCed myself to this bug.
>> The reason for this is: When cutting and pasting an object from/to the same
>> container once, the ID may not change.
> On could argue that cut and paste isn't the same as cut and undo...
One could also argue that rearranging the order of elements should always
yield the same result, no matter how it was performed. Moving the objects
around with drag&drop operations does not change the IDs. Cutting objects and
pasting them at a different location within the same model should not change
the IDs either.
>> When pasting the object for a second time or if the object was
>> copied instead of cut, the ID has to be regenerated.
> When pasting after a cut, the existing ID wouldn't conflict with any ID
> existing in the tree...
When pasting for the first time, that's true - but you can cut once and paste
multiple times...
Perhaps I should explain the background a bit: The ID is used to generate
database structures in a legacy system. If cutting and copying the field
generates a new ID, the database table will get a new field and the old
contents won't be accessible any longer.
>> When pasting the object
>> to a different container, the ID has to be changed. In other words: If the
>> source container is identical to the target container and the target container
>> still contains the original object, I need to regenerate the ID.
> So it sounds like you should update the ID during the add, rather than during
> the copy creation....
Yes, definitely.
>> This means I can only decide whether I need to regenerate the ID when pasting
>> the object, and I need to have some details about the original object to do
>> so.
> None of the conditions you spelled out sounded like you should need to know
> something about the original object. It sounds more like if you copied the ID
> and then when you pasted it you changed it to be unique if it conflicted,
> you'd be fine.
Not really, it's more like "copy the ID, and when pasting it, under certain
very specific conditions, keep it, otherwise regenerate it".
>> I haven't found a way to carry this information from the
>> InitializeCopyCommand to the PasteFromClipboardCommand - is there any?
> Nothing jumps to mind, no...
I've rigged something now - generating transient GUIDs before the copy,
copying the container's ID into the contained object and comparing the GUIDs
during pasting. Rather kludgy, but it works for the moment...
Thanks for the help
Volker
--
* Volker Wegert * http://www.volker-wegert.de/contact *
"And yes, to me, headless does mean no video. But in my case it also means no
keyboard/mouse. Is that headless-armless-legless?" (unknown)
|
|
|
Goto Forum:
Current Time: Thu Apr 25 14:58:26 GMT 2024
Powered by FUDForum. Page generated in 0.03849 seconds |
] 
Search
Help
Register
Login
Home
