Eclipse Community Forums: EMF "Technology" (Ecore Tools, EMFatic, etc)

Help

Home

Home » Modeling » EMF "Technology" (Ecore Tools, EMFatic, etc) » Client server EMF?

Show: Today's Messages :: Show Polls :: Message Navigator

Client server EMF? [message #113526]

Thu, 28 February 2008 14:38

Henrik önsson

Messages: 53
Registered: July 2009

Member

Hi,

I have an requirement from my users to allow multiple users to
read/write/update/delete objects from the same EMF models. I have written
some posts about this eariler, but I don't fully understand what I need to
do.

When I first read about Teneo a year ago or so I thought this was the
perfect choice. It uses Hibernate in the bottom for the actual database
interface. I didn't understand what problems CDO solved. The documentation
for CDO was kind of thin (which I understand).

Now when I try to understand more about this, I think CDO is better suited
for my needs. Teneo is not meant to be used in a client/server scenario
(although some users seems to do this). I have also read in the newsgroup
about a new Hibernate integration in CDO.

Here are some typical scenarios I need to support:
1) We have mostly table based editor (customised from the generated EMF
editor plugin). User A opens the table editor on the routes model. User B
also opens up the same instance of the table editor on the routes model.
User A changes the attribute routeId on a object and saves the model. Now
I would like that the instance user B has opened gets refreshed so that
user A's change is populated from user A to user B.

2) User A opens the table editor on the routes model. User B also opens up
the same instance of the table editor on the routes model. User A changes
the attribute routeId on a object. User B would like to change the same
attribute (before his model is refreshed). Now I would like that the B
has is informed that another user has updated this attribute and user B
changes will be lost. I.e. some kind of locking scenario.

My questions:
* Can someone help me explain if these scenarios can be implemented in
Teneo or CDO or something else?
* What do I need to implement for myself, and what do I get for "free"
from the frameworks?
* As I understand CDO is better on client server scenarios. What features
does Teneo lack that makes CDO better on this?
* I would like to use PostgreSQL. Hibernate has of course support on this,
but CDO don't. Is the "new" CDO/Hibernate integration in a state where I
can test it?

Thanks for your help!

Regards

Henrik

Report message to a moderator

Re: Client server EMF? [message #113539 is a reply to message #113526]

Thu, 28 February 2008 19:32

Eike Stepper

Messages: 6682
Registered: July 2009

Senior Member

Hi Henrik,

Comments below...

Henrik wrote:

> Hi,

> I have an requirement from my users to allow multiple users to
> read/write/update/delete objects from the same EMF models. I have written
> some posts about this eariler, but I don't fully understand what I need to
> do.

> When I first read about Teneo a year ago or so I thought this was the
> perfect choice. It uses Hibernate in the bottom for the actual database
> interface. I didn't understand what problems CDO solved. The documentation
> for CDO was kind of thin (which I understand).

> Now when I try to understand more about this, I think CDO is better suited
> for my needs. Teneo is not meant to be used in a client/server scenario
> (although some users seems to do this). I have also read in the newsgroup
> about a new Hibernate integration in CDO.

> Here are some typical scenarios I need to support:
> 1) We have mostly table based editor (customised from the generated EMF
> editor plugin). User A opens the table editor on the routes model. User B
> also opens up the same instance of the table editor on the routes model.
> User A changes the attribute routeId on a object and saves the model. Now
> I would like that the instance user B has opened gets refreshed so that
> user A's change is populated from user A to user B.

> 2) User A opens the table editor on the routes model. User B also opens up
> the same instance of the table editor on the routes model. User A changes
> the attribute routeId on a object. User B would like to change the same
> attribute (before his model is refreshed). Now I would like that the B
> has is informed that another user has updated this attribute and user B
> changes will be lost. I.e. some kind of locking scenario.

> My questions:
> * Can someone help me explain if these scenarios can be implemented in
> Teneo or CDO or something else?

Both of these scenarios are supported by CDO, it is a distributed shared
model with exactly the semantics that you explain/require.

> * What do I need to implement for myself, and what do I get for "free"
> from the frameworks?

With CDO you shouldn't be forced to do much yourself. Maybe you would have
to apply some changes to the CDOEditor (if you want to use it) to support
tables, since I deactivated the multipage support.

> * As I understand CDO is better on client server scenarios. What features
> does Teneo lack that makes CDO better on this?

Short answer: It lacks client/server capabilities ;-)
Sorry for the joke, but maybe Martin wants to elaborate on this...

> * I would like to use PostgreSQL. Hibernate has of course support on this,
> but CDO don't. Is the "new" CDO/Hibernate integration in a state where I
> can test it?

Postgresql integration for CDO should be quite easy. So far nobody has
asked for it. If you have tested CDO with one of the provided db adapters
(derby, hsqldb, mysql) and have the feeling that you like CDO, I could
quickly provide a Postgresql adapter as well.

