Skip to main content


Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Modeling » EMF "Technology" (Ecore Tools, EMFatic, etc)  » Teneo or CDO?
Teneo or CDO? [message #108357] Sat, 26 January 2008 11:55 Go to next message
Henrik  önsson is currently offline Henrik önssonFriend
Messages: 53
Registered: July 2009
Member
Hi,

We have about 15 EMF models at the moment in our product that uses the
default XMI persistance in EMF. Now we have requirements to let multiple
user read and write in the same model instances. As I understand EMFT
provides two solutions for this: CDO and Teneo.

What are the differences between these two frameworks?
Which framework would be "best" for us?

Regards

Henrik
Re: Teneo or CDO? [message #108449 is a reply to message #108357] Sat, 26 January 2008 15:04 Go to previous messageGo to next message
Eclipse UserFriend
Originally posted by: stepper.sympedia.de

Hi Henrik,

I believe both CDO and Teneo solve some very similar problems and can be
what you're looking for.
As the author of CDO, what should I say? ;-)
You can find a feature list of CDO (and a bit more information) at
http://wiki.eclipse.org/CDO

What about evaluating both technologies and report your experiences here?!
That'd be very interesting.

Of course, if you have more detailed questions with respect to CDO, I'm
here ;-)

Regards,
Eike Stepper
----
http://wiki.eclipse.org/CDO
http://wiki.eclipse.org/Net4j




Henrik Jönsson schrieb:
> Hi,
>
> We have about 15 EMF models at the moment in our product that uses the
> default XMI persistance in EMF. Now we have requirements to let
> multiple user read and write in the same model instances. As I
> understand EMFT provides two solutions for this: CDO and Teneo.
>
> What are the differences between these two frameworks?
> Which framework would be "best" for us?
>
> Regards
>
> Henrik
>
Re: Teneo or CDO? [message #108536 is a reply to message #108449] Sun, 27 January 2008 11:42 Go to previous messageGo to next message
Martin Taal is currently offline Martin TaalFriend
Messages: 5468
Registered: July 2009
Senior Member
Hi Henrik,
My answer is very much the same as Eike's. Just check out both solutions (Teneo's can be found here:
http://www.elver.org) and see what fits best.

Teneo is very much focused on the mapping any type of model to a relational store. The mapping
support is very complete (imho) with support for most EMF constructs (for example, featuremaps,
mixed, etc.). Teneo offers a default mapping logic which you can easily override using jpa
annotations in the model or in a separate xml file.
See here for a more detailed listing of features:
http://www.elver.org/hibernate/features.html

Btw, it is on my wishlist to integrate CDO and Teneo combining the client-server layer of CDO/Net4j
with the relational mapping capabilities of Teneo. Until now I have not yet found the time to do so :-(.

gr. Martin

Eike Stepper wrote:
> Hi Henrik,
>
> I believe both CDO and Teneo solve some very similar problems and can be
> what you're looking for.
> As the author of CDO, what should I say? ;-)
> You can find a feature list of CDO (and a bit more information) at
> http://wiki.eclipse.org/CDO
>
> What about evaluating both technologies and report your experiences here?!
> That'd be very interesting.
>
> Of course, if you have more detailed questions with respect to CDO, I'm
> here ;-)
>
> Regards,
> Eike Stepper
> ----
> http://wiki.eclipse.org/CDO
> http://wiki.eclipse.org/Net4j
>
>
>
>
> Henrik Jönsson schrieb:
>> Hi,
>>
>> We have about 15 EMF models at the moment in our product that uses the
>> default XMI persistance in EMF. Now we have requirements to let
>> multiple user read and write in the same model instances. As I
>> understand EMFT provides two solutions for this: CDO and Teneo.
>>
>> What are the differences between these two frameworks?
>> Which framework would be "best" for us?
>>
>> Regards
>>
>> Henrik
>>


