Home » Modeling » EMF » [CDO] Explicit locking / Changes to EPackages
| [CDO] Explicit locking / Changes to EPackages [message #422813] |
Tue, 16 September 2008 09:55  |
 Jasper
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  |
Ed Merks
Messages: 33140
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 |
|
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
Cheers
/Eike
----
http://www.esc-net.de
http://thegordian.blogspot.com
http://twitter.com/eikestepper
|
|
|
| Re: [CDO] Explicit locking / Changes to EPackages [message #422819 is a reply to message #422816] |
Tue, 16 September 2008 11:09 |
Jasper
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 |
Martin Taal
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 |
|
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
>
>
Cheers
/Eike
----
http://www.esc-net.de
http://thegordian.blogspot.com
http://twitter.com/eikestepper
|
|
|
Goto Forum:
Current Time: Tue Apr 23 11:04:15 GMT 2024
Powered by FUDForum. Page generated in 0.04459 seconds |
] 
Search
Help
Register
Login
Home
