Skip to main content


Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Modeling » EMF » [CDO] Explicit locking / Changes to EPackages
[CDO] Explicit locking / Changes to EPackages [message #422813] Tue, 16 September 2008 09:55 Go to next message
Jasper is currently offline JasperFriend
Messages: 84
Registered: July 2009
Member
Just for discussion, there are two features that I believe CDO does not
have that I'd like to put out here, to get some feedback.

1. Explicit locking: Something like a method #lock()/#unlock() in the
CDOObject interface, allowing the caller to flag an object as not
editable by any users other than him/her. Whenever another user
committed a tx affecting the object, s/he would receive a
CdoObjectLockedException and his tx would roll back.

2. Support for changes to EPackages, especially dynamic ones: say I add
an EAttribute to an EClass, would be great if CDO picked up on that,
added a column to the table, and could keep going without a database
re-write. In the simple case of an addition of a feature or a class, it
seems doable to me: if there is a difference between the Ecore xml in
the database and that in the EPackage being registered, the new features
can be found and added.

Btw, currently plain EClass names are used as table names. Wouldn't it
be better to prepend the package name? Currently two EClasses with the
same name, but with different features, can't coexist.

Thanks,
Jasper.
Re: [CDO] Explicit locking / Changes to EPackages [message #422815 is a reply to message #422813] Tue, 16 September 2008 10:17 Go to previous messageGo to next message
Ed Merks is currently offline Ed MerksFriend
Messages: 31494
Registered: July 2009
Senior Member
Jasper,

Comments below.

Jasper wrote:
> Just for discussion, there are two features that I believe CDO does
> not have that I'd like to put out here, to get some feedback.
>
> 1. Explicit locking: Something like a method #lock()/#unlock() in the
> CDOObject interface, allowing the caller to flag an object as not
> editable by any users other than him/her. Whenever another user
> committed a tx affecting the object, s/he would receive a
> CdoObjectLockedException and his tx would roll back.
This relates somewhat to
https://bugs.eclipse.org/bugs/show_bug.cgi?id=247130. One tricky aspect
to the desire to veto updates that Eike and I discussed a few days ago
is that during the process of updating a bidirectional reference as many
as 6 different pointer swizzles involving as many 4 different objects
are involved. A veto part way through the process is very difficult to
address. As long as all the ends involved have the same notion of what
should be vetoed, it's not a problem... A cross document bidirectional
reference where one of the two documents is read-only is problematic
when edited from the writable side...
>
> 2. Support for changes to EPackages, especially dynamic ones: say I
> add an EAttribute to an EClass, would be great if CDO picked up on
> that, added a column to the table, and could keep going without a
> database re-write.
How dynamic is this? While the model is live and instances exist? Not
even Java with hot replace supports such a thing...
> In the simple case of an addition of a feature or a class, it seems
> doable to me: if there is a difference between the Ecore xml in the
> database and that in the EPackage being registered, the new features
> can be found and added.
If you're not expecting live objects to grow, it seems okay...
>
> Btw, currently plain EClass names are used as table names. Wouldn't it
> be better to prepend the package name? Currently two EClasses with the
> same name, but with different features, can't coexist.
I think Teneo addresses such issues fully...
>
>
> Thanks,
> Jasper.


Ed Merks
Professional Support: https://www.macromodeling.com/
Re: [CDO] Explicit locking / Changes to EPackages [message #422816 is a reply to message #422813] Tue, 16 September 2008 10:21 Go to previous messageGo to next message
Eike Stepper is currently offline Eike StepperFriend
Messages: 6509
Registered: July 2009
Senior Member
Jasper schrieb:
> Just for discussion, there are two features that I believe CDO does
> not have that I'd like to put out here, to get some feedback.
>
> 1. Explicit locking: Something like a method #lock()/#unlock() in the
> CDOObject interface, allowing the caller to flag an object as not
> editable by any users other than him/her. Whenever another user
> committed a tx affecting the object, s/he would receive a
> CdoObjectLockedException and his tx would roll back.
Although I have some concerns with making this a default capability of a
CDO repository I think the idea is worth being discussed in a Bugzilla ;-)

>
> 2. Support for changes to EPackages, especially dynamic ones: say I
> add an EAttribute to an EClass, would be great if CDO picked up on
> that, added a column to the table, and could keep going without a
> database re-write. In the simple case of an addition of a feature or a
> class, it seems doable to me: if there is a difference between the
> Ecore xml in the database and that in the EPackage being registered,
> the new features can be found and added.
This topic has been discussed several times, for example search the web
for "model-evolution CDO".
I always thought this is a cool feature but it'd be *very* hard to
implement correctly, particularly because CDO supports
recording/accessing historical states of the model instances!
I don't see a possibility to add this feature anytime soon. If you're
willing to discuss technical details and contribute major effort please
feel free to file a Bugzilla.

>
> Btw, currently plain EClass names are used as table names. Wouldn't it
> be better to prepend the package name? Currently two EClasses with the
> same name, but with different features, can't coexist.
In the DBStore or the HibernateStore?
For the DBStore I would not mind an enhancement request and for the
HibernateStore I'd suggest to talk to Martin first.

Cheers
/Eike


Re: [CDO] Explicit locking / Changes to EPackages [message #422819 is a reply to message #422816] Tue, 16 September 2008 11:09 Go to previous messageGo to next message
Jasper is currently offline JasperFriend
Messages: 84
Registered: July 2009
Member
Ed, Eike,

Thanks for your quick responses. I've opened enhancement requests for
the locking issue and the class-name conflicts:

http://bugs.eclipse.org/247427
http://bugs.eclipse.org/247428

Regarding the class-name conflicts and prefixes to address it, I'm
talking about the DBStore. The HibernateStore may or may not address
this problem, but it's unusable to me because it doesn't keep a revision
history..

On the matter of model-evolution CDO, I'm not concerned about live
objects. If it's a requirement for all sessions to be closed for a
change to an EPackage, that doesn't bother me. It's really about the
database. Domain models inevitably evolve, and it's undesirable to
dispatch a DBA to manually fix things. On the other hand, I realize that
indeed it's a hard problem. Will sleep on it before I submit an
enhancement request ;-)

Thanks guys,
Jasper.



Eike Stepper wrote:
> Jasper schrieb:
>> Just for discussion, there are two features that I believe CDO does
>> not have that I'd like to put out here, to get some feedback.
>>
>> 1. Explicit locking: Something like a method #lock()/#unlock() in the
>> CDOObject interface, allowing the caller to flag an object as not
>> editable by any users other than him/her. Whenever another user
>> committed a tx affecting the object, s/he would receive a
>> CdoObjectLockedException and his tx would roll back.
> Although I have some concerns with making this a default capability of a
> CDO repository I think the idea is worth being discussed in a Bugzilla ;-)
>
>>
>> 2. Support for changes to EPackages, especially dynamic ones: say I
>> add an EAttribute to an EClass, would be great if CDO picked up on
>> that, added a column to the table, and could keep going without a
>> database re-write. In the simple case of an addition of a feature or a
>> class, it seems doable to me: if there is a difference between the
>> Ecore xml in the database and that in the EPackage being registered,
>> the new features can be found and added.
> This topic has been discussed several times, for example search the web
> for "model-evolution CDO".
> I always thought this is a cool feature but it'd be *very* hard to
> implement correctly, particularly because CDO supports
> recording/accessing historical states of the model instances!
> I don't see a possibility to add this feature anytime soon. If you're
> willing to discuss technical details and contribute major effort please
> feel free to file a Bugzilla.
>
>>
>> Btw, currently plain EClass names are used as table names. Wouldn't it
>> be better to prepend the package name? Currently two EClasses with the
>> same name, but with different features, can't coexist.
> In the DBStore or the HibernateStore?
> For the DBStore I would not mind an enhancement request and for the
> HibernateStore I'd suggest to talk to Martin first.
>
> Cheers
> /Eike
Re: [CDO] Explicit locking / Changes to EPackages [message #422821 is a reply to message #422816] Tue, 16 September 2008 12:23 Go to previous messageGo to next message
Martin Taal is currently offline Martin TaalFriend
Messages: 5468
Registered: July 2009
Senior Member
Hi Eike, Jasper,
You can annotate the ECLass with a @Table annotation to force a certain tablename.

Or another way is that Teneo supports prepending the package prefix before the classname. But I
checked currently with cdo this feature is not reachable (the api does not offer it yet). I will add
this.

The @Table annotation works.

gr. Martin

Eike Stepper wrote:
> Jasper schrieb:
>> Just for discussion, there are two features that I believe CDO does
>> not have that I'd like to put out here, to get some feedback.
>>
>> 1. Explicit locking: Something like a method #lock()/#unlock() in the
>> CDOObject interface, allowing the caller to flag an object as not
>> editable by any users other than him/her. Whenever another user
>> committed a tx affecting the object, s/he would receive a
>> CdoObjectLockedException and his tx would roll back.
> Although I have some concerns with making this a default capability of a
> CDO repository I think the idea is worth being discussed in a Bugzilla ;-)
>
>>
>> 2. Support for changes to EPackages, especially dynamic ones: say I
>> add an EAttribute to an EClass, would be great if CDO picked up on
>> that, added a column to the table, and could keep going without a
>> database re-write. In the simple case of an addition of a feature or a
>> class, it seems doable to me: if there is a difference between the
>> Ecore xml in the database and that in the EPackage being registered,
>> the new features can be found and added.
> This topic has been discussed several times, for example search the web
> for "model-evolution CDO".
> I always thought this is a cool feature but it'd be *very* hard to
> implement correctly, particularly because CDO supports
> recording/accessing historical states of the model instances!
> I don't see a possibility to add this feature anytime soon. If you're
> willing to discuss technical details and contribute major effort please
> feel free to file a Bugzilla.
>
>>
>> Btw, currently plain EClass names are used as table names. Wouldn't it
>> be better to prepend the package name? Currently two EClasses with the
>> same name, but with different features, can't coexist.
> In the DBStore or the HibernateStore?
> For the DBStore I would not mind an enhancement request and for the
> HibernateStore I'd suggest to talk to Martin first.
>
> Cheers
> /Eike


--

With Regards, Martin Taal

Springsite/Elver.org
Office: Hardwareweg 4, 3821 BV Amersfoort
Postal: Nassaulaan 7, 3941 EC Doorn
The Netherlands
Cell: +31 (0)6 288 48 943
Tel: +31 (0)84 420 2397
Fax: +31 (0)84 225 9307
Mail: mtaal@springsite.com - mtaal@elver.org
Web: www.springsite.com - www.elver.org
Re: [CDO] Explicit locking / Changes to EPackages [message #422822 is a reply to message #422821] Tue, 16 September 2008 12:34 Go to previous message
Eike Stepper is currently offline Eike StepperFriend
Messages: 6509
Registered: July 2009
Senior Member
Martin Taal schrieb:
> Hi Eike, Jasper,
> You can annotate the ECLass with a @Table annotation to force a
> certain tablename.
>
> Or another way is that Teneo supports prepending the package prefix
> before the classname. But I checked currently with cdo this feature is
> not reachable (the api does not offer it yet). I will add this.
>
> The @Table annotation works.
Thank you for clarifying this, Martin ;-)

Cheers
/Eike

>
> gr. Martin
>
> Eike Stepper wrote:
>> Jasper schrieb:
>>> Just for discussion, there are two features that I believe CDO does
>>> not have that I'd like to put out here, to get some feedback.
>>>
>>> 1. Explicit locking: Something like a method #lock()/#unlock() in
>>> the CDOObject interface, allowing the caller to flag an object as
>>> not editable by any users other than him/her. Whenever another user
>>> committed a tx affecting the object, s/he would receive a
>>> CdoObjectLockedException and his tx would roll back.
>> Although I have some concerns with making this a default capability
>> of a CDO repository I think the idea is worth being discussed in a
>> Bugzilla ;-)
>>
>>>
>>> 2. Support for changes to EPackages, especially dynamic ones: say I
>>> add an EAttribute to an EClass, would be great if CDO picked up on
>>> that, added a column to the table, and could keep going without a
>>> database re-write. In the simple case of an addition of a feature or
>>> a class, it seems doable to me: if there is a difference between the
>>> Ecore xml in the database and that in the EPackage being registered,
>>> the new features can be found and added.
>> This topic has been discussed several times, for example search the
>> web for "model-evolution CDO".
>> I always thought this is a cool feature but it'd be *very* hard to
>> implement correctly, particularly because CDO supports
>> recording/accessing historical states of the model instances!
>> I don't see a possibility to add this feature anytime soon. If you're
>> willing to discuss technical details and contribute major effort
>> please feel free to file a Bugzilla.
>>
>>>
>>> Btw, currently plain EClass names are used as table names. Wouldn't
>>> it be better to prepend the package name? Currently two EClasses
>>> with the same name, but with different features, can't coexist.
>> In the DBStore or the HibernateStore?
>> For the DBStore I would not mind an enhancement request and for the
>> HibernateStore I'd suggest to talk to Martin first.
>>
>> Cheers
>> /Eike
>
>


Previous Topic:Using keyword 'super' in GenModel annotation
Next Topic:FileURIHandlerImpl bug ?
Goto Forum:
  


Current Time: Wed Sep 30 22:33:06 GMT 2020

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

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

Back to the top