--

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 or CDO? [message #109086 is a reply to message #108357] Tue, 29 January 2008 14:35 Go to previous messageGo to next message
Stefan Winkler is currently offline Stefan WinklerFriend
Messages: 307
Registered: July 2009
Location: Germany
Senior Member
Hi,

I'll add a bit of a "neutral" voice to this thread.

*** disclaimer ***
I am only reporting from about one week personal playing with both CDO
and Teneo.
What I write here is my personal experience. This report is thus quite
subjective.
If I missed any feature or functionality or reported something wrong,
please, Eike, Martin, do correct me.
*** disclaimer end ***

A bit of personal motivation (just to clarify my environment and
requirements):
I want to build a research prototype which converts text-documents or
other more or less structured collections of text to models (like - e.g.
making one model-element "Paragraph" out of one text-paragraph with an
attribute "content") and then apply algorithms to them. I use models as
a common platform to apply my algorithms to texts of whichever format,
so models are a form of abstraction for me.

I quickly found out that working with huge models with EMF is a bit
problematic, because resources in EMF are atomar - i.e. you can only
load or unload a resource as a whole, not work with parts of it.
Additionally storing huge models in a database seemed to make more sense
than working with XMI files.

So I was pointed to EMFT Teneo and CDO.

I started playing around with Teneo/Hibernate.
Pros:
- Easy installable using update site
- Works almost out of the box with existing ecore-based model
- Storage Annotations can be added to the .genmodel
- Mapping is generated on the fly (but can also be changes as far as I
know, didn't try this out)
- Uses Hibernate -> can be used with lots of databases
- Tutorials and documentation at http://www.elver.org/hibernate/ are in
most parts usable for a quick start
- Lazy loading (not using EMF-proxies but Hibernate cglib proxies)
- Excellent support in the newsgroup
Cons:
- No client-server architecture (besides the db-server/-client - so you
have the eclipse application and the database server) - so I think no
mechanism to propagate changes between multiple concurrent users
- No re-proxying (you can't lazy-load your object-net and then throw
away part of that net while still keeping the other part) - this is
unsuitable for working with large models

Because of the last point I started playing around with CDO:
Pros:
- Client-Server architecture with change notifications between the
clients (didn't try that out)
- It's possible to put client and repository management into the same
application, so Client/Server is optional
- Lazy-loading and Lazy-unloading is possible (and is done
transparently, so no management needed for this).
- If the basic framework is set up, you can simply work naturally with
the model, and commit() whenever you like
- Excellent support in the newsgroup
Cons:
- Documentation (mostly the Wiki) is incomplete - so setting up the
basic framework is a bit tricky (but as stated above, newsgroup support
is excellent ;-))
- Subjectively higher learning curve than with Teneo for setting up the
infrastructure
- Only works with mysql, derby and hsqldb (as well as with a memory-only
store) - more to come (I think)
- No direct influence on the database mapping (some parameters for the
mapping strategy can be tuned)

Regarding performance, I can not make any statement, as I haven't tried
any of the technologies with huge models.

In one sentence I would characterize Teneo as an ORM-solution for EMF,
while CDO is a client-server architecture for EMF models.

In a recent post, Martin stated, that he'll try to integrate Teneo and CDO.
I think that would be the ultimate client-server ORM solution for EMF.

As stated above, these lists are very subjective and they are guaranteed
to be incomplete.
Maybe they are a starting point and I would like if other users of any
of both technologies could add to any of the lists.

Cheers
Stefan


Henrik Jönsson schrieb:
> Hi,
>
> We have about 15 EMF models at the moment in our product that uses the
> default XMI persistance in EMF. Now we have requirements to let
> multiple user read and write in the same model instances. As I
> understand EMFT provides two solutions for this: CDO and Teneo.
>
> What are the differences between these two frameworks?
> Which framework would be "best" for us?
>
> Regards
>
> Henrik
>
Re: Teneo or CDO? [message #109126 is a reply to message #109086] Tue, 29 January 2008 15:04 Go to previous messageGo to next message
Eclipse UserFriend
Originally posted by: stepper.sympedia.de

Stefan,

Thanks for your excellent (from my perspective) analysis!
More comments below...



Stefan Winkler schrieb:
> Hi,
>
> I'll add a bit of a "neutral" voice to this thread.
>
> *** disclaimer ***
> I am only reporting from about one week personal playing with both CDO
> and Teneo.
> What I write here is my personal experience. This report is thus quite
> subjective.
> If I missed any feature or functionality or reported something wrong,
> please, Eike, Martin, do correct me.
> *** disclaimer end ***
>
> A bit of personal motivation (just to clarify my environment and
> requirements):
> I want to build a research prototype which converts text-documents or
> other more or less structured collections of text to models (like -
> e.g. making one model-element "Paragraph" out of one text-paragraph
> with an attribute "content") and then apply algorithms to them. I use
> models as a common platform to apply my algorithms to texts of
> whichever format, so models are a form of abstraction for me.
>
> I quickly found out that working with huge models with EMF is a bit
> problematic, because resources in EMF are atomar - i.e. you can only
> load or unload a resource as a whole, not work with parts of it.
> Additionally storing huge models in a database seemed to make more
> sense than working with XMI files.
>
> So I was pointed to EMFT Teneo and CDO.
>
> I started playing around with Teneo/Hibernate.
> Pros:
> - Easy installable using update site
> - Works almost out of the box with existing ecore-based model
> - Storage Annotations can be added to the .genmodel
> - Mapping is generated on the fly (but can also be changes as far as I
> know, didn't try this out)
> - Uses Hibernate -> can be used with lots of databases
> - Tutorials and documentation at http://www.elver.org/hibernate/ are
> in most parts usable for a quick start
> - Lazy loading (not using EMF-proxies but Hibernate cglib proxies)
> - Excellent support in the newsgroup
> Cons:
> - No client-server architecture (besides the db-server/-client - so
> you have the eclipse application and the database server) - so I think
> no mechanism to propagate changes between multiple concurrent users
> - No re-proxying (you can't lazy-load your object-net and then throw
> away part of that net while still keeping the other part) - this is
> unsuitable for working with large models
>
> Because of the last point I started playing around with CDO:
> Pros:
> - Client-Server architecture with change notifications between the
> clients (didn't try that out)
> - It's possible to put client and repository management into the same
> application, so Client/Server is optional
> - Lazy-loading and Lazy-unloading is possible (and is done
> transparently, so no management needed for this).
> - If the basic framework is set up, you can simply work naturally with
> the model, and commit() whenever you like
> - Excellent support in the newsgroup
> Cons:
> - Documentation (mostly the Wiki) is incomplete - so setting up the
> basic framework is a bit tricky (but as stated above, newsgroup
> support is excellent ;-))
Apologies for that! I guess one reason that open source developers
choose to work without being paid is that they are free to postpone
documentation tasks as long as there are coding tasks in the list ;-)

> - Subjectively higher learning curve than with Teneo for setting up
> the infrastructure
Agreed. Do you think this is an implication of the incomplete
documentation? Or do you have suggestions to simplify the setup?

> - Only works with mysql, derby and hsqldb (as well as with a
> memory-only store) - more to come (I think)
Contributions of additional DB adapters are welcome ;-)

> - No direct influence on the database mapping (some parameters for the
> mapping strategy can be tuned)
>
> Regarding performance, I can not make any statement, as I haven't
> tried any of the technologies with huge models.
>
> In one sentence I would characterize Teneo as an ORM-solution for EMF,
> while CDO is a client-server architecture for EMF models.
I think this is a good summary.

>
> In a recent post, Martin stated, that he'll try to integrate Teneo and
> CDO.
> I think that would be the ultimate client-server ORM solution for EMF.
Volunteers hands up ;-)
Unfortunately Martin and I didn't have time so far to dig into this
issue although we're both sure that this effort could deliver a great
solution.

Regards,
Eike Stepper
----
http://wiki.eclipse.org/CDO
http://wiki.eclipse.org/Net4j


>
> As stated above, these lists are very subjective and they are
> guaranteed to be incomplete.
> Maybe they are a starting point and I would like if other users of any
> of both technologies could add to any of the lists.
>
> Cheers
> Stefan
>
>
> Henrik Jönsson schrieb:
>> Hi,
>>
>> We have about 15 EMF models at the moment in our product that uses
>> the default XMI persistance in EMF. Now we have requirements to let
>> multiple user read and write in the same model instances. As I
>> understand EMFT provides two solutions for this: CDO and Teneo.
>>
>> What are the differences between these two frameworks?
>> Which framework would be "best" for us?
>>
>> Regards
>>
>> Henrik
>>
Re: Teneo or CDO? [message #109152 is a reply to message #109126] Tue, 29 January 2008 15:27 Go to previous messageGo to next message
Martin Taal is currently offline Martin TaalFriend
Messages: 5468
Registered: July 2009
Senior Member
Hi Stefan,
Also from my point of view your post contains a balanced pro/con overview.
I am very interested in integrating Teneo with cdo. With Teneo I have/will never have the intention
to offer client-server functionality. On the other hand I see a clear requirement from Teneo users
for this functionality and CDO seems to me as a perfect solution to this.
Posts like yours and the others which appeared the past few days help to put this integration much
higher (somewhere around the top :-) of my priority list.

gr. Martin

Eike Stepper wrote:
> Stefan,
>
> Thanks for your excellent (from my perspective) analysis!
> More comments below...
>
>
>
> Stefan Winkler schrieb:
>> Hi,
>>
>> I'll add a bit of a "neutral" voice to this thread.
>>
>> *** disclaimer ***
>> I am only reporting from about one week personal playing with both CDO
>> and Teneo.
>> What I write here is my personal experience. This report is thus quite
>> subjective.
>> If I missed any feature or functionality or reported something wrong,
>> please, Eike, Martin, do correct me.
>> *** disclaimer end ***
>>
>> A bit of personal motivation (just to clarify my environment and
>> requirements):
>> I want to build a research prototype which converts text-documents or
>> other more or less structured collections of text to models (like -
>> e.g. making one model-element "Paragraph" out of one text-paragraph
>> with an attribute "content") and then apply algorithms to them. I use
>> models as a common platform to apply my algorithms to texts of
>> whichever format, so models are a form of abstraction for me.
>>
>> I quickly found out that working with huge models with EMF is a bit
>> problematic, because resources in EMF are atomar - i.e. you can only
>> load or unload a resource as a whole, not work with parts of it.
>> Additionally storing huge models in a database seemed to make more
>> sense than working with XMI files.
>>
>> So I was pointed to EMFT Teneo and CDO.
>>
>> I started playing around with Teneo/Hibernate.
>> Pros:
>> - Easy installable using update site
>> - Works almost out of the box with existing ecore-based model
>> - Storage Annotations can be added to the .genmodel
>> - Mapping is generated on the fly (but can also be changes as far as I
>> know, didn't try this out)
>> - Uses Hibernate -> can be used with lots of databases
>> - Tutorials and documentation at http://www.elver.org/hibernate/ are
>> in most parts usable for a quick start
>> - Lazy loading (not using EMF-proxies but Hibernate cglib proxies)
>> - Excellent support in the newsgroup
>> Cons:
>> - No client-server architecture (besides the db-server/-client - so
>> you have the eclipse application and the database server) - so I think
>> no mechanism to propagate changes between multiple concurrent users
>> - No re-proxying (you can't lazy-load your object-net and then throw
>> away part of that net while still keeping the other part) - this is
>> unsuitable for working with large models
>>
>> Because of the last point I started playing around with CDO:
>> Pros:
>> - Client-Server architecture with change notifications between the
>> clients (didn't try that out)
>> - It's possible to put client and repository management into the same
>> application, so Client/Server is optional
>> - Lazy-loading and Lazy-unloading is possible (and is done
>> transparently, so no management needed for this).
>> - If the basic framework is set up, you can simply work naturally with
>> the model, and commit() whenever you like
>> - Excellent support in the newsgroup
>> Cons:
>> - Documentation (mostly the Wiki) is incomplete - so setting up the
>> basic framework is a bit tricky (but as stated above, newsgroup
>> support is excellent ;-))
> Apologies for that! I guess one reason that open source developers
> choose to work without being paid is that they are free to postpone
> documentation tasks as long as there are coding tasks in the list ;-)
>
>> - Subjectively higher learning curve than with Teneo for setting up
>> the infrastructure
> Agreed. Do you think this is an implication of the incomplete
> documentation? Or do you have suggestions to simplify the setup?
>
>> - Only works with mysql, derby and hsqldb (as well as with a
>> memory-only store) - more to come (I think)
> Contributions of additional DB adapters are welcome ;-)
>
>> - No direct influence on the database mapping (some parameters for the
>> mapping strategy can be tuned)
>>
>> Regarding performance, I can not make any statement, as I haven't
>> tried any of the technologies with huge models.
>>
>> In one sentence I would characterize Teneo as an ORM-solution for EMF,
>> while CDO is a client-server architecture for EMF models.
> I think this is a good summary.
>
>>
>> In a recent post, Martin stated, that he'll try to integrate Teneo and
>> CDO.
>> I think that would be the ultimate client-server ORM solution for EMF.
> Volunteers hands up ;-)
> Unfortunately Martin and I didn't have time so far to dig into this
> issue although we're both sure that this effort could deliver a great
> solution.
>
> Regards,
> Eike Stepper
> ----
> http://wiki.eclipse.org/CDO
> http://wiki.eclipse.org/Net4j
>
>
>>
>> As stated above, these lists are very subjective and they are
>> guaranteed to be incomplete.
>> Maybe they are a starting point and I would like if other users of any
>> of both technologies could add to any of the lists.
>>
>> Cheers
>> Stefan
>>
>>
>> Henrik Jönsson schrieb:
>>> Hi,
>>>
>>> We have about 15 EMF models at the moment in our product that uses
>>> the default XMI persistance in EMF. Now we have requirements to let
>>> multiple user read and write in the same model instances. As I
>>> understand EMFT provides two solutions for this: CDO and Teneo.
>>>
>>> What are the differences between these two frameworks?
>>> Which framework would be "best" for us?
>>>
>>> Regards
>>>
>>> Henrik
>>>


