Home » Modeling » EMF "Technology" (Ecore Tools, EMFatic, etc) » EMF Compare & ChangeDescription on Teneo/Database backed EMF objects
|
| Re: EMF Compare & ChangeDescription on Teneo/Database backed EMF objects [message #125165 is a reply to message #125164] |
Thu, 05 June 2008 20:53   |
 Martin Taal
Messages: 5468
Registered: July 2009 |
Senior Member |
|
|
Hi Jason,
I think that a change descriptor with a list index won't even work in an environment were the list
index was also present in the db. Assume that the server receives the changedescription you listed
below. Now between the time the object was passed to the client and the changedescription comes back
the list has been adapted by another client then the indexes in the list will have changed anyway.
Or do you prevent this by doing a version check?
To solve this what you mean is that the changedescription should be recorded as:
<value featureName="contactList">
<listChanges kind="REMOVE" id="5_myentityname"/>
</value>
(whereby id is something encoding the id and the entityname)
correct?
I think this is more an emf question than a Teneo question though.
gr. Martin
jason henriksen wrote:
> Hi all,
>
> This is really a theoretical concern that I want to put in your brains,
> more than a specific bug. That said, I'm worried that the current
> implementation of ChangeDescription is going to bite me if I use it as
> it is.
>
> I've just recorded a ChangeDescription on an object I held in my client
> tier. The change description has a part that looks like this:
>
> <value featureName="contactList">
> <listChanges kind="REMOVE" index="4"/>
> </value>
>
> On the server I receive the change description, load the referenced
> object out of the database and get ready to apply the change to the
> Teneo backed object.
>
> But here's the rub: Teneo/Hibernate does NOT guarantee that the objects
> in the child list will be in the same order each time it is loaded from
> the DB! (unlike a filesystem file that is the same each time you load
> it) I can force Teneo to track the child-object-order but that means
> adding a column to the database and sorting by that column when I
> populate the list. Since my EMF objects are sitting on top of a legacy
> database I can't easily do that plus it's a lot of error prone work to
> make sure that's done correctly for every child list in the data model.
>
> So now if I apply the change I'm going to delete whatever child object
> happens to be in position 4 even though the order of the list may have
> been shuffled. Oops.
>
> Here's a possible solution: Database backed objects should all have an
> @Id member in them. If the listChanges tag contained the value of the
> ID column whenever it is present then we could use these
> ChangeDescriptions on DB backed objects and be safe. As it is,
> ChangeDescription + Teneo backed EMF = potentially lost data unless your
> Teneo annotations are very specific and carefully checked.
>
> Is that analysis correct, or does Ed have some magic up his sleeve?
>
> Thanks all,
>
> Jason Henriksen
>
>
--
With Regards, Martin Taal
Springsite/Elver.org
Office: Hardwareweg 4, 3821 BV Amersfoort
Postal: Nassaulaan 7, 3941 EC Doorn
The Netherlands
Cell: +31 (0)6 288 48 943
Tel: +31 (0)84 420 2397
Fax: +31 (0)84 225 9307
Mail: mtaal@springsite.com - mtaal@elver.org
Web: www.springsite.com - www.elver.org
|
|
| |
| Re: EMF Compare & ChangeDescription on Teneo/Database backed EMF objects [message #125167 is a reply to message #125165] |
Thu, 05 June 2008 21:21 |
Eclipse User |
|
|
|
Originally posted by: merks.ca.ibm.com
Martin,
A change description for which the referenced model has changed in some
potentially arbitrary way just isn't coherent. Imagine trying to add to
a specific location in a list, but the list has different contents;
what's the right location. It's possible to set values explicitly and
have them serialized too...
Martin Taal wrote:
> Hi Jason,
> I think that a change descriptor with a list index won't even work in
> an environment were the list index was also present in the db. Assume
> that the server receives the changedescription you listed below. Now
> between the time the object was passed to the client and the
> changedescription comes back the list has been adapted by another
> client then the indexes in the list will have changed anyway. Or do
> you prevent this by doing a version check?
>
> To solve this what you mean is that the changedescription should be
> recorded as:
> <value featureName="contactList">
> <listChanges kind="REMOVE" id="5_myentityname"/>
> </value>
> (whereby id is something encoding the id and the entityname)
>
> correct?
>
> I think this is more an emf question than a Teneo question though.
>
> gr. Martin
>
> jason henriksen wrote:
>> Hi all,
>>
>> This is really a theoretical concern that I want to put in your
>> brains, more than a specific bug. That said, I'm worried that the
>> current implementation of ChangeDescription is going to bite me if I
>> use it as it is.
>>
>> I've just recorded a ChangeDescription on an object I held in my
>> client tier. The change description has a part that looks like this:
>>
>> <value featureName="contactList">
>> <listChanges kind="REMOVE" index="4"/>
>> </value>
>>
>> On the server I receive the change description, load the referenced
>> object out of the database and get ready to apply the change to the
>> Teneo backed object.
>>
>> But here's the rub: Teneo/Hibernate does NOT guarantee that the
>> objects in the child list will be in the same order each time it is
>> loaded from the DB! (unlike a filesystem file that is the same each
>> time you load it) I can force Teneo to track the child-object-order
>> but that means adding a column to the database and sorting by that
>> column when I populate the list. Since my EMF objects are sitting on
>> top of a legacy database I can't easily do that plus it's a lot of
>> error prone work to make sure that's done correctly for every child
>> list in the data model.
>>
>> So now if I apply the change I'm going to delete whatever child
>> object happens to be in position 4 even though the order of the list
>> may have been shuffled. Oops.
>>
>> Here's a possible solution: Database backed objects should all have
>> an @Id member in them. If the listChanges tag contained the value of
>> the ID column whenever it is present then we could use these
>> ChangeDescriptions on DB backed objects and be safe. As it is,
>> ChangeDescription + Teneo backed EMF = potentially lost data unless
>> your Teneo annotations are very specific and carefully checked.
>>
>> Is that analysis correct, or does Ed have some magic up his sleeve?
>>
>> Thanks all,
>>
>> Jason Henriksen
>>
>>
>
>
|
|
|
| Re: EMF Compare & ChangeDescription on Teneo/Database backed EMF objects [message #125168 is a reply to message #125167] |
Thu, 05 June 2008 21:46 |
Martin Taal
Messages: 5468
Registered: July 2009 |
Senior Member |
|
|
Hi Ed,
Yes, but is there a way to handle non-ordered lists using change descriptors?
gr. Martin
Ed Merks wrote:
> Martin,
>
> A change description for which the referenced model has changed in some
> potentially arbitrary way just isn't coherent. Imagine trying to add to
> a specific location in a list, but the list has different contents;
> what's the right location. It's possible to set values explicitly and
> have them serialized too...
>
>
> Martin Taal wrote:
>> Hi Jason,
>> I think that a change descriptor with a list index won't even work in
>> an environment were the list index was also present in the db. Assume
>> that the server receives the changedescription you listed below. Now
>> between the time the object was passed to the client and the
>> changedescription comes back the list has been adapted by another
>> client then the indexes in the list will have changed anyway. Or do
>> you prevent this by doing a version check?
>>
>> To solve this what you mean is that the changedescription should be
>> recorded as:
>> <value featureName="contactList">
>> <listChanges kind="REMOVE" id="5_myentityname"/>
>> </value>
>> (whereby id is something encoding the id and the entityname)
>>
>> correct?
>>
>> I think this is more an emf question than a Teneo question though.
>>
>> gr. Martin
>>
>> jason henriksen wrote:
>>> Hi all,
>>>
>>> This is really a theoretical concern that I want to put in your
>>> brains, more than a specific bug. That said, I'm worried that the
>>> current implementation of ChangeDescription is going to bite me if I
>>> use it as it is.
>>>
>>> I've just recorded a ChangeDescription on an object I held in my
>>> client tier. The change description has a part that looks like this:
>>>
>>> <value featureName="contactList">
>>> <listChanges kind="REMOVE" index="4"/>
>>> </value>
>>>
>>> On the server I receive the change description, load the referenced
>>> object out of the database and get ready to apply the change to the
>>> Teneo backed object.
>>>
>>> But here's the rub: Teneo/Hibernate does NOT guarantee that the
>>> objects in the child list will be in the same order each time it is
>>> loaded from the DB! (unlike a filesystem file that is the same each
>>> time you load it) I can force Teneo to track the child-object-order
>>> but that means adding a column to the database and sorting by that
>>> column when I populate the list. Since my EMF objects are sitting on
>>> top of a legacy database I can't easily do that plus it's a lot of
>>> error prone work to make sure that's done correctly for every child
>>> list in the data model.
>>>
>>> So now if I apply the change I'm going to delete whatever child
>>> object happens to be in position 4 even though the order of the list
>>> may have been shuffled. Oops.
>>>
>>> Here's a possible solution: Database backed objects should all have
>>> an @Id member in them. If the listChanges tag contained the value of
>>> the ID column whenever it is present then we could use these
>>> ChangeDescriptions on DB backed objects and be safe. As it is,
>>> ChangeDescription + Teneo backed EMF = potentially lost data unless
>>> your Teneo annotations are very specific and carefully checked.
>>>
>>> Is that analysis correct, or does Ed have some magic up his sleeve?
>>>
>>> Thanks all,
>>>
>>> Jason Henriksen
>>>
>>>
>>
>>
--
With Regards, Martin Taal
Springsite/Elver.org
Office: Hardwareweg 4, 3821 BV Amersfoort
Postal: Nassaulaan 7, 3941 EC Doorn
The Netherlands
Cell: +31 (0)6 288 48 943
Tel: +31 (0)84 420 2397
Fax: +31 (0)84 225 9307
Mail: mtaal@springsite.com - mtaal@elver.org
Web: www.springsite.com - www.elver.org
|
|
|
| Re: EMF Compare & ChangeDescription on Teneo/Database backed EMF objects [message #125169 is a reply to message #125168] |
Thu, 05 June 2008 22:44 |
| Eclipse User |
|
|
|
Originally posted by: merks.ca.ibm.com
This is a multi-part message in MIME format.
--------------080903090802060303080803
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Martin,
List verses unordered are mutually exclusive terms since lists are
ordered collections. Is there a way to just treat a multi-valued
feature as a just set? No, EMF assumes that all features are backed by
lists and even if order has no deep semantic meaning, order is something
that's intended to be preserved and will be preserved. Some old
bugzillas are open regarding this type of issue:
https://bugs.eclipse.org/bugs/show_bug.cgi?id=75931
https://bugs.eclipse.org/bugs/show_bug.cgi?id=89325
It's very hard to change the framework break assumptions of the past...
Martin Taal wrote:
> Hi Ed,
> Yes, but is there a way to handle non-ordered lists using change
> descriptors?
>
> gr. Martin
>
> Ed Merks wrote:
>> Martin,
>>
>> A change description for which the referenced model has changed in
>> some potentially arbitrary way just isn't coherent. Imagine trying
>> to add to a specific location in a list, but the list has different
>> contents; what's the right location. It's possible to set values
>> explicitly and have them serialized too...
>>
>>
>> Martin Taal wrote:
>>> Hi Jason,
>>> I think that a change descriptor with a list index won't even work
>>> in an environment were the list index was also present in the db.
>>> Assume that the server receives the changedescription you listed
>>> below. Now between the time the object was passed to the client and
>>> the changedescription comes back the list has been adapted by
>>> another client then the indexes in the list will have changed
>>> anyway. Or do you prevent this by doing a version check?
>>>
>>> To solve this what you mean is that the changedescription should be
>>> recorded as:
>>> <value featureName="contactList">
>>> <listChanges kind="REMOVE" id="5_myentityname"/>
>>> </value>
>>> (whereby id is something encoding the id and the entityname)
>>>
>>> correct?
>>>
>>> I think this is more an emf question than a Teneo question though.
>>>
>>> gr. Martin
>>>
>>> jason henriksen wrote:
>>>> Hi all,
>>>>
>>>> This is really a theoretical concern that I want to put in your
>>>> brains, more than a specific bug. That said, I'm worried that the
>>>> current implementation of ChangeDescription is going to bite me if
>>>> I use it as it is.
>>>>
>>>> I've just recorded a ChangeDescription on an object I held in my
>>>> client tier. The change description has a part that looks like this:
>>>>
>>>> <value featureName="contactList">
>>>> <listChanges kind="REMOVE" index="4"/>
>>>> </value>
>>>>
>>>> On the server I receive the change description, load the referenced
>>>> object out of the database and get ready to apply the change to the
>>>> Teneo backed object.
>>>>
>>>> But here's the rub: Teneo/Hibernate does NOT guarantee that the
>>>> objects in the child list will be in the same order each time it is
>>>> loaded from the DB! (unlike a filesystem file that is the same each
>>>> time you load it) I can force Teneo to track the
>>>> child-object-order but that means adding a column to the database
>>>> and sorting by that column when I populate the list. Since my EMF
>>>> objects are sitting on top of a legacy database I can't easily do
>>>> that plus it's a lot of error prone work to make sure that's done
>>>> correctly for every child list in the data model.
>>>>
>>>> So now if I apply the change I'm going to delete whatever child
>>>> object happens to be in position 4 even though the order of the
>>>> list may have been shuffled. Oops.
>>>>
>>>> Here's a possible solution: Database backed objects should all
>>>> have an @Id member in them. If the listChanges tag contained the
>>>> value of the ID column whenever it is present then we could use
>>>> these ChangeDescriptions on DB backed objects and be safe. As it
>>>> is, ChangeDescription + Teneo backed EMF = potentially lost data
>>>> unless your Teneo annotations are very specific and carefully checked.
>>>>
>>>> Is that analysis correct, or does Ed have some magic up his sleeve?
>>>>
>>>> Thanks all,
>>>>
>>>> Jason Henriksen
>>>>
>>>>
>>>
>>>
>
>
--------------080903090802060303080803
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">
Martin,<br>
<br>
List verses unordered are mutually exclusive terms since lists are
ordered collections. Is there a way to just treat a multi-valued
feature as a just set? No, EMF assumes that all features are backed by
lists and even if order has no deep semantic meaning, order is
something that's intended to be preserved and will be preserved. Some
old bugzillas are open regarding this type of issue:<br>
<blockquote><a
href="https://bugs.eclipse.org/bugs/show_bug.cgi?id=75931">https://bugs.eclipse.org/bugs/show_bug.cgi?id=75931</a><br>
<a href="https://bugs.eclipse.org/bugs/show_bug.cgi?id=89325">https://bugs.eclipse.org/bugs/show_bug.cgi?id=89325</a><br>
</blockquote>
It's very hard to change the framework break assumptions of the past...<br>
<br>
<br>
Martin Taal wrote:
<blockquote cite="mid:g29mr9$2nf$1@build.eclipse.org" type="cite">Hi
Ed,
<br>
Yes, but is there a way to handle non-ordered lists using change
descriptors?
<br>
<br>
gr. Martin
<br>
<br>
Ed Merks wrote:
<br>
<blockquote type="cite">Martin,
<br>
<br>
A change description for which the referenced model has changed in some
potentially arbitrary way just isn't coherent. Imagine trying to add
to a specific location in a list, but the list has different contents;
what's the right location. It's possible to set values explicitly and
have them serialized too...
<br>
<br>
<br>
Martin Taal wrote:
<br>
<blockquote type="cite">Hi Jason,
<br>
I think that a change descriptor with a list index won't even work in
an environment were the list index was also present in the db. Assume
that the server receives the changedescription you listed below. Now
between the time the object was passed to the client and the
changedescription comes back the list has been adapted by another
client then the indexes in the list will have changed anyway. Or do you
prevent this by doing a version check?
<br>
<br>
To solve this what you mean is that the changedescription should be
recorded as:
<br>
<value featureName="contactList">
<br>
<listChanges kind="REMOVE" id="5_myentityname"/>
<br>
</value>
<br>
(whereby id is something encoding the id and the entityname)
<br>
<br>
correct?
<br>
<br>
I think this is more an emf question than a Teneo question though.
<br>
<br>
gr. Martin
<br>
<br>
jason henriksen wrote:
<br>
<blockquote type="cite">Hi all,
<br>
<br>
This is really a theoretical concern that I want to put in your brains,
more than a specific bug. That said, I'm worried that the current
implementation of ChangeDescription is going to bite me if I use it as
it is.
<br>
<br>
I've just recorded a ChangeDescription on an object I held in my client
tier. The change description has a part that looks like this:
<br>
<br>
<value featureName="contactList">
<br>
<listChanges kind="REMOVE" index="4"/>
<br>
</value>
<br>
<br>
On the server I receive the change description, load the referenced
object out of the database and get ready to apply the change to the
Teneo backed object.
<br>
<br>
But here's the rub: Teneo/Hibernate does NOT guarantee that the
objects in the child list will be in the same order each time it is
loaded from the DB! (unlike a filesystem file that is the same each
time you load it) I can force Teneo to track the child-object-order
but that means adding a column to the database and sorting by that
column when I populate the list. Since my EMF objects are sitting on
top of a legacy database I can't easily do that plus it's a lot of
error prone work to make sure that's done correctly for every child
list in the data model.
<br>
<br>
So now if I apply the change I'm going to delete whatever child object
happens to be in position 4 even though the order of the list may have
been shuffled. Oops.
<br>
<br>
Here's a possible solution: Database backed objects should all have an
@Id member in them. If the listChanges tag contained the value of the
ID column whenever it is present then we could use these
ChangeDescriptions on DB backed objects and be safe. As it is,
ChangeDescription + Teneo backed EMF = potentially lost data unless
your Teneo annotations are very specific and carefully checked.
<br>
<br>
Is that analysis correct, or does Ed have some magic up his sleeve?
<br>
<br>
Thanks all,
<br>
<br>
Jason Henriksen
<br>
<br>
<br>
</blockquote>
<br>
<br>
</blockquote>
</blockquote>
<br>
<br>
</blockquote>
<br>
</body>
</html>
--------------080903090802060303080803--
|
|
|
| Re: EMF Compare & ChangeDescription on Teneo/Database backed EMF objects [message #125170 is a reply to message #125165] |
Thu, 05 June 2008 23:06 |
Jason Henriksen
Messages: 231
Registered: July 2009 |
Senior Member |
|
|
HaHA! Maybe this was a red herring of a problem!
On further analysis I've found that if I make the object have an
attribute with type xsd:ID then my child object references go from being
an index into being a URL that contains the REAL ID TEXT! This is a big
win because it means that the order of the listing is no longer
important at all.
For example:
<subDiffElements xsi:type="diff:UpdateAttribute">
<attribute
href="http:///com/ibm/example/Building.ecore#//Building/size"
/>
<leftElement href="original.xml#home"/>
<rightElement href="altered.xml#vacation home"/>
</subDiffElements>
From what I've ready, Teneo will automatically set EAttribute.isID()
true on any objects that have the @Id annotation set. Is that true?
Will that work if the attribute is a long instead of a String?
If so, then I don't actually have a problem at all.
Jason
Martin Taal wrote:
> Hi Jason,
> I think that a change descriptor with a list index won't even work in an
> environment were the list index was also present in the db. Assume that
> the server receives the changedescription you listed below. Now between
> the time the object was passed to the client and the changedescription
> comes back the list has been adapted by another client then the indexes
> in the list will have changed anyway. Or do you prevent this by doing a
> version check?
>
> To solve this what you mean is that the changedescription should be
> recorded as:
> <value featureName="contactList">
> <listChanges kind="REMOVE" id="5_myentityname"/>
> </value>
> (whereby id is something encoding the id and the entityname)
>
> correct?
>
> I think this is more an emf question than a Teneo question though.
>
> gr. Martin
>
> jason henriksen wrote:
>> Hi all,
>>
>> This is really a theoretical concern that I want to put in your
>> brains, more than a specific bug. That said, I'm worried that the
>> current implementation of ChangeDescription is going to bite me if I
>> use it as it is.
>>
>> I've just recorded a ChangeDescription on an object I held in my
>> client tier. The change description has a part that looks like this:
>>
>> <value featureName="contactList">
>> <listChanges kind="REMOVE" index="4"/>
>> </value>
>>
>> On the server I receive the change description, load the referenced
>> object out of the database and get ready to apply the change to the
>> Teneo backed object.
>>
>> But here's the rub: Teneo/Hibernate does NOT guarantee that the
>> objects in the child list will be in the same order each time it is
>> loaded from the DB! (unlike a filesystem file that is the same each
>> time you load it) I can force Teneo to track the child-object-order
>> but that means adding a column to the database and sorting by that
>> column when I populate the list. Since my EMF objects are sitting on
>> top of a legacy database I can't easily do that plus it's a lot of
>> error prone work to make sure that's done correctly for every child
>> list in the data model.
>>
>> So now if I apply the change I'm going to delete whatever child object
>> happens to be in position 4 even though the order of the list may have
>> been shuffled. Oops.
>>
>> Here's a possible solution: Database backed objects should all have
>> an @Id member in them. If the listChanges tag contained the value of
>> the ID column whenever it is present then we could use these
>> ChangeDescriptions on DB backed objects and be safe. As it is,
>> ChangeDescription + Teneo backed EMF = potentially lost data unless
>> your Teneo annotations are very specific and carefully checked.
>>
>> Is that analysis correct, or does Ed have some magic up his sleeve?
>>
>> Thanks all,
>>
>> Jason Henriksen
>>
>>
>
>
|
|
|
| Re: EMF Compare & ChangeDescription on Teneo/Database backed EMF objects [message #125173 is a reply to message #125170] |
Fri, 06 June 2008 04:41 |
Martin Taal
Messages: 5468
Registered: July 2009 |
Senior Member |
|
|
Hi Jason,
Teneo does not set the EAttribute.isId for you. Also as I understand it the isId should be set on
the client and not on the server (where Teneo runs).
However, assuming that the client has the ecore with the annotations then it is very easy to set the
id of the attributes which have a @Id annotation. Just iterate over the epackages, eclasses,
eattributes, check the eannotation and if it contains @Id call eAttribute.setId(true).
gr. Martin
jason henriksen wrote:
>
> HaHA! Maybe this was a red herring of a problem!
>
> On further analysis I've found that if I make the object have an
> attribute with type xsd:ID then my child object references go from being
> an index into being a URL that contains the REAL ID TEXT! This is a big
> win because it means that the order of the listing is no longer
> important at all.
>
> For example:
>
> <subDiffElements xsi:type="diff:UpdateAttribute">
> <attribute
> href="http:///com/ibm/example/Building.ecore#//Building/size"
> />
> <leftElement href="original.xml#home"/>
> <rightElement href="altered.xml#vacation home"/>
> </subDiffElements>
>
>
> From what I've ready, Teneo will automatically set EAttribute.isID()
> true on any objects that have the @Id annotation set. Is that true?
> Will that work if the attribute is a long instead of a String?
> If so, then I don't actually have a problem at all.
>
> Jason
>
>
>
> Martin Taal wrote:
>> Hi Jason,
>> I think that a change descriptor with a list index won't even work in
>> an environment were the list index was also present in the db. Assume
>> that the server receives the changedescription you listed below. Now
>> between the time the object was passed to the client and the
>> changedescription comes back the list has been adapted by another
>> client then the indexes in the list will have changed anyway. Or do
>> you prevent this by doing a version check?
>>
>> To solve this what you mean is that the changedescription should be
>> recorded as:
>> <value featureName="contactList">
>> <listChanges kind="REMOVE" id="5_myentityname"/>
>> </value>
>> (whereby id is something encoding the id and the entityname)
>>
>> correct?
>>
>> I think this is more an emf question than a Teneo question though.
>>
>> gr. Martin
>>
>> jason henriksen wrote:
>>> Hi all,
>>>
>>> This is really a theoretical concern that I want to put in your
>>> brains, more than a specific bug. That said, I'm worried that the
>>> current implementation of ChangeDescription is going to bite me if I
>>> use it as it is.
>>>
>>> I've just recorded a ChangeDescription on an object I held in my
>>> client tier. The change description has a part that looks like this:
>>>
>>> <value featureName="contactList">
>>> <listChanges kind="REMOVE" index="4"/>
>>> </value>
>>>
>>> On the server I receive the change description, load the referenced
>>> object out of the database and get ready to apply the change to the
>>> Teneo backed object.
>>>
>>> But here's the rub: Teneo/Hibernate does NOT guarantee that the
>>> objects in the child list will be in the same order each time it is
>>> loaded from the DB! (unlike a filesystem file that is the same each
>>> time you load it) I can force Teneo to track the child-object-order
>>> but that means adding a column to the database and sorting by that
>>> column when I populate the list. Since my EMF objects are sitting on
>>> top of a legacy database I can't easily do that plus it's a lot of
>>> error prone work to make sure that's done correctly for every child
>>> list in the data model.
>>>
>>> So now if I apply the change I'm going to delete whatever child
>>> object happens to be in position 4 even though the order of the list
>>> may have been shuffled. Oops.
>>>
>>> Here's a possible solution: Database backed objects should all have
>>> an @Id member in them. If the listChanges tag contained the value of
>>> the ID column whenever it is present then we could use these
>>> ChangeDescriptions on DB backed objects and be safe. As it is,
>>> ChangeDescription + Teneo backed EMF = potentially lost data unless
>>> your Teneo annotations are very specific and carefully checked.
>>>
>>> Is that analysis correct, or does Ed have some magic up his sleeve?
>>>
>>> Thanks all,
>>>
>>> Jason Henriksen
>>>
>>>
>>
>>
--
With Regards, Martin Taal
Springsite/Elver.org
Office: Hardwareweg 4, 3821 BV Amersfoort
Postal: Nassaulaan 7, 3941 EC Doorn
The Netherlands
Cell: +31 (0)6 288 48 943
Tel: +31 (0)84 420 2397
Fax: +31 (0)84 225 9307
Mail: mtaal@springsite.com - mtaal@elver.org
Web: www.springsite.com - www.elver.org
|
|
| | |
| Re: EMF Compare & ChangeDescription on Teneo/Database backed EMF objects [message #125292 is a reply to message #125279] |
Fri, 06 June 2008 20:30 |
| Eclipse User |
|
|
|
Originally posted by: merks.ca.ibm.com
Jason,
Keep in mind that an ID must be an NCName so an integer is not a
conforming thing. You might create a restricted ID so that it's _
followed by digits (where the first digit can't be 0), and then map it
to a a long with a value to string conversion that eats/inserts the "_"...
Martin Taal wrote:
> Hi Jason,
> Afaik normally xsd:ID maps to a string in ecore but maybe using an
> edatatype/instanceclass would prevent this. So yes this sounds like a
> good approach to me.
>
> gr. Martin
>
> jason henriksen wrote:
>> Martin Taal wrote:
>>
>>> Hi Jason,
>>> Teneo does not set the EAttribute.isId for you. Also as I understand
>>> it the isId should be set on the client and not on the server (where
>>> Teneo runs).
>>
>> Would it hurt anything if I used xsd:ID as the type for my @Id fields
>> and then used instance type to make the id into a long so that it
>> matches the database?
>>
>> Unfortunately, the front end software may be run at a 3rd party
>> company. Therefore all database information is stripped from the XSD
>> before it is presented to them. However if the type is xsd:ID then
>> it wont matter, so long as I can make sure that Teneo doesn't get
>> confused by that.
>>
>>
>> Jason
>
>
|
|
|
| Re: EMF Compare & ChangeDescription on Teneo/Database backed EMF objects [message #619183 is a reply to message #125164] |
Thu, 05 June 2008 20:53 |
Martin Taal
Messages: 5468
Registered: July 2009 |
Senior Member |
|
|
Hi Jason,
I think that a change descriptor with a list index won't even work in an environment were the list
index was also present in the db. Assume that the server receives the changedescription you listed
below. Now between the time the object was passed to the client and the changedescription comes back
the list has been adapted by another client then the indexes in the list will have changed anyway.
Or do you prevent this by doing a version check?
To solve this what you mean is that the changedescription should be recorded as:
<value featureName="contactList">
<listChanges kind="REMOVE" id="5_myentityname"/>
</value>
(whereby id is something encoding the id and the entityname)
correct?
I think this is more an emf question than a Teneo question though.
gr. Martin
jason henriksen wrote:
> Hi all,
>
> This is really a theoretical concern that I want to put in your brains,
> more than a specific bug. That said, I'm worried that the current
> implementation of ChangeDescription is going to bite me if I use it as
> it is.
>
> I've just recorded a ChangeDescription on an object I held in my client
> tier. The change description has a part that looks like this:
>
> <value featureName="contactList">
> <listChanges kind="REMOVE" index="4"/>
> </value>
>
> On the server I receive the change description, load the referenced
> object out of the database and get ready to apply the change to the
> Teneo backed object.
>
> But here's the rub: Teneo/Hibernate does NOT guarantee that the objects
> in the child list will be in the same order each time it is loaded from
> the DB! (unlike a filesystem file that is the same each time you load
> it) I can force Teneo to track the child-object-order but that means
> adding a column to the database and sorting by that column when I
> populate the list. Since my EMF objects are sitting on top of a legacy
> database I can't easily do that plus it's a lot of error prone work to
> make sure that's done correctly for every child list in the data model.
>
> So now if I apply the change I'm going to delete whatever child object
> happens to be in position 4 even though the order of the list may have
> been shuffled. Oops.
>
> Here's a possible solution: Database backed objects should all have an
> @Id member in them. If the listChanges tag contained the value of the
> ID column whenever it is present then we could use these
> ChangeDescriptions on DB backed objects and be safe. As it is,
> ChangeDescription + Teneo backed EMF = potentially lost data unless your
> Teneo annotations are very specific and carefully checked.
>
> Is that analysis correct, or does Ed have some magic up his sleeve?
>
> Thanks all,
>
> Jason Henriksen
>
>
--
With Regards, Martin Taal
Springsite/Elver.org
Office: Hardwareweg 4, 3821 BV Amersfoort
Postal: Nassaulaan 7, 3941 EC Doorn
The Netherlands
Cell: +31 (0)6 288 48 943
Tel: +31 (0)84 420 2397
Fax: +31 (0)84 225 9307
Mail: mtaal@springsite.com - mtaal@elver.org
Web: www.springsite.com - www.elver.org
|
|
| |
| Re: EMF Compare & ChangeDescription on Teneo/Database backed EMF objects [message #619185 is a reply to message #125165] |
Thu, 05 June 2008 21:21 |
Ed Merks
Messages: 33142
Registered: July 2009 |
Senior Member |
|
|
Martin,
A change description for which the referenced model has changed in some
potentially arbitrary way just isn't coherent. Imagine trying to add to
a specific location in a list, but the list has different contents;
what's the right location. It's possible to set values explicitly and
have them serialized too...
Martin Taal wrote:
> Hi Jason,
> I think that a change descriptor with a list index won't even work in
> an environment were the list index was also present in the db. Assume
> that the server receives the changedescription you listed below. Now
> between the time the object was passed to the client and the
> changedescription comes back the list has been adapted by another
> client then the indexes in the list will have changed anyway. Or do
> you prevent this by doing a version check?
>
> To solve this what you mean is that the changedescription should be
> recorded as:
> <value featureName="contactList">
> <listChanges kind="REMOVE" id="5_myentityname"/>
> </value>
> (whereby id is something encoding the id and the entityname)
>
> correct?
>
> I think this is more an emf question than a Teneo question though.
>
> gr. Martin
>
> jason henriksen wrote:
>> Hi all,
>>
>> This is really a theoretical concern that I want to put in your
>> brains, more than a specific bug. That said, I'm worried that the
>> current implementation of ChangeDescription is going to bite me if I
>> use it as it is.
>>
>> I've just recorded a ChangeDescription on an object I held in my
>> client tier. The change description has a part that looks like this:
>>
>> <value featureName="contactList">
>> <listChanges kind="REMOVE" index="4"/>
>> </value>
>>
>> On the server I receive the change description, load the referenced
>> object out of the database and get ready to apply the change to the
>> Teneo backed object.
>>
>> But here's the rub: Teneo/Hibernate does NOT guarantee that the
>> objects in the child list will be in the same order each time it is
>> loaded from the DB! (unlike a filesystem file that is the same each
>> time you load it) I can force Teneo to track the child-object-order
>> but that means adding a column to the database and sorting by that
>> column when I populate the list. Since my EMF objects are sitting on
>> top of a legacy database I can't easily do that plus it's a lot of
>> error prone work to make sure that's done correctly for every child
>> list in the data model.
>>
>> So now if I apply the change I'm going to delete whatever child
>> object happens to be in position 4 even though the order of the list
>> may have been shuffled. Oops.
>>
>> Here's a possible solution: Database backed objects should all have
>> an @Id member in them. If the listChanges tag contained the value of
>> the ID column whenever it is present then we could use these
>> ChangeDescriptions on DB backed objects and be safe. As it is,
>> ChangeDescription + Teneo backed EMF = potentially lost data unless
>> your Teneo annotations are very specific and carefully checked.
>>
>> Is that analysis correct, or does Ed have some magic up his sleeve?
>>
>> Thanks all,
>>
>> Jason Henriksen
>>
>>
>
>
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
|
| Re: EMF Compare & ChangeDescription on Teneo/Database backed EMF objects [message #619186 is a reply to message #125167] |
Thu, 05 June 2008 21:46 |
Martin Taal
Messages: 5468
Registered: July 2009 |
Senior Member |
|
|
Hi Ed,
Yes, but is there a way to handle non-ordered lists using change descriptors?
gr. Martin
Ed Merks wrote:
> Martin,
>
> A change description for which the referenced model has changed in some
> potentially arbitrary way just isn't coherent. Imagine trying to add to
> a specific location in a list, but the list has different contents;
> what's the right location. It's possible to set values explicitly and
> have them serialized too...
>
>
> Martin Taal wrote:
>> Hi Jason,
>> I think that a change descriptor with a list index won't even work in
>> an environment were the list index was also present in the db. Assume
>> that the server receives the changedescription you listed below. Now
>> between the time the object was passed to the client and the
>> changedescription comes back the list has been adapted by another
>> client then the indexes in the list will have changed anyway. Or do
>> you prevent this by doing a version check?
>>
>> To solve this what you mean is that the changedescription should be
>> recorded as:
>> <value featureName="contactList">
>> <listChanges kind="REMOVE" id="5_myentityname"/>
>> </value>
>> (whereby id is something encoding the id and the entityname)
>>
>> correct?
>>
>> I think this is more an emf question than a Teneo question though.
>>
>> gr. Martin
>>
>> jason henriksen wrote:
>>> Hi all,
>>>
>>> This is really a theoretical concern that I want to put in your
>>> brains, more than a specific bug. That said, I'm worried that the
>>> current implementation of ChangeDescription is going to bite me if I
>>> use it as it is.
>>>
>>> I've just recorded a ChangeDescription on an object I held in my
>>> client tier. The change description has a part that looks like this:
>>>
>>> <value featureName="contactList">
>>> <listChanges kind="REMOVE" index="4"/>
>>> </value>
>>>
>>> On the server I receive the change description, load the referenced
>>> object out of the database and get ready to apply the change to the
>>> Teneo backed object.
>>>
>>> But here's the rub: Teneo/Hibernate does NOT guarantee that the
>>> objects in the child list will be in the same order each time it is
>>> loaded from the DB! (unlike a filesystem file that is the same each
>>> time you load it) I can force Teneo to track the child-object-order
>>> but that means adding a column to the database and sorting by that
>>> column when I populate the list. Since my EMF objects are sitting on
>>> top of a legacy database I can't easily do that plus it's a lot of
>>> error prone work to make sure that's done correctly for every child
>>> list in the data model.
>>>
>>> So now if I apply the change I'm going to delete whatever child
>>> object happens to be in position 4 even though the order of the list
>>> may have been shuffled. Oops.
>>>
>>> Here's a possible solution: Database backed objects should all have
>>> an @Id member in them. If the listChanges tag contained the value of
>>> the ID column whenever it is present then we could use these
>>> ChangeDescriptions on DB backed objects and be safe. As it is,
>>> ChangeDescription + Teneo backed EMF = potentially lost data unless
>>> your Teneo annotations are very specific and carefully checked.
>>>
>>> Is that analysis correct, or does Ed have some magic up his sleeve?
>>>
>>> Thanks all,
>>>
>>> Jason Henriksen
>>>
>>>
>>
>>
--
With Regards, Martin Taal
Springsite/Elver.org
Office: Hardwareweg 4, 3821 BV Amersfoort
Postal: Nassaulaan 7, 3941 EC Doorn
The Netherlands
Cell: +31 (0)6 288 48 943
Tel: +31 (0)84 420 2397
Fax: +31 (0)84 225 9307
Mail: mtaal@springsite.com - mtaal@elver.org
Web: www.springsite.com - www.elver.org
|
|
|
| Re: EMF Compare & ChangeDescription on Teneo/Database backed EMF objects [message #619187 is a reply to message #125168] |
Thu, 05 June 2008 22:44 |
Ed Merks
Messages: 33142
Registered: July 2009 |
Senior Member |
|
|
This is a multi-part message in MIME format.
--------------080903090802060303080803
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Martin,
List verses unordered are mutually exclusive terms since lists are
ordered collections. Is there a way to just treat a multi-valued
feature as a just set? No, EMF assumes that all features are backed by
lists and even if order has no deep semantic meaning, order is something
that's intended to be preserved and will be preserved. Some old
bugzillas are open regarding this type of issue:
https://bugs.eclipse.org/bugs/show_bug.cgi?id=75931
https://bugs.eclipse.org/bugs/show_bug.cgi?id=89325
It's very hard to change the framework break assumptions of the past...
Martin Taal wrote:
> Hi Ed,
> Yes, but is there a way to handle non-ordered lists using change
> descriptors?
>
> gr. Martin
>
> Ed Merks wrote:
>> Martin,
>>
>> A change description for which the referenced model has changed in
>> some potentially arbitrary way just isn't coherent. Imagine trying
>> to add to a specific location in a list, but the list has different
>> contents; what's the right location. It's possible to set values
>> explicitly and have them serialized too...
>>
>>
>> Martin Taal wrote:
>>> Hi Jason,
>>> I think that a change descriptor with a list index won't even work
>>> in an environment were the list index was also present in the db.
>>> Assume that the server receives the changedescription you listed
>>> below. Now between the time the object was passed to the client and
>>> the changedescription comes back the list has been adapted by
>>> another client then the indexes in the list will have changed
>>> anyway. Or do you prevent this by doing a version check?
>>>
>>> To solve this what you mean is that the changedescription should be
>>> recorded as:
>>> <value featureName="contactList">
>>> <listChanges kind="REMOVE" id="5_myentityname"/>
>>> </value>
>>> (whereby id is something encoding the id and the entityname)
>>>
>>> correct?
>>>
>>> I think this is more an emf question than a Teneo question though.
>>>
>>> gr. Martin
>>>
>>> jason henriksen wrote:
>>>> Hi all,
>>>>
>>>> This is really a theoretical concern that I want to put in your
>>>> brains, more than a specific bug. That said, I'm worried that the
>>>> current implementation of ChangeDescription is going to bite me if
>>>> I use it as it is.
>>>>
>>>> I've just recorded a ChangeDescription on an object I held in my
>>>> client tier. The change description has a part that looks like this:
>>>>
>>>> <value featureName="contactList">
>>>> <listChanges kind="REMOVE" index="4"/>
>>>> </value>
>>>>
>>>> On the server I receive the change description, load the referenced
>>>> object out of the database and get ready to apply the change to the
>>>> Teneo backed object.
>>>>
>>>> But here's the rub: Teneo/Hibernate does NOT guarantee that the
>>>> objects in the child list will be in the same order each time it is
>>>> loaded from the DB! (unlike a filesystem file that is the same each
>>>> time you load it) I can force Teneo to track the
>>>> child-object-order but that means adding a column to the database
>>>> and sorting by that column when I populate the list. Since my EMF
>>>> objects are sitting on top of a legacy database I can't easily do
>>>> that plus it's a lot of error prone work to make sure that's done
>>>> correctly for every child list in the data model.
>>>>
>>>> So now if I apply the change I'm going to delete whatever child
>>>> object happens to be in position 4 even though the order of the
>>>> list may have been shuffled. Oops.
>>>>
>>>> Here's a possible solution: Database backed objects should all
>>>> have an @Id member in them. If the listChanges tag contained the
>>>> value of the ID column whenever it is present then we could use
>>>> these ChangeDescriptions on DB backed objects and be safe. As it
>>>> is, ChangeDescription + Teneo backed EMF = potentially lost data
>>>> unless your Teneo annotations are very specific and carefully checked.
>>>>
>>>> Is that analysis correct, or does Ed have some magic up his sleeve?
>>>>
>>>> Thanks all,
>>>>
>>>> Jason Henriksen
>>>>
>>>>
>>>
>>>
>
>
--------------080903090802060303080803
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">
Martin,<br>
<br>
List verses unordered are mutually exclusive terms since lists are
ordered collections. Is there a way to just treat a multi-valued
feature as a just set? No, EMF assumes that all features are backed by
lists and even if order has no deep semantic meaning, order is
something that's intended to be preserved and will be preserved. Some
old bugzillas are open regarding this type of issue:<br>
<blockquote><a
href="https://bugs.eclipse.org/bugs/show_bug.cgi?id=75931">https://bugs.eclipse.org/bugs/show_bug.cgi?id=75931</a><br>
<a href="https://bugs.eclipse.org/bugs/show_bug.cgi?id=89325">https://bugs.eclipse.org/bugs/show_bug.cgi?id=89325</a><br>
</blockquote>
It's very hard to change the framework break assumptions of the past...<br>
<br>
<br>
Martin Taal wrote:
<blockquote cite="mid:g29mr9$2nf$1@build.eclipse.org" type="cite">Hi
Ed,
<br>
Yes, but is there a way to handle non-ordered lists using change
descriptors?
<br>
<br>
gr. Martin
<br>
<br>
Ed Merks wrote:
<br>
<blockquote type="cite">Martin,
<br>
<br>
A change description for which the referenced model has changed in some
potentially arbitrary way just isn't coherent. Imagine trying to add
to a specific location in a list, but the list has different contents;
what's the right location. It's possible to set values explicitly and
have them serialized too...
<br>
<br>
<br>
Martin Taal wrote:
<br>
<blockquote type="cite">Hi Jason,
<br>
I think that a change descriptor with a list index won't even work in
an environment were the list index was also present in the db. Assume
that the server receives the changedescription you listed below. Now
between the time the object was passed to the client and the
changedescription comes back the list has been adapted by another
client then the indexes in the list will have changed anyway. Or do you
prevent this by doing a version check?
<br>
<br>
To solve this what you mean is that the changedescription should be
recorded as:
<br>
<value featureName="contactList">
<br>
<listChanges kind="REMOVE" id="5_myentityname"/>
<br>
</value>
<br>
(whereby id is something encoding the id and the entityname)
<br>
<br>
correct?
<br>
<br>
I think this is more an emf question than a Teneo question though.
<br>
<br>
gr. Martin
<br>
<br>
jason henriksen wrote:
<br>
<blockquote type="cite">Hi all,
<br>
<br>
This is really a theoretical concern that I want to put in your brains,
more than a specific bug. That said, I'm worried that the current
implementation of ChangeDescription is going to bite me if I use it as
it is.
<br>
<br>
I've just recorded a ChangeDescription on an object I held in my client
tier. The change description has a part that looks like this:
<br>
<br>
<value featureName="contactList">
<br>
<listChanges kind="REMOVE" index="4"/>
<br>
</value>
<br>
<br>
On the server I receive the change description, load the referenced
object out of the database and get ready to apply the change to the
Teneo backed object.
<br>
<br>
But here's the rub: Teneo/Hibernate does NOT guarantee that the
objects in the child list will be in the same order each time it is
loaded from the DB! (unlike a filesystem file that is the same each
time you load it) I can force Teneo to track the child-object-order
but that means adding a column to the database and sorting by that
column when I populate the list. Since my EMF objects are sitting on
top of a legacy database I can't easily do that plus it's a lot of
error prone work to make sure that's done correctly for every child
list in the data model.
<br>
<br>
So now if I apply the change I'm going to delete whatever child object
happens to be in position 4 even though the order of the list may have
been shuffled. Oops.
<br>
<br>
Here's a possible solution: Database backed objects should all have an
@Id member in them. If the listChanges tag contained the value of the
ID column whenever it is present then we could use these
ChangeDescriptions on DB backed objects and be safe. As it is,
ChangeDescription + Teneo backed EMF = potentially lost data unless
your Teneo annotations are very specific and carefully checked.
<br>
<br>
Is that analysis correct, or does Ed have some magic up his sleeve?
<br>
<br>
Thanks all,
<br>
<br>
Jason Henriksen
<br>
<br>
<br>
</blockquote>
<br>
<br>
</blockquote>
</blockquote>
<br>
<br>
</blockquote>
<br>
</body>
</html>
--------------080903090802060303080803--
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
|
| Re: EMF Compare & ChangeDescription on Teneo/Database backed EMF objects [message #619188 is a reply to message #125165] |
Thu, 05 June 2008 23:06 |
Jason Henriksen
Messages: 231
Registered: July 2009 |
Senior Member |
|
|
HaHA! Maybe this was a red herring of a problem!
On further analysis I've found that if I make the object have an
attribute with type xsd:ID then my child object references go from being
an index into being a URL that contains the REAL ID TEXT! This is a big
win because it means that the order of the listing is no longer
important at all.
For example:
<subDiffElements xsi:type="diff:UpdateAttribute">
<attribute
href="http:///com/ibm/example/Building.ecore#//Building/size"
/>
<leftElement href="original.xml#home"/>
<rightElement href="altered.xml#vacation home"/>
</subDiffElements>
From what I've ready, Teneo will automatically set EAttribute.isID()
true on any objects that have the @Id annotation set. Is that true?
Will that work if the attribute is a long instead of a String?
If so, then I don't actually have a problem at all.
Jason
Martin Taal wrote:
> Hi Jason,
> I think that a change descriptor with a list index won't even work in an
> environment were the list index was also present in the db. Assume that
> the server receives the changedescription you listed below. Now between
> the time the object was passed to the client and the changedescription
> comes back the list has been adapted by another client then the indexes
> in the list will have changed anyway. Or do you prevent this by doing a
> version check?
>
> To solve this what you mean is that the changedescription should be
> recorded as:
> <value featureName="contactList">
> <listChanges kind="REMOVE" id="5_myentityname"/>
> </value>
> (whereby id is something encoding the id and the entityname)
>
> correct?
>
> I think this is more an emf question than a Teneo question though.
>
> gr. Martin
>
> jason henriksen wrote:
>> Hi all,
>>
>> This is really a theoretical concern that I want to put in your
>> brains, more than a specific bug. That said, I'm worried that the
>> current implementation of ChangeDescription is going to bite me if I
>> use it as it is.
>>
>> I've just recorded a ChangeDescription on an object I held in my
>> client tier. The change description has a part that looks like this:
>>
>> <value featureName="contactList">
>> <listChanges kind="REMOVE" index="4"/>
>> </value>
>>
>> On the server I receive the change description, load the referenced
>> object out of the database and get ready to apply the change to the
>> Teneo backed object.
>>
>> But here's the rub: Teneo/Hibernate does NOT guarantee that the
>> objects in the child list will be in the same order each time it is
>> loaded from the DB! (unlike a filesystem file that is the same each
>> time you load it) I can force Teneo to track the child-object-order
>> but that means adding a column to the database and sorting by that
>> column when I populate the list. Since my EMF objects are sitting on
>> top of a legacy database I can't easily do that plus it's a lot of
>> error prone work to make sure that's done correctly for every child
>> list in the data model.
>>
>> So now if I apply the change I'm going to delete whatever child object
>> happens to be in position 4 even though the order of the list may have
>> been shuffled. Oops.
>>
>> Here's a possible solution: Database backed objects should all have
>> an @Id member in them. If the listChanges tag contained the value of
>> the ID column whenever it is present then we could use these
>> ChangeDescriptions on DB backed objects and be safe. As it is,
>> ChangeDescription + Teneo backed EMF = potentially lost data unless
>> your Teneo annotations are very specific and carefully checked.
>>
>> Is that analysis correct, or does Ed have some magic up his sleeve?
>>
>> Thanks all,
>>
>> Jason Henriksen
>>
>>
>
>
|
|
|
| Re: EMF Compare & ChangeDescription on Teneo/Database backed EMF objects [message #619191 is a reply to message #125170] |
Fri, 06 June 2008 04:41 |
Martin Taal
Messages: 5468
Registered: July 2009 |
Senior Member |
|
|
Hi Jason,
Teneo does not set the EAttribute.isId for you. Also as I understand it the isId should be set on
the client and not on the server (where Teneo runs).
However, assuming that the client has the ecore with the annotations then it is very easy to set the
id of the attributes which have a @Id annotation. Just iterate over the epackages, eclasses,
eattributes, check the eannotation and if it contains @Id call eAttribute.setId(true).
gr. Martin
jason henriksen wrote:
>
> HaHA! Maybe this was a red herring of a problem!
>
> On further analysis I've found that if I make the object have an
> attribute with type xsd:ID then my child object references go from being
> an index into being a URL that contains the REAL ID TEXT! This is a big
> win because it means that the order of the listing is no longer
> important at all.
>
> For example:
>
> <subDiffElements xsi:type="diff:UpdateAttribute">
> <attribute
> href="http:///com/ibm/example/Building.ecore#//Building/size"
> />
> <leftElement href="original.xml#home"/>
> <rightElement href="altered.xml#vacation home"/>
> </subDiffElements>
>
>
> From what I've ready, Teneo will automatically set EAttribute.isID()
> true on any objects that have the @Id annotation set. Is that true?
> Will that work if the attribute is a long instead of a String?
> If so, then I don't actually have a problem at all.
>
> Jason
>
>
>
> Martin Taal wrote:
>> Hi Jason,
>> I think that a change descriptor with a list index won't even work in
>> an environment were the list index was also present in the db. Assume
>> that the server receives the changedescription you listed below. Now
>> between the time the object was passed to the client and the
>> changedescription comes back the list has been adapted by another
>> client then the indexes in the list will have changed anyway. Or do
>> you prevent this by doing a version check?
>>
>> To solve this what you mean is that the changedescription should be
>> recorded as:
>> <value featureName="contactList">
>> <listChanges kind="REMOVE" id="5_myentityname"/>
>> </value>
>> (whereby id is something encoding the id and the entityname)
>>
>> correct?
>>
>> I think this is more an emf question than a Teneo question though.
>>
>> gr. Martin
>>
>> jason henriksen wrote:
>>> Hi all,
>>>
>>> This is really a theoretical concern that I want to put in your
>>> brains, more than a specific bug. That said, I'm worried that the
>>> current implementation of ChangeDescription is going to bite me if I
>>> use it as it is.
>>>
>>> I've just recorded a ChangeDescription on an object I held in my
>>> client tier. The change description has a part that looks like this:
>>>
>>> <value featureName="contactList">
>>> <listChanges kind="REMOVE" index="4"/>
>>> </value>
>>>
>>> On the server I receive the change description, load the referenced
>>> object out of the database and get ready to apply the change to the
>>> Teneo backed object.
>>>
>>> But here's the rub: Teneo/Hibernate does NOT guarantee that the
>>> objects in the child list will be in the same order each time it is
>>> loaded from the DB! (unlike a filesystem file that is the same each
>>> time you load it) I can force Teneo to track the child-object-order
>>> but that means adding a column to the database and sorting by that
>>> column when I populate the list. Since my EMF objects are sitting on
>>> top of a legacy database I can't easily do that plus it's a lot of
>>> error prone work to make sure that's done correctly for every child
>>> list in the data model.
>>>
>>> So now if I apply the change I'm going to delete whatever child
>>> object happens to be in position 4 even though the order of the list
>>> may have been shuffled. Oops.
>>>
>>> Here's a possible solution: Database backed objects should all have
>>> an @Id member in them. If the listChanges tag contained the value of
>>> the ID column whenever it is present then we could use these
>>> ChangeDescriptions on DB backed objects and be safe. As it is,
>>> ChangeDescription + Teneo backed EMF = potentially lost data unless
>>> your Teneo annotations are very specific and carefully checked.
>>>
>>> Is that analysis correct, or does Ed have some magic up his sleeve?
>>>
>>> Thanks all,
>>>
>>> Jason Henriksen
>>>
>>>
>>
>>
--
With Regards, Martin Taal
Springsite/Elver.org
Office: Hardwareweg 4, 3821 BV Amersfoort
Postal: Nassaulaan 7, 3941 EC Doorn
The Netherlands
Cell: +31 (0)6 288 48 943
Tel: +31 (0)84 420 2397
Fax: +31 (0)84 225 9307
Mail: mtaal@springsite.com - mtaal@elver.org
Web: www.springsite.com - www.elver.org
|
|
| | |
| Re: EMF Compare & ChangeDescription on Teneo/Database backed EMF objects [message #619204 is a reply to message #125279] |
Fri, 06 June 2008 20:30 |
Ed Merks
Messages: 33142
Registered: July 2009 |
Senior Member |
|
|
Jason,
Keep in mind that an ID must be an NCName so an integer is not a
conforming thing. You might create a restricted ID so that it's _
followed by digits (where the first digit can't be 0), and then map it
to a a long with a value to string conversion that eats/inserts the "_"...
Martin Taal wrote:
> Hi Jason,
> Afaik normally xsd:ID maps to a string in ecore but maybe using an
> edatatype/instanceclass would prevent this. So yes this sounds like a
> good approach to me.
>
> gr. Martin
>
> jason henriksen wrote:
>> Martin Taal wrote:
>>
>>> Hi Jason,
>>> Teneo does not set the EAttribute.isId for you. Also as I understand
>>> it the isId should be set on the client and not on the server (where
>>> Teneo runs).
>>
>> Would it hurt anything if I used xsd:ID as the type for my @Id fields
>> and then used instance type to make the id into a long so that it
>> matches the database?
>>
>> Unfortunately, the front end software may be run at a 3rd party
>> company. Therefore all database information is stripped from the XSD
>> before it is presented to them. However if the type is xsd:ID then
>> it wont matter, so long as I can make sure that Teneo doesn't get
>> confused by that.
>>
>>
>> Jason
>
>
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
|
Goto Forum:
Current Time: Sat Apr 27 05:24:22 GMT 2024
Powered by FUDForum. Page generated in 0.05855 seconds |
] 
Search
Help
Register
Login
Home
