Home » Modeling » EMF » [teneo] one-to-many mapping bug?
|
| Re: [teneo] one-to-many mapping bug? [message #423515 is a reply to message #423513] |
Wed, 01 October 2008 16:39   |
 Martin Taal
Messages: 5468
Registered: July 2009 |
Senior Member |
|
|
Hi Knut,
I have a testcase (using a list though and not a bag) which shows the correct behavior (one column
on the many side). Can you post the ecore then I can try myself with your model?
The error in the javadoc has been corrected in cvs, thanks for pointing that out.
gr. Martin
Knut Wannheden wrote:
> Hi,
>
> I have a problem mapping a non-containment one-to-many relationship the
> way I want.
>
> In the library example and using Teneo 1.0.0 I would like to map the
> Writer.books reference (with opposite Book.author) as a column
> BOOK.AUTHOR without any additional index column or any join table.
>
> To do this I checked that the Writer.books reference is set to
> ordered=false and set the JOIN_TABLE_FOR_NON_CONTAINED_ASSOCIATIONS
> option to false (the default is true although the Javadoc in
> PersistenceOptions claims the opposite).
>
> The problem I have is that I both get a column BOOK.AUTHOR and a column
> BOOK.BOOK_AUTHOR. Can you confirm that this is a bug? Is this possibly
> already fixed in CVS HEAD?
>
> I found a working workaround by adding a @JoinColumn(name="AUTHOR")
> annotation to the Writer.books reference. If I want to specify a
> different column name, let's say AUTHOR_ID, I have to add a
> corresponding and matching @JoinColumn to both references.
>
> Regards,
> Knut Wannheden
>
--
With Regards, Martin Taal
Springsite/Elver.org
Office: Hardwareweg 4, 3821 BV Amersfoort
Postal: Nassaulaan 7, 3941 EC Doorn
The Netherlands
Cell: +31 (0)6 288 48 943
Tel: +31 (0)84 420 2397
Fax: +31 (0)84 225 9307
Mail: mtaal@springsite.com - mtaal@elver.org
Web: www.springsite.com - www.elver.org
|
|
| |
| Re: [teneo] one-to-many mapping bug? [message #423553 is a reply to message #423550] |
Thu, 02 October 2008 07:57 |
Martin Taal
Messages: 5468
Registered: July 2009 |
Senior Member |
|
|
Hi Knut,
See my other comments inline.
gr. Martin
Knut Wannheden wrote:
> Hi Martin,
>
> After some more experimenting I found what causes the problem. It's the
> combination of using JOIN_TABLE_FOR_NON_CONTAINED_ASSOCIATIONS="false"
> and JOIN_COLUMN_NAMING_STRATEGY="simple". The same problem occurs
> whether the reference is ordered or not (list or bag). I've included the
> Ecore model below (it is the EMF library model without any alterations).
MT>> Can you file a bugzilla for this?
>
> I have a few more remarks and questions on this topic:
>
> 1. IMHO "false" would have been a more sensible default for
> JOIN_TABLE_FOR_NON_CONTAINED_ASSOCIATIONS as it would then still be
> possible to force the use of a join table by setting the reference to
> non-unique or using a corresponding annotation. With the option set to
> "true" it is impossible to not get a join table.
MT>> Yes it was false before, but I noticed with more complex models that not using join tables
resulted in name clashes when join columns are created. This can happen with models with inheritance
and mappedsuperclass (and multiple inheritance). These name clashes are very difficult to find and
analyse (models are large, no exception is thrown but your lists contain wrong values) and in the
end the naming conflict was not solvable in an automatic way. Generating names for joincolumns is a
more complex thing then it seems at first because the naming logic needs to remain stable (always
generate the same name for the same thing) also when the model changes.
Therefore the options are currently set to the safest values when using Teneo out-of-the-box.
>
> 2. Is there the possibility of specifying my own
> JOIN_COLUMN_NAMING_STRATEGY? I'd like something like "simple" but with
> an "_ID" suffix.
MT>> You can implement your own SQLNameStrategy (or extend a current one) and then set the class to
be used by Teneo as follows:
dataStore.getExtensionManager().registerExtension(SQLNameStr ategy.class.getName(),
MyNamingStrategy.class.getName());
before calling dataStore.initialize()
>
> 3. Also with the default naming strategy ("unique") I cannot simply
> change the name of the Book.author reference using a @JoinColumn
> annotation. Then I also end up with two join columns. Replace the
> reference with the following if you'd like to test that.
MT>> Hmm this seems to be wrong, can you file a bugzilla for this?
>
> <eStructuralFeatures xsi:type="ecore:EReference" name="author"
> lowerBound="1"
> eType="#//Writer" eOpposite="#//Writer/books">
> <eAnnotations source="teneo.jpa">
> <details key="appinfo"
> value="@JoinColumn(name="AUTHOR_ID")"/>
> </eAnnotations>
> </eStructuralFeatures>
>
>
> Here's the complete Ecore model:
>
> <?xml version="1.0" encoding="UTF-8"?>
> <ecore:EPackage xmi:version="2.0"
> xmlns:xmi="http://www.omg.org/XMI"
> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
> xmlns:ecore="http://www.eclipse.org/emf/2002/Ecore" name="library"
> nsURI="http://www.example.eclipse.org/Library" nsPrefix="library">
> <eClassifiers xsi:type="ecore:EClass" name="Book">
> <eStructuralFeatures xsi:type="ecore:EAttribute" name="title"
> lowerBound="1" eType="ecore:EDataType
> http://www.eclipse.org/emf/2003/XMLType#//String"/>
> <eStructuralFeatures xsi:type="ecore:EAttribute" name="pages"
> lowerBound="1" eType="ecore:EDataType
> http://www.eclipse.org/emf/2003/XMLType#//Int"
> unsettable="true"/>
> <eStructuralFeatures xsi:type="ecore:EAttribute" name="category"
> lowerBound="1"
> eType="#//BookCategory" unsettable="true"/>
> <eStructuralFeatures xsi:type="ecore:EReference" name="author"
> lowerBound="1"
> eType="#//Writer" eOpposite="#//Writer/books"/>
> </eClassifiers>
> <eClassifiers xsi:type="ecore:EEnum" name="BookCategory">
> <eLiterals name="Mystery"/>
> <eLiterals name="ScienceFiction" value="1"/>
> <eLiterals name="Biography" value="2"/>
> </eClassifiers>
> <eClassifiers xsi:type="ecore:EClass" name="Library">
> <eStructuralFeatures xsi:type="ecore:EAttribute" name="name"
> lowerBound="1" eType="ecore:EDataType
> http://www.eclipse.org/emf/2003/XMLType#//String"/>
> <eStructuralFeatures xsi:type="ecore:EReference" name="writers"
> upperBound="-1"
> eType="#//Writer" containment="true" resolveProxies="false"/>
> <eStructuralFeatures xsi:type="ecore:EReference" name="books"
> upperBound="-1"
> eType="#//Book" containment="true" resolveProxies="false"/>
> </eClassifiers>
> <eClassifiers xsi:type="ecore:EClass" name="Writer">
> <eStructuralFeatures xsi:type="ecore:EAttribute" name="name"
> lowerBound="1" eType="ecore:EDataType
> http://www.eclipse.org/emf/2003/XMLType#//String"/>
> <eStructuralFeatures xsi:type="ecore:EReference" name="books"
> upperBound="-1"
> eType="#//Book" eOpposite="#//Book/author"/>
> </eClassifiers>
> </ecore:EPackage>
>
> Regards,
>
> --knut
>
> Martin Taal wrote:
>> Hi Knut,
>> I have a testcase (using a list though and not a bag) which shows the
>> correct behavior (one column on the many side). Can you post the ecore
>> then I can try myself with your model?
>>
>> The error in the javadoc has been corrected in cvs, thanks for
>> pointing that out.
>>
>> gr. Martin
>>
>> Knut Wannheden wrote:
>>> Hi,
>>>
>>> I have a problem mapping a non-containment one-to-many relationship
>>> the way I want.
>>>
>>> In the library example and using Teneo 1.0.0 I would like to map the
>>> Writer.books reference (with opposite Book.author) as a column
>>> BOOK.AUTHOR without any additional index column or any join table.
>>>
>>> To do this I checked that the Writer.books reference is set to
>>> ordered=false and set the JOIN_TABLE_FOR_NON_CONTAINED_ASSOCIATIONS
>>> option to false (the default is true although the Javadoc in
>>> PersistenceOptions claims the opposite).
>>>
>>> The problem I have is that I both get a column BOOK.AUTHOR and a
>>> column BOOK.BOOK_AUTHOR. Can you confirm that this is a bug? Is this
>>> possibly already fixed in CVS HEAD?
>>>
>>> I found a working workaround by adding a @JoinColumn(name="AUTHOR")
>>> annotation to the Writer.books reference. If I want to specify a
>>> different column name, let's say AUTHOR_ID, I have to add a
>>> corresponding and matching @JoinColumn to both references.
>>>
>>> Regards,
>>> Knut Wannheden
>>>
>>
>>
--
With Regards, Martin Taal
Springsite/Elver.org
Office: Hardwareweg 4, 3821 BV Amersfoort
Postal: Nassaulaan 7, 3941 EC Doorn
The Netherlands
Cell: +31 (0)6 288 48 943
Tel: +31 (0)84 420 2397
Fax: +31 (0)84 225 9307
Mail: mtaal@springsite.com - mtaal@elver.org
Web: www.springsite.com - www.elver.org
|
|
|
| Re: [teneo] one-to-many mapping bug? [message #423555 is a reply to message #423553] |
Thu, 02 October 2008 08:04 |
Knut Wannheden
Messages: 298
Registered: July 2009 |
Senior Member |
|
|
Hi Martin,
Martin Taal wrote:
> Hi Knut,
> See my other comments inline.
>
> gr. Martin
>
> Knut Wannheden wrote:
>> Hi Martin,
>>
>> After some more experimenting I found what causes the problem. It's
>> the combination of using
>> JOIN_TABLE_FOR_NON_CONTAINED_ASSOCIATIONS="false" and
>> JOIN_COLUMN_NAMING_STRATEGY="simple". The same problem occurs whether
>> the reference is ordered or not (list or bag). I've included the Ecore
>> model below (it is the EMF library model without any alterations).
> MT>> Can you file a bugzilla for this?
>
OK. I will include the details of point 3 below as I think it is really
the same issue, just that it's more prominent using the "simple" naming
strategy.
>>
>> I have a few more remarks and questions on this topic:
>>
>> 1. IMHO "false" would have been a more sensible default for
>> JOIN_TABLE_FOR_NON_CONTAINED_ASSOCIATIONS as it would then still be
>> possible to force the use of a join table by setting the reference to
>> non-unique or using a corresponding annotation. With the option set to
>> "true" it is impossible to not get a join table.
> MT>> Yes it was false before, but I noticed with more complex models
> that not using join tables resulted in name clashes when join columns
> are created. This can happen with models with inheritance and
> mappedsuperclass (and multiple inheritance). These name clashes are very
> difficult to find and analyse (models are large, no exception is thrown
> but your lists contain wrong values) and in the end the naming conflict
> was not solvable in an automatic way. Generating names for joincolumns
> is a more complex thing then it seems at first because the naming logic
> needs to remain stable (always generate the same name for the same
> thing) also when the model changes.
> Therefore the options are currently set to the safest values when using
> Teneo out-of-the-box.
>
OK, makes perfectly sense.
>>
>> 2. Is there the possibility of specifying my own
>> JOIN_COLUMN_NAMING_STRATEGY? I'd like something like "simple" but with
>> an "_ID" suffix.
> MT>> You can implement your own SQLNameStrategy (or extend a current
> one) and then set the class to be used by Teneo as follows:
> dataStore.getExtensionManager().registerExtension(SQLNameStr ategy.class.getName(),
> MyNamingStrategy.class.getName());
>
> before calling dataStore.initialize()
>
Excellent!
>>
>> 3. Also with the default naming strategy ("unique") I cannot simply
>> change the name of the Book.author reference using a @JoinColumn
>> annotation. Then I also end up with two join columns. Replace the
>> reference with the following if you'd like to test that.
> MT>> Hmm this seems to be wrong, can you file a bugzilla for this?
>
Regards,
--knut
|
|
|
| Re: [teneo] one-to-many mapping bug? [message #423557 is a reply to message #423555] |
Thu, 02 October 2008 08:28 |
Knut Wannheden
Messages: 298
Registered: July 2009 |
Senior Member |
|
|
Hi Martin,
See https://bugs.eclipse.org/bugs/show_bug.cgi?id=249440.
Regards,
--knut
Knut Wannheden wrote:
> Hi Martin,
>
> Martin Taal wrote:
>> Hi Knut,
>> See my other comments inline.
>>
>> gr. Martin
>>
>> Knut Wannheden wrote:
>>> Hi Martin,
>>>
>>> After some more experimenting I found what causes the problem. It's
>>> the combination of using
>>> JOIN_TABLE_FOR_NON_CONTAINED_ASSOCIATIONS="false" and
>>> JOIN_COLUMN_NAMING_STRATEGY="simple". The same problem occurs whether
>>> the reference is ordered or not (list or bag). I've included the
>>> Ecore model below (it is the EMF library model without any alterations).
>> MT>> Can you file a bugzilla for this?
>>
>
> OK. I will include the details of point 3 below as I think it is really
> the same issue, just that it's more prominent using the "simple" naming
> strategy.
>
>>>
>>> I have a few more remarks and questions on this topic:
>>>
>>> 1. IMHO "false" would have been a more sensible default for
>>> JOIN_TABLE_FOR_NON_CONTAINED_ASSOCIATIONS as it would then still be
>>> possible to force the use of a join table by setting the reference to
>>> non-unique or using a corresponding annotation. With the option set
>>> to "true" it is impossible to not get a join table.
>> MT>> Yes it was false before, but I noticed with more complex models
>> that not using join tables resulted in name clashes when join columns
>> are created. This can happen with models with inheritance and
>> mappedsuperclass (and multiple inheritance). These name clashes are
>> very difficult to find and analyse (models are large, no exception is
>> thrown but your lists contain wrong values) and in the end the naming
>> conflict was not solvable in an automatic way. Generating names for
>> joincolumns is a more complex thing then it seems at first because the
>> naming logic needs to remain stable (always generate the same name for
>> the same thing) also when the model changes.
>> Therefore the options are currently set to the safest values when
>> using Teneo out-of-the-box.
>>
>
> OK, makes perfectly sense.
>
>>>
>>> 2. Is there the possibility of specifying my own
>>> JOIN_COLUMN_NAMING_STRATEGY? I'd like something like "simple" but
>>> with an "_ID" suffix.
>> MT>> You can implement your own SQLNameStrategy (or extend a current
>> one) and then set the class to be used by Teneo as follows:
>> dataStore.getExtensionManager().registerExtension(SQLNameStr ategy.class.getName(),
>> MyNamingStrategy.class.getName());
>>
>> before calling dataStore.initialize()
>>
>
> Excellent!
>
>>>
>>> 3. Also with the default naming strategy ("unique") I cannot simply
>>> change the name of the Book.author reference using a @JoinColumn
>>> annotation. Then I also end up with two join columns. Replace the
>>> reference with the following if you'd like to test that.
>> MT>> Hmm this seems to be wrong, can you file a bugzilla for this?
>>
>
> Regards,
>
> --knut
|
|
|
Goto Forum:
Current Time: Fri Apr 26 05:51:41 GMT 2024
Powered by FUDForum. Page generated in 0.02852 seconds |
] 
Search
Help
Register
Login
Home