--

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 or CDO? [message #109241 is a reply to message #109152] Tue, 29 January 2008 18:26 Go to previous messageGo to next message
Eclipse UserFriend
Originally posted by: tom.eiswind.de

HI Martin,

I only came across CDO this morning and it seems to be what I didnt know
that I want it so much. As with the others teneo integration is whats
missing the most. Why create another database mapping solution when
hibernate is around and so well supported. (this is what i dislike on
cdo most at the first glance) I will dive into CDO the next days as Im
currently off project and have some time to do so. WHat I think we have
to look at is the following: hibernate does its lazy loading through its
own custom proxies. I will have to see how it is done with cdo. I
remember I saw some implementation of custom lazy loading with remote
ejbs strategy on the hibernate wiki

http://www.hibernate.org/377.html



but i wonder how this would go with cdo. cdo has its own proxies, so we
would have to teach hibernate to use those and put a tuplizer in the
hibernate mapping. dont know if this is so easy and what would be the
best way.

I havent seen much of the CDO implementation, but I think at least this
should be possible to achieve without too much trouble.



Martin Taal schrieb:
> Hi Stefan,
> Also from my point of view your post contains a balanced pro/con overview.
> I am very interested in integrating Teneo with cdo. With Teneo I
> have/will never have the intention to offer client-server functionality.
> On the other hand I see a clear requirement from Teneo users for this
> functionality and CDO seems to me as a perfect solution to this.
> Posts like yours and the others which appeared the past few days help to
> put this integration much higher (somewhere around the top :-) of my
> priority list.
>
> gr. Martin
>
> Eike Stepper wrote:
>> Stefan,
>>
>> Thanks for your excellent (from my perspective) analysis!
>> More comments below...
>>
>>
>>
>> Stefan Winkler schrieb:
>>> Hi,
>>>
>>> I'll add a bit of a "neutral" voice to this thread.
>>>
>>> *** disclaimer ***
>>> I am only reporting from about one week personal playing with both
>>> CDO and Teneo.
>>> What I write here is my personal experience. This report is thus
>>> quite subjective.
>>> If I missed any feature or functionality or reported something wrong,
>>> please, Eike, Martin, do correct me.
>>> *** disclaimer end ***
>>>
>>> A bit of personal motivation (just to clarify my environment and
>>> requirements):
>>> I want to build a research prototype which converts text-documents or
>>> other more or less structured collections of text to models (like -
>>> e.g. making one model-element "Paragraph" out of one text-paragraph
>>> with an attribute "content") and then apply algorithms to them. I use
>>> models as a common platform to apply my algorithms to texts of
>>> whichever format, so models are a form of abstraction for me.
>>>
>>> I quickly found out that working with huge models with EMF is a bit
>>> problematic, because resources in EMF are atomar - i.e. you can only
>>> load or unload a resource as a whole, not work with parts of it.
>>> Additionally storing huge models in a database seemed to make more
>>> sense than working with XMI files.
>>>
>>> So I was pointed to EMFT Teneo and CDO.
>>>
>>> I started playing around with Teneo/Hibernate.
>>> Pros:
>>> - Easy installable using update site
>>> - Works almost out of the box with existing ecore-based model
>>> - Storage Annotations can be added to the .genmodel
>>> - Mapping is generated on the fly (but can also be changes as far as
>>> I know, didn't try this out)
>>> - Uses Hibernate -> can be used with lots of databases
>>> - Tutorials and documentation at http://www.elver.org/hibernate/ are
>>> in most parts usable for a quick start
>>> - Lazy loading (not using EMF-proxies but Hibernate cglib proxies)
>>> - Excellent support in the newsgroup
>>> Cons:
>>> - No client-server architecture (besides the db-server/-client - so
>>> you have the eclipse application and the database server) - so I
>>> think no mechanism to propagate changes between multiple concurrent
>>> users
>>> - No re-proxying (you can't lazy-load your object-net and then throw
>>> away part of that net while still keeping the other part) - this is
>>> unsuitable for working with large models
>>>
>>> Because of the last point I started playing around with CDO:
>>> Pros:
>>> - Client-Server architecture with change notifications between the
>>> clients (didn't try that out)
>>> - It's possible to put client and repository management into the same
>>> application, so Client/Server is optional
>>> - Lazy-loading and Lazy-unloading is possible (and is done
>>> transparently, so no management needed for this).
>>> - If the basic framework is set up, you can simply work naturally
>>> with the model, and commit() whenever you like
>>> - Excellent support in the newsgroup
>>> Cons:
>>> - Documentation (mostly the Wiki) is incomplete - so setting up the
>>> basic framework is a bit tricky (but as stated above, newsgroup
>>> support is excellent ;-))
>> Apologies for that! I guess one reason that open source developers
>> choose to work without being paid is that they are free to postpone
>> documentation tasks as long as there are coding tasks in the list ;-)
>>
>>> - Subjectively higher learning curve than with Teneo for setting up
>>> the infrastructure
>> Agreed. Do you think this is an implication of the incomplete
>> documentation? Or do you have suggestions to simplify the setup?
>>
>>> - Only works with mysql, derby and hsqldb (as well as with a
>>> memory-only store) - more to come (I think)
>> Contributions of additional DB adapters are welcome ;-)
>>
>>> - No direct influence on the database mapping (some parameters for
>>> the mapping strategy can be tuned)
>>>
>>> Regarding performance, I can not make any statement, as I haven't
>>> tried any of the technologies with huge models.
>>>
>>> In one sentence I would characterize Teneo as an ORM-solution for EMF,
>>> while CDO is a client-server architecture for EMF models.
>> I think this is a good summary.
>>
>>>
>>> In a recent post, Martin stated, that he'll try to integrate Teneo
>>> and CDO.
>>> I think that would be the ultimate client-server ORM solution for EMF.
>> Volunteers hands up ;-)
>> Unfortunately Martin and I didn't have time so far to dig into this
>> issue although we're both sure that this effort could deliver a great
>> solution.
>>
>> Regards,
>> Eike Stepper
>> ----
>> http://wiki.eclipse.org/CDO
>> http://wiki.eclipse.org/Net4j
>>
>>
>>>
>>> As stated above, these lists are very subjective and they are
>>> guaranteed to be incomplete.
>>> Maybe they are a starting point and I would like if other users of
>>> any of both technologies could add to any of the lists.
>>>
>>> Cheers
>>> Stefan
>>>
>>>
>>> Henrik Jönsson schrieb:
>>>> Hi,
>>>>
>>>> We have about 15 EMF models at the moment in our product that uses
>>>> the default XMI persistance in EMF. Now we have requirements to let
>>>> multiple user read and write in the same model instances. As I
>>>> understand EMFT provides two solutions for this: CDO and Teneo.
>>>>
>>>> What are the differences between these two frameworks?
>>>> Which framework would be "best" for us?
>>>>
>>>> Regards
>>>>
>>>> Henrik
>>>>
>
>
Re: Teneo or CDO? [message #110090 is a reply to message #109126] Wed, 30 January 2008 13:22 Go to previous messageGo to next message
Stefan Winkler is currently offline Stefan WinklerFriend
Messages: 307
Registered: July 2009
Location: Germany
Senior Member
Hi Eike,

comments below ...


Eike Stepper schrieb:
> Stefan,
>
> Thanks for your excellent (from my perspective) analysis!
> More comments below...
>
>
>
> Stefan Winkler schrieb:
>> Hi,
>>
>> I'll add a bit of a "neutral" voice to this thread.
>>
>> *** disclaimer ***
>> I am only reporting from about one week personal playing with both
>> CDO and Teneo.
>> What I write here is my personal experience. This report is thus
>> quite subjective.
>> If I missed any feature or functionality or reported something wrong,
>> please, Eike, Martin, do correct me.
>> *** disclaimer end ***
>>
>> A bit of personal motivation (just to clarify my environment and
>> requirements):
>> I want to build a research prototype which converts text-documents or
>> other more or less structured collections of text to models (like -
>> e.g. making one model-element "Paragraph" out of one text-paragraph
>> with an attribute "content") and then apply algorithms to them. I use
>> models as a common platform to apply my algorithms to texts of
>> whichever format, so models are a form of abstraction for me.
>>
>> I quickly found out that working with huge models with EMF is a bit
>> problematic, because resources in EMF are atomar - i.e. you can only
>> load or unload a resource as a whole, not work with parts of it.
>> Additionally storing huge models in a database seemed to make more
>> sense than working with XMI files.
>>
>> So I was pointed to EMFT Teneo and CDO.
>>
>> I started playing around with Teneo/Hibernate.
>> Pros:
>> - Easy installable using update site
>> - Works almost out of the box with existing ecore-based model
>> - Storage Annotations can be added to the .genmodel
>> - Mapping is generated on the fly (but can also be changes as far as
>> I know, didn't try this out)
>> - Uses Hibernate -> can be used with lots of databases
>> - Tutorials and documentation at http://www.elver.org/hibernate/ are
>> in most parts usable for a quick start
>> - Lazy loading (not using EMF-proxies but Hibernate cglib proxies)
>> - Excellent support in the newsgroup
>> Cons:
>> - No client-server architecture (besides the db-server/-client - so
>> you have the eclipse application and the database server) - so I
>> think no mechanism to propagate changes between multiple concurrent
>> users
>> - No re-proxying (you can't lazy-load your object-net and then throw
>> away part of that net while still keeping the other part) - this is
>> unsuitable for working with large models
>>
>> Because of the last point I started playing around with CDO:
>> Pros:
>> - Client-Server architecture with change notifications between the
>> clients (didn't try that out)
>> - It's possible to put client and repository management into the same
>> application, so Client/Server is optional
>> - Lazy-loading and Lazy-unloading is possible (and is done
>> transparently, so no management needed for this).
>> - If the basic framework is set up, you can simply work naturally
>> with the model, and commit() whenever you like
>> - Excellent support in the newsgroup
>> Cons:
>> - Documentation (mostly the Wiki) is incomplete - so setting up the
>> basic framework is a bit tricky (but as stated above, newsgroup
>> support is excellent ;-))
> Apologies for that! I guess one reason that open source developers
> choose to work without being paid is that they are free to postpone
> documentation tasks as long as there are coding tasks in the list ;-)
I fully understand that - so no apology necessary :-)
I know loads of better things to do with my unpaid free time - so I
really acknowledge all the resources you (and Martin and all of the
other OSS developers) spend!