The hibernate support is (thanks to Martins' recent efforts) quite
progressed. We can already commit resources and load them again. I don't
believe that it's finished or even ready to be used for testing, since we
started with some simplifications that have to be done properly now. After
my initial preparation work I'm mostly assisting Martin at the moment. So
may be he has more to say about the status.

As far as I can forsee at the moment there will be some major pros/cons
with the hibernate integration:

pros: hibernate is much more mature and tested than the CDO native
mapping. It's (quasi-) standards based which seems to be what many people
want. And the mapping itself is much more influenceable which is what
people need who work with existing dbs.

cons: It seems as if there will remain some features of the CDO framework
which are not possible (or at least very hard) to implement with
hibernate, i.e. partial collection loading over the network, retrieval of
historical state (audit views), storage of change deltas (what the CDO
native store could do, but doesn't do at the moment).

I hope this sheds some light on CDO and Hibernate.

Cheers
/Eike

> Thanks for your help!

> Regards

> Henrik

Cheers
/Eike

----
http://www.esc-net.de
http://thegordian.blogspot.com
http://twitter.com/eikestepper

Report message to a moderator

Re: Client server EMF? [message #113553 is a reply to message #113539]

Fri, 29 February 2008 06:01

Martin Taal

Messages: 5468
Registered: July 2009

Senior Member

Hi Henrik,
Teneo maps emf models to hibernate (or jdo) and offers a single-server runtime for emf-hibernate
(and emf-jpox). So it is not a client-server solution and therefore does not have client-server
functionality. On the other hand Teneo can be used as part of a client-server solution. Other users
have developed there own client-server functionality and incorporated Teneo in this. Or you can use
Teneo in web-apps or web service environments.
Together with Eike I am integrating Teneo with CDO and developing a cdo-hibernate integration. So
this is also an example where Teneo is integrated into other functionality.

Teneo is complete in its support of ecore models (incl. featuremaps). Not all of these features will
be present (initially) in the cdo-hibernate-teneo integration. But a standard model with inheritance
and (bi-directional) associations should work fine.

The current status is that the cdo-hibernate integration is working (can persist and read with
dates, strings and one-to-many and many-to-one associations). We need to spend some extra time on
testing delete/update scenarios and on ease-of-use and some documentation. The target is to release
this for EclipseCon and that is very feasible. You can see the current work in the hibernate folder
of the cdo cvs repository.

gr. Martin

Eike Stepper wrote:
> Hi Henrik,
>
> Comments below...
>
>
>
> Henrik wrote:
>
>> Hi,
>
>> I have an requirement from my users to allow multiple users to
>> read/write/update/delete objects from the same EMF models. I have
>> written some posts about this eariler, but I don't fully understand
>> what I need to do.
>
>> When I first read about Teneo a year ago or so I thought this was the
>> perfect choice. It uses Hibernate in the bottom for the actual
>> database interface. I didn't understand what problems CDO solved. The
>> documentation for CDO was kind of thin (which I understand).
>
>> Now when I try to understand more about this, I think CDO is better
>> suited for my needs. Teneo is not meant to be used in a client/server
>> scenario (although some users seems to do this). I have also read in
>> the newsgroup about a new Hibernate integration in CDO.
>
>> Here are some typical scenarios I need to support:
>> 1) We have mostly table based editor (customised from the generated
>> EMF editor plugin). User A opens the table editor on the routes model.
>> User B also opens up the same instance of the table editor on the
>> routes model. User A changes the attribute routeId on a object and
>> saves the model. Now I would like that the instance user B has opened
>> gets refreshed so that user A's change is populated from user A to
>> user B.
>
>> 2) User A opens the table editor on the routes model. User B also
>> opens up the same instance of the table editor on the routes model.
>> User A changes the attribute routeId on a object. User B would like to
>> change the same attribute (before his model is refreshed). Now I
>> would like that the B has is informed that another user has updated
>> this attribute and user B changes will be lost. I.e. some kind of
>> locking scenario.
>
>> My questions:
>> * Can someone help me explain if these scenarios can be implemented in
>> Teneo or CDO or something else?
>
> Both of these scenarios are supported by CDO, it is a distributed shared
> model with exactly the semantics that you explain/require.
>
>> * What do I need to implement for myself, and what do I get for "free"
>> from the frameworks?
>
> With CDO you shouldn't be forced to do much yourself. Maybe you would
> have to apply some changes to the CDOEditor (if you want to use it) to
> support tables, since I deactivated the multipage support.
>
>> * As I understand CDO is better on client server scenarios. What
>> features does Teneo lack that makes CDO better on this?
>
> Short answer: It lacks client/server capabilities ;-)
> Sorry for the joke, but maybe Martin wants to elaborate on this...
>
>> * I would like to use PostgreSQL. Hibernate has of course support on
>> this, but CDO don't. Is the "new" CDO/Hibernate integration in a state
>> where I can test it?
>
> Postgresql integration for CDO should be quite easy. So far nobody has
> asked for it. If you have tested CDO with one of the provided db
> adapters (derby, hsqldb, mysql) and have the feeling that you like CDO,
> I could quickly provide a Postgresql adapter as well.
>
> The hibernate support is (thanks to Martins' recent efforts) quite
> progressed. We can already commit resources and load them again. I don't
> believe that it's finished or even ready to be used for testing, since
> we started with some simplifications that have to be done properly now.
> After my initial preparation work I'm mostly assisting Martin at the
> moment. So may be he has more to say about the status.
>
> As far as I can forsee at the moment there will be some major pros/cons
> with the hibernate integration:
>
> pros: hibernate is much more mature and tested than the CDO native
> mapping. It's (quasi-) standards based which seems to be what many
> people want. And the mapping itself is much more influenceable which is
> what people need who work with existing dbs.
>
> cons: It seems as if there will remain some features of the CDO
> framework which are not possible (or at least very hard) to implement
> with hibernate, i.e. partial collection loading over the network,
> retrieval of historical state (audit views), storage of change deltas
> (what the CDO native store could do, but doesn't do at the moment).
>
>
> I hope this sheds some light on CDO and Hibernate.
>
> Cheers
> /Eike
>
>
>
>> Thanks for your help!
>
>> 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

Report message to a moderator