Skip to main content


Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Modeling » EMF » [CDO/Teneo] EMF Specific Extra Columns in DDL
[CDO/Teneo] EMF Specific Extra Columns in DDL [message #917557] Thu, 20 September 2012 07:40 Go to next message
Appasamy Thirugnana is currently offline Appasamy ThirugnanaFriend
Messages: 27
Registered: September 2012
Junior Member
Hi Everyone,
Environment: Teneo /Hibernate

When I use Teneo to store EObjects it is generating extra columns in database
(E_CONTAINER,E_CONTAINER_FEATURE_NAME,..) is there any way to avoid those?

or generate as a seperate table?

I want only columns specific to my ECORE model to be created in the DDL.

Thanks.

Appasamy







Re: [CDO/Teneo] EMF Specific Extra Columns in DDL [message #917584 is a reply to message #917557] Thu, 20 September 2012 08:10 Go to previous messageGo to next message
Martin Taal is currently offline Martin TaalFriend
Messages: 5468
Registered: July 2009
Senior Member
Hi Appasamy,
See here:
http://wiki.eclipse.org/Teneo/Hibernate/ModelRelational/Association_Mapping#Storing_container_relation

Also checkout several configuration options in this page to prevent specific columns or to control naming etc.:
http://wiki.eclipse.org/Teneo/Hibernate/Configuration_Options

gr. Martin

On 09/20/2012 09:40 AM, Appasamy Thirugnana wrote:
> Hi Everyone,
> Environment: Teneo /Hibernate
>
> When I use Teneo to store EObjects it is generating extra columns in database
> (E_CONTAINER,E_CONTAINER_FEATURE_NAME,..) is there any way to avoid those?
>
> or generate as a seperate table?
>
> I want only columns specific to my ECORE model to be created in the DDL.
>
> Thanks.
>
> Appasamy
>
>
>
>
>
>
>
>


--

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@xxxxxxxx - mtaal@xxxxxxxx
Web: www.springsite.com - www.elver.org
Re: [CDO/Teneo] EMF Specific Extra Columns in DDL [message #917614 is a reply to message #917584] Thu, 20 September 2012 08:50 Go to previous messageGo to next message
Appasamy Thirugnana is currently offline Appasamy ThirugnanaFriend
Messages: 27
Registered: September 2012
Junior Member
Thanks Martin. This helped me.

Regards,
~Appasamy
Re: [CDO/Teneo] EMF Specific Extra Columns in DDL [message #917615 is a reply to message #917584] Thu, 20 September 2012 08:51 Go to previous messageGo to next message
Christoph Keimel is currently offline Christoph KeimelFriend
Messages: 482
Registered: December 2010
Location: Germany
Senior Member
Hi Martin

that is interessting.
How does Teneo evaluate the container, when container relations are disabled?
Are there any drawbacks, when this option is used?

Thanks
Christoph
Re: [CDO/Teneo] EMF Specific Extra Columns in DDL [message #917833 is a reply to message #917615] Thu, 20 September 2012 13:31 Go to previous messageGo to next message
Martin Taal is currently offline Martin TaalFriend
Messages: 5468
Registered: July 2009
Senior Member
Hi Christophe,
Without these econtainer columns the econtainer association is only set if first the parent is read and then the
children are accessed through the parent. So if A is a child of B. When you read A directly from the database the
container association is not set (is null). If you would read first B and then do getA then the container association
from A to B would be set.

gr. Martin

On 09/20/2012 10:51 AM, Christoph Keimel wrote:
> Hi Martin
>
> that is interessting. How does Teneo evaluate the container, when container relations are disabled? Are there any
> drawbacks, when this option is used?
>
> Thanks
> Christoph


--

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@xxxxxxxx - mtaal@xxxxxxxx
Web: www.springsite.com - www.elver.org
Re: [CDO/Teneo] EMF Specific Extra Columns in DDL [message #917929 is a reply to message #917833] Thu, 20 September 2012 15:15 Go to previous messageGo to next message
Christoph Keimel is currently offline Christoph KeimelFriend
Messages: 482
Registered: December 2010
Location: Germany
Senior Member
Hi Martin

Thank you for the information.

So if A is a child of B and has an opposite reference to B
class B {
	contains A[] a opposite b
}
class A {
	container B[1] b opposite a
}
and I read A directly, the call to getB() would return null, since this internally uses the eContainer attribute. Correct?

What if the reference from A to B is non-containment?
class B {
	refers A[] a opposite b
}
class A {
	refers B[1] b opposite a
}
Would A.getB() lazy-load its reference to B in this situation?

I ask, because I am currently thinking about whether to use containment references at all. I get the feeling that, when working with the database, the concept of containment vs. reference is unnecessarily complex. Opinions on this statement are very welcome Smile

Greetings
Christoph
Re: [CDO/Teneo] EMF Specific Extra Columns in DDL [message #918253 is a reply to message #917929] Thu, 20 September 2012 22:05 Go to previous message
Martin Taal is currently offline Martin TaalFriend
Messages: 5468
Registered: July 2009
Senior Member
Hi Christoph,
In this specific case the container column is not needed even if you do containment like this. Mainly because you model
the bidirectional side of the containment association explicitly in the model.

Containment in itself makes sense for certain structures like order and orderlines. But as you touch upon, for a xml
document it is important that everything is contained in something (except for the root), this is less relevant for data
persisted in databases. There is no overall containing root type necessary then.

gr. Martin


On 09/20/2012 05:15 PM, Christoph Keimel wrote:
> Hi Martin
>
> Thank you for the information.
>
> So if A is a child of B and has an opposite reference to B class B {
> contains A[] a opposite b
> }
> class A {
> container B[1] b opposite a
> }and I read A directly, the call to getB() would return null, since this internally uses the eContainer attribute. Correct?
>
> What if the reference from A to B is non-containment?
> class B {
> refers A[] a opposite b
> }
> class A {
> refers B[1] b opposite a
> }Would A.getB() lazy-load its reference to B in this situation?
>
> I ask, because I am currently thinking about whether to use containment references at all. I get the feeling that, when
> working with the database, the concept of containment vs. reference is unnecessarily complex. Opinions on this statement
> are very welcome :)
>
> Greetings
> Christoph


--

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@xxxxxxxx - mtaal@xxxxxxxx
Web: www.springsite.com - www.elver.org
Previous Topic:[CDO] Sharing a resource set amongst views
Next Topic:Problem with with mutually referencing ELists
Goto Forum:
  


Current Time: Thu Apr 25 01:53:09 GMT 2024

Powered by FUDForum. Page generated in 0.03039 seconds
.:: Contact :: Home ::.

Powered by: FUDforum 3.0.2.
Copyright ©2001-2010 FUDforum Bulletin Board Software

Back to the top