>> - Subjectively higher learning curve than with Teneo for setting up
>> the infrastructure
> Agreed. Do you think this is an implication of the incomplete
> documentation? Or do you have suggestions to simplify the setup?
I think it simply is a consequence of the more complex architecture. In
contrast to Teneo/Hibernate which only needs the Hibernate engine to be
initialized, which is done in 3 LOC, setting up the
client-server-infrastructure and establishing the communication between
both needs some more understanding of the underlying concepts (or a good
tutorial ;-)).
At the same time - as I am experiencing right now - a lot can go wrong
before you can commit your first EObject ...

So what is needed - as Thomas stated in another post - is a getting
started tutorial (maybe one for client-server scenario and one for my
case with the single-user approach) and a small knowledge base, which
lists some common errors (like mine) which can occur during the first steps.

Both things do not have to be written by you. As soon as I got my basic
code working over here, I am willing contribute a small tutorial to the
wiki - at least if you can say that the API is stable enough.

>> In a recent post, Martin stated, that he'll try to integrate Teneo
>> and CDO.
>> I think that would be the ultimate client-server ORM solution for EMF.
> Volunteers hands up ;-)
> Unfortunately Martin and I didn't have time so far to dig into this
> issue although we're both sure that this effort could deliver a great
> solution.
Well, I personally don't really need Hibernate support - I need the
lazy-loading-and-unloading properties which CDO provides.

Cheers,
Stefan
Re: Teneo or CDO? [message #110166 is a reply to message #110090] Wed, 30 January 2008 13:42 Go to previous messageGo to next message
Eclipse UserFriend
Originally posted by: stepper.sympedia.de

Stefan Winkler schrieb:
>
>>> - Subjectively higher learning curve than with Teneo for setting up
>>> the infrastructure
>> Agreed. Do you think this is an implication of the incomplete
>> documentation? Or do you have suggestions to simplify the setup?
> I think it simply is a consequence of the more complex architecture.
> In contrast to Teneo/Hibernate which only needs the Hibernate engine
> to be initialized, which is done in 3 LOC, setting up the
> client-server-infrastructure and establishing the communication
> between both needs some more understanding of the underlying concepts
> (or a good tutorial ;-)).
> At the same time - as I am experiencing right now - a lot can go wrong
> before you can commit your first EObject ...
>
> So what is needed - as Thomas stated in another post - is a getting
> started tutorial (maybe one for client-server scenario and one for my
> case with the single-user approach) and a small knowledge base, which
> lists some common errors (like mine) which can occur during the first
> steps.
>
> Both things do not have to be written by you. As soon as I got my
> basic code working over here, I am willing contribute a small tutorial
> to the wiki - at least if you can say that the API is stable enough.
That'd be most welcome ;-)
The API is quite stable although new features could change it (doesn't
affect users) or new IStore implementations (only effects other extenders).
From time to time I apply a bit of renaming or moving to enhance the
internal structure.
This is the benefit I take from not being allowed to publish a 1.0.0
release (Ed will want to comment on the word "allowed" ;-) )

>
>>> In a recent post, Martin stated, that he'll try to integrate Teneo
>>> and CDO.
>>> I think that would be the ultimate client-server ORM solution for EMF.
>> Volunteers hands up ;-)
>> Unfortunately Martin and I didn't have time so far to dig into this
>> issue although we're both sure that this effort could deliver a great
>> solution.
> Well, I personally don't really need Hibernate support - I need the
> lazy-loading-and-unloading properties which CDO provides.
Don't you even need any RDB store? May be a file based persistency
solution is adequate for you, too?
I already thought about providing such a store implementation which
would even be better aligned with modeling needs...

Regards,
Eike Stepper
----
http://wiki.eclipse.org/CDO
http://wiki.eclipse.org/Net4j
Re: Teneo or CDO? [message #111208 is a reply to message #110166] Thu, 31 January 2008 09:04 Go to previous messageGo to next message
Stefan Winkler is currently offline Stefan WinklerFriend
Messages: 307
Registered: July 2009
Location: Germany
Senior Member
Eike Stepper schrieb:
>> Well, I personally don't really need Hibernate support - I need the
>> lazy-loading-and-unloading properties which CDO provides.
> Don't you even need any RDB store? May be a file based persistency
> solution is adequate for you, too?
> I already thought about providing such a store implementation which
> would even be better aligned with modeling needs...
Basically, the only hard requirement I have is the ability to be able to
manage models as huge as several GB as transparently as possible.

I don't need revisions, client-server, multi-user or RDB, really.
(However, I have a feeling that an RDB would do a better job in keeping
that amount of data compared to files, but who knows. And as I am doing
research and want to do some statistical analysis of the outcome of my
experiments, I could do some quick SQL queries on the RDB to achieve
that which could save me some time later...).

Cheers,
Stefan
Re: Teneo or CDO? [message #111250 is a reply to message #111208] Thu, 31 January 2008 09:20 Go to previous message
Eclipse UserFriend
Originally posted by: stepper.sympedia.de

Stefan Winkler schrieb:
> Eike Stepper schrieb:
>>> Well, I personally don't really need Hibernate support - I need the
>>> lazy-loading-and-unloading properties which CDO provides.
>> Don't you even need any RDB store? May be a file based persistency
>> solution is adequate for you, too?
>> I already thought about providing such a store implementation which
>> would even be better aligned with modeling needs...
> Basically, the only hard requirement I have is the ability to be able
> to manage models as huge as several GB as transparently as possible.
>
> I don't need revisions, client-server, multi-user or RDB, really.
> (However, I have a feeling that an RDB would do a better job in
> keeping that amount of data compared to files, but who knows. And as I
> am doing research and want to do some statistical analysis of the
> outcome of my experiments, I could do some quick SQL queries on the
> RDB to achieve that which could save me some time later...).
Martin and I are making some progress on the Hibernate Store. Let's see
what that leads to ;-)

Regards,
Eike Stepper
----
http://wiki.eclipse.org/CDO
http://wiki.eclipse.org/Net4j
Re: Teneo or CDO? [message #614100 is a reply to message #108357] Sat, 26 January 2008 15:04 Go to previous message
Eike Stepper is currently offline Eike StepperFriend
Messages: 6682
Registered: July 2009
Senior Member
Hi Henrik,

I believe both CDO and Teneo solve some very similar problems and can be
what you're looking for.
As the author of CDO, what should I say? ;-)
You can find a feature list of CDO (and a bit more information) at
http://wiki.eclipse.org/CDO

What about evaluating both technologies and report your experiences here?!
That'd be very interesting.

Of course, if you have more detailed questions with respect to CDO, I'm
here ;-)

