Home » Modeling » EMF "Technology" (Ecore Tools, EMFatic, etc) » Teneo: Identity (ID) scope conflicts
| Teneo: Identity (ID) scope conflicts [message #70304] |
Fri, 02 February 2007 19:44  |
 Brian Vetter
Messages: 74
Registered: July 2009 |
Member |
|
|
As I've read and witnessed, Teneo needs to place a unique id in every table. It will auto-generate one if a primary key (id) is not defined in a type/class (the name by default is e_id). If an element has an @Id annotation, it will use that as the primary key/id. I have also found that if a type defines an attributed named "id", it will use that at the primary key/id.
I have a series of XSDs and documents that utilize ID and IDREF for internal references within the document. In this scenario, the IDs and references are scoped to the document. When I try to bring these into a database using Teneo, these IDs must now be scoped to database - they must be unique not just within the document, but all documents.
While in a few cases, I can use annotations to change the primary key to another element (I haven't tried this yet so I don't know if it will override the check for the attributed named "id"), there are some types where there is no obvious unique key. Going back to the original schema developer to add one isn't really possible.
Is there a way to tell Teneo to not use the ID attribute as the key and to auto-generate one (an e_id field) instead?
And on a related front, is there plans for Teneo to support <key>, <keyref>, and <unique> in XSD in the future (or does it and I just didn't see it listed as supported on the web site or the test documents). I don't need it right now, but I see the need coming in the future.
Thanks,
Brian
|
|
|
| Re: Teneo: Identity (ID) scope conflicts [message #70345 is a reply to message #70304] |
Sat, 03 February 2007 10:56  |
Martin Taal
Messages: 5468
Registered: July 2009 |
Senior Member |
|
|
Brian,
Automatically assuming that an attribute with name 'id' is the id-attribute (if there is no other id
attribute) will be removed.
fyi, the auto-generated id (e_id) field does not work in situations were you serialize and then
de-serialize objects as the synthetic id is not (de-)serialized with the object.
gr. Martin
Brian Vetter wrote:
> As I've read and witnessed, Teneo needs to place a unique id in every
> table. It will auto-generate one if a primary key (id) is not defined in
> a type/class (the name by default is e_id). If an element has an @Id
> annotation, it will use that as the primary key/id. I have also found
> that if a type defines an attributed named "id", it will use that at the
> primary key/id.
>
> I have a series of XSDs and documents that utilize ID and IDREF for
> internal references within the document. In this scenario, the IDs and
> references are scoped to the document. When I try to bring these into a
> database using Teneo, these IDs must now be scoped to database - they
> must be unique not just within the document, but all documents.
>
> While in a few cases, I can use annotations to change the primary key to
> another element (I haven't tried this yet so I don't know if it will
> override the check for the attributed named "id"), there are some types
> where there is no obvious unique key. Going back to the original schema
> developer to add one isn't really possible.
>
> Is there a way to tell Teneo to not use the ID attribute as the key and
> to auto-generate one (an e_id field) instead?
>
> And on a related front, is there plans for Teneo to support <key>,
> <keyref>, and <unique> in XSD in the future (or does it and I just
> didn't see it listed as supported on the web site or the test
> documents). I don't need it right now, but I see the need coming in the
> future.
>
> Thanks,
>
> Brian
--
With Regards, Martin Taal
Springsite/Elver.org
Office: Hardwareweg 4, 3821 BV Amersfoort
Postal: Nassaulaan 7, 3941 EC Doorn
The Netherlands
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: Teneo: Identity (ID) scope conflicts [message #70426 is a reply to message #70407] |
Mon, 05 February 2007 19:19 |
Martin Taal
Messages: 5468
Registered: July 2009 |
Senior Member |
|
|
I solved it differently, an option now controls the default name of an id-efeature:
PersistenceOptions.DEFAULT_ID_FEATURE_NAME
the default value has been changed to e_id so that it is less likely that clashes occur.
This has been checked in.
gr. Martin
Brian Vetter wrote:
>
> Martin Taal wrote:
>> Brian,
>> Automatically assuming that an attribute with name 'id' is the
>> id-attribute (if there is no other id attribute) will be removed.
>
> Cool. Now that I've got Teneo building, I can pull it down and test it
> or if you point me in the right direction, I can excise it myself.
>
>> fyi, the auto-generated id (e_id) field does not work in situations
>> were you serialize and then de-serialize objects as the synthetic id
>> is not (de-)serialized with the object.
>
> I presume they are only being used for persistence purposes? Since I'm
> not using them for anything, what, if any, are the downsides of this? Do
> these ids have any value outside of the database references?
>
> Thanks,
>
> Brian
--
With Regards, Martin Taal
Springsite/Elver.org
Office: Hardwareweg 4, 3821 BV Amersfoort
Postal: Nassaulaan 7, 3941 EC Doorn
The Netherlands
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: Teneo: Identity (ID) scope conflicts [message #70445 is a reply to message #70407] |
Mon, 05 February 2007 19:19 |
Martin Taal
Messages: 5468
Registered: July 2009 |
Senior Member |
|
|
Yes the synthetic id's are only used for persistence purposes. A synthetic id is not stored in the
object itself but in a weak reference cache within Teneo (see
org.eclipse.emf.teneo.hibernate.mapping.identifier.Identifie rCacheHandler).
The downside of a synthetic id is that it does not work in situations were you would want
(de-)serialization emf objects, for example in case of rich clients or web clients using jsf and
client side-state saving. When you serialize an object and send it over the wire and then get it
back (from the rich client) and de-serialize it again the id can not be found anymore in the
weak-reference cache.
The synthetic id is mainly there to easily support tutorials and testcases.
gr. Martin
Brian Vetter wrote:
>
> Martin Taal wrote:
>> Brian,
>> Automatically assuming that an attribute with name 'id' is the
>> id-attribute (if there is no other id attribute) will be removed.
>
> Cool. Now that I've got Teneo building, I can pull it down and test it
> or if you point me in the right direction, I can excise it myself.
>
>> fyi, the auto-generated id (e_id) field does not work in situations
>> were you serialize and then de-serialize objects as the synthetic id
>> is not (de-)serialized with the object.
>
> I presume they are only being used for persistence purposes? Since I'm
> not using them for anything, what, if any, are the downsides of this? Do
> these ids have any value outside of the database references?
>
> Thanks,
>
> Brian
--
With Regards, Martin Taal
Springsite/Elver.org
Office: Hardwareweg 4, 3821 BV Amersfoort
Postal: Nassaulaan 7, 3941 EC Doorn
The Netherlands
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: Teneo: Identity (ID) scope conflicts [message #70565 is a reply to message #70426] |
Tue, 06 February 2007 18:39 |
Brian Vetter
Messages: 74
Registered: July 2009 |
Member |
|
|
Martin,
I updated to the latest source and it still decides to assign my ID attribute as the primary key even though there is no @Id annotation set for it. I tried both the default setting as well as trying to explicitly set DEFAULT_ID_FEATURE_NAME (although it shouldn't have mattered - I did it primary to make sure I was building against the latest source).
While debugging, I see in getIDFeaturesNamesRecurse() that it looks for an id attribute in line 1339 and if found, adds it to a list. The calling function getIDFeaturesNames() that refers to the bug, simply adds the default id attribute name if the getIDFeaturesNamesRecurse() returns an empty list.
I'm not quite sure what is going on in the code, but this behavior still seems to be grabbing the ID even though it isn't annotated. I'm not sure if it is an ecore issue (falsly reporting an annotation on the ID attribute) or a Teneo issue.
Brian
Martin Taal wrote:
> I solved it differently, an option now controls the default name of an
> id-efeature:
> PersistenceOptions.DEFAULT_ID_FEATURE_NAME
>
> the default value has been changed to e_id so that it is less likely
> that clashes occur.
>
> This has been checked in.
>
> gr. Martin
>
> Brian Vetter wrote:
>>
>> Martin Taal wrote:
>>> Brian,
>>> Automatically assuming that an attribute with name 'id' is the
>>> id-attribute (if there is no other id attribute) will be removed.
>>
>> Cool. Now that I've got Teneo building, I can pull it down and test it
>> or if you point me in the right direction, I can excise it myself.
>>
>>> fyi, the auto-generated id (e_id) field does not work in situations
>>> were you serialize and then de-serialize objects as the synthetic id
>>> is not (de-)serialized with the object.
>>
>> I presume they are only being used for persistence purposes? Since I'm
>> not using them for anything, what, if any, are the downsides of this?
>> Do these ids have any value outside of the database references?
>>
>> Thanks,
>>
>> Brian
>
>
|
|
|
| Re: Teneo: Identity (ID) scope conflicts [message #70583 is a reply to message #70565] |
Tue, 06 February 2007 19:13 |
Martin Taal
Messages: 5468
Registered: July 2009 |
Senior Member |
|
|
Brian,
The id annotation is also added automatically when the ID property of the eattribute is true. Is
this the case with your model?
gr. Martin
Brian Vetter wrote:
> Martin,
>
> I updated to the latest source and it still decides to assign my ID
> attribute as the primary key even though there is no @Id annotation set
> for it. I tried both the default setting as well as trying to explicitly
> set DEFAULT_ID_FEATURE_NAME (although it shouldn't have mattered - I did
> it primary to make sure I was building against the latest source).
>
> While debugging, I see in getIDFeaturesNamesRecurse() that it looks for
> an id attribute in line 1339 and if found, adds it to a list. The
> calling function getIDFeaturesNames() that refers to the bug, simply
> adds the default id attribute name if the getIDFeaturesNamesRecurse()
> returns an empty list.
>
> I'm not quite sure what is going on in the code, but this behavior still
> seems to be grabbing the ID even though it isn't annotated. I'm not sure
> if it is an ecore issue (falsly reporting an annotation on the ID
> attribute) or a Teneo issue.
>
> Brian
>
> Martin Taal wrote:
>> I solved it differently, an option now controls the default name of an
>> id-efeature:
>> PersistenceOptions.DEFAULT_ID_FEATURE_NAME
>>
>> the default value has been changed to e_id so that it is less likely
>> that clashes occur.
>>
>> This has been checked in.
>>
>> gr. Martin
>>
>> Brian Vetter wrote:
>>>
>>> Martin Taal wrote:
>>>> Brian,
>>>> Automatically assuming that an attribute with name 'id' is the
>>>> id-attribute (if there is no other id attribute) will be removed.
>>>
>>> Cool. Now that I've got Teneo building, I can pull it down and test
>>> it or if you point me in the right direction, I can excise it myself.
>>>
>>>> fyi, the auto-generated id (e_id) field does not work in situations
>>>> were you serialize and then de-serialize objects as the synthetic id
>>>> is not (de-)serialized with the object.
>>>
>>> I presume they are only being used for persistence purposes? Since
>>> I'm not using them for anything, what, if any, are the downsides of
>>> this? Do these ids have any value outside of the database references?
>>>
>>> Thanks,
>>>
>>> Brian
>>
>>
--
With Regards, Martin Taal
Springsite/Elver.org
Office: Hardwareweg 4, 3821 BV Amersfoort
Postal: Nassaulaan 7, 3941 EC Doorn
The Netherlands
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: Teneo: Identity (ID) scope conflicts [message #70620 is a reply to message #70583] |
Tue, 06 February 2007 20:08 |
Brian Vetter
Messages: 74
Registered: July 2009 |
Member |
|
|
Apparently, the default XSD->ecore mapping translates my id attributes with the ID property of the eattribute to true. The original XSD attribute definition is:
<attribute name="id" type="ID"></attribute>
Here's the ecore translation of the attribute - it works just as specified as in section 4.1 of the xsd->ecore mapping document.
<eStructuralFeatures xsi:type="ecore:EAttribute" name="id" unique="false" eType="ecore:EDataType http://www.eclipse.org/emf/2003/XMLType#//ID"
iD="true">
<eAnnotations source="http:///org/eclipse/emf/ecore/util/ExtendedMetaData">
<details key="kind" value="attribute"/>
<details key="name" value="id"/>
</eAnnotations>
</eStructuralFeatures>
The root problem is still the same: the ids in an XML Schema document are only scoped to the document, not to the database and thus are seldom unique. In addition, they are optional in many cases. So using them to be a unique primary key isn't feasible without reworking the original XSDs to make them DB aware.
So is there an easy way for me to control the mapping for IDs for all of my schemas or is there some other way to distinguish between an XSD:ID and one specified in ecore that needs to be used as the DB identifier? Is the "unique" attribute useful here?
Brian
Martin Taal wrote:
> Brian,
> The id annotation is also added automatically when the ID property of
> the eattribute is true. Is this the case with your model?
>
> gr. Martin
>
> Brian Vetter wrote:
>> Martin,
>>
>> I updated to the latest source and it still decides to assign my ID
>> attribute as the primary key even though there is no @Id annotation
>> set for it. I tried both the default setting as well as trying to
>> explicitly set DEFAULT_ID_FEATURE_NAME (although it shouldn't have
>> mattered - I did it primary to make sure I was building against the
>> latest source).
>>
>> While debugging, I see in getIDFeaturesNamesRecurse() that it looks
>> for an id attribute in line 1339 and if found, adds it to a list. The
>> calling function getIDFeaturesNames() that refers to the bug, simply
>> adds the default id attribute name if the getIDFeaturesNamesRecurse()
>> returns an empty list.
>>
>> I'm not quite sure what is going on in the code, but this behavior
>> still seems to be grabbing the ID even though it isn't annotated. I'm
>> not sure if it is an ecore issue (falsly reporting an annotation on
>> the ID attribute) or a Teneo issue.
>>
>> Brian
>>
>> Martin Taal wrote:
>>> I solved it differently, an option now controls the default name of
>>> an id-efeature:
>>> PersistenceOptions.DEFAULT_ID_FEATURE_NAME
>>>
>>> the default value has been changed to e_id so that it is less likely
>>> that clashes occur.
>>>
>>> This has been checked in.
>>>
>>> gr. Martin
>>>
>>> Brian Vetter wrote:
>>>>
>>>> Martin Taal wrote:
>>>>> Brian,
>>>>> Automatically assuming that an attribute with name 'id' is the
>>>>> id-attribute (if there is no other id attribute) will be removed.
>>>>
>>>> Cool. Now that I've got Teneo building, I can pull it down and test
>>>> it or if you point me in the right direction, I can excise it myself.
>>>>
>>>>> fyi, the auto-generated id (e_id) field does not work in situations
>>>>> were you serialize and then de-serialize objects as the synthetic
>>>>> id is not (de-)serialized with the object.
>>>>
>>>> I presume they are only being used for persistence purposes? Since
>>>> I'm not using them for anything, what, if any, are the downsides of
>>>> this? Do these ids have any value outside of the database references?
>>>>
>>>> Thanks,
>>>>
>>>> Brian
>>>
>>>
>
>
|
|
|
| Re: Teneo: Identity (ID) scope conflicts [message #70637 is a reply to message #70620] |
Tue, 06 February 2007 20:26 |
Brian Vetter
Messages: 74
Registered: July 2009 |
Member |
|
|
Just for grins, I changed line xx in xx to the following:
if (false && eAttribute.isID() && aAttribute.getId() == null) {
^^^^^^^^^
While not 100% confident, I did seem to get the behavior I wanted/expected. All of the types that I had that included id attributes now sport e_id fields for their primary keys and my id fields are now simple columns in the DB. I need to experiment a bit to see if the idrefs work as I expected.
Brian
Brian Vetter wrote:
> Apparently, the default XSD->ecore mapping translates my id attributes
> with the ID property of the eattribute to true. The original XSD
> attribute definition is:
>
> <attribute name="id" type="ID"></attribute>
>
> Here's the ecore translation of the attribute - it works just as
> specified as in section 4.1 of the xsd->ecore mapping document.
>
> <eStructuralFeatures xsi:type="ecore:EAttribute" name="id"
> unique="false" eType="ecore:EDataType
> http://www.eclipse.org/emf/2003/XMLType#//ID"
> iD="true">
> <eAnnotations
> source="http:///org/eclipse/emf/ecore/util/ExtendedMetaData">
> <details key="kind" value="attribute"/>
> <details key="name" value="id"/>
> </eAnnotations>
> </eStructuralFeatures>
>
> The root problem is still the same: the ids in an XML Schema document
> are only scoped to the document, not to the database and thus are seldom
> unique. In addition, they are optional in many cases. So using them to
> be a unique primary key isn't feasible without reworking the original
> XSDs to make them DB aware.
>
> So is there an easy way for me to control the mapping for IDs for all of
> my schemas or is there some other way to distinguish between an XSD:ID
> and one specified in ecore that needs to be used as the DB identifier?
> Is the "unique" attribute useful here?
>
> Brian
>
> Martin Taal wrote:
>> Brian,
>> The id annotation is also added automatically when the ID property of
>> the eattribute is true. Is this the case with your model?
>>
>> gr. Martin
>>
>> Brian Vetter wrote:
>>> Martin,
>>>
>>> I updated to the latest source and it still decides to assign my ID
>>> attribute as the primary key even though there is no @Id annotation
>>> set for it. I tried both the default setting as well as trying to
>>> explicitly set DEFAULT_ID_FEATURE_NAME (although it shouldn't have
>>> mattered - I did it primary to make sure I was building against the
>>> latest source).
>>>
>>> While debugging, I see in getIDFeaturesNamesRecurse() that it looks
>>> for an id attribute in line 1339 and if found, adds it to a list. The
>>> calling function getIDFeaturesNames() that refers to the bug, simply
>>> adds the default id attribute name if the getIDFeaturesNamesRecurse()
>>> returns an empty list.
>>>
>>> I'm not quite sure what is going on in the code, but this behavior
>>> still seems to be grabbing the ID even though it isn't annotated. I'm
>>> not sure if it is an ecore issue (falsly reporting an annotation on
>>> the ID attribute) or a Teneo issue.
>>>
>>> Brian
>>>
>>> Martin Taal wrote:
>>>> I solved it differently, an option now controls the default name of
>>>> an id-efeature:
>>>> PersistenceOptions.DEFAULT_ID_FEATURE_NAME
>>>>
>>>> the default value has been changed to e_id so that it is less likely
>>>> that clashes occur.
>>>>
>>>> This has been checked in.
>>>>
>>>> gr. Martin
>>>>
>>>> Brian Vetter wrote:
>>>>>
>>>>> Martin Taal wrote:
>>>>>> Brian,
>>>>>> Automatically assuming that an attribute with name 'id' is the
>>>>>> id-attribute (if there is no other id attribute) will be removed.
>>>>>
>>>>> Cool. Now that I've got Teneo building, I can pull it down and test
>>>>> it or if you point me in the right direction, I can excise it myself.
>>>>>
>>>>>> fyi, the auto-generated id (e_id) field does not work in
>>>>>> situations were you serialize and then de-serialize objects as the
>>>>>> synthetic id is not (de-)serialized with the object.
>>>>>
>>>>> I presume they are only being used for persistence purposes? Since
>>>>> I'm not using them for anything, what, if any, are the downsides of
>>>>> this? Do these ids have any value outside of the database references?
>>>>>
>>>>> Thanks,
>>>>>
>>>>> Brian
>>>>
>>>>
>>
>>
|
|
|
| Re: Teneo: Identity (ID) scope conflicts [message #70653 is a reply to message #70637] |
Tue, 06 February 2007 20:29 |
Brian Vetter
Messages: 74
Registered: July 2009 |
Member |
|
|
Oops, I forgot to include the line number and the file: 509 of DefaultAnnotator.java.
BTW, I have no intention of this being a proposed fix - just that as an experiment of cutting out the code in that if statement, whether I'd get my expected behavior.
Brian
Brian Vetter wrote:
> Just for grins, I changed line xx in xx to the following:
>
> if (false && eAttribute.isID() && aAttribute.getId() == null) {
> ^^^^^^^^^
>
> While not 100% confident, I did seem to get the behavior I
> wanted/expected. All of the types that I had that included id attributes
> now sport e_id fields for their primary keys and my id fields are now
> simple columns in the DB. I need to experiment a bit to see if the
> idrefs work as I expected.
>
> Brian
>
> Brian Vetter wrote:
>> Apparently, the default XSD->ecore mapping translates my id attributes
>> with the ID property of the eattribute to true. The original XSD
>> attribute definition is:
>>
>> <attribute name="id" type="ID"></attribute>
>>
>> Here's the ecore translation of the attribute - it works just as
>> specified as in section 4.1 of the xsd->ecore mapping document.
>>
>> <eStructuralFeatures xsi:type="ecore:EAttribute" name="id"
>> unique="false" eType="ecore:EDataType
>> http://www.eclipse.org/emf/2003/XMLType#//ID"
>> iD="true">
>> <eAnnotations
>> source="http:///org/eclipse/emf/ecore/util/ExtendedMetaData">
>> <details key="kind" value="attribute"/>
>> <details key="name" value="id"/>
>> </eAnnotations>
>> </eStructuralFeatures>
>>
>> The root problem is still the same: the ids in an XML Schema document
>> are only scoped to the document, not to the database and thus are
>> seldom unique. In addition, they are optional in many cases. So using
>> them to be a unique primary key isn't feasible without reworking the
>> original XSDs to make them DB aware.
>>
>> So is there an easy way for me to control the mapping for IDs for all
>> of my schemas or is there some other way to distinguish between an
>> XSD:ID and one specified in ecore that needs to be used as the DB
>> identifier? Is the "unique" attribute useful here?
>>
>> Brian
>>
>> Martin Taal wrote:
>>> Brian,
>>> The id annotation is also added automatically when the ID property of
>>> the eattribute is true. Is this the case with your model?
>>>
>>> gr. Martin
>>>
>>> Brian Vetter wrote:
>>>> Martin,
>>>>
>>>> I updated to the latest source and it still decides to assign my ID
>>>> attribute as the primary key even though there is no @Id annotation
>>>> set for it. I tried both the default setting as well as trying to
>>>> explicitly set DEFAULT_ID_FEATURE_NAME (although it shouldn't have
>>>> mattered - I did it primary to make sure I was building against the
>>>> latest source).
>>>>
>>>> While debugging, I see in getIDFeaturesNamesRecurse() that it looks
>>>> for an id attribute in line 1339 and if found, adds it to a list.
>>>> The calling function getIDFeaturesNames() that refers to the bug,
>>>> simply adds the default id attribute name if the
>>>> getIDFeaturesNamesRecurse() returns an empty list.
>>>>
>>>> I'm not quite sure what is going on in the code, but this behavior
>>>> still seems to be grabbing the ID even though it isn't annotated.
>>>> I'm not sure if it is an ecore issue (falsly reporting an annotation
>>>> on the ID attribute) or a Teneo issue.
>>>>
>>>> Brian
>>>>
>>>> Martin Taal wrote:
>>>>> I solved it differently, an option now controls the default name of
>>>>> an id-efeature:
>>>>> PersistenceOptions.DEFAULT_ID_FEATURE_NAME
>>>>>
>>>>> the default value has been changed to e_id so that it is less
>>>>> likely that clashes occur.
>>>>>
>>>>> This has been checked in.
>>>>>
>>>>> gr. Martin
>>>>>
>>>>> Brian Vetter wrote:
>>>>>>
>>>>>> Martin Taal wrote:
>>>>>>> Brian,
>>>>>>> Automatically assuming that an attribute with name 'id' is the
>>>>>>> id-attribute (if there is no other id attribute) will be removed.
>>>>>>
>>>>>> Cool. Now that I've got Teneo building, I can pull it down and
>>>>>> test it or if you point me in the right direction, I can excise it
>>>>>> myself.
>>>>>>
>>>>>>> fyi, the auto-generated id (e_id) field does not work in
>>>>>>> situations were you serialize and then de-serialize objects as
>>>>>>> the synthetic id is not (de-)serialized with the object.
>>>>>>
>>>>>> I presume they are only being used for persistence purposes? Since
>>>>>> I'm not using them for anything, what, if any, are the downsides
>>>>>> of this? Do these ids have any value outside of the database
>>>>>> references?
>>>>>>
>>>>>> Thanks,
>>>>>>
>>>>>> Brian
>>>>>
>>>>>
>>>
>>>
|
|
|
| Re: Teneo: Identity (ID) scope conflicts [message #70681 is a reply to message #70653] |
Tue, 06 February 2007 23:14 |
Martin Taal
Messages: 5468
Registered: July 2009 |
Senior Member |
|
|
Brian,
Yes this is the correct location to disable this. I am not (yet) 100% convinced that the
ID-attribute can be ignored for determining if it is a database id. The unique attribute can not be
used as it seems to be false as a default. Maybe optional can be a correct discriminator (a real id
can not be optional).
gr. Martin
Brian Vetter wrote:
> Oops, I forgot to include the line number and the file: 509 of
> DefaultAnnotator.java.
>
> BTW, I have no intention of this being a proposed fix - just that as an
> experiment of cutting out the code in that if statement, whether I'd get
> my expected behavior.
>
> Brian
>
> Brian Vetter wrote:
>> Just for grins, I changed line xx in xx to the following:
>>
>> if (false && eAttribute.isID() && aAttribute.getId() == null) {
>> ^^^^^^^^^
>>
>> While not 100% confident, I did seem to get the behavior I
>> wanted/expected. All of the types that I had that included id
>> attributes now sport e_id fields for their primary keys and my id
>> fields are now simple columns in the DB. I need to experiment a bit
>> to see if the idrefs work as I expected.
>>
>> Brian
>>
>> Brian Vetter wrote:
>>> Apparently, the default XSD->ecore mapping translates my id
>>> attributes with the ID property of the eattribute to true. The
>>> original XSD attribute definition is:
>>>
>>> <attribute name="id" type="ID"></attribute>
>>>
>>> Here's the ecore translation of the attribute - it works just as
>>> specified as in section 4.1 of the xsd->ecore mapping document.
>>>
>>> <eStructuralFeatures xsi:type="ecore:EAttribute" name="id"
>>> unique="false" eType="ecore:EDataType
>>> http://www.eclipse.org/emf/2003/XMLType#//ID"
>>> iD="true">
>>> <eAnnotations
>>> source="http:///org/eclipse/emf/ecore/util/ExtendedMetaData">
>>> <details key="kind" value="attribute"/>
>>> <details key="name" value="id"/>
>>> </eAnnotations>
>>> </eStructuralFeatures>
>>>
>>> The root problem is still the same: the ids in an XML Schema document
>>> are only scoped to the document, not to the database and thus are
>>> seldom unique. In addition, they are optional in many cases. So using
>>> them to be a unique primary key isn't feasible without reworking the
>>> original XSDs to make them DB aware.
>>>
>>> So is there an easy way for me to control the mapping for IDs for all
>>> of my schemas or is there some other way to distinguish between an
>>> XSD:ID and one specified in ecore that needs to be used as the DB
>>> identifier? Is the "unique" attribute useful here?
>>>
>>> Brian
>>>
>>> Martin Taal wrote:
>>>> Brian,
>>>> The id annotation is also added automatically when the ID property
>>>> of the eattribute is true. Is this the case with your model?
>>>>
>>>> gr. Martin
>>>>
>>>> Brian Vetter wrote:
>>>>> Martin,
>>>>>
>>>>> I updated to the latest source and it still decides to assign my ID
>>>>> attribute as the primary key even though there is no @Id annotation
>>>>> set for it. I tried both the default setting as well as trying to
>>>>> explicitly set DEFAULT_ID_FEATURE_NAME (although it shouldn't have
>>>>> mattered - I did it primary to make sure I was building against the
>>>>> latest source).
>>>>>
>>>>> While debugging, I see in getIDFeaturesNamesRecurse() that it looks
>>>>> for an id attribute in line 1339 and if found, adds it to a list.
>>>>> The calling function getIDFeaturesNames() that refers to the bug,
>>>>> simply adds the default id attribute name if the
>>>>> getIDFeaturesNamesRecurse() returns an empty list.
>>>>>
>>>>> I'm not quite sure what is going on in the code, but this behavior
>>>>> still seems to be grabbing the ID even though it isn't annotated.
>>>>> I'm not sure if it is an ecore issue (falsly reporting an
>>>>> annotation on the ID attribute) or a Teneo issue.
>>>>>
>>>>> Brian
>>>>>
>>>>> Martin Taal wrote:
>>>>>> I solved it differently, an option now controls the default name
>>>>>> of an id-efeature:
>>>>>> PersistenceOptions.DEFAULT_ID_FEATURE_NAME
>>>>>>
>>>>>> the default value has been changed to e_id so that it is less
>>>>>> likely that clashes occur.
>>>>>>
>>>>>> This has been checked in.
>>>>>>
>>>>>> gr. Martin
>>>>>>
>>>>>> Brian Vetter wrote:
>>>>>>>
>>>>>>> Martin Taal wrote:
>>>>>>>> Brian,
>>>>>>>> Automatically assuming that an attribute with name 'id' is the
>>>>>>>> id-attribute (if there is no other id attribute) will be removed.
>>>>>>>
>>>>>>> Cool. Now that I've got Teneo building, I can pull it down and
>>>>>>> test it or if you point me in the right direction, I can excise
>>>>>>> it myself.
>>>>>>>
>>>>>>>> fyi, the auto-generated id (e_id) field does not work in
>>>>>>>> situations were you serialize and then de-serialize objects as
>>>>>>>> the synthetic id is not (de-)serialized with the object.
>>>>>>>
>>>>>>> I presume they are only being used for persistence purposes?
>>>>>>> Since I'm not using them for anything, what, if any, are the
>>>>>>> downsides of this? Do these ids have any value outside of the
>>>>>>> database references?
>>>>>>>
>>>>>>> Thanks,
>>>>>>>
>>>>>>> Brian
>>>>>>
>>>>>>
>>>>
>>>>
--
With Regards, Martin Taal
Springsite/Elver.org
Office: Hardwareweg 4, 3821 BV Amersfoort
Postal: Nassaulaan 7, 3941 EC Doorn
The Netherlands
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: Teneo: Identity (ID) scope conflicts [message #70755 is a reply to message #70681] |
Wed, 07 February 2007 19:58 |
Brian Vetter
Messages: 74
Registered: July 2009 |
Member |
|
|
Martin,
While optional is one way to discriminate, I'm not sure it is sufficient. An XSD can also require an ID attribute, yet it may only be unique to the document and not globally/DB unique. From what I can tell, ecore will map all attributes of type ID to an EAttribute with ID set to "true" and unique set to "false". If you simply look at the ID value, you will incorrectly associate all ID types as a unique database key.
I'm arguing that you shouldn't do this automatically. You should only map an ID to a DB key unless an accompanying @Id annotation is there and that by default, an ID is not assumed to be a key.
Alternatively, you could use the "unique" attribute, but apparently, you have some concerns about it since it is usually false - at least it is when mapping an ID type in an XSD (which is most likely correct from my perspective :->). If someone were creating a model directly in ecore (or perhaps some other mapping), I would presume that "unique" may sometimes be "true", which would seem to be a likely candidate for a key (especially if ID is true). I saw a tersely worded bugzilla note (156934) that implies you've taken a hard look at unique in the past so perhaps it too is not sufficient for the purpose of automatically assuming/mapping to a DB key or at least, placing a unique constraint on a column.
Perhaps you can let the decision to perform this mapping be controlled by a preference. For example, if you have a preference called DEFAULT_ID_PRIMARY_KEY that when set to true, does the mapping as it works today. When false, it does not automatically map ID-typed attributes to a primary key. In either case, you can override the default behavior by specifying the appropriate annotation.
If emf/ecore supported the key/keyref/unique constraint mappings, that might have been a means for specifying keys and such, although that again may be somewhat limited by scope.
Brian
Martin Taal wrote:
> Brian,
> Yes this is the correct location to disable this. I am not (yet) 100%
> convinced that the ID-attribute can be ignored for determining if it is
> a database id. The unique attribute can not be used as it seems to be
> false as a default. Maybe optional can be a correct discriminator (a
> real id can not be optional).
>
> gr. Martin
>
> Brian Vetter wrote:
>> Oops, I forgot to include the line number and the file: 509 of
>> DefaultAnnotator.java.
>>
>> BTW, I have no intention of this being a proposed fix - just that as
>> an experiment of cutting out the code in that if statement, whether
>> I'd get my expected behavior.
>>
>> Brian
>>
>> Brian Vetter wrote:
>>> Just for grins, I changed line xx in xx to the following:
>>>
>>> if (false && eAttribute.isID() && aAttribute.getId() == null) {
>>> ^^^^^^^^^
>>>
>>> While not 100% confident, I did seem to get the behavior I
>>> wanted/expected. All of the types that I had that included id
>>> attributes now sport e_id fields for their primary keys and my id
>>> fields are now simple columns in the DB. I need to experiment a bit
>>> to see if the idrefs work as I expected.
>>>
>>> Brian
>>>
>>> Brian Vetter wrote:
>>>> Apparently, the default XSD->ecore mapping translates my id
>>>> attributes with the ID property of the eattribute to true. The
>>>> original XSD attribute definition is:
>>>>
>>>> <attribute name="id" type="ID"></attribute>
>>>>
>>>> Here's the ecore translation of the attribute - it works just as
>>>> specified as in section 4.1 of the xsd->ecore mapping document.
>>>>
>>>> <eStructuralFeatures xsi:type="ecore:EAttribute" name="id"
>>>> unique="false" eType="ecore:EDataType
>>>> http://www.eclipse.org/emf/2003/XMLType#//ID"
>>>> iD="true">
>>>> <eAnnotations
>>>> source="http:///org/eclipse/emf/ecore/util/ExtendedMetaData">
>>>> <details key="kind" value="attribute"/>
>>>> <details key="name" value="id"/>
>>>> </eAnnotations>
>>>> </eStructuralFeatures>
>>>>
>>>> The root problem is still the same: the ids in an XML Schema
>>>> document are only scoped to the document, not to the database and
>>>> thus are seldom unique. In addition, they are optional in many
>>>> cases. So using them to be a unique primary key isn't feasible
>>>> without reworking the original XSDs to make them DB aware.
>>>>
>>>> So is there an easy way for me to control the mapping for IDs for
>>>> all of my schemas or is there some other way to distinguish between
>>>> an XSD:ID and one specified in ecore that needs to be used as the DB
>>>> identifier? Is the "unique" attribute useful here?
>>>>
>>>> Brian
>>>>
>>>> Martin Taal wrote:
>>>>> Brian,
>>>>> The id annotation is also added automatically when the ID property
>>>>> of the eattribute is true. Is this the case with your model?
>>>>>
>>>>> gr. Martin
>>>>>
>>>>> Brian Vetter wrote:
>>>>>> Martin,
>>>>>>
>>>>>> I updated to the latest source and it still decides to assign my
>>>>>> ID attribute as the primary key even though there is no @Id
>>>>>> annotation set for it. I tried both the default setting as well as
>>>>>> trying to explicitly set DEFAULT_ID_FEATURE_NAME (although it
>>>>>> shouldn't have mattered - I did it primary to make sure I was
>>>>>> building against the latest source).
>>>>>>
>>>>>> While debugging, I see in getIDFeaturesNamesRecurse() that it
>>>>>> looks for an id attribute in line 1339 and if found, adds it to a
>>>>>> list. The calling function getIDFeaturesNames() that refers to the
>>>>>> bug, simply adds the default id attribute name if the
>>>>>> getIDFeaturesNamesRecurse() returns an empty list.
>>>>>>
>>>>>> I'm not quite sure what is going on in the code, but this behavior
>>>>>> still seems to be grabbing the ID even though it isn't annotated.
>>>>>> I'm not sure if it is an ecore issue (falsly reporting an
>>>>>> annotation on the ID attribute) or a Teneo issue.
>>>>>>
>>>>>> Brian
>>>>>>
>>>>>> Martin Taal wrote:
>>>>>>> I solved it differently, an option now controls the default name
>>>>>>> of an id-efeature:
>>>>>>> PersistenceOptions.DEFAULT_ID_FEATURE_NAME
>>>>>>>
>>>>>>> the default value has been changed to e_id so that it is less
>>>>>>> likely that clashes occur.
>>>>>>>
>>>>>>> This has been checked in.
>>>>>>>
>>>>>>> gr. Martin
>>>>>>>
>>>>>>> Brian Vetter wrote:
>>>>>>>>
>>>>>>>> Martin Taal wrote:
>>>>>>>>> Brian,
>>>>>>>>> Automatically assuming that an attribute with name 'id' is the
>>>>>>>>> id-attribute (if there is no other id attribute) will be removed.
>>>>>>>>
>>>>>>>> Cool. Now that I've got Teneo building, I can pull it down and
>>>>>>>> test it or if you point me in the right direction, I can excise
>>>>>>>> it myself.
>>>>>>>>
>>>>>>>>> fyi, the auto-generated id (e_id) field does not work in
>>>>>>>>> situations were you serialize and then de-serialize objects as
>>>>>>>>> the synthetic id is not (de-)serialized with the object.
>>>>>>>>
>>>>>>>> I presume they are only being used for persistence purposes?
>>>>>>>> Since I'm not using them for anything, what, if any, are the
>>>>>>>> downsides of this? Do these ids have any value outside of the
>>>>>>>> database references?
>>>>>>>>
>>>>>>>> Thanks,
>>>>>>>>
>>>>>>>> Brian
>>>>>>>
>>>>>>>
>>>>>
>>>>>
>
>
|
|
|
| Re: Teneo: Identity (ID) scope conflicts [message #70816 is a reply to message #70755] |
Wed, 07 February 2007 20:18 |
Eclipse User |
|
|
|
Originally posted by: merks.ca.ibm.com
Brian,
The unique attribute is really not meaningful unless the upper bound is
something other than 1. It indicates whether the same value may occur
more than once in the multiplicity of values. In the future we may use
it to generate a Set verses a List (and in combination with ordered a
Collection), but again, that only affects the isMany case.
Note that in EMF 2.3, we provide support for EReference.eKeys, which is
very much like a keyref. It specifies a set of the EAttributes from the
EClass that is the EReference's eType that unique identify the
referenced instance with respect to that particular EReference. The
reference will then be serialized as @something[feature='value'] which
represent the object in the "something" reference value whose "feature"
attribute has the value 'value'. I still need to provide Ecore -> XSD
->Ecore mapping support for this (and all the other generics support
that was added).
Brian Vetter wrote:
> Martin,
>
> While optional is one way to discriminate, I'm not sure it is
> sufficient. An XSD can also require an ID attribute, yet it may only
> be unique to the document and not globally/DB unique. From what I can
> tell, ecore will map all attributes of type ID to an EAttribute with
> ID set to "true" and unique set to "false". If you simply look at the
> ID value, you will incorrectly associate all ID types as a unique
> database key.
>
> I'm arguing that you shouldn't do this automatically. You should only
> map an ID to a DB key unless an accompanying @Id annotation is there
> and that by default, an ID is not assumed to be a key.
>
> Alternatively, you could use the "unique" attribute, but apparently,
> you have some concerns about it since it is usually false - at least
> it is when mapping an ID type in an XSD (which is most likely correct
> from my perspective :->). If someone were creating a model directly in
> ecore (or perhaps some other mapping), I would presume that "unique"
> may sometimes be "true", which would seem to be a likely candidate for
> a key (especially if ID is true). I saw a tersely worded bugzilla note
> (156934) that implies you've taken a hard look at unique in the past
> so perhaps it too is not sufficient for the purpose of automatically
> assuming/mapping to a DB key or at least, placing a unique constraint
> on a column.
>
> Perhaps you can let the decision to perform this mapping be controlled
> by a preference. For example, if you have a preference called
> DEFAULT_ID_PRIMARY_KEY that when set to true, does the mapping as it
> works today. When false, it does not automatically map ID-typed
> attributes to a primary key. In either case, you can override the
> default behavior by specifying the appropriate annotation.
>
> If emf/ecore supported the key/keyref/unique constraint mappings, that
> might have been a means for specifying keys and such, although that
> again may be somewhat limited by scope.
> Brian
>
> Martin Taal wrote:
>> Brian,
>> Yes this is the correct location to disable this. I am not (yet) 100%
>> convinced that the ID-attribute can be ignored for determining if it
>> is a database id. The unique attribute can not be used as it seems to
>> be false as a default. Maybe optional can be a correct discriminator
>> (a real id can not be optional).
>>
>> gr. Martin
>>
>> Brian Vetter wrote:
>>> Oops, I forgot to include the line number and the file: 509 of
>>> DefaultAnnotator.java.
>>>
>>> BTW, I have no intention of this being a proposed fix - just that as
>>> an experiment of cutting out the code in that if statement, whether
>>> I'd get my expected behavior.
>>>
>>> Brian
>>>
>>> Brian Vetter wrote:
>>>> Just for grins, I changed line xx in xx to the following:
>>>>
>>>> if (false && eAttribute.isID() && aAttribute.getId() == null) {
>>>> ^^^^^^^^^
>>>>
>>>> While not 100% confident, I did seem to get the behavior I
>>>> wanted/expected. All of the types that I had that included id
>>>> attributes now sport e_id fields for their primary keys and my id
>>>> fields are now simple columns in the DB. I need to experiment a
>>>> bit to see if the idrefs work as I expected.
>>>>
>>>> Brian
>>>>
>>>> Brian Vetter wrote:
>>>>> Apparently, the default XSD->ecore mapping translates my id
>>>>> attributes with the ID property of the eattribute to true. The
>>>>> original XSD attribute definition is:
>>>>>
>>>>> <attribute name="id" type="ID"></attribute>
>>>>>
>>>>> Here's the ecore translation of the attribute - it works just as
>>>>> specified as in section 4.1 of the xsd->ecore mapping document.
>>>>>
>>>>> <eStructuralFeatures xsi:type="ecore:EAttribute" name="id"
>>>>> unique="false" eType="ecore:EDataType
>>>>> http://www.eclipse.org/emf/2003/XMLType#//ID"
>>>>> iD="true">
>>>>> <eAnnotations
>>>>> source="http:///org/eclipse/emf/ecore/util/ExtendedMetaData">
>>>>> <details key="kind" value="attribute"/>
>>>>> <details key="name" value="id"/>
>>>>> </eAnnotations>
>>>>> </eStructuralFeatures>
>>>>>
>>>>> The root problem is still the same: the ids in an XML Schema
>>>>> document are only scoped to the document, not to the database and
>>>>> thus are seldom unique. In addition, they are optional in many
>>>>> cases. So using them to be a unique primary key isn't feasible
>>>>> without reworking the original XSDs to make them DB aware.
>>>>>
>>>>> So is there an easy way for me to control the mapping for IDs for
>>>>> all of my schemas or is there some other way to distinguish
>>>>> between an XSD:ID and one specified in ecore that needs to be used
>>>>> as the DB identifier? Is the "unique" attribute useful here?
>>>>>
>>>>> Brian
>>>>>
>>>>> Martin Taal wrote:
>>>>>> Brian,
>>>>>> The id annotation is also added automatically when the ID
>>>>>> property of the eattribute is true. Is this the case with your
>>>>>> model?
>>>>>>
>>>>>> gr. Martin
>>>>>>
>>>>>> Brian Vetter wrote:
>>>>>>> Martin,
>>>>>>>
>>>>>>> I updated to the latest source and it still decides to assign my
>>>>>>> ID attribute as the primary key even though there is no @Id
>>>>>>> annotation set for it. I tried both the default setting as well
>>>>>>> as trying to explicitly set DEFAULT_ID_FEATURE_NAME (although it
>>>>>>> shouldn't have mattered - I did it primary to make sure I was
>>>>>>> building against the latest source).
>>>>>>>
>>>>>>> While debugging, I see in getIDFeaturesNamesRecurse() that it
>>>>>>> looks for an id attribute in line 1339 and if found, adds it to
>>>>>>> a list. The calling function getIDFeaturesNames() that refers to
>>>>>>> the bug, simply adds the default id attribute name if the
>>>>>>> getIDFeaturesNamesRecurse() returns an empty list.
>>>>>>>
>>>>>>> I'm not quite sure what is going on in the code, but this
>>>>>>> behavior still seems to be grabbing the ID even though it isn't
>>>>>>> annotated. I'm not sure if it is an ecore issue (falsly
>>>>>>> reporting an annotation on the ID attribute) or a Teneo issue.
>>>>>>>
>>>>>>> Brian
>>>>>>>
>>>>>>> Martin Taal wrote:
>>>>>>>> I solved it differently, an option now controls the default
>>>>>>>> name of an id-efeature:
>>>>>>>> PersistenceOptions.DEFAULT_ID_FEATURE_NAME
>>>>>>>>
>>>>>>>> the default value has been changed to e_id so that it is less
>>>>>>>> likely that clashes occur.
>>>>>>>>
>>>>>>>> This has been checked in.
>>>>>>>>
>>>>>>>> gr. Martin
>>>>>>>>
>>>>>>>> Brian Vetter wrote:
>>>>>>>>>
>>>>>>>>> Martin Taal wrote:
>>>>>>>>>> Brian,
>>>>>>>>>> Automatically assuming that an attribute with name 'id' is
>>>>>>>>>> the id-attribute (if there is no other id attribute) will be
>>>>>>>>>> removed.
>>>>>>>>>
>>>>>>>>> Cool. Now that I've got Teneo building, I can pull it down and
>>>>>>>>> test it or if you point me in the right direction, I can
>>>>>>>>> excise it myself.
>>>>>>>>>
>>>>>>>>>> fyi, the auto-generated id (e_id) field does not work in
>>>>>>>>>> situations were you serialize and then de-serialize objects
>>>>>>>>>> as the synthetic id is not (de-)serialized with the object.
>>>>>>>>>
>>>>>>>>> I presume they are only being used for persistence purposes?
>>>>>>>>> Since I'm not using them for anything, what, if any, are the
>>>>>>>>> downsides of this? Do these ids have any value outside of the
>>>>>>>>> database references?
>>>>>>>>>
>>>>>>>>> Thanks,
>>>>>>>>>
>>>>>>>>> Brian
>>>>>>>>
>>>>>>>>
>>>>>>
>>>>>>
>>
>>
|
|
|
| Re: Teneo: Identity (ID) scope conflicts [message #70929 is a reply to message #70816] |
Thu, 08 February 2007 08:54 |
Martin Taal
Messages: 5468
Registered: July 2009 |
Senior Member |
|
|
Brian,
Afaics opinions can differ on what the exact semantics of ID is (it depends on the specific
usecase). The current approach of translating the ID to a database id is from before Teneo supported
the @id annotation. I tend to agree that @id is a more explicit approach than the ID which is more
xml oriented. So please enter a bugzilla if you want the current ID behavior to be controlled by an
option.
gr. Martin
Ed Merks wrote:
> Brian,
>
> The unique attribute is really not meaningful unless the upper bound is
> something other than 1. It indicates whether the same value may occur
> more than once in the multiplicity of values. In the future we may use
> it to generate a Set verses a List (and in combination with ordered a
> Collection), but again, that only affects the isMany case.
>
> Note that in EMF 2.3, we provide support for EReference.eKeys, which is
> very much like a keyref. It specifies a set of the EAttributes from the
> EClass that is the EReference's eType that unique identify the
> referenced instance with respect to that particular EReference. The
> reference will then be serialized as @something[feature='value'] which
> represent the object in the "something" reference value whose "feature"
> attribute has the value 'value'. I still need to provide Ecore -> XSD
> ->Ecore mapping support for this (and all the other generics support
> that was added).
>
>
> Brian Vetter wrote:
>> Martin,
>>
>> While optional is one way to discriminate, I'm not sure it is
>> sufficient. An XSD can also require an ID attribute, yet it may only
>> be unique to the document and not globally/DB unique. From what I can
>> tell, ecore will map all attributes of type ID to an EAttribute with
>> ID set to "true" and unique set to "false". If you simply look at the
>> ID value, you will incorrectly associate all ID types as a unique
>> database key.
>>
>> I'm arguing that you shouldn't do this automatically. You should only
>> map an ID to a DB key unless an accompanying @Id annotation is there
>> and that by default, an ID is not assumed to be a key.
>>
>> Alternatively, you could use the "unique" attribute, but apparently,
>> you have some concerns about it since it is usually false - at least
>> it is when mapping an ID type in an XSD (which is most likely correct
>> from my perspective :->). If someone were creating a model directly in
>> ecore (or perhaps some other mapping), I would presume that "unique"
>> may sometimes be "true", which would seem to be a likely candidate for
>> a key (especially if ID is true). I saw a tersely worded bugzilla note
>> (156934) that implies you've taken a hard look at unique in the past
>> so perhaps it too is not sufficient for the purpose of automatically
>> assuming/mapping to a DB key or at least, placing a unique constraint
>> on a column.
>>
>> Perhaps you can let the decision to perform this mapping be controlled
>> by a preference. For example, if you have a preference called
>> DEFAULT_ID_PRIMARY_KEY that when set to true, does the mapping as it
>> works today. When false, it does not automatically map ID-typed
>> attributes to a primary key. In either case, you can override the
>> default behavior by specifying the appropriate annotation.
>>
>> If emf/ecore supported the key/keyref/unique constraint mappings, that
>> might have been a means for specifying keys and such, although that
>> again may be somewhat limited by scope.
>> Brian
>>
>> Martin Taal wrote:
>>> Brian,
>>> Yes this is the correct location to disable this. I am not (yet) 100%
>>> convinced that the ID-attribute can be ignored for determining if it
>>> is a database id. The unique attribute can not be used as it seems to
>>> be false as a default. Maybe optional can be a correct discriminator
>>> (a real id can not be optional).
>>>
>>> gr. Martin
>>>
>>> Brian Vetter wrote:
>>>> Oops, I forgot to include the line number and the file: 509 of
>>>> DefaultAnnotator.java.
>>>>
>>>> BTW, I have no intention of this being a proposed fix - just that as
>>>> an experiment of cutting out the code in that if statement, whether
>>>> I'd get my expected behavior.
>>>>
>>>> Brian
>>>>
>>>> Brian Vetter wrote:
>>>>> Just for grins, I changed line xx in xx to the following:
>>>>>
>>>>> if (false && eAttribute.isID() && aAttribute.getId() == null) {
>>>>> ^^^^^^^^^
>>>>>
>>>>> While not 100% confident, I did seem to get the behavior I
>>>>> wanted/expected. All of the types that I had that included id
>>>>> attributes now sport e_id fields for their primary keys and my id
>>>>> fields are now simple columns in the DB. I need to experiment a
>>>>> bit to see if the idrefs work as I expected.
>>>>>
>>>>> Brian
>>>>>
>>>>> Brian Vetter wrote:
>>>>>> Apparently, the default XSD->ecore mapping translates my id
>>>>>> attributes with the ID property of the eattribute to true. The
>>>>>> original XSD attribute definition is:
>>>>>>
>>>>>> <attribute name="id" type="ID"></attribute>
>>>>>>
>>>>>> Here's the ecore translation of the attribute - it works just as
>>>>>> specified as in section 4.1 of the xsd->ecore mapping document.
>>>>>>
>>>>>> <eStructuralFeatures xsi:type="ecore:EAttribute" name="id"
>>>>>> unique="false" eType="ecore:EDataType
>>>>>> http://www.eclipse.org/emf/2003/XMLType#//ID"
>>>>>> iD="true">
>>>>>> <eAnnotations
>>>>>> source="http:///org/eclipse/emf/ecore/util/ExtendedMetaData">
>>>>>> <details key="kind" value="attribute"/>
>>>>>> <details key="name" value="id"/>
>>>>>> </eAnnotations>
>>>>>> </eStructuralFeatures>
>>>>>>
>>>>>> The root problem is still the same: the ids in an XML Schema
>>>>>> document are only scoped to the document, not to the database and
>>>>>> thus are seldom unique. In addition, they are optional in many
>>>>>> cases. So using them to be a unique primary key isn't feasible
>>>>>> without reworking the original XSDs to make them DB aware.
>>>>>>
>>>>>> So is there an easy way for me to control the mapping for IDs for
>>>>>> all of my schemas or is there some other way to distinguish
>>>>>> between an XSD:ID and one specified in ecore that needs to be used
>>>>>> as the DB identifier? Is the "unique" attribute useful here?
>>>>>>
>>>>>> Brian
>>>>>>
>>>>>> Martin Taal wrote:
>>>>>>> Brian,
>>>>>>> The id annotation is also added automatically when the ID
>>>>>>> property of the eattribute is true. Is this the case with your
>>>>>>> model?
>>>>>>>
>>>>>>> gr. Martin
>>>>>>>
>>>>>>> Brian Vetter wrote:
>>>>>>>> Martin,
>>>>>>>>
>>>>>>>> I updated to the latest source and it still decides to assign my
>>>>>>>> ID attribute as the primary key even though there is no @Id
>>>>>>>> annotation set for it. I tried both the default setting as well
>>>>>>>> as trying to explicitly set DEFAULT_ID_FEATURE_NAME (although it
>>>>>>>> shouldn't have mattered - I did it primary to make sure I was
>>>>>>>> building against the latest source).
>>>>>>>>
>>>>>>>> While debugging, I see in getIDFeaturesNamesRecurse() that it
>>>>>>>> looks for an id attribute in line 1339 and if found, adds it to
>>>>>>>> a list. The calling function getIDFeaturesNames() that refers to
>>>>>>>> the bug, simply adds the default id attribute name if the
>>>>>>>> getIDFeaturesNamesRecurse() returns an empty list.
>>>>>>>>
>>>>>>>> I'm not quite sure what is going on in the code, but this
>>>>>>>> behavior still seems to be grabbing the ID even though it isn't
>>>>>>>> annotated. I'm not sure if it is an ecore issue (falsly
>>>>>>>> reporting an annotation on the ID attribute) or a Teneo issue.
>>>>>>>>
>>>>>>>> Brian
>>>>>>>>
>>>>>>>> Martin Taal wrote:
>>>>>>>>> I solved it differently, an option now controls the default
>>>>>>>>> name of an id-efeature:
>>>>>>>>> PersistenceOptions.DEFAULT_ID_FEATURE_NAME
>>>>>>>>>
>>>>>>>>> the default value has been changed to e_id so that it is less
>>>>>>>>> likely that clashes occur.
>>>>>>>>>
>>>>>>>>> This has been checked in.
>>>>>>>>>
>>>>>>>>> gr. Martin
>>>>>>>>>
>>>>>>>>> Brian Vetter wrote:
>>>>>>>>>>
>>>>>>>>>> Martin Taal wrote:
>>>>>>>>>>> Brian,
>>>>>>>>>>> Automatically assuming that an attribute with name 'id' is
>>>>>>>>>>> the id-attribute (if there is no other id attribute) will be
>>>>>>>>>>> removed.
>>>>>>>>>>
>>>>>>>>>> Cool. Now that I've got Teneo building, I can pull it down and
>>>>>>>>>> test it or if you point me in the right direction, I can
>>>>>>>>>> excise it myself.
>>>>>>>>>>
>>>>>>>>>>> fyi, the auto-generated id (e_id) field does not work in
>>>>>>>>>>> situations were you serialize and then de-serialize objects
>>>>>>>>>>> as the synthetic id is not (de-)serialized with the object.
>>>>>>>>>>
>>>>>>>>>> I presume they are only being used for persistence purposes?
>>>>>>>>>> Since I'm not using them for anything, what, if any, are the
>>>>>>>>>> downsides of this? Do these ids have any value outside of the
>>>>>>>>>> database references?
>>>>>>>>>>
>>>>>>>>>> Thanks,
>>>>>>>>>>
>>>>>>>>>> Brian
>>>>>>>>>
>>>>>>>>>
>>>>>>>
>>>>>>>
>>>
>>>
--
With Regards, Martin Taal
Springsite/Elver.org
Office: Hardwareweg 4, 3821 BV Amersfoort
Postal: Nassaulaan 7, 3941 EC Doorn
The Netherlands
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: Teneo: Identity (ID) scope conflicts [message #71053 is a reply to message #70929] |
Thu, 08 February 2007 16:15 |
Brian Vetter
Messages: 74
Registered: July 2009 |
Member |
|
|
I entered bugzilla ID 173478 for this request.
Thanks,
Brian
Martin Taal wrote:
> Brian,
> Afaics opinions can differ on what the exact semantics of ID is (it
> depends on the specific usecase). The current approach of translating
> the ID to a database id is from before Teneo supported the @id
> annotation. I tend to agree that @id is a more explicit approach than
> the ID which is more xml oriented. So please enter a bugzilla if you
> want the current ID behavior to be controlled by an option.
>
> gr. Martin
>
> Ed Merks wrote:
>> Brian,
>>
>> The unique attribute is really not meaningful unless the upper bound
>> is something other than 1. It indicates whether the same value may
>> occur more than once in the multiplicity of values. In the future we
>> may use it to generate a Set verses a List (and in combination with
>> ordered a Collection), but again, that only affects the isMany case.
>>
>> Note that in EMF 2.3, we provide support for EReference.eKeys, which
>> is very much like a keyref. It specifies a set of the EAttributes
>> from the EClass that is the EReference's eType that unique identify
>> the referenced instance with respect to that particular EReference.
>> The reference will then be serialized as @something[feature='value']
>> which represent the object in the "something" reference value whose
>> "feature" attribute has the value 'value'. I still need to provide
>> Ecore -> XSD ->Ecore mapping support for this (and all the other
>> generics support that was added).
>>
>>
>> Brian Vetter wrote:
>>> Martin,
>>>
>>> While optional is one way to discriminate, I'm not sure it is
>>> sufficient. An XSD can also require an ID attribute, yet it may only
>>> be unique to the document and not globally/DB unique. From what I can
>>> tell, ecore will map all attributes of type ID to an EAttribute with
>>> ID set to "true" and unique set to "false". If you simply look at the
>>> ID value, you will incorrectly associate all ID types as a unique
>>> database key.
>>>
>>> I'm arguing that you shouldn't do this automatically. You should only
>>> map an ID to a DB key unless an accompanying @Id annotation is there
>>> and that by default, an ID is not assumed to be a key.
>>>
>>> Alternatively, you could use the "unique" attribute, but apparently,
>>> you have some concerns about it since it is usually false - at least
>>> it is when mapping an ID type in an XSD (which is most likely correct
>>> from my perspective :->). If someone were creating a model directly
>>> in ecore (or perhaps some other mapping), I would presume that
>>> "unique" may sometimes be "true", which would seem to be a likely
>>> candidate for a key (especially if ID is true). I saw a tersely
>>> worded bugzilla note (156934) that implies you've taken a hard look
>>> at unique in the past so perhaps it too is not sufficient for the
>>> purpose of automatically assuming/mapping to a DB key or at least,
>>> placing a unique constraint on a column.
>>>
>>> Perhaps you can let the decision to perform this mapping be
>>> controlled by a preference. For example, if you have a preference
>>> called DEFAULT_ID_PRIMARY_KEY that when set to true, does the mapping
>>> as it works today. When false, it does not automatically map ID-typed
>>> attributes to a primary key. In either case, you can override the
>>> default behavior by specifying the appropriate annotation.
>>>
>>> If emf/ecore supported the key/keyref/unique constraint mappings,
>>> that might have been a means for specifying keys and such, although
>>> that again may be somewhat limited by scope.
>>> Brian
>>>
>>> Martin Taal wrote:
>>>> Brian,
>>>> Yes this is the correct location to disable this. I am not (yet)
>>>> 100% convinced that the ID-attribute can be ignored for determining
>>>> if it is a database id. The unique attribute can not be used as it
>>>> seems to be false as a default. Maybe optional can be a correct
>>>> discriminator (a real id can not be optional).
>>>>
>>>> gr. Martin
>>>>
>>>> Brian Vetter wrote:
>>>>> Oops, I forgot to include the line number and the file: 509 of
>>>>> DefaultAnnotator.java.
>>>>>
>>>>> BTW, I have no intention of this being a proposed fix - just that
>>>>> as an experiment of cutting out the code in that if statement,
>>>>> whether I'd get my expected behavior.
>>>>>
>>>>> Brian
>>>>>
>>>>> Brian Vetter wrote:
>>>>>> Just for grins, I changed line xx in xx to the following:
>>>>>>
>>>>>> if (false && eAttribute.isID() && aAttribute.getId() == null) {
>>>>>> ^^^^^^^^^
>>>>>>
>>>>>> While not 100% confident, I did seem to get the behavior I
>>>>>> wanted/expected. All of the types that I had that included id
>>>>>> attributes now sport e_id fields for their primary keys and my id
>>>>>> fields are now simple columns in the DB. I need to experiment a
>>>>>> bit to see if the idrefs work as I expected.
>>>>>>
>>>>>> Brian
>>>>>>
>>>>>> Brian Vetter wrote:
>>>>>>> Apparently, the default XSD->ecore mapping translates my id
>>>>>>> attributes with the ID property of the eattribute to true. The
>>>>>>> original XSD attribute definition is:
>>>>>>>
>>>>>>> <attribute name="id" type="ID"></attribute>
>>>>>>>
>>>>>>> Here's the ecore translation of the attribute - it works just as
>>>>>>> specified as in section 4.1 of the xsd->ecore mapping document.
>>>>>>>
>>>>>>> <eStructuralFeatures xsi:type="ecore:EAttribute" name="id"
>>>>>>> unique="false" eType="ecore:EDataType
>>>>>>> http://www.eclipse.org/emf/2003/XMLType#//ID"
>>>>>>> iD="true">
>>>>>>> <eAnnotations
>>>>>>> source="http:///org/eclipse/emf/ecore/util/ExtendedMetaData">
>>>>>>> <details key="kind" value="attribute"/>
>>>>>>> <details key="name" value="id"/>
>>>>>>> </eAnnotations>
>>>>>>> </eStructuralFeatures>
>>>>>>>
>>>>>>> The root problem is still the same: the ids in an XML Schema
>>>>>>> document are only scoped to the document, not to the database and
>>>>>>> thus are seldom unique. In addition, they are optional in many
>>>>>>> cases. So using them to be a unique primary key isn't feasible
>>>>>>> without reworking the original XSDs to make them DB aware.
>>>>>>>
>>>>>>> So is there an easy way for me to control the mapping for IDs for
>>>>>>> all of my schemas or is there some other way to distinguish
>>>>>>> between an XSD:ID and one specified in ecore that needs to be
>>>>>>> used as the DB identifier? Is the "unique" attribute useful here?
>>>>>>>
>>>>>>> Brian
>>>>>>>
>>>>>>> Martin Taal wrote:
>>>>>>>> Brian,
>>>>>>>> The id annotation is also added automatically when the ID
>>>>>>>> property of the eattribute is true. Is this the case with your
>>>>>>>> model?
>>>>>>>>
>>>>>>>> gr. Martin
>>>>>>>>
>>>>>>>> Brian Vetter wrote:
>>>>>>>>> Martin,
>>>>>>>>>
>>>>>>>>> I updated to the latest source and it still decides to assign
>>>>>>>>> my ID attribute as the primary key even though there is no @Id
>>>>>>>>> annotation set for it. I tried both the default setting as well
>>>>>>>>> as trying to explicitly set DEFAULT_ID_FEATURE_NAME (although
>>>>>>>>> it shouldn't have mattered - I did it primary to make sure I
>>>>>>>>> was building against the latest source).
>>>>>>>>>
>>>>>>>>> While debugging, I see in getIDFeaturesNamesRecurse() that it
>>>>>>>>> looks for an id attribute in line 1339 and if found, adds it to
>>>>>>>>> a list. The calling function getIDFeaturesNames() that refers
>>>>>>>>> to the bug, simply adds the default id attribute name if the
>>>>>>>>> getIDFeaturesNamesRecurse() returns an empty list.
>>>>>>>>>
>>>>>>>>> I'm not quite sure what is going on in the code, but this
>>>>>>>>> behavior still seems to be grabbing the ID even though it isn't
>>>>>>>>> annotated. I'm not sure if it is an ecore issue (falsly
>>>>>>>>> reporting an annotation on the ID attribute) or a Teneo issue.
>>>>>>>>>
>>>>>>>>> Brian
>>>>>>>>>
>>>>>>>>> Martin Taal wrote:
>>>>>>>>>> I solved it differently, an option now controls the default
>>>>>>>>>> name of an id-efeature:
>>>>>>>>>> PersistenceOptions.DEFAULT_ID_FEATURE_NAME
>>>>>>>>>>
>>>>>>>>>> the default value has been changed to e_id so that it is less
>>>>>>>>>> likely that clashes occur.
>>>>>>>>>>
>>>>>>>>>> This has been checked in.
>>>>>>>>>>
>>>>>>>>>> gr. Martin
>>>>>>>>>>
>>>>>>>>>> Brian Vetter wrote:
>>>>>>>>>>>
>>>>>>>>>>> Martin Taal wrote:
>>>>>>>>>>>> Brian,
>>>>>>>>>>>> Automatically assuming that an attribute with name 'id' is
>>>>>>>>>>>> the id-attribute (if there is no other id attribute) will be
>>>>>>>>>>>> removed.
>>>>>>>>>>>
>>>>>>>>>>> Cool. Now that I've got Teneo building, I can pull it down
>>>>>>>>>>> and test it or if you point me in the right direction, I can
>>>>>>>>>>> excise it myself.
>>>>>>>>>>>
>>>>>>>>>>>> fyi, the auto-generated id (e_id) field does not work in
>>>>>>>>>>>> situations were you serialize and then de-serialize objects
>>>>>>>>>>>> as the synthetic id is not (de-)serialized with the object.
>>>>>>>>>>>
>>>>>>>>>>> I presume they are only being used for persistence purposes?
>>>>>>>>>>> Since I'm not using them for anything, what, if any, are the
>>>>>>>>>>> downsides of this? Do these ids have any value outside of the
>>>>>>>>>>> database references?
>>>>>>>>>>>
>>>>>>>>>>> Thanks,
>>>>>>>>>>>
>>>>>>>>>>> Brian
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>
>>>>
>
>
|
|
|
| Re: Teneo: Identity (ID) scope conflicts [message #602103 is a reply to message #70304] |
Sat, 03 February 2007 10:56 |
Martin Taal
Messages: 5468
Registered: July 2009 |
Senior Member |
|
|
Brian,
Automatically assuming that an attribute with name 'id' is the id-attribute (if there is no other id
attribute) will be removed.
fyi, the auto-generated id (e_id) field does not work in situations were you serialize and then
de-serialize objects as the synthetic id is not (de-)serialized with the object.
gr. Martin
Brian Vetter wrote:
> As I've read and witnessed, Teneo needs to place a unique id in every
> table. It will auto-generate one if a primary key (id) is not defined in
> a type/class (the name by default is e_id). If an element has an @Id
> annotation, it will use that as the primary key/id. I have also found
> that if a type defines an attributed named "id", it will use that at the
> primary key/id.
>
> I have a series of XSDs and documents that utilize ID and IDREF for
> internal references within the document. In this scenario, the IDs and
> references are scoped to the document. When I try to bring these into a
> database using Teneo, these IDs must now be scoped to database - they
> must be unique not just within the document, but all documents.
>
> While in a few cases, I can use annotations to change the primary key to
> another element (I haven't tried this yet so I don't know if it will
> override the check for the attributed named "id"), there are some types
> where there is no obvious unique key. Going back to the original schema
> developer to add one isn't really possible.
>
> Is there a way to tell Teneo to not use the ID attribute as the key and
> to auto-generate one (an e_id field) instead?
>
> And on a related front, is there plans for Teneo to support <key>,
> <keyref>, and <unique> in XSD in the future (or does it and I just
> didn't see it listed as supported on the web site or the test
> documents). I don't need it right now, but I see the need coming in the
> future.
>
> Thanks,
>
> Brian
--
With Regards, Martin Taal
Springsite/Elver.org
Office: Hardwareweg 4, 3821 BV Amersfoort
Postal: Nassaulaan 7, 3941 EC Doorn
The Netherlands
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: Teneo: Identity (ID) scope conflicts [message #602139 is a reply to message #70407] |
Mon, 05 February 2007 19:19 |
Martin Taal
Messages: 5468
Registered: July 2009 |
Senior Member |
|
|
I solved it differently, an option now controls the default name of an id-efeature:
PersistenceOptions.DEFAULT_ID_FEATURE_NAME
the default value has been changed to e_id so that it is less likely that clashes occur.
This has been checked in.
gr. Martin
Brian Vetter wrote:
>
> Martin Taal wrote:
>> Brian,
>> Automatically assuming that an attribute with name 'id' is the
>> id-attribute (if there is no other id attribute) will be removed.
>
> Cool. Now that I've got Teneo building, I can pull it down and test it
> or if you point me in the right direction, I can excise it myself.
>
>> fyi, the auto-generated id (e_id) field does not work in situations
>> were you serialize and then de-serialize objects as the synthetic id
>> is not (de-)serialized with the object.
>
> I presume they are only being used for persistence purposes? Since I'm
> not using them for anything, what, if any, are the downsides of this? Do
> these ids have any value outside of the database references?
>
> Thanks,
>
> Brian
--
With Regards, Martin Taal
Springsite/Elver.org
Office: Hardwareweg 4, 3821 BV Amersfoort
Postal: Nassaulaan 7, 3941 EC Doorn
The Netherlands
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: Teneo: Identity (ID) scope conflicts [message #602144 is a reply to message #70407] |
Mon, 05 February 2007 19:19 |
Martin Taal
Messages: 5468
Registered: July 2009 |
Senior Member |
|
|
Yes the synthetic id's are only used for persistence purposes. A synthetic id is not stored in the
object itself but in a weak reference cache within Teneo (see
org.eclipse.emf.teneo.hibernate.mapping.identifier.Identifie rCacheHandler).
The downside of a synthetic id is that it does not work in situations were you would want
(de-)serialization emf objects, for example in case of rich clients or web clients using jsf and
client side-state saving. When you serialize an object and send it over the wire and then get it
back (from the rich client) and de-serialize it again the id can not be found anymore in the
weak-reference cache.
The synthetic id is mainly there to easily support tutorials and testcases.
gr. Martin
Brian Vetter wrote:
>
> Martin Taal wrote:
>> Brian,
>> Automatically assuming that an attribute with name 'id' is the
>> id-attribute (if there is no other id attribute) will be removed.
>
> Cool. Now that I've got Teneo building, I can pull it down and test it
> or if you point me in the right direction, I can excise it myself.
>
>> fyi, the auto-generated id (e_id) field does not work in situations
>> were you serialize and then de-serialize objects as the synthetic id
>> is not (de-)serialized with the object.
>
> I presume they are only being used for persistence purposes? Since I'm
> not using them for anything, what, if any, are the downsides of this? Do
> these ids have any value outside of the database references?
>
> Thanks,
>
> Brian
--
With Regards, Martin Taal
Springsite/Elver.org
Office: Hardwareweg 4, 3821 BV Amersfoort
Postal: Nassaulaan 7, 3941 EC Doorn
The Netherlands
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: Teneo: Identity (ID) scope conflicts [message #602223 is a reply to message #70426] |
Tue, 06 February 2007 18:39 |
Brian Vetter
Messages: 74
Registered: July 2009 |
Member |
|
|
Martin,
I updated to the latest source and it still decides to assign my ID attribute as the primary key even though there is no @Id annotation set for it. I tried both the default setting as well as trying to explicitly set DEFAULT_ID_FEATURE_NAME (although it shouldn't have mattered - I did it primary to make sure I was building against the latest source).
While debugging, I see in getIDFeaturesNamesRecurse() that it looks for an id attribute in line 1339 and if found, adds it to a list. The calling function getIDFeaturesNames() that refers to the bug, simply adds the default id attribute name if the getIDFeaturesNamesRecurse() returns an empty list.
I'm not quite sure what is going on in the code, but this behavior still seems to be grabbing the ID even though it isn't annotated. I'm not sure if it is an ecore issue (falsly reporting an annotation on the ID attribute) or a Teneo issue.
Brian
Martin Taal wrote:
> I solved it differently, an option now controls the default name of an
> id-efeature:
> PersistenceOptions.DEFAULT_ID_FEATURE_NAME
>
> the default value has been changed to e_id so that it is less likely
> that clashes occur.
>
> This has been checked in.
>
> gr. Martin
>
> Brian Vetter wrote:
>>
>> Martin Taal wrote:
>>> Brian,
>>> Automatically assuming that an attribute with name 'id' is the
>>> id-attribute (if there is no other id attribute) will be removed.
>>
>> Cool. Now that I've got Teneo building, I can pull it down and test it
>> or if you point me in the right direction, I can excise it myself.
>>
>>> fyi, the auto-generated id (e_id) field does not work in situations
>>> were you serialize and then de-serialize objects as the synthetic id
>>> is not (de-)serialized with the object.
>>
>> I presume they are only being used for persistence purposes? Since I'm
>> not using them for anything, what, if any, are the downsides of this?
>> Do these ids have any value outside of the database references?
>>
>> Thanks,
>>
>> Brian
>
>
|
|
|
| Re: Teneo: Identity (ID) scope conflicts [message #602228 is a reply to message #70565] |
Tue, 06 February 2007 19:13 |
Martin Taal
Messages: 5468
Registered: July 2009 |
Senior Member |
|
|
Brian,
The id annotation is also added automatically when the ID property of the eattribute is true. Is
this the case with your model?
gr. Martin
Brian Vetter wrote:
> Martin,
>
> I updated to the latest source and it still decides to assign my ID
> attribute as the primary key even though there is no @Id annotation set
> for it. I tried both the default setting as well as trying to explicitly
> set DEFAULT_ID_FEATURE_NAME (although it shouldn't have mattered - I did
> it primary to make sure I was building against the latest source).
>
> While debugging, I see in getIDFeaturesNamesRecurse() that it looks for
> an id attribute in line 1339 and if found, adds it to a list. The
> calling function getIDFeaturesNames() that refers to the bug, simply
> adds the default id attribute name if the getIDFeaturesNamesRecurse()
> returns an empty list.
>
> I'm not quite sure what is going on in the code, but this behavior still
> seems to be grabbing the ID even though it isn't annotated. I'm not sure
> if it is an ecore issue (falsly reporting an annotation on the ID
> attribute) or a Teneo issue.
>
> Brian
>
> Martin Taal wrote:
>> I solved it differently, an option now controls the default name of an
>> id-efeature:
>> PersistenceOptions.DEFAULT_ID_FEATURE_NAME
>>
>> the default value has been changed to e_id so that it is less likely
>> that clashes occur.
>>
>> This has been checked in.
>>
>> gr. Martin
>>
>> Brian Vetter wrote:
>>>
>>> Martin Taal wrote:
>>>> Brian,
>>>> Automatically assuming that an attribute with name 'id' is the
>>>> id-attribute (if there is no other id attribute) will be removed.
>>>
>>> Cool. Now that I've got Teneo building, I can pull it down and test
>>> it or if you point me in the right direction, I can excise it myself.
>>>
>>>> fyi, the auto-generated id (e_id) field does not work in situations
>>>> were you serialize and then de-serialize objects as the synthetic id
>>>> is not (de-)serialized with the object.
>>>
>>> I presume they are only being used for persistence purposes? Since
>>> I'm not using them for anything, what, if any, are the downsides of
>>> this? Do these ids have any value outside of the database references?
>>>
>>> Thanks,
>>>
>>> Brian
>>
>>
--
With Regards, Martin Taal
Springsite/Elver.org
Office: Hardwareweg 4, 3821 BV Amersfoort
Postal: Nassaulaan 7, 3941 EC Doorn
The Netherlands
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: Teneo: Identity (ID) scope conflicts [message #602241 is a reply to message #70583] |
Tue, 06 February 2007 20:08 |
Brian Vetter
Messages: 74
Registered: July 2009 |
Member |
|
|
Apparently, the default XSD->ecore mapping translates my id attributes with the ID property of the eattribute to true. The original XSD attribute definition is:
<attribute name="id" type="ID"></attribute>
Here's the ecore translation of the attribute - it works just as specified as in section 4.1 of the xsd->ecore mapping document.
<eStructuralFeatures xsi:type="ecore:EAttribute" name="id" unique="false" eType="ecore:EDataType http://www.eclipse.org/emf/2003/XMLType#//ID"
iD="true">
<eAnnotations source="http:///org/eclipse/emf/ecore/util/ExtendedMetaData">
<details key="kind" value="attribute"/>
<details key="name" value="id"/>
</eAnnotations>
</eStructuralFeatures>
The root problem is still the same: the ids in an XML Schema document are only scoped to the document, not to the database and thus are seldom unique. In addition, they are optional in many cases. So using them to be a unique primary key isn't feasible without reworking the original XSDs to make them DB aware.
So is there an easy way for me to control the mapping for IDs for all of my schemas or is there some other way to distinguish between an XSD:ID and one specified in ecore that needs to be used as the DB identifier? Is the "unique" attribute useful here?
Brian
Martin Taal wrote:
> Brian,
> The id annotation is also added automatically when the ID property of
> the eattribute is true. Is this the case with your model?
>
> gr. Martin
>
> Brian Vetter wrote:
>> Martin,
>>
>> I updated to the latest source and it still decides to assign my ID
>> attribute as the primary key even though there is no @Id annotation
>> set for it. I tried both the default setting as well as trying to
>> explicitly set DEFAULT_ID_FEATURE_NAME (although it shouldn't have
>> mattered - I did it primary to make sure I was building against the
>> latest source).
>>
>> While debugging, I see in getIDFeaturesNamesRecurse() that it looks
>> for an id attribute in line 1339 and if found, adds it to a list. The
>> calling function getIDFeaturesNames() that refers to the bug, simply
>> adds the default id attribute name if the getIDFeaturesNamesRecurse()
>> returns an empty list.
>>
>> I'm not quite sure what is going on in the code, but this behavior
>> still seems to be grabbing the ID even though it isn't annotated. I'm
>> not sure if it is an ecore issue (falsly reporting an annotation on
>> the ID attribute) or a Teneo issue.
>>
>> Brian
>>
>> Martin Taal wrote:
>>> I solved it differently, an option now controls the default name of
>>> an id-efeature:
>>> PersistenceOptions.DEFAULT_ID_FEATURE_NAME
>>>
>>> the default value has been changed to e_id so that it is less likely
>>> that clashes occur.
>>>
>>> This has been checked in.
>>>
>>> gr. Martin
>>>
>>> Brian Vetter wrote:
>>>>
>>>> Martin Taal wrote:
>>>>> Brian,
>>>>> Automatically assuming that an attribute with name 'id' is the
>>>>> id-attribute (if there is no other id attribute) will be removed.
>>>>
>>>> Cool. Now that I've got Teneo building, I can pull it down and test
>>>> it or if you point me in the right direction, I can excise it myself.
>>>>
>>>>> fyi, the auto-generated id (e_id) field does not work in situations
>>>>> were you serialize and then de-serialize objects as the synthetic
>>>>> id is not (de-)serialized with the object.
>>>>
>>>> I presume they are only being used for persistence purposes? Since
>>>> I'm not using them for anything, what, if any, are the downsides of
>>>> this? Do these ids have any value outside of the database references?
>>>>
>>>> Thanks,
>>>>
>>>> Brian
>>>
>>>
>
>
|
|
|
| Re: Teneo: Identity (ID) scope conflicts [message #602245 is a reply to message #70620] |
Tue, 06 February 2007 20:26 |
Brian Vetter
Messages: 74
Registered: July 2009 |
Member |
|
|
Just for grins, I changed line xx in xx to the following:
if (false && eAttribute.isID() && aAttribute.getId() == null) {
^^^^^^^^^
While not 100% confident, I did seem to get the behavior I wanted/expected. All of the types that I had that included id attributes now sport e_id fields for their primary keys and my id fields are now simple columns in the DB. I need to experiment a bit to see if the idrefs work as I expected.
Brian
Brian Vetter wrote:
> Apparently, the default XSD->ecore mapping translates my id attributes
> with the ID property of the eattribute to true. The original XSD
> attribute definition is:
>
> <attribute name="id" type="ID"></attribute>
>
> Here's the ecore translation of the attribute - it works just as
> specified as in section 4.1 of the xsd->ecore mapping document.
>
> <eStructuralFeatures xsi:type="ecore:EAttribute" name="id"
> unique="false" eType="ecore:EDataType
> http://www.eclipse.org/emf/2003/XMLType#//ID"
> iD="true">
> <eAnnotations
> source="http:///org/eclipse/emf/ecore/util/ExtendedMetaData">
> <details key="kind" value="attribute"/>
> <details key="name" value="id"/>
> </eAnnotations>
> </eStructuralFeatures>
>
> The root problem is still the same: the ids in an XML Schema document
> are only scoped to the document, not to the database and thus are seldom
> unique. In addition, they are optional in many cases. So using them to
> be a unique primary key isn't feasible without reworking the original
> XSDs to make them DB aware.
>
> So is there an easy way for me to control the mapping for IDs for all of
> my schemas or is there some other way to distinguish between an XSD:ID
> and one specified in ecore that needs to be used as the DB identifier?
> Is the "unique" attribute useful here?
>
> Brian
>
> Martin Taal wrote:
>> Brian,
>> The id annotation is also added automatically when the ID property of
>> the eattribute is true. Is this the case with your model?
>>
>> gr. Martin
>>
>> Brian Vetter wrote:
>>> Martin,
>>>
>>> I updated to the latest source and it still decides to assign my ID
>>> attribute as the primary key even though there is no @Id annotation
>>> set for it. I tried both the default setting as well as trying to
>>> explicitly set DEFAULT_ID_FEATURE_NAME (although it shouldn't have
>>> mattered - I did it primary to make sure I was building against the
>>> latest source).
>>>
>>> While debugging, I see in getIDFeaturesNamesRecurse() that it looks
>>> for an id attribute in line 1339 and if found, adds it to a list. The
>>> calling function getIDFeaturesNames() that refers to the bug, simply
>>> adds the default id attribute name if the getIDFeaturesNamesRecurse()
>>> returns an empty list.
>>>
>>> I'm not quite sure what is going on in the code, but this behavior
>>> still seems to be grabbing the ID even though it isn't annotated. I'm
>>> not sure if it is an ecore issue (falsly reporting an annotation on
>>> the ID attribute) or a Teneo issue.
>>>
>>> Brian
>>>
>>> Martin Taal wrote:
>>>> I solved it differently, an option now controls the default name of
>>>> an id-efeature:
>>>> PersistenceOptions.DEFAULT_ID_FEATURE_NAME
>>>>
>>>> the default value has been changed to e_id so that it is less likely
>>>> that clashes occur.
>>>>
>>>> This has been checked in.
>>>>
>>>> gr. Martin
>>>>
>>>> Brian Vetter wrote:
>>>>>
>>>>> Martin Taal wrote:
>>>>>> Brian,
>>>>>> Automatically assuming that an attribute with name 'id' is the
>>>>>> id-attribute (if there is no other id attribute) will be removed.
>>>>>
>>>>> Cool. Now that I've got Teneo building, I can pull it down and test
>>>>> it or if you point me in the right direction, I can excise it myself.
>>>>>
>>>>>> fyi, the auto-generated id (e_id) field does not work in
>>>>>> situations were you serialize and then de-serialize objects as the
>>>>>> synthetic id is not (de-)serialized with the object.
>>>>>
>>>>> I presume they are only being used for persistence purposes? Since
>>>>> I'm not using them for anything, what, if any, are the downsides of
>>>>> this? Do these ids have any value outside of the database references?
>>>>>
>>>>> Thanks,
>>>>>
>>>>> Brian
>>>>
>>>>
>>
>>
|
|
|
| Re: Teneo: Identity (ID) scope conflicts [message #602250 is a reply to message #70637] |
Tue, 06 February 2007 20:29 |
Brian Vetter
Messages: 74
Registered: July 2009 |
Member |
|
|
Oops, I forgot to include the line number and the file: 509 of DefaultAnnotator.java.
BTW, I have no intention of this being a proposed fix - just that as an experiment of cutting out the code in that if statement, whether I'd get my expected behavior.
Brian
Brian Vetter wrote:
> Just for grins, I changed line xx in xx to the following:
>
> if (false && eAttribute.isID() && aAttribute.getId() == null) {
> ^^^^^^^^^
>
> While not 100% confident, I did seem to get the behavior I
> wanted/expected. All of the types that I had that included id attributes
> now sport e_id fields for their primary keys and my id fields are now
> simple columns in the DB. I need to experiment a bit to see if the
> idrefs work as I expected.
>
> Brian
>
> Brian Vetter wrote:
>> Apparently, the default XSD->ecore mapping translates my id attributes
>> with the ID property of the eattribute to true. The original XSD
>> attribute definition is:
>>
>> <attribute name="id" type="ID"></attribute>
>>
>> Here's the ecore translation of the attribute - it works just as
>> specified as in section 4.1 of the xsd->ecore mapping document.
>>
>> <eStructuralFeatures xsi:type="ecore:EAttribute" name="id"
>> unique="false" eType="ecore:EDataType
>> http://www.eclipse.org/emf/2003/XMLType#//ID"
>> iD="true">
>> <eAnnotations
>> source="http:///org/eclipse/emf/ecore/util/ExtendedMetaData">
>> <details key="kind" value="attribute"/>
>> <details key="name" value="id"/>
>> </eAnnotations>
>> </eStructuralFeatures>
>>
>> The root problem is still the same: the ids in an XML Schema document
>> are only scoped to the document, not to the database and thus are
>> seldom unique. In addition, they are optional in many cases. So using
>> them to be a unique primary key isn't feasible without reworking the
>> original XSDs to make them DB aware.
>>
>> So is there an easy way for me to control the mapping for IDs for all
>> of my schemas or is there some other way to distinguish between an
>> XSD:ID and one specified in ecore that needs to be used as the DB
>> identifier? Is the "unique" attribute useful here?
>>
>> Brian
>>
>> Martin Taal wrote:
>>> Brian,
>>> The id annotation is also added automatically when the ID property of
>>> the eattribute is true. Is this the case with your model?
>>>
>>> gr. Martin
>>>
>>> Brian Vetter wrote:
>>>> Martin,
>>>>
>>>> I updated to the latest source and it still decides to assign my ID
>>>> attribute as the primary key even though there is no @Id annotation
>>>> set for it. I tried both the default setting as well as trying to
>>>> explicitly set DEFAULT_ID_FEATURE_NAME (although it shouldn't have
>>>> mattered - I did it primary to make sure I was building against the
>>>> latest source).
>>>>
>>>> While debugging, I see in getIDFeaturesNamesRecurse() that it looks
>>>> for an id attribute in line 1339 and if found, adds it to a list.
>>>> The calling function getIDFeaturesNames() that refers to the bug,
>>>> simply adds the default id attribute name if the
>>>> getIDFeaturesNamesRecurse() returns an empty list.
>>>>
>>>> I'm not quite sure what is going on in the code, but this behavior
>>>> still seems to be grabbing the ID even though it isn't annotated.
>>>> I'm not sure if it is an ecore issue (falsly reporting an annotation
>>>> on the ID attribute) or a Teneo issue.
>>>>
>>>> Brian
>>>>
>>>> Martin Taal wrote:
>>>>> I solved it differently, an option now controls the default name of
>>>>> an id-efeature:
>>>>> PersistenceOptions.DEFAULT_ID_FEATURE_NAME
>>>>>
>>>>> the default value has been changed to e_id so that it is less
>>>>> likely that clashes occur.
>>>>>
>>>>> This has been checked in.
>>>>>
>>>>> gr. Martin
>>>>>
>>>>> Brian Vetter wrote:
>>>>>>
>>>>>> Martin Taal wrote:
>>>>>>> Brian,
>>>>>>> Automatically assuming that an attribute with name 'id' is the
>>>>>>> id-attribute (if there is no other id attribute) will be removed.
>>>>>>
>>>>>> Cool. Now that I've got Teneo building, I can pull it down and
>>>>>> test it or if you point me in the right direction, I can excise it
>>>>>> myself.
>>>>>>
>>>>>>> fyi, the auto-generated id (e_id) field does not work in
>>>>>>> situations were you serialize and then de-serialize objects as
>>>>>>> the synthetic id is not (de-)serialized with the object.
>>>>>>
>>>>>> I presume they are only being used for persistence purposes? Since
>>>>>> I'm not using them for anything, what, if any, are the downsides
>>>>>> of this? Do these ids have any value outside of the database
>>>>>> references?
>>>>>>
>>>>>> Thanks,
>>>>>>
>>>>>> Brian
>>>>>
>>>>>
>>>
>>>
|
|
|
| Re: Teneo: Identity (ID) scope conflicts [message #602260 is a reply to message #70653] |
Tue, 06 February 2007 23:14 |
Martin Taal
Messages: 5468
Registered: July 2009 |
Senior Member |
|
|
Brian,
Yes this is the correct location to disable this. I am not (yet) 100% convinced that the
ID-attribute can be ignored for determining if it is a database id. The unique attribute can not be
used as it seems to be false as a default. Maybe optional can be a correct discriminator (a real id
can not be optional).
gr. Martin
Brian Vetter wrote:
> Oops, I forgot to include the line number and the file: 509 of
> DefaultAnnotator.java.
>
> BTW, I have no intention of this being a proposed fix - just that as an
> experiment of cutting out the code in that if statement, whether I'd get
> my expected behavior.
>
> Brian
>
> Brian Vetter wrote:
>> Just for grins, I changed line xx in xx to the following:
>>
>> if (false && eAttribute.isID() && aAttribute.getId() == null) {
>> ^^^^^^^^^
>>
>> While not 100% confident, I did seem to get the behavior I
>> wanted/expected. All of the types that I had that included id
>> attributes now sport e_id fields for their primary keys and my id
>> fields are now simple columns in the DB. I need to experiment a bit
>> to see if the idrefs work as I expected.
>>
>> Brian
>>
>> Brian Vetter wrote:
>>> Apparently, the default XSD->ecore mapping translates my id
>>> attributes with the ID property of the eattribute to true. The
>>> original XSD attribute definition is:
>>>
>>> <attribute name="id" type="ID"></attribute>
>>>
>>> Here's the ecore translation of the attribute - it works just as
>>> specified as in section 4.1 of the xsd->ecore mapping document.
>>>
>>> <eStructuralFeatures xsi:type="ecore:EAttribute" name="id"
>>> unique="false" eType="ecore:EDataType
>>> http://www.eclipse.org/emf/2003/XMLType#//ID"
>>> iD="true">
>>> <eAnnotations
>>> source="http:///org/eclipse/emf/ecore/util/ExtendedMetaData">
>>> <details key="kind" value="attribute"/>
>>> <details key="name" value="id"/>
>>> </eAnnotations>
>>> </eStructuralFeatures>
>>>
>>> The root problem is still the same: the ids in an XML Schema document
>>> are only scoped to the document, not to the database and thus are
>>> seldom unique. In addition, they are optional in many cases. So using
>>> them to be a unique primary key isn't feasible without reworking the
>>> original XSDs to make them DB aware.
>>>
>>> So is there an easy way for me to control the mapping for IDs for all
>>> of my schemas or is there some other way to distinguish between an
>>> XSD:ID and one specified in ecore that needs to be used as the DB
>>> identifier? Is the "unique" attribute useful here?
>>>
>>> Brian
>>>
>>> Martin Taal wrote:
>>>> Brian,
>>>> The id annotation is also added automatically when the ID property
>>>> of the eattribute is true. Is this the case with your model?
>>>>
>>>> gr. Martin
>>>>
>>>> Brian Vetter wrote:
>>>>> Martin,
>>>>>
>>>>> I updated to the latest source and it still decides to assign my ID
>>>>> attribute as the primary key even though there is no @Id annotation
>>>>> set for it. I tried both the default setting as well as trying to
>>>>> explicitly set DEFAULT_ID_FEATURE_NAME (although it shouldn't have
>>>>> mattered - I did it primary to make sure I was building against the
>>>>> latest source).
>>>>>
>>>>> While debugging, I see in getIDFeaturesNamesRecurse() that it looks
>>>>> for an id attribute in line 1339 and if found, adds it to a list.
>>>>> The calling function getIDFeaturesNames() that refers to the bug,
>>>>> simply adds the default id attribute name if the
>>>>> getIDFeaturesNamesRecurse() returns an empty list.
>>>>>
>>>>> I'm not quite sure what is going on in the code, but this behavior
>>>>> still seems to be grabbing the ID even though it isn't annotated.
>>>>> I'm not sure if it is an ecore issue (falsly reporting an
>>>>> annotation on the ID attribute) or a Teneo issue.
>>>>>
>>>>> Brian
>>>>>
>>>>> Martin Taal wrote:
>>>>>> I solved it differently, an option now controls the default name
>>>>>> of an id-efeature:
>>>>>> PersistenceOptions.DEFAULT_ID_FEATURE_NAME
>>>>>>
>>>>>> the default value has been changed to e_id so that it is less
>>>>>> likely that clashes occur.
>>>>>>
>>>>>> This has been checked in.
>>>>>>
>>>>>> gr. Martin
>>>>>>
>>>>>> Brian Vetter wrote:
>>>>>>>
>>>>>>> Martin Taal wrote:
>>>>>>>> Brian,
>>>>>>>> Automatically assuming that an attribute with name 'id' is the
>>>>>>>> id-attribute (if there is no other id attribute) will be removed.
>>>>>>>
>>>>>>> Cool. Now that I've got Teneo building, I can pull it down and
>>>>>>> test it or if you point me in the right direction, I can excise
>>>>>>> it myself.
>>>>>>>
>>>>>>>> fyi, the auto-generated id (e_id) field does not work in
>>>>>>>> situations were you serialize and then de-serialize objects as
>>>>>>>> the synthetic id is not (de-)serialized with the object.
>>>>>>>
>>>>>>> I presume they are only being used for persistence purposes?
>>>>>>> Since I'm not using them for anything, what, if any, are the
>>>>>>> downsides of this? Do these ids have any value outside of the
>>>>>>> database references?
>>>>>>>
>>>>>>> Thanks,
>>>>>>>
>>>>>>> Brian
>>>>>>
>>>>>>
>>>>
>>>>
--
With Regards, Martin Taal
Springsite/Elver.org
Office: Hardwareweg 4, 3821 BV Amersfoort
Postal: Nassaulaan 7, 3941 EC Doorn
The Netherlands
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: Teneo: Identity (ID) scope conflicts [message #602306 is a reply to message #70681] |
Wed, 07 February 2007 19:58 |
Brian Vetter
Messages: 74
Registered: July 2009 |
Member |
|
|
Martin,
While optional is one way to discriminate, I'm not sure it is sufficient. An XSD can also require an ID attribute, yet it may only be unique to the document and not globally/DB unique. From what I can tell, ecore will map all attributes of type ID to an EAttribute with ID set to "true" and unique set to "false". If you simply look at the ID value, you will incorrectly associate all ID types as a unique database key.
I'm arguing that you shouldn't do this automatically. You should only map an ID to a DB key unless an accompanying @Id annotation is there and that by default, an ID is not assumed to be a key.
Alternatively, you could use the "unique" attribute, but apparently, you have some concerns about it since it is usually false - at least it is when mapping an ID type in an XSD (which is most likely correct from my perspective :->). If someone were creating a model directly in ecore (or perhaps some other mapping), I would presume that "unique" may sometimes be "true", which would seem to be a likely candidate for a key (especially if ID is true). I saw a tersely worded bugzilla note (156934) that implies you've taken a hard look at unique in the past so perhaps it too is not sufficient for the purpose of automatically assuming/mapping to a DB key or at least, placing a unique constraint on a column.
Perhaps you can let the decision to perform this mapping be controlled by a preference. For example, if you have a preference called DEFAULT_ID_PRIMARY_KEY that when set to true, does the mapping as it works today. When false, it does not automatically map ID-typed attributes to a primary key. In either case, you can override the default behavior by specifying the appropriate annotation.
If emf/ecore supported the key/keyref/unique constraint mappings, that might have been a means for specifying keys and such, although that again may be somewhat limited by scope.
Brian
Martin Taal wrote:
> Brian,
> Yes this is the correct location to disable this. I am not (yet) 100%
> convinced that the ID-attribute can be ignored for determining if it is
> a database id. The unique attribute can not be used as it seems to be
> false as a default. Maybe optional can be a correct discriminator (a
> real id can not be optional).
>
> gr. Martin
>
> Brian Vetter wrote:
>> Oops, I forgot to include the line number and the file: 509 of
>> DefaultAnnotator.java.
>>
>> BTW, I have no intention of this being a proposed fix - just that as
>> an experiment of cutting out the code in that if statement, whether
>> I'd get my expected behavior.
>>
>> Brian
>>
>> Brian Vetter wrote:
>>> Just for grins, I changed line xx in xx to the following:
>>>
>>> if (false && eAttribute.isID() && aAttribute.getId() == null) {
>>> ^^^^^^^^^
>>>
>>> While not 100% confident, I did seem to get the behavior I
>>> wanted/expected. All of the types that I had that included id
>>> attributes now sport e_id fields for their primary keys and my id
>>> fields are now simple columns in the DB. I need to experiment a bit
>>> to see if the idrefs work as I expected.
>>>
>>> Brian
>>>
>>> Brian Vetter wrote:
>>>> Apparently, the default XSD->ecore mapping translates my id
>>>> attributes with the ID property of the eattribute to true. The
>>>> original XSD attribute definition is:
>>>>
>>>> <attribute name="id" type="ID"></attribute>
>>>>
>>>> Here's the ecore translation of the attribute - it works just as
>>>> specified as in section 4.1 of the xsd->ecore mapping document.
>>>>
>>>> <eStructuralFeatures xsi:type="ecore:EAttribute" name="id"
>>>> unique="false" eType="ecore:EDataType
>>>> http://www.eclipse.org/emf/2003/XMLType#//ID"
>>>> iD="true">
>>>> <eAnnotations
>>>> source="http:///org/eclipse/emf/ecore/util/ExtendedMetaData">
>>>> <details key="kind" value="attribute"/>
>>>> <details key="name" value="id"/>
>>>> </eAnnotations>
>>>> </eStructuralFeatures>
>>>>
>>>> The root problem is still the same: the ids in an XML Schema
>>>> document are only scoped to the document, not to the database and
>>>> thus are seldom unique. In addition, they are optional in many
>>>> cases. So using them to be a unique primary key isn't feasible
>>>> without reworking the original XSDs to make them DB aware.
>>>>
>>>> So is there an easy way for me to control the mapping for IDs for
>>>> all of my schemas or is there some other way to distinguish between
>>>> an XSD:ID and one specified in ecore that needs to be used as the DB
>>>> identifier? Is the "unique" attribute useful here?
>>>>
>>>> Brian
>>>>
>>>> Martin Taal wrote:
>>>>> Brian,
>>>>> The id annotation is also added automatically when the ID property
>>>>> of the eattribute is true. Is this the case with your model?
>>>>>
>>>>> gr. Martin
>>>>>
>>>>> Brian Vetter wrote:
>>>>>> Martin,
>>>>>>
>>>>>> I updated to the latest source and it still decides to assign my
>>>>>> ID attribute as the primary key even though there is no @Id
>>>>>> annotation set for it. I tried both the default setting as well as
>>>>>> trying to explicitly set DEFAULT_ID_FEATURE_NAME (although it
>>>>>> shouldn't have mattered - I did it primary to make sure I was
>>>>>> building against the latest source).
>>>>>>
>>>>>> While debugging, I see in getIDFeaturesNamesRecurse() that it
>>>>>> looks for an id attribute in line 1339 and if found, adds it to a
>>>>>> list. The calling function getIDFeaturesNames() that refers to the
>>>>>> bug, simply adds the default id attribute name if the
>>>>>> getIDFeaturesNamesRecurse() returns an empty list.
>>>>>>
>>>>>> I'm not quite sure what is going on in the code, but this behavior
>>>>>> still seems to be grabbing the ID even though it isn't annotated.
>>>>>> I'm not sure if it is an ecore issue (falsly reporting an
>>>>>> annotation on the ID attribute) or a Teneo issue.
>>>>>>
>>>>>> Brian
>>>>>>
>>>>>> Martin Taal wrote:
>>>>>>> I solved it differently, an option now controls the default name
>>>>>>> of an id-efeature:
>>>>>>> PersistenceOptions.DEFAULT_ID_FEATURE_NAME
>>>>>>>
>>>>>>> the default value has been changed to e_id so that it is less
>>>>>>> likely that clashes occur.
>>>>>>>
>>>>>>> This has been checked in.
>>>>>>>
>>>>>>> gr. Martin
>>>>>>>
>>>>>>> Brian Vetter wrote:
>>>>>>>>
>>>>>>>> Martin Taal wrote:
>>>>>>>>> Brian,
>>>>>>>>> Automatically assuming that an attribute with name 'id' is the
>>>>>>>>> id-attribute (if there is no other id attribute) will be removed.
>>>>>>>>
>>>>>>>> Cool. Now that I've got Teneo building, I can pull it down and
>>>>>>>> test it or if you point me in the right direction, I can excise
>>>>>>>> it myself.
>>>>>>>>
>>>>>>>>> fyi, the auto-generated id (e_id) field does not work in
>>>>>>>>> situations were you serialize and then de-serialize objects as
>>>>>>>>> the synthetic id is not (de-)serialized with the object.
>>>>>>>>
>>>>>>>> I presume they are only being used for persistence purposes?
>>>>>>>> Since I'm not using them for anything, what, if any, are the
>>>>>>>> downsides of this? Do these ids have any value outside of the
>>>>>>>> database references?
>>>>>>>>
>>>>>>>> Thanks,
>>>>>>>>
>>>>>>>> Brian
>>>>>>>
>>>>>>>
>>>>>
>>>>>
>
>
|
|
|
| Re: Teneo: Identity (ID) scope conflicts [message #602314 is a reply to message #70755] |
Wed, 07 February 2007 20:18 |
Ed Merks
Messages: 33136
Registered: July 2009 |
Senior Member |
|
|
Brian,
The unique attribute is really not meaningful unless the upper bound is
something other than 1. It indicates whether the same value may occur
more than once in the multiplicity of values. In the future we may use
it to generate a Set verses a List (and in combination with ordered a
Collection), but again, that only affects the isMany case.
Note that in EMF 2.3, we provide support for EReference.eKeys, which is
very much like a keyref. It specifies a set of the EAttributes from the
EClass that is the EReference's eType that unique identify the
referenced instance with respect to that particular EReference. The
reference will then be serialized as @something[feature='value'] which
represent the object in the "something" reference value whose "feature"
attribute has the value 'value'. I still need to provide Ecore -> XSD
->Ecore mapping support for this (and all the other generics support
that was added).
Brian Vetter wrote:
> Martin,
>
> While optional is one way to discriminate, I'm not sure it is
> sufficient. An XSD can also require an ID attribute, yet it may only
> be unique to the document and not globally/DB unique. From what I can
> tell, ecore will map all attributes of type ID to an EAttribute with
> ID set to "true" and unique set to "false". If you simply look at the
> ID value, you will incorrectly associate all ID types as a unique
> database key.
>
> I'm arguing that you shouldn't do this automatically. You should only
> map an ID to a DB key unless an accompanying @Id annotation is there
> and that by default, an ID is not assumed to be a key.
>
> Alternatively, you could use the "unique" attribute, but apparently,
> you have some concerns about it since it is usually false - at least
> it is when mapping an ID type in an XSD (which is most likely correct
> from my perspective :->). If someone were creating a model directly in
> ecore (or perhaps some other mapping), I would presume that "unique"
> may sometimes be "true", which would seem to be a likely candidate for
> a key (especially if ID is true). I saw a tersely worded bugzilla note
> (156934) that implies you've taken a hard look at unique in the past
> so perhaps it too is not sufficient for the purpose of automatically
> assuming/mapping to a DB key or at least, placing a unique constraint
> on a column.
>
> Perhaps you can let the decision to perform this mapping be controlled
> by a preference. For example, if you have a preference called
> DEFAULT_ID_PRIMARY_KEY that when set to true, does the mapping as it
> works today. When false, it does not automatically map ID-typed
> attributes to a primary key. In either case, you can override the
> default behavior by specifying the appropriate annotation.
>
> If emf/ecore supported the key/keyref/unique constraint mappings, that
> might have been a means for specifying keys and such, although that
> again may be somewhat limited by scope.
> Brian
>
> Martin Taal wrote:
>> Brian,
>> Yes this is the correct location to disable this. I am not (yet) 100%
>> convinced that the ID-attribute can be ignored for determining if it
>> is a database id. The unique attribute can not be used as it seems to
>> be false as a default. Maybe optional can be a correct discriminator
>> (a real id can not be optional).
>>
>> gr. Martin
>>
>> Brian Vetter wrote:
>>> Oops, I forgot to include the line number and the file: 509 of
>>> DefaultAnnotator.java.
>>>
>>> BTW, I have no intention of this being a proposed fix - just that as
>>> an experiment of cutting out the code in that if statement, whether
>>> I'd get my expected behavior.
>>>
>>> Brian
>>>
>>> Brian Vetter wrote:
>>>> Just for grins, I changed line xx in xx to the following:
>>>>
>>>> if (false && eAttribute.isID() && aAttribute.getId() == null) {
>>>> ^^^^^^^^^
>>>>
>>>> While not 100% confident, I did seem to get the behavior I
>>>> wanted/expected. All of the types that I had that included id
>>>> attributes now sport e_id fields for their primary keys and my id
>>>> fields are now simple columns in the DB. I need to experiment a
>>>> bit to see if the idrefs work as I expected.
>>>>
>>>> Brian
>>>>
>>>> Brian Vetter wrote:
>>>>> Apparently, the default XSD->ecore mapping translates my id
>>>>> attributes with the ID property of the eattribute to true. The
>>>>> original XSD attribute definition is:
>>>>>
>>>>> <attribute name="id" type="ID"></attribute>
>>>>>
>>>>> Here's the ecore translation of the attribute - it works just as
>>>>> specified as in section 4.1 of the xsd->ecore mapping document.
>>>>>
>>>>> <eStructuralFeatures xsi:type="ecore:EAttribute" name="id"
>>>>> unique="false" eType="ecore:EDataType
>>>>> http://www.eclipse.org/emf/2003/XMLType#//ID"
>>>>> iD="true">
>>>>> <eAnnotations
>>>>> source="http:///org/eclipse/emf/ecore/util/ExtendedMetaData">
>>>>> <details key="kind" value="attribute"/>
>>>>> <details key="name" value="id"/>
>>>>> </eAnnotations>
>>>>> </eStructuralFeatures>
>>>>>
>>>>> The root problem is still the same: the ids in an XML Schema
>>>>> document are only scoped to the document, not to the database and
>>>>> thus are seldom unique. In addition, they are optional in many
>>>>> cases. So using them to be a unique primary key isn't feasible
>>>>> without reworking the original XSDs to make them DB aware.
>>>>>
>>>>> So is there an easy way for me to control the mapping for IDs for
>>>>> all of my schemas or is there some other way to distinguish
>>>>> between an XSD:ID and one specified in ecore that needs to be used
>>>>> as the DB identifier? Is the "unique" attribute useful here?
>>>>>
>>>>> Brian
>>>>>
>>>>> Martin Taal wrote:
>>>>>> Brian,
>>>>>> The id annotation is also added automatically when the ID
>>>>>> property of the eattribute is true. Is this the case with your
>>>>>> model?
>>>>>>
>>>>>> gr. Martin
>>>>>>
>>>>>> Brian Vetter wrote:
>>>>>>> Martin,
>>>>>>>
>>>>>>> I updated to the latest source and it still decides to assign my
>>>>>>> ID attribute as the primary key even though there is no @Id
>>>>>>> annotation set for it. I tried both the default setting as well
>>>>>>> as trying to explicitly set DEFAULT_ID_FEATURE_NAME (although it
>>>>>>> shouldn't have mattered - I did it primary to make sure I was
>>>>>>> building against the latest source).
>>>>>>>
>>>>>>> While debugging, I see in getIDFeaturesNamesRecurse() that it
>>>>>>> looks for an id attribute in line 1339 and if found, adds it to
>>>>>>> a list. The calling function getIDFeaturesNames() that refers to
>>>>>>> the bug, simply adds the default id attribute name if the
>>>>>>> getIDFeaturesNamesRecurse() returns an empty list.
>>>>>>>
>>>>>>> I'm not quite sure what is going on in the code, but this
>>>>>>> behavior still seems to be grabbing the ID even though it isn't
>>>>>>> annotated. I'm not sure if it is an ecore issue (falsly
>>>>>>> reporting an annotation on the ID attribute) or a Teneo issue.
>>>>>>>
>>>>>>> Brian
>>>>>>>
>>>>>>> Martin Taal wrote:
>>>>>>>> I solved it differently, an option now controls the default
>>>>>>>> name of an id-efeature:
>>>>>>>> PersistenceOptions.DEFAULT_ID_FEATURE_NAME
>>>>>>>>
>>>>>>>> the default value has been changed to e_id so that it is less
>>>>>>>> likely that clashes occur.
>>>>>>>>
>>>>>>>> This has been checked in.
>>>>>>>>
>>>>>>>> gr. Martin
>>>>>>>>
>>>>>>>> Brian Vetter wrote:
>>>>>>>>>
>>>>>>>>> Martin Taal wrote:
>>>>>>>>>> Brian,
>>>>>>>>>> Automatically assuming that an attribute with name 'id' is
>>>>>>>>>> the id-attribute (if there is no other id attribute) will be
>>>>>>>>>> removed.
>>>>>>>>>
>>>>>>>>> Cool. Now that I've got Teneo building, I can pull it down and
>>>>>>>>> test it or if you point me in the right direction, I can
>>>>>>>>> excise it myself.
>>>>>>>>>
>>>>>>>>>> fyi, the auto-generated id (e_id) field does not work in
>>>>>>>>>> situations were you serialize and then de-serialize objects
>>>>>>>>>> as the synthetic id is not (de-)serialized with the object.
>>>>>>>>>
>>>>>>>>> I presume they are only being used for persistence purposes?
>>>>>>>>> Since I'm not using them for anything, what, if any, are the
>>>>>>>>> downsides of this? Do these ids have any value outside of the
>>>>>>>>> database references?
>>>>>>>>>
>>>>>>>>> Thanks,
>>>>>>>>>
>>>>>>>>> Brian
>>>>>>>>
>>>>>>>>
>>>>>>
>>>>>>
>>
>>
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
|
| Re: Teneo: Identity (ID) scope conflicts [message #602343 is a reply to message #70816] |
Thu, 08 February 2007 08:54 |
Martin Taal
Messages: 5468
Registered: July 2009 |
Senior Member |
|
|
Brian,
Afaics opinions can differ on what the exact semantics of ID is (it depends on the specific
usecase). The current approach of translating the ID to a database id is from before Teneo supported
the @id annotation. I tend to agree that @id is a more explicit approach than the ID which is more
xml oriented. So please enter a bugzilla if you want the current ID behavior to be controlled by an
option.
gr. Martin
Ed Merks wrote:
> Brian,
>
> The unique attribute is really not meaningful unless the upper bound is
> something other than 1. It indicates whether the same value may occur
> more than once in the multiplicity of values. In the future we may use
> it to generate a Set verses a List (and in combination with ordered a
> Collection), but again, that only affects the isMany case.
>
> Note that in EMF 2.3, we provide support for EReference.eKeys, which is
> very much like a keyref. It specifies a set of the EAttributes from the
> EClass that is the EReference's eType that unique identify the
> referenced instance with respect to that particular EReference. The
> reference will then be serialized as @something[feature='value'] which
> represent the object in the "something" reference value whose "feature"
> attribute has the value 'value'. I still need to provide Ecore -> XSD
> ->Ecore mapping support for this (and all the other generics support
> that was added).
>
>
> Brian Vetter wrote:
>> Martin,
>>
>> While optional is one way to discriminate, I'm not sure it is
>> sufficient. An XSD can also require an ID attribute, yet it may only
>> be unique to the document and not globally/DB unique. From what I can
>> tell, ecore will map all attributes of type ID to an EAttribute with
>> ID set to "true" and unique set to "false". If you simply look at the
>> ID value, you will incorrectly associate all ID types as a unique
>> database key.
>>
>> I'm arguing that you shouldn't do this automatically. You should only
>> map an ID to a DB key unless an accompanying @Id annotation is there
>> and that by default, an ID is not assumed to be a key.
>>
>> Alternatively, you could use the "unique" attribute, but apparently,
>> you have some concerns about it since it is usually false - at least
>> it is when mapping an ID type in an XSD (which is most likely correct
>> from my perspective :->). If someone were creating a model directly in
>> ecore (or perhaps some other mapping), I would presume that "unique"
>> may sometimes be "true", which would seem to be a likely candidate for
>> a key (especially if ID is true). I saw a tersely worded bugzilla note
>> (156934) that implies you've taken a hard look at unique in the past
>> so perhaps it too is not sufficient for the purpose of automatically
>> assuming/mapping to a DB key or at least, placing a unique constraint
>> on a column.
>>
>> Perhaps you can let the decision to perform this mapping be controlled
>> by a preference. For example, if you have a preference called
>> DEFAULT_ID_PRIMARY_KEY that when set to true, does the mapping as it
>> works today. When false, it does not automatically map ID-typed
>> attributes to a primary key. In either case, you can override the
>> default behavior by specifying the appropriate annotation.
>>
>> If emf/ecore supported the key/keyref/unique constraint mappings, that
>> might have been a means for specifying keys and such, although that
>> again may be somewhat limited by scope.
>> Brian
>>
>> Martin Taal wrote:
>>> Brian,
>>> Yes this is the correct location to disable this. I am not (yet) 100%
>>> convinced that the ID-attribute can be ignored for determining if it
>>> is a database id. The unique attribute can not be used as it seems to
>>> be false as a default. Maybe optional can be a correct discriminator
>>> (a real id can not be optional).
>>>
>>> gr. Martin
>>>
>>> Brian Vetter wrote:
>>>> Oops, I forgot to include the line number and the file: 509 of
>>>> DefaultAnnotator.java.
>>>>
>>>> BTW, I have no intention of this being a proposed fix - just that as
>>>> an experiment of cutting out the code in that if statement, whether
>>>> I'd get my expected behavior.
>>>>
>>>> Brian
>>>>
>>>> Brian Vetter wrote:
>>>>> Just for grins, I changed line xx in xx to the following:
>>>>>
>>>>> if (false && eAttribute.isID() && aAttribute.getId() == null) {
>>>>> ^^^^^^^^^
>>>>>
>>>>> While not 100% confident, I did seem to get the behavior I
>>>>> wanted/expected. All of the types that I had that included id
>>>>> attributes now sport e_id fields for their primary keys and my id
>>>>> fields are now simple columns in the DB. I need to experiment a
>>>>> bit to see if the idrefs work as I expected.
>>>>>
>>>>> Brian
>>>>>
>>>>> Brian Vetter wrote:
>>>>>> Apparently, the default XSD->ecore mapping translates my id
>>>>>> attributes with the ID property of the eattribute to true. The
>>>>>> original XSD attribute definition is:
>>>>>>
>>>>>> <attribute name="id" type="ID"></attribute>
>>>>>>
>>>>>> Here's the ecore translation of the attribute - it works just as
>>>>>> specified as in section 4.1 of the xsd->ecore mapping document.
>>>>>>
>>>>>> <eStructuralFeatures xsi:type="ecore:EAttribute" name="id"
>>>>>> unique="false" eType="ecore:EDataType
>>>>>> http://www.eclipse.org/emf/2003/XMLType#//ID"
>>>>>> iD="true">
>>>>>> <eAnnotations
>>>>>> source="http:///org/eclipse/emf/ecore/util/ExtendedMetaData">
>>>>>> <details key="kind" value="attribute"/>
>>>>>> <details key="name" value="id"/>
>>>>>> </eAnnotations>
>>>>>> </eStructuralFeatures>
>>>>>>
>>>>>> The root problem is still the same: the ids in an XML Schema
>>>>>> document are only scoped to the document, not to the database and
>>>>>> thus are seldom unique. In addition, they are optional in many
>>>>>> cases. So using them to be a unique primary key isn't feasible
>>>>>> without reworking the original XSDs to make them DB aware.
>>>>>>
>>>>>> So is there an easy way for me to control the mapping for IDs for
>>>>>> all of my schemas or is there some other way to distinguish
>>>>>> between an XSD:ID and one specified in ecore that needs to be used
>>>>>> as the DB identifier? Is the "unique" attribute useful here?
>>>>>>
>>>>>> Brian
>>>>>>
>>>>>> Martin Taal wrote:
>>>>>>> Brian,
>>>>>>> The id annotation is also added automatically when the ID
>>>>>>> property of the eattribute is true. Is this the case with your
>>>>>>> model?
>>>>>>>
>>>>>>> gr. Martin
>>>>>>>
>>>>>>> Brian Vetter wrote:
>>>>>>>> Martin,
>>>>>>>>
>>>>>>>> I updated to the latest source and it still decides to assign my
>>>>>>>> ID attribute as the primary key even though there is no @Id
>>>>>>>> annotation set for it. I tried both the default setting as well
>>>>>>>> as trying to explicitly set DEFAULT_ID_FEATURE_NAME (although it
>>>>>>>> shouldn't have mattered - I did it primary to make sure I was
>>>>>>>> building against the latest source).
>>>>>>>>
>>>>>>>> While debugging, I see in getIDFeaturesNamesRecurse() that it
>>>>>>>> looks for an id attribute in line 1339 and if found, adds it to
>>>>>>>> a list. The calling function getIDFeaturesNames() that refers to
>>>>>>>> the bug, simply adds the default id attribute name if the
>>>>>>>> getIDFeaturesNamesRecurse() returns an empty list.
>>>>>>>>
>>>>>>>> I'm not quite sure what is going on in the code, but this
>>>>>>>> behavior still seems to be grabbing the ID even though it isn't
>>>>>>>> annotated. I'm not sure if it is an ecore issue (falsly
>>>>>>>> reporting an annotation on the ID attribute) or a Teneo issue.
>>>>>>>>
>>>>>>>> Brian
>>>>>>>>
>>>>>>>> Martin Taal wrote:
>>>>>>>>> I solved it differently, an option now controls the default
>>>>>>>>> name of an id-efeature:
>>>>>>>>> PersistenceOptions.DEFAULT_ID_FEATURE_NAME
>>>>>>>>>
>>>>>>>>> the default value has been changed to e_id so that it is less
>>>>>>>>> likely that clashes occur.
>>>>>>>>>
>>>>>>>>> This has been checked in.
>>>>>>>>>
>>>>>>>>> gr. Martin
>>>>>>>>>
>>>>>>>>> Brian Vetter wrote:
>>>>>>>>>>
>>>>>>>>>> Martin Taal wrote:
>>>>>>>>>>> Brian,
>>>>>>>>>>> Automatically assuming that an attribute with name 'id' is
>>>>>>>>>>> the id-attribute (if there is no other id attribute) will be
>>>>>>>>>>> removed.
>>>>>>>>>>
>>>>>>>>>> Cool. Now that I've got Teneo building, I can pull it down and
>>>>>>>>>> test it or if you point me in the right direction, I can
>>>>>>>>>> excise it myself.
>>>>>>>>>>
>>>>>>>>>>> fyi, the auto-generated id (e_id) field does not work in
>>>>>>>>>>> situations were you serialize and then de-serialize objects
>>>>>>>>>>> as the synthetic id is not (de-)serialized with the object.
>>>>>>>>>>
>>>>>>>>>> I presume they are only being used for persistence purposes?
>>>>>>>>>> Since I'm not using them for anything, what, if any, are the
>>>>>>>>>> downsides of this? Do these ids have any value outside of the
>>>>>>>>>> database references?
>>>>>>>>>>
>>>>>>>>>> Thanks,
>>>>>>>>>>
>>>>>>>>>> Brian
>>>>>>>>>
>>>>>>>>>
>>>>>>>
>>>>>>>
>>>
>>>
--
With Regards, Martin Taal
Springsite/Elver.org
Office: Hardwareweg 4, 3821 BV Amersfoort
Postal: Nassaulaan 7, 3941 EC Doorn
The Netherlands
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: Teneo: Identity (ID) scope conflicts [message #602368 is a reply to message #70929] |
Thu, 08 February 2007 16:15 |
Brian Vetter
Messages: 74
Registered: July 2009 |
Member |
|
|
I entered bugzilla ID 173478 for this request.
Thanks,
Brian
Martin Taal wrote:
> Brian,
> Afaics opinions can differ on what the exact semantics of ID is (it
> depends on the specific usecase). The current approach of translating
> the ID to a database id is from before Teneo supported the @id
> annotation. I tend to agree that @id is a more explicit approach than
> the ID which is more xml oriented. So please enter a bugzilla if you
> want the current ID behavior to be controlled by an option.
>
> gr. Martin
>
> Ed Merks wrote:
>> Brian,
>>
>> The unique attribute is really not meaningful unless the upper bound
>> is something other than 1. It indicates whether the same value may
>> occur more than once in the multiplicity of values. In the future we
>> may use it to generate a Set verses a List (and in combination with
>> ordered a Collection), but again, that only affects the isMany case.
>>
>> Note that in EMF 2.3, we provide support for EReference.eKeys, which
>> is very much like a keyref. It specifies a set of the EAttributes
>> from the EClass that is the EReference's eType that unique identify
>> the referenced instance with respect to that particular EReference.
>> The reference will then be serialized as @something[feature='value']
>> which represent the object in the "something" reference value whose
>> "feature" attribute has the value 'value'. I still need to provide
>> Ecore -> XSD ->Ecore mapping support for this (and all the other
>> generics support that was added).
>>
>>
>> Brian Vetter wrote:
>>> Martin,
>>>
>>> While optional is one way to discriminate, I'm not sure it is
>>> sufficient. An XSD can also require an ID attribute, yet it may only
>>> be unique to the document and not globally/DB unique. From what I can
>>> tell, ecore will map all attributes of type ID to an EAttribute with
>>> ID set to "true" and unique set to "false". If you simply look at the
>>> ID value, you will incorrectly associate all ID types as a unique
>>> database key.
>>>
>>> I'm arguing that you shouldn't do this automatically. You should only
>>> map an ID to a DB key unless an accompanying @Id annotation is there
>>> and that by default, an ID is not assumed to be a key.
>>>
>>> Alternatively, you could use the "unique" attribute, but apparently,
>>> you have some concerns about it since it is usually false - at least
>>> it is when mapping an ID type in an XSD (which is most likely correct
>>> from my perspective :->). If someone were creating a model directly
>>> in ecore (or perhaps some other mapping), I would presume that
>>> "unique" may sometimes be "true", which would seem to be a likely
>>> candidate for a key (especially if ID is true). I saw a tersely
>>> worded bugzilla note (156934) that implies you've taken a hard look
>>> at unique in the past so perhaps it too is not sufficient for the
>>> purpose of automatically assuming/mapping to a DB key or at least,
>>> placing a unique constraint on a column.
>>>
>>> Perhaps you can let the decision to perform this mapping be
>>> controlled by a preference. For example, if you have a preference
>>> called DEFAULT_ID_PRIMARY_KEY that when set to true, does the mapping
>>> as it works today. When false, it does not automatically map ID-typed
>>> attributes to a primary key. In either case, you can override the
>>> default behavior by specifying the appropriate annotation.
>>>
>>> If emf/ecore supported the key/keyref/unique constraint mappings,
>>> that might have been a means for specifying keys and such, although
>>> that again may be somewhat limited by scope.
>>> Brian
>>>
>>> Martin Taal wrote:
>>>> Brian,
>>>> Yes this is the correct location to disable this. I am not (yet)
>>>> 100% convinced that the ID-attribute can be ignored for determining
>>>> if it is a database id. The unique attribute can not be used as it
>>>> seems to be false as a default. Maybe optional can be a correct
>>>> discriminator (a real id can not be optional).
>>>>
>>>> gr. Martin
>>>>
>>>> Brian Vetter wrote:
>>>>> Oops, I forgot to include the line number and the file: 509 of
>>>>> DefaultAnnotator.java.
>>>>>
>>>>> BTW, I have no intention of this being a proposed fix - just that
>>>>> as an experiment of cutting out the code in that if statement,
>>>>> whether I'd get my expected behavior.
>>>>>
>>>>> Brian
>>>>>
>>>>> Brian Vetter wrote:
>>>>>> Just for grins, I changed line xx in xx to the following:
>>>>>>
>>>>>> if (false && eAttribute.isID() && aAttribute.getId() == null) {
>>>>>> ^^^^^^^^^
>>>>>>
>>>>>> While not 100% confident, I did seem to get the behavior I
>>>>>> wanted/expected. All of the types that I had that included id
>>>>>> attributes now sport e_id fields for their primary keys and my id
>>>>>> fields are now simple columns in the DB. I need to experiment a
>>>>>> bit to see if the idrefs work as I expected.
>>>>>>
>>>>>> Brian
>>>>>>
>>>>>> Brian Vetter wrote:
>>>>>>> Apparently, the default XSD->ecore mapping translates my id
>>>>>>> attributes with the ID property of the eattribute to true. The
>>>>>>> original XSD attribute definition is:
>>>>>>>
>>>>>>> <attribute name="id" type="ID"></attribute>
>>>>>>>
>>>>>>> Here's the ecore translation of the attribute - it works just as
>>>>>>> specified as in section 4.1 of the xsd->ecore mapping document.
>>>>>>>
>>>>>>> <eStructuralFeatures xsi:type="ecore:EAttribute" name="id"
>>>>>>> unique="false" eType="ecore:EDataType
>>>>>>> http://www.eclipse.org/emf/2003/XMLType#//ID"
>>>>>>> iD="true">
>>>>>>> <eAnnotations
>>>>>>> source="http:///org/eclipse/emf/ecore/util/ExtendedMetaData">
>>>>>>> <details key="kind" value="attribute"/>
>>>>>>> <details key="name" value="id"/>
>>>>>>> </eAnnotations>
>>>>>>> </eStructuralFeatures>
>>>>>>>
>>>>>>> The root problem is still the same: the ids in an XML Schema
>>>>>>> document are only scoped to the document, not to the database and
>>>>>>> thus are seldom unique. In addition, they are optional in many
>>>>>>> cases. So using them to be a unique primary key isn't feasible
>>>>>>> without reworking the original XSDs to make them DB aware.
>>>>>>>
>>>>>>> So is there an easy way for me to control the mapping for IDs for
>>>>>>> all of my schemas or is there some other way to distinguish
>>>>>>> between an XSD:ID and one specified in ecore that needs to be
>>>>>>> used as the DB identifier? Is the "unique" attribute useful here?
>>>>>>>
>>>>>>> Brian
>>>>>>>
>>>>>>> Martin Taal wrote:
>>>>>>>> Brian,
>>>>>>>> The id annotation is also added automatically when the ID
>>>>>>>> property of the eattribute is true. Is this the case with your
>>>>>>>> model?
>>>>>>>>
>>>>>>>> gr. Martin
>>>>>>>>
>>>>>>>> Brian Vetter wrote:
>>>>>>>>> Martin,
>>>>>>>>>
>>>>>>>>> I updated to the latest source and it still decides to assign
>>>>>>>>> my ID attribute as the primary key even though there is no @Id
>>>>>>>>> annotation set for it. I tried both the default setting as well
>>>>>>>>> as trying to explicitly set DEFAULT_ID_FEATURE_NAME (although
>>>>>>>>> it shouldn't have mattered - I did it primary to make sure I
>>>>>>>>> was building against the latest source).
>>>>>>>>>
>>>>>>>>> While debugging, I see in getIDFeaturesNamesRecurse() that it
>>>>>>>>> looks for an id attribute in line 1339 and if found, adds it to
>>>>>>>>> a list. The calling function getIDFeaturesNames() that refers
>>>>>>>>> to the bug, simply adds the default id attribute name if the
>>>>>>>>> getIDFeaturesNamesRecurse() returns an empty list.
>>>>>>>>>
>>>>>>>>> I'm not quite sure what is going on in the code, but this
>>>>>>>>> behavior still seems to be grabbing the ID even though it isn't
>>>>>>>>> annotated. I'm not sure if it is an ecore issue (falsly
>>>>>>>>> reporting an annotation on the ID attribute) or a Teneo issue.
>>>>>>>>>
>>>>>>>>> Brian
>>>>>>>>>
>>>>>>>>> Martin Taal wrote:
>>>>>>>>>> I solved it differently, an option now controls the default
>>>>>>>>>> name of an id-efeature:
>>>>>>>>>> PersistenceOptions.DEFAULT_ID_FEATURE_NAME
>>>>>>>>>>
>>>>>>>>>> the default value has been changed to e_id so that it is less
>>>>>>>>>> likely that clashes occur.
>>>>>>>>>>
>>>>>>>>>> This has been checked in.
>>>>>>>>>>
>>>>>>>>>> gr. Martin
>>>>>>>>>>
>>>>>>>>>> Brian Vetter wrote:
>>>>>>>>>>>
>>>>>>>>>>> Martin Taal wrote:
>>>>>>>>>>>> Brian,
>>>>>>>>>>>> Automatically assuming that an attribute with name 'id' is
>>>>>>>>>>>> the id-attribute (if there is no other id attribute) will be
>>>>>>>>>>>> removed.
>>>>>>>>>>>
>>>>>>>>>>> Cool. Now that I've got Teneo building, I can pull it down
>>>>>>>>>>> and test it or if you point me in the right direction, I can
>>>>>>>>>>> excise it myself.
>>>>>>>>>>>
>>>>>>>>>>>> fyi, the auto-generated id (e_id) field does not work in
>>>>>>>>>>>> situations were you serialize and then de-serialize objects
>>>>>>>>>>>> as the synthetic id is not (de-)serialized with the object.
>>>>>>>>>>>
>>>>>>>>>>> I presume they are only being used for persistence purposes?
>>>>>>>>>>> Since I'm not using them for anything, what, if any, are the
>>>>>>>>>>> downsides of this? Do these ids have any value outside of the
>>>>>>>>>>> database references?
>>>>>>>>>>>
>>>>>>>>>>> Thanks,
>>>>>>>>>>>
>>>>>>>>>>> Brian
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>
>>>>
>
>
|
|
|
Goto Forum:
Current Time: Thu Apr 18 23:08:39 GMT 2024
Powered by FUDForum. Page generated in 0.04127 seconds |
] 
Search
Help
Register
Login
Home