Regards,
Eike Stepper
----
http://wiki.eclipse.org/CDO
http://wiki.eclipse.org/Net4j




Henrik Jönsson schrieb:
> Hi,
>
> We have about 15 EMF models at the moment in our product that uses the
> default XMI persistance in EMF. Now we have requirements to let
> multiple user read and write in the same model instances. As I
> understand EMFT provides two solutions for this: CDO and Teneo.
>
> What are the differences between these two frameworks?
> Which framework would be "best" for us?
>
> Regards
>
> Henrik
>


Re: Teneo or CDO? [message #614106 is a reply to message #108449] Sun, 27 January 2008 11:42 Go to previous message
Martin Taal is currently offline Martin TaalFriend
Messages: 5468
Registered: July 2009
Senior Member
Hi Henrik,
My answer is very much the same as Eike's. Just check out both solutions (Teneo's can be found here:
http://www.elver.org) and see what fits best.

Teneo is very much focused on the mapping any type of model to a relational store. The mapping
support is very complete (imho) with support for most EMF constructs (for example, featuremaps,
mixed, etc.). Teneo offers a default mapping logic which you can easily override using jpa
annotations in the model or in a separate xml file.
See here for a more detailed listing of features:
http://www.elver.org/hibernate/features.html

Btw, it is on my wishlist to integrate CDO and Teneo combining the client-server layer of CDO/Net4j
with the relational mapping capabilities of Teneo. Until now I have not yet found the time to do so :-(.

gr. Martin

Eike Stepper wrote:
> Hi Henrik,
>
> I believe both CDO and Teneo solve some very similar problems and can be
> what you're looking for.
> As the author of CDO, what should I say? ;-)
> You can find a feature list of CDO (and a bit more information) at
> http://wiki.eclipse.org/CDO
>
> What about evaluating both technologies and report your experiences here?!
> That'd be very interesting.
>
> Of course, if you have more detailed questions with respect to CDO, I'm
> here ;-)
>
> Regards,
> Eike Stepper
> ----
> http://wiki.eclipse.org/CDO
> http://wiki.eclipse.org/Net4j
>
>
>
>
> Henrik Jönsson schrieb:
>> Hi,
>>
>> We have about 15 EMF models at the moment in our product that uses the
>> default XMI persistance in EMF. Now we have requirements to let
>> multiple user read and write in the same model instances. As I
>> understand EMFT provides two solutions for this: CDO and Teneo.
>>
>> What are the differences between these two frameworks?
>> Which framework would be "best" for us?
>>
>> Regards
>>
>> Henrik
>>


--

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 or CDO? [message #614148 is a reply to message #108357] Tue, 29 January 2008 14:35 Go to previous message
Stefan Winkler is currently offline Stefan WinklerFriend
Messages: 307
Registered: July 2009
Location: Germany
Senior Member
Hi,

I'll add a bit of a "neutral" voice to this thread.

*** disclaimer ***
I am only reporting from about one week personal playing with both CDO
and Teneo.
What I write here is my personal experience. This report is thus quite
subjective.
If I missed any feature or functionality or reported something wrong,
please, Eike, Martin, do correct me.
*** disclaimer end ***

A bit of personal motivation (just to clarify my environment and
requirements):
I want to build a research prototype which converts text-documents or
other more or less structured collections of text to models (like - e.g.
making one model-element "Paragraph" out of one text-paragraph with an
attribute "content") and then apply algorithms to them. I use models as
a common platform to apply my algorithms to texts of whichever format,
so models are a form of abstraction for me.

I quickly found out that working with huge models with EMF is a bit
problematic, because resources in EMF are atomar - i.e. you can only
load or unload a resource as a whole, not work with parts of it.
Additionally storing huge models in a database seemed to make more sense
than working with XMI files.

So I was pointed to EMFT Teneo and CDO.

I started playing around with Teneo/Hibernate.
Pros:
- Easy installable using update site
- Works almost out of the box with existing ecore-based model
- Storage Annotations can be added to the .genmodel
- Mapping is generated on the fly (but can also be changes as far as I
know, didn't try this out)
- Uses Hibernate -> can be used with lots of databases
- Tutorials and documentation at http://www.elver.org/hibernate/ are in
most parts usable for a quick start
- Lazy loading (not using EMF-proxies but Hibernate cglib proxies)
- Excellent support in the newsgroup
Cons:
- No client-server architecture (besides the db-server/-client - so you
have the eclipse application and the database server) - so I think no
mechanism to propagate changes between multiple concurrent users
- No re-proxying (you can't lazy-load your object-net and then throw
away part of that net while still keeping the other part) - this is
unsuitable for working with large models

Because of the last point I started playing around with CDO:
Pros:
- Client-Server architecture with change notifications between the
clients (didn't try that out)
- It's possible to put client and repository management into the same
application, so Client/Server is optional
- Lazy-loading and Lazy-unloading is possible (and is done
transparently, so no management needed for this).
- If the basic framework is set up, you can simply work naturally with
the model, and commit() whenever you like
- Excellent support in the newsgroup
Cons:
- Documentation (mostly the Wiki) is incomplete - so setting up the
basic framework is a bit tricky (but as stated above, newsgroup support
is excellent ;-))
- Subjectively higher learning curve than with Teneo for setting up the
infrastructure
- Only works with mysql, derby and hsqldb (as well as with a memory-only
store) - more to come (I think)
- No direct influence on the database mapping (some parameters for the
mapping strategy can be tuned)

Regarding performance, I can not make any statement, as I haven't tried
any of the technologies with huge models.

In one sentence I would characterize Teneo as an ORM-solution for EMF,
while CDO is a client-server architecture for EMF models.

In a recent post, Martin stated, that he'll try to integrate Teneo and CDO.
I think that would be the ultimate client-server ORM solution for EMF.

As stated above, these lists are very subjective and they are guaranteed
to be incomplete.
Maybe they are a starting point and I would like if other users of any
of both technologies could add to any of the lists.

Cheers
Stefan


Henrik Jönsson schrieb:
> Hi,
>
> We have about 15 EMF models at the moment in our product that uses the
> default XMI persistance in EMF. Now we have requirements to let
> multiple user read and write in the same model instances. As I
> understand EMFT provides two solutions for this: CDO and Teneo.
>
> What are the differences between these two frameworks?
> Which framework would be "best" for us?
>
> Regards
>
> Henrik
>
Re: Teneo or CDO? [message #614151 is a reply to message #109086] Tue, 29 January 2008 15:04 Go to previous message
Eike Stepper is currently offline Eike StepperFriend
Messages: 6682
Registered: July 2009
Senior Member
Stefan,

Thanks for your excellent (from my perspective) analysis!
More comments below...



Stefan Winkler schrieb:
> Hi,
>
> I'll add a bit of a "neutral" voice to this thread.
>
> *** disclaimer ***
> I am only reporting from about one week personal playing with both CDO
> and Teneo.
> What I write here is my personal experience. This report is thus quite
> subjective.
> If I missed any feature or functionality or reported something wrong,
> please, Eike, Martin, do correct me.
> *** disclaimer end ***
>
> A bit of personal motivation (just to clarify my environment and
> requirements):
> I want to build a research prototype which converts text-documents or
> other more or less structured collections of text to models (like -
> e.g. making one model-element "Paragraph" out of one text-paragraph
> with an attribute "content") and then apply algorithms to them. I use
> models as a common platform to apply my algorithms to texts of
> whichever format, so models are a form of abstraction for me.
>
> I quickly found out that working with huge models with EMF is a bit
> problematic, because resources in EMF are atomar - i.e. you can only
> load or unload a resource as a whole, not work with parts of it.
> Additionally storing huge models in a database seemed to make more
> sense than working with XMI files.
>
> So I was pointed to EMFT Teneo and CDO.
>
> I started playing around with Teneo/Hibernate.
> Pros:
> - Easy installable using update site
> - Works almost out of the box with existing ecore-based model
> - Storage Annotations can be added to the .genmodel
> - Mapping is generated on the fly (but can also be changes as far as I
> know, didn't try this out)
> - Uses Hibernate -> can be used with lots of databases
> - Tutorials and documentation at http://www.elver.org/hibernate/ are
> in most parts usable for a quick start
> - Lazy loading (not using EMF-proxies but Hibernate cglib proxies)
> - Excellent support in the newsgroup
> Cons:
> - No client-server architecture (besides the db-server/-client - so
> you have the eclipse application and the database server) - so I think
> no mechanism to propagate changes between multiple concurrent users
> - No re-proxying (you can't lazy-load your object-net and then throw
> away part of that net while still keeping the other part) - this is
> unsuitable for working with large models
>
> Because of the last point I started playing around with CDO:
> Pros:
> - Client-Server architecture with change notifications between the
> clients (didn't try that out)
> - It's possible to put client and repository management into the same
> application, so Client/Server is optional
> - Lazy-loading and Lazy-unloading is possible (and is done
> transparently, so no management needed for this).
> - If the basic framework is set up, you can simply work naturally with
> the model, and commit() whenever you like
> - Excellent support in the newsgroup
> Cons:
> - Documentation (mostly the Wiki) is incomplete - so setting up the
> basic framework is a bit tricky (but as stated above, newsgroup
> support is excellent ;-))
Apologies for that! I guess one reason that open source developers
choose to work without being paid is that they are free to postpone
documentation tasks as long as there are coding tasks in the list ;-)

> - Subjectively higher learning curve than with Teneo for setting up
> the infrastructure
Agreed. Do you think this is an implication of the incomplete
documentation? Or do you have suggestions to simplify the setup?

> - Only works with mysql, derby and hsqldb (as well as with a
> memory-only store) - more to come (I think)
Contributions of additional DB adapters are welcome ;-)

> - No direct influence on the database mapping (some parameters for the
> mapping strategy can be tuned)
>
> Regarding performance, I can not make any statement, as I haven't
> tried any of the technologies with huge models.
>
> In one sentence I would characterize Teneo as an ORM-solution for EMF,
> while CDO is a client-server architecture for EMF models.
I think this is a good summary.

>
> In a recent post, Martin stated, that he'll try to integrate Teneo and
> CDO.
> I think that would be the ultimate client-server ORM solution for EMF.
Volunteers hands up ;-)
Unfortunately Martin and I didn't have time so far to dig into this
issue although we're both sure that this effort could deliver a great
solution.

Regards,
Eike Stepper
----
http://wiki.eclipse.org/CDO
http://wiki.eclipse.org/Net4j


>
> As stated above, these lists are very subjective and they are
> guaranteed to be incomplete.
> Maybe they are a starting point and I would like if other users of any
> of both technologies could add to any of the lists.
>
> Cheers
> Stefan
>
>
> Henrik Jönsson schrieb:
>> Hi,
>>
>> We have about 15 EMF models at the moment in our product that uses
>> the default XMI persistance in EMF. Now we have requirements to let
>> multiple user read and write in the same model instances. As I
>> understand EMFT provides two solutions for this: CDO and Teneo.
>>
>> What are the differences between these two frameworks?
>> Which framework would be "best" for us?
>>
>> Regards
>>
>> Henrik
>>


Re: Teneo or CDO? [message #614153 is a reply to message #109126] Tue, 29 January 2008 15:27 Go to previous message
Martin Taal is currently offline Martin TaalFriend
Messages: 5468
Registered: July 2009
Senior Member
Hi Stefan,
Also from my point of view your post contains a balanced pro/con overview.
I am very interested in integrating Teneo with cdo. With Teneo I have/will never have the intention
to offer client-server functionality. On the other hand I see a clear requirement from Teneo users
for this functionality and CDO seems to me as a perfect solution to this.
Posts like yours and the others which appeared the past few days help to put this integration much
higher (somewhere around the top :-) of my priority list.

gr. Martin

Eike Stepper wrote:
> Stefan,
>
> Thanks for your excellent (from my perspective) analysis!
> More comments below...
>
>
>
> Stefan Winkler schrieb:
>> Hi,
>>
>> I'll add a bit of a "neutral" voice to this thread.
>>
>> *** disclaimer ***
>> I am only reporting from about one week personal playing with both CDO
>> and Teneo.
>> What I write here is my personal experience. This report is thus quite
>> subjective.
>> If I missed any feature or functionality or reported something wrong,
>> please, Eike, Martin, do correct me.
>> *** disclaimer end ***
>>
>> A bit of personal motivation (just to clarify my environment and
>> requirements):
>> I want to build a research prototype which converts text-documents or
>> other more or less structured collections of text to models (like -
>> e.g. making one model-element "Paragraph" out of one text-paragraph
>> with an attribute "content") and then apply algorithms to them. I use
>> models as a common platform to apply my algorithms to texts of
>> whichever format, so models are a form of abstraction for me.
>>
>> I quickly found out that working with huge models with EMF is a bit
>> problematic, because resources in EMF are atomar - i.e. you can only
>> load or unload a resource as a whole, not work with parts of it.
>> Additionally storing huge models in a database seemed to make more
>> sense than working with XMI files.
>>
>> So I was pointed to EMFT Teneo and CDO.
>>
>> I started playing around with Teneo/Hibernate.
>> Pros:
>> - Easy installable using update site
>> - Works almost out of the box with existing ecore-based model
>> - Storage Annotations can be added to the .genmodel
>> - Mapping is generated on the fly (but can also be changes as far as I
>> know, didn't try this out)
>> - Uses Hibernate -> can be used with lots of databases
>> - Tutorials and documentation at http://www.elver.org/hibernate/ are
>> in most parts usable for a quick start
>> - Lazy loading (not using EMF-proxies but Hibernate cglib proxies)
>> - Excellent support in the newsgroup
>> Cons:
>> - No client-server architecture (besides the db-server/-client - so
>> you have the eclipse application and the database server) - so I think
>> no mechanism to propagate changes between multiple concurrent users
>> - No re-proxying (you can't lazy-load your object-net and then throw
>> away part of that net while still keeping the other part) - this is
>> unsuitable for working with large models
>>
>> Because of the last point I started playing around with CDO:
>> Pros:
>> - Client-Server architecture with change notifications between the
>> clients (didn't try that out)
>> - It's possible to put client and repository management into the same
>> application, so Client/Server is optional
>> - Lazy-loading and Lazy-unloading is possible (and is done
>> transparently, so no management needed for this).
>> - If the basic framework is set up, you can simply work naturally with
>> the model, and commit() whenever you like
>> - Excellent support in the newsgroup
>> Cons:
>> - Documentation (mostly the Wiki) is incomplete - so setting up the
>> basic framework is a bit tricky (but as stated above, newsgroup
>> support is excellent ;-))
> Apologies for that! I guess one reason that open source developers
> choose to work without being paid is that they are free to postpone
> documentation tasks as long as there are coding tasks in the list ;-)
>
>> - Subjectively higher learning curve than with Teneo for setting up
>> the infrastructure
> Agreed. Do you think this is an implication of the incomplete
> documentation? Or do you have suggestions to simplify the setup?
>
>> - Only works with mysql, derby and hsqldb (as well as with a
>> memory-only store) - more to come (I think)
> Contributions of additional DB adapters are welcome ;-)
>
>> - No direct influence on the database mapping (some parameters for the
>> mapping strategy can be tuned)
>>
>> Regarding performance, I can not make any statement, as I haven't
>> tried any of the technologies with huge models.
>>
>> In one sentence I would characterize Teneo as an ORM-solution for EMF,
>> while CDO is a client-server architecture for EMF models.
> I think this is a good summary.
>
>>
>> In a recent post, Martin stated, that he'll try to integrate Teneo and
>> CDO.
>> I think that would be the ultimate client-server ORM solution for EMF.
> Volunteers hands up ;-)
> Unfortunately Martin and I didn't have time so far to dig into this
> issue although we're both sure that this effort could deliver a great
> solution.
>
> Regards,
> Eike Stepper
> ----
> http://wiki.eclipse.org/CDO
> http://wiki.eclipse.org/Net4j
>
>
>>
>> As stated above, these lists are very subjective and they are
>> guaranteed to be incomplete.
>> Maybe they are a starting point and I would like if other users of any
>> of both technologies could add to any of the lists.
>>
>> Cheers
>> Stefan
>>
>>
>> Henrik Jönsson schrieb:
>>> Hi,
>>>
>>> We have about 15 EMF models at the moment in our product that uses
>>> the default XMI persistance in EMF. Now we have requirements to let
>>> multiple user read and write in the same model instances. As I
>>> understand EMFT provides two solutions for this: CDO and Teneo.
>>>
>>> What are the differences between these two frameworks?
>>> Which framework would be "best" for us?
>>>
>>> Regards
>>>
>>> Henrik
>>>


--

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 or CDO? [message #614160 is a reply to message #109152] Tue, 29 January 2008 18:26 Go to previous message
Thomas is currently offline ThomasFriend
Messages: 151
Registered: July 2009
Senior Member
HI Martin,

I only came across CDO this morning and it seems to be what I didnt know
that I want it so much. As with the others teneo integration is whats
missing the most. Why create another database mapping solution when
hibernate is around and so well supported. (this is what i dislike on
cdo most at the first glance) I will dive into CDO the next days as Im
currently off project and have some time to do so. WHat I think we have
to look at is the following: hibernate does its lazy loading through its
own custom proxies. I will have to see how it is done with cdo. I
remember I saw some implementation of custom lazy loading with remote
ejbs strategy on the hibernate wiki

http://www.hibernate.org/377.html



but i wonder how this would go with cdo. cdo has its own proxies, so we
would have to teach hibernate to use those and put a tuplizer in the
hibernate mapping. dont know if this is so easy and what would be the
best way.

I havent seen much of the CDO implementation, but I think at least this
should be possible to achieve without too much trouble.



Martin Taal schrieb:
> Hi Stefan,
> Also from my point of view your post contains a balanced pro/con overview.
> I am very interested in integrating Teneo with cdo. With Teneo I
> have/will never have the intention to offer client-server functionality.
> On the other hand I see a clear requirement from Teneo users for this
> functionality and CDO seems to me as a perfect solution to this.
> Posts like yours and the others which appeared the past few days help to
> put this integration much higher (somewhere around the top :-) of my
> priority list.
>
> gr. Martin
>
> Eike Stepper wrote:
>> Stefan,
>>
>> Thanks for your excellent (from my perspective) analysis!
>> More comments below...
>>
>>
>>
>> Stefan Winkler schrieb:
>>> Hi,
>>>
>>> I'll add a bit of a "neutral" voice to this thread.
>>>
>>> *** disclaimer ***
>>> I am only reporting from about one week personal playing with both
>>> CDO and Teneo.
>>> What I write here is my personal experience. This report is thus
>>> quite subjective.
>>> If I missed any feature or functionality or reported something wrong,
>>> please, Eike, Martin, do correct me.
>>> *** disclaimer end ***
>>>
>>> A bit of personal motivation (just to clarify my environment and
>>> requirements):
>>> I want to build a research prototype which converts text-documents or
>>> other more or less structured collections of text to models (like -
>>> e.g. making one model-element "Paragraph" out of one text-paragraph
>>> with an attribute "content") and then apply algorithms to them. I use
>>> models as a common platform to apply my algorithms to texts of
>>> whichever format, so models are a form of abstraction for me.
>>>
>>> I quickly found out that working with huge models with EMF is a bit
>>> problematic, because resources in EMF are atomar - i.e. you can only
>>> load or unload a resource as a whole, not work with parts of it.
>>> Additionally storing huge models in a database seemed to make more
>>> sense than working with XMI files.
>>>
>>> So I was pointed to EMFT Teneo and CDO.
>>>
>>> I started playing around with Teneo/Hibernate.
>>> Pros:
>>> - Easy installable using update site
>>> - Works almost out of the box with existing ecore-based model
>>> - Storage Annotations can be added to the .genmodel
>>> - Mapping is generated on the fly (but can also be changes as far as
>>> I know, didn't try this out)
>>> - Uses Hibernate -> can be used with lots of databases
>>> - Tutorials and documentation at http://www.elver.org/hibernate/ are
>>> in most parts usable for a quick start
>>> - Lazy loading (not using EMF-proxies but Hibernate cglib proxies)
>>> - Excellent support in the newsgroup
>>> Cons:
>>> - No client-server architecture (besides the db-server/-client - so
>>> you have the eclipse application and the database server) - so I
>>> think no mechanism to propagate changes between multiple concurrent
>>> users
>>> - No re-proxying (you can't lazy-load your object-net and then throw
>>> away part of that net while still keeping the other part) - this is
>>> unsuitable for working with large models
>>>
>>> Because of the last point I started playing around with CDO:
>>> Pros:
>>> - Client-Server architecture with change notifications between the
>>> clients (didn't try that out)
>>> - It's possible to put client and repository management into the same
>>> application, so Client/Server is optional
>>> - Lazy-loading and Lazy-unloading is possible (and is done
>>> transparently, so no management needed for this).
>>> - If the basic framework is set up, you can simply work naturally
>>> with the model, and commit() whenever you like
>>> - Excellent support in the newsgroup
>>> Cons:
>>> - Documentation (mostly the Wiki) is incomplete - so setting up the
>>> basic framework is a bit tricky (but as stated above, newsgroup
>>> support is excellent ;-))
>> Apologies for that! I guess one reason that open source developers
>> choose to work without being paid is that they are free to postpone
>> documentation tasks as long as there are coding tasks in the list ;-)
>>
>>> - Subjectively higher learning curve than with Teneo for setting up
>>> the infrastructure
>> Agreed. Do you think this is an implication of the incomplete
>> documentation? Or do you have suggestions to simplify the setup?
>>
>>> - Only works with mysql, derby and hsqldb (as well as with a
>>> memory-only store) - more to come (I think)
>> Contributions of additional DB adapters are welcome ;-)
>>
>>> - No direct influence on the database mapping (some parameters for
>>> the mapping strategy can be tuned)
>>>
>>> Regarding performance, I can not make any statement, as I haven't
>>> tried any of the technologies with huge models.
>>>
>>> In one sentence I would characterize Teneo as an ORM-solution for EMF,
>>> while CDO is a client-server architecture for EMF models.
>> I think this is a good summary.
>>
>>>
>>> In a recent post, Martin stated, that he'll try to integrate Teneo
>>> and CDO.
>>> I think that would be the ultimate client-server ORM solution for EMF.
>> Volunteers hands up ;-)
>> Unfortunately Martin and I didn't have time so far to dig into this
>> issue although we're both sure that this effort could deliver a great
>> solution.
>>
>> Regards,
>> Eike Stepper
>> ----
>> http://wiki.eclipse.org/CDO
>> http://wiki.eclipse.org/Net4j
>>
>>
>>>
>>> As stated above, these lists are very subjective and they are
>>> guaranteed to be incomplete.
>>> Maybe they are a starting point and I would like if other users of
>>> any of both technologies could add to any of the lists.
>>>
>>> Cheers
>>> Stefan
>>>
>>>
>>> Henrik Jönsson schrieb:
>>>> Hi,
>>>>
>>>> We have about 15 EMF models at the moment in our product that uses
>>>> the default XMI persistance in EMF. Now we have requirements to let
>>>> multiple user read and write in the same model instances. As I
>>>> understand EMFT provides two solutions for this: CDO and Teneo.
>>>>
>>>> What are the differences between these two frameworks?
>>>> Which framework would be "best" for us?
>>>>
>>>> Regards
>>>>
>>>> Henrik
>>>>
>
>
Re: Teneo or CDO? [message #614303 is a reply to message #109126] Wed, 30 January 2008 13:22 Go to previous message
Stefan Winkler is currently offline Stefan WinklerFriend
Messages: 307
Registered: July 2009
Location: Germany
Senior Member
Hi Eike,

comments below ...


Eike Stepper schrieb:
> Stefan,
>
> Thanks for your excellent (from my perspective) analysis!
> More comments below...
>
>
>
> Stefan Winkler schrieb:
>> Hi,
>>
>> I'll add a bit of a "neutral" voice to this thread.
>>
>> *** disclaimer ***
>> I am only reporting from about one week personal playing with both
>> CDO and Teneo.
>> What I write here is my personal experience. This report is thus
>> quite subjective.
>> If I missed any feature or functionality or reported something wrong,
>> please, Eike, Martin, do correct me.
>> *** disclaimer end ***
>>
>> A bit of personal motivation (just to clarify my environment and
>> requirements):
>> I want to build a research prototype which converts text-documents or
>> other more or less structured collections of text to models (like -
>> e.g. making one model-element "Paragraph" out of one text-paragraph
>> with an attribute "content") and then apply algorithms to them. I use
>> models as a common platform to apply my algorithms to texts of
>> whichever format, so models are a form of abstraction for me.
>>
>> I quickly found out that working with huge models with EMF is a bit
>> problematic, because resources in EMF are atomar - i.e. you can only
>> load or unload a resource as a whole, not work with parts of it.
>> Additionally storing huge models in a database seemed to make more
>> sense than working with XMI files.
>>
>> So I was pointed to EMFT Teneo and CDO.
>>
>> I started playing around with Teneo/Hibernate.
>> Pros:
>> - Easy installable using update site
>> - Works almost out of the box with existing ecore-based model
>> - Storage Annotations can be added to the .genmodel
>> - Mapping is generated on the fly (but can also be changes as far as
>> I know, didn't try this out)
>> - Uses Hibernate -> can be used with lots of databases
>> - Tutorials and documentation at http://www.elver.org/hibernate/ are
>> in most parts usable for a quick start
>> - Lazy loading (not using EMF-proxies but Hibernate cglib proxies)
>> - Excellent support in the newsgroup
>> Cons:
>> - No client-server architecture (besides the db-server/-client - so
>> you have the eclipse application and the database server) - so I
>> think no mechanism to propagate changes between multiple concurrent
>> users
>> - No re-proxying (you can't lazy-load your object-net and then throw
>> away part of that net while still keeping the other part) - this is
>> unsuitable for working with large models
>>
>> Because of the last point I started playing around with CDO:
>> Pros:
>> - Client-Server architecture with change notifications between the
>> clients (didn't try that out)
>> - It's possible to put client and repository management into the same
>> application, so Client/Server is optional
>> - Lazy-loading and Lazy-unloading is possible (and is done
>> transparently, so no management needed for this).
>> - If the basic framework is set up, you can simply work naturally
>> with the model, and commit() whenever you like
>> - Excellent support in the newsgroup
>> Cons:
>> - Documentation (mostly the Wiki) is incomplete - so setting up the
>> basic framework is a bit tricky (but as stated above, newsgroup
>> support is excellent ;-))
> Apologies for that! I guess one reason that open source developers
> choose to work without being paid is that they are free to postpone
> documentation tasks as long as there are coding tasks in the list ;-)
I fully understand that - so no apology necessary :-)
I know loads of better things to do with my unpaid free time - so I
really acknowledge all the resources you (and Martin and all of the
other OSS developers) spend!

>> - Subjectively higher learning curve than with Teneo for setting up
>> the infrastructure
> Agreed. Do you think this is an implication of the incomplete
> documentation? Or do you have suggestions to simplify the setup?
I think it simply is a consequence of the more complex architecture. In
contrast to Teneo/Hibernate which only needs the Hibernate engine to be
initialized, which is done in 3 LOC, setting up the
client-server-infrastructure and establishing the communication between
both needs some more understanding of the underlying concepts (or a good
tutorial ;-)).
At the same time - as I am experiencing right now - a lot can go wrong
before you can commit your first EObject ...

So what is needed - as Thomas stated in another post - is a getting
started tutorial (maybe one for client-server scenario and one for my
case with the single-user approach) and a small knowledge base, which
lists some common errors (like mine) which can occur during the first steps.

Both things do not have to be written by you. As soon as I got my basic
code working over here, I am willing contribute a small tutorial to the
wiki - at least if you can say that the API is stable enough.

>> In a recent post, Martin stated, that he'll try to integrate Teneo
>> and CDO.
>> I think that would be the ultimate client-server ORM solution for EMF.
> Volunteers hands up ;-)
> Unfortunately Martin and I didn't have time so far to dig into this
> issue although we're both sure that this effort could deliver a great
> solution.
Well, I personally don't really need Hibernate support - I need the
lazy-loading-and-unloading properties which CDO provides.

Cheers,
Stefan
Re: Teneo or CDO? [message #614319 is a reply to message #110090] Wed, 30 January 2008 13:42 Go to previous message
Eike Stepper is currently offline Eike StepperFriend
Messages: 6682
Registered: July 2009
Senior Member
Stefan Winkler schrieb:
>
>>> - Subjectively higher learning curve than with Teneo for setting up
>>> the infrastructure
>> Agreed. Do you think this is an implication of the incomplete
>> documentation? Or do you have suggestions to simplify the setup?
> I think it simply is a consequence of the more complex architecture.
> In contrast to Teneo/Hibernate which only needs the Hibernate engine
> to be initialized, which is done in 3 LOC, setting up the
> client-server-infrastructure and establishing the communication
> between both needs some more understanding of the underlying concepts
> (or a good tutorial ;-)).
> At the same time - as I am experiencing right now - a lot can go wrong
> before you can commit your first EObject ...
>
> So what is needed - as Thomas stated in another post - is a getting
> started tutorial (maybe one for client-server scenario and one for my
> case with the single-user approach) and a small knowledge base, which
> lists some common errors (like mine) which can occur during the first
> steps.
>
> Both things do not have to be written by you. As soon as I got my
> basic code working over here, I am willing contribute a small tutorial
> to the wiki - at least if you can say that the API is stable enough.
That'd be most welcome ;-)
The API is quite stable although new features could change it (doesn't
affect users) or new IStore implementations (only effects other extenders).
From time to time I apply a bit of renaming or moving to enhance the
internal structure.
This is the benefit I take from not being allowed to publish a 1.0.0
release (Ed will want to comment on the word "allowed" ;-) )

>
>>> In a recent post, Martin stated, that he'll try to integrate Teneo
>>> and CDO.
>>> I think that would be the ultimate client-server ORM solution for EMF.
>> Volunteers hands up ;-)
>> Unfortunately Martin and I didn't have time so far to dig into this
>> issue although we're both sure that this effort could deliver a great
>> solution.
> Well, I personally don't really need Hibernate support - I need the
> lazy-loading-and-unloading properties which CDO provides.
Don't you even need any RDB store? May be a file based persistency
solution is adequate for you, too?
I already thought about providing such a store implementation which
would even be better aligned with modeling needs...

Regards,
Eike Stepper
----
http://wiki.eclipse.org/CDO
http://wiki.eclipse.org/Net4j


Re: Teneo or CDO? [message #614362 is a reply to message #110166] Thu, 31 January 2008 09:04 Go to previous message
Stefan Winkler is currently offline Stefan WinklerFriend
Messages: 307
Registered: July 2009
Location: Germany
Senior Member
Eike Stepper schrieb:
>> Well, I personally don't really need Hibernate support - I need the
>> lazy-loading-and-unloading properties which CDO provides.
> Don't you even need any RDB store? May be a file based persistency
> solution is adequate for you, too?
> I already thought about providing such a store implementation which
> would even be better aligned with modeling needs...
Basically, the only hard requirement I have is the ability to be able to
manage models as huge as several GB as transparently as possible.

I don't need revisions, client-server, multi-user or RDB, really.
(However, I have a feeling that an RDB would do a better job in keeping
that amount of data compared to files, but who knows. And as I am doing
research and want to do some statistical analysis of the outcome of my
experiments, I could do some quick SQL queries on the RDB to achieve
that which could save me some time later...).

Cheers,
Stefan
Re: Teneo or CDO? [message #614368 is a reply to message #111208] Thu, 31 January 2008 09:20 Go to previous message
Eike Stepper is currently offline Eike StepperFriend
Messages: 6682
Registered: July 2009
Senior Member
Stefan Winkler schrieb:
> Eike Stepper schrieb:
>>> Well, I personally don't really need Hibernate support - I need the
>>> lazy-loading-and-unloading properties which CDO provides.
>> Don't you even need any RDB store? May be a file based persistency
>> solution is adequate for you, too?
>> I already thought about providing such a store implementation which
>> would even be better aligned with modeling needs...
> Basically, the only hard requirement I have is the ability to be able
> to manage models as huge as several GB as transparently as possible.
>
> I don't need revisions, client-server, multi-user or RDB, really.
> (However, I have a feeling that an RDB would do a better job in
> keeping that amount of data compared to files, but who knows. And as I
> am doing research and want to do some statistical analysis of the
> outcome of my experiments, I could do some quick SQL queries on the
> RDB to achieve that which could save me some time later...).
Martin and I are making some progress on the Hibernate Store. Let's see
what that leads to ;-)

Regards,
Eike Stepper
----
http://wiki.eclipse.org/CDO
http://wiki.eclipse.org/Net4j


Previous Topic:CDO standalone
Next Topic:[CDO] examples question
Goto Forum:
  


Current Time: Fri Mar 29 07:36:24 GMT 2024

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

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

Back to the top