Skip to main content


Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Modeling » EMF » [CDO] is it abandoned? what is alternative?
[CDO] is it abandoned? what is alternative? [message #1444026] Mon, 13 October 2014 14:51 Go to next message
ModelGeek Mising name is currently offline ModelGeek Mising nameFriend
Messages: 550
Registered: June 2011
Senior Member
I am doing some pre study for developing EMF based multiuser application facilitating collaboration.

CDO and EMF store came as two candiates. I liked CDO as it offers database persistance. EMF Store is also good but it offers file persistance which might be problematic when data size increases and we need to make sure our application can handle really big models...
I just came across to one of the thread (https://www.eclipse.org/forums/index.php/t/826480/) saying CDO is already abandoned..... is it true? Should i drop the idea of using CDO? Is Teneo offers a good replacement for CDO? Does Teneo also supports collaboration and transactions?


thanks!

[Updated on: Mon, 13 October 2014 15:25]

Report message to a moderator

Re: [CDO] Multi user collaborations [message #1444558 is a reply to message #1444026] Tue, 14 October 2014 08:29 Go to previous messageGo to next message
Eike Stepper is currently offline Eike StepperFriend
Messages: 6447
Registered: July 2009
Senior Member
Am 13.10.2014 um 16:51 schrieb ModelGeek Mising name:
> I am doing some pre study for developing EMF based multiuser application facilitating collaboration.
> CDO and EMF store came as two candiates. I liked CDO as it offers database persistance. EMF Store is also good but it
> offers file persistance which might be problematic when data size increases and we need to make sure our application
> can handle really big models...
Then CDO is probably the best fit.

> I just came across to one of the thread (https://www.eclipse.org/forums/index.php/t/826480/) saying CDO is already
> abondoned..... is it true?
That thread didn't say that CDO is abandoned. David was frustrated because his CDO-based application didn't work as he
expected and couldn't find someone who was willing to solve his problem in four hours. So he felt compelled to tell the
world why *he* abandoned CDO.

Of course the CDO project is not terminated and won't be terminated. A great many companies use it successfully.

Cheers
/Eike

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



> Should i drop the idea of using CDO? Is Teneo offers a good replacement for CDO?
>
>
> thanks!
>
>


Re: [CDO] Multi user collaborations [message #1444636 is a reply to message #1444558] Tue, 14 October 2014 10:41 Go to previous messageGo to next message
ModelGeek Mising name is currently offline ModelGeek Mising nameFriend
Messages: 550
Registered: June 2011
Senior Member
thanks for the clarification.

Cheers
Re: [CDO] Multi user collaborations [message #1446176 is a reply to message #1444636] Thu, 16 October 2014 13:08 Go to previous messageGo to next message
David Wynter is currently offline David WynterFriend
Messages: 4624
Registered: July 2009
Senior Member
I agree with Eike. It is a problem that is either how we use CDO or maybe something else.

But to say we expected the problem to be solved in 4 hours is incorrect. I asked if Eike could at least look at our corrupted repositories, frankly it would take an hour to look at them and someone with deep knowledge of CDO will probably quickly realise what is wrong. You only need to use the standard CDO Explorer view that comes with the CDO plugins to try to export the repository and it clearly shows the corruption, it will fail. Inspecting that then might give a clue to how we recover them and even possibly how they get into that state. Our experience has been that CDO works well most of the time and then at random, saving the same class types as many times successfully previously, using exactly the same code it corrupts the repository. We have no idea why and various test cases where we effectively copy the entire repository pass. Clearly a difficult problem to solve. Eike admitted himself that he is very busy, he has to make a living after all.

Regarding the drop off of commits, I did not make it up, - http://git.eclipse.org/c/cdo/cdo.git/stats/?period=q&ofs=10

You make your own decision.

David



Re: [CDO] Multi user collaborations [message #1446202 is a reply to message #1446176] Thu, 16 October 2014 13:43 Go to previous messageGo to next message
Christophe Bouhier is currently offline Christophe BouhierFriend
Messages: 937
Registered: July 2009
Senior Member
On 16-10-14 15:08, David Wynter wrote:
> I agree with Eike. It is a problem that is either how we use CDO or
> maybe something else.
> But to say we expected the problem to be solved in 4 hours is incorrect.
> I asked if Eike could at least look at our corrupted repositories,
> frankly it would take an hour to look at them and someone with deep
> knowledge of CDO will probably quickly realise what is wrong. You only
> need to use the standard CDO Explorer view that comes with the CDO
> plugins to try to export the repository and it clearly shows the
> corruption, it will fail. Inspecting that then might give a clue to how
> we recover them and even possibly how they get into that state. Our
> experience has been that CDO works well most of the time and then at
> random, saving the same class types as many times successfully
> previously, using exactly the same code it corrupts the repository. We
> have no idea why and various test cases where we effectively copy the
> entire repository pass. Clearly a difficult problem to solve. Eike
> admitted himself that he is very busy, he has to make a living after all.
>
> Regarding the drop off of commits, I did not make it up, -
> http://git.eclipse.org/c/cdo/cdo.git/stats/?period=q&ofs=10
>
> You make your own decision.
>
So David, did you know completely abandon CDO, or would you give it
another try if your problem was addressed? The reason I ask, is I have
been CDO for several years and at some point we had corruption issues,
which we reported here:
https://bugs.eclipse.org/bugs/show_bug.cgi?id=396743

Both Eike and Stefan went through a great deal of trouble, to
solve the problem, which they did in the end.

I don't want to speak for Eike, but what I gather is that there is a bit
of disappointment, that the community hasn't been more active to
document, promote, patch and whatever else CDO. (Mea culpa here).
It's a great technology, but also very complex and simply diving-in is
not a trivial task. It requires a lot of time to understand the code,
hence perhaps the reason people are hesitant. I remember one comment
stating "Massively intimidating", which says it all.

What I know for sure though, is that Eike has been very responsive on
questions on the forum, Skype and email..So he certainly can't be blamed
for not being responsive from my experience.

> David
>
>
>
>
Re: [CDO] Multi user collaborations [message #1449423 is a reply to message #1446202] Tue, 21 October 2014 10:28 Go to previous messageGo to next message
David Wynter is currently offline David WynterFriend
Messages: 4624
Registered: July 2009
Senior Member
Hi,

At this stage I still have 3 broken repos with hundreds of hours design work in them, so yes I'd like to solve this issue. We modified the CDO code to skip over the model objects that had this
> java.lang.ClassCastException: org.eclipse.emf.cdo.common.revision.CDORevisionUtil$uninitialized cannot be cast to
> org.eclipse.emf.cdo.common.id.CDOID
> org.eclipse.net4j.signal.RemoteException: java.lang.ClassCastException:
> org.eclipse.emf.cdo.common.revision.CDORevisionUtil$uninitialized cannot be cast to org.eclipse.emf.cdo.common.id.CDOID

and saved to xmi files.

But when we try to reimport and commit those xmi files using the std CDO Explorer view we get this
The object "SubstitutionField[TRANSIENT](org.eclipse.emf.internal.cdo.object.DynamicCDOObjectImpl)" is not contained in a resource


Eike had thought our model design might have been a problem. For all our design classes we subclass an Abstract class called BaseModel which has one EAttribute, a class called UUID which has 2 EAttribute values lsb and msb. In fact I found that about 32 of these UUID in one corrupted repo had a CDO_VERSION of -2 when the class instances that reference them had not been 'deleted'. But removing these from the H2 repo did not fix the repository. If I ever recover these repos I can change the ecore to include the lsb and msb EAttributes from UUID class in BaseModel directly making it concrete, if that is what causes our issue, who knows, and then change the H2 repo like so
ALTER TABLE "REPO_20140827"."PUBLIC".SUBSTITUTIONFIELD ADD "LSB" bigint NULL ;
ALTER TABLE "REPO_20140827"."PUBLIC".SUBSTITUTIONFIELD ADD "MSB" bigint NULL ;
UPDATE SUBSTITUTIONFIELD  SET LSB = (SELECT LSB FROM UUID WHERE SUBSTITUTIONFIELD.UUID = UUID.CDO_ID);
UPDATE SUBSTITUTIONFIELD SET MSB = (SELECT MSB FROM UUID WHERE SUBSTITUTIONFIELD.UUID = UUID.CDO_ID);
ALTER TABLE SUBSTITUTIONFIELD DROP COLUMN "UUID" ;


Frankly we are in the dark and hacking like mad to try to recover the situation.
If you want to spend 15 minutes to open a corrupt repo in the CDO Explorer view then drop me an email to stpdave on the gmail domain.

All you have to do is open a repo and try to export, boom.

David
Re: [CDO] Multi user collaborations [message #1449529 is a reply to message #1449423] Tue, 21 October 2014 13:50 Go to previous messageGo to next message
David Wynter is currently offline David WynterFriend
Messages: 4624
Registered: July 2009
Senior Member
I discovered something just now. As above we managed to export to xmi from a corrupt repository by skipping the java.lang.ClassCastException: org.eclipse.emf.cdo.common.revision.CDORevisionUtil$uninitialized

The resultant xmi file is Imported into a empty CDO repo with the Package Registry loaded for the model edmmodel and opened in the Eclipse Text editor.

We get this, clearly were the problem lies.

  <model:MappingSubstitution xmi:id="t40167" substitutionFields="NNULL" name="Mapping BBG COLLAT_TYPE to collateraltype">
    <uuid xmi:id="t40168" lsb="-6140311635292653201" msb="9063455697632575823"/>


Note the NNULL

This is the equivalent input xmi element
  <edmmodel:MappingSubstitution name="Mapping BBG COLLAT_TYPE to collateraltype">
    <uuid lsb="-6140311635292653201" msb="9063455697632575823"/>
    <substitutionFields inputField="/936/@containedField.14" outputField="/1186/@containedField.0">
      <uuid lsb="-8198965334738203190" msb="-2815692950055403294"/>
    </substitutionFields>


This suggests the /936 offset to the related object of Class TransformationNodePort is incorrect?

No idea how to fix this though, a weakness of the offset notation used is you cannot easily find the reference objects, much better to use something like the href.

Re: [CDO] Multi user collaborations [message #1449532 is a reply to message #1449423] Tue, 21 October 2014 13:50 Go to previous messageGo to next message
David Wynter is currently offline David WynterFriend
Messages: 4624
Registered: July 2009
Senior Member
I discovered something just now. As above we managed to export to xmi from a corrupt repository by skipping the java.lang.ClassCastException: org.eclipse.emf.cdo.common.revision.CDORevisionUtil$uninitialized

The resultant xmi file is Imported into a empty CDO repo and opened in a Text editor

We get this, clearly were the problem lies.

  <model:MappingSubstitution xmi:id="t40167" substitutionFields="NNULL" name="Mapping BBG COLLAT_TYPE to collateraltype">
    <uuid xmi:id="t40168" lsb="-6140311635292653201" msb="9063455697632575823"/>


Note the NNULL

This is the equivalent input xmi element
  <edmmodel:MappingSubstitution name="Mapping BBG COLLAT_TYPE to collateraltype">
    <uuid lsb="-6140311635292653201" msb="9063455697632575823"/>
    <substitutionFields inputField="/936/@containedField.14" outputField="/1186/@containedField.0">
      <uuid lsb="-8198965334738203190" msb="-2815692950055403294"/>
    </substitutionFields>


This suggests the /936 offset to the related object of Class TransformationNodePort is incorrect?

No idea how to fix this though, a weakness of the offset notation used is you cannot easily find the reference objects, much better to use something like the href.

Re: [CDO] Multi user collaborations [message #1449533 is a reply to message #1449423] Tue, 21 October 2014 13:54 Go to previous messageGo to next message
David Wynter is currently offline David WynterFriend
Messages: 4624
Registered: July 2009
Senior Member
I discovered something just now. As above we managed to export to xmi from a corrupt repository by skipping the java.lang.ClassCastException: org.eclipse.emf.cdo.common.revision.CDORevisionUtil$uninitialized

The resultant xmi file is Imported into a empty CDO repo and opened in a Text editor

We get this, clearly were the problem lies.

  <model:MappingSubstitution xmi:id="t40167" substitutionFields="NNULL" name="Mapping BBG COLLAT_TYPE to collateraltype">
    <uuid xmi:id="t40168" lsb="-6140311635292653201" msb="9063455697632575823"/>


Note the NNULL

This is the equivalent input xmi element
  <edmmodel:MappingSubstitution name="Mapping BBG COLLAT_TYPE to collateraltype">
    <uuid lsb="-6140311635292653201" msb="9063455697632575823"/>
    <substitutionFields inputField="/936/@containedField.14" outputField="/1186/@containedField.0">
      <uuid lsb="-8198965334738203190" msb="-2815692950055403294"/>
    </substitutionFields>


This suggests the /936 offset to the related object of Class TransformationNodePort is incorrect?

No idea how to fix this though, a weakness of the offset notation used is you cannot easily find the reference objects, much better to use something like the href.

Re: [CDO] Multi user collaborations [message #1449534 is a reply to message #1449423] Tue, 21 October 2014 13:54 Go to previous messageGo to next message
David Wynter is currently offline David WynterFriend
Messages: 4624
Registered: July 2009
Senior Member
I discovered something just now. As above we managed to export to xmi from a corrupt repository by skipping the java.lang.ClassCastException: org.eclipse.emf.cdo.common.revision.CDORevisionUtil$uninitialized

The resultant xmi file is Imported into a empty CDO repo and opened in a Text editor

We get this, clearly were the problem lies.

  <model:MappingSubstitution xmi:id="t40167" substitutionFields="NNULL" name="Mapping BBG COLLAT_TYPE to collateraltype">
    <uuid xmi:id="t40168" lsb="-6140311635292653201" msb="9063455697632575823"/>


Note the NNULL

This is the equivalent input xmi element
  <edmmodel:MappingSubstitution name="Mapping BBG COLLAT_TYPE to collateraltype">
    <uuid lsb="-6140311635292653201" msb="9063455697632575823"/>
    <substitutionFields inputField="/936/@containedField.14" outputField="/1186/@containedField.0">
      <uuid lsb="-8198965334738203190" msb="-2815692950055403294"/>
    </substitutionFields>


This suggests the /936 offset to the related object of Class TransformationNodePort is incorrect?

No idea how to fix this though, a weakness of the offset notation used is you cannot easily find the reference objects, much better to use something like the href.
Re: [CDO] Multi user collaborations [message #1449535 is a reply to message #1449423] Tue, 21 October 2014 13:54 Go to previous messageGo to next message
David Wynter is currently offline David WynterFriend
Messages: 4624
Registered: July 2009
Senior Member
I discovered something just now. As above we managed to export to xmi from a corrupt repository by skipping the java.lang.ClassCastException: org.eclipse.emf.cdo.common.revision.CDORevisionUtil$uninitialized

The resultant xmi file is Imported into a empty CDO repo and opened in a Text editor

We get this, clearly were the problem lies.

  <model:MappingSubstitution xmi:id="t40167" substitutionFields="NNULL" name="Mapping BBG COLLAT_TYPE to collateraltype">
    <uuid xmi:id="t40168" lsb="-6140311635292653201" msb="9063455697632575823"/>


Note the NNULL

This is the equivalent input xmi element
  <edmmodel:MappingSubstitution name="Mapping BBG COLLAT_TYPE to collateraltype">
    <uuid lsb="-6140311635292653201" msb="9063455697632575823"/>
    <substitutionFields inputField="/936/@containedField.14" outputField="/1186/@containedField.0">
      <uuid lsb="-8198965334738203190" msb="-2815692950055403294"/>
    </substitutionFields>


This suggests the /936 offset to the related object of Class TransformationNodePort is incorrect?

No idea how to fix this though, a weakness of the offset notation used is you cannot easily find the reference objects, much better to use something like the href.
Re: [CDO] Multi user collaborations [message #1449538 is a reply to message #1449423] Tue, 21 October 2014 13:56 Go to previous messageGo to next message
David Wynter is currently offline David WynterFriend
Messages: 4624
Registered: July 2009
Senior Member
I discovered something just now. As above we managed to export to xmi from a corrupt repository by skipping the java.lang.ClassCastException: org.eclipse.emf.cdo.common.revision.CDORevisionUtil$uninitialized

The resultant xmi file is Imported into a empty CDO repo and opened in a Text editor

We get this, clearly were the problem lies.

  <model:MappingSubstitution xmi:id="t40167" substitutionFields="NNULL" name="Mapping BBG COLLAT_TYPE to collateraltype">
    <uuid xmi:id="t40168" lsb="-6140311635292653201" msb="9063455697632575823"/>
   ...
  </model:MappingSubstitution>



Note the NNULL

This is the equivalent input xmi element
  <edmmodel:MappingSubstitution name="Mapping BBG COLLAT_TYPE to collateraltype">
    <uuid lsb="-6140311635292653201" msb="9063455697632575823"/>
    <substitutionFields inputField="/936/@containedField.14" outputField="/1186/@containedField.0">
      <uuid lsb="-8198965334738203190" msb="-2815692950055403294"/>
    </substitutionFields>
...
  </edmmodel>


This suggests the /936 offset to the related object of Class TransformationNodePort is incorrect?

No idea how to fix this though, a weakness of the offset notation used is you cannot easily find the reference objects, much better to use something like the href.
Re: [CDO] Multi user collaborations [message #1449539 is a reply to message #1449423] Tue, 21 October 2014 13:58 Go to previous messageGo to next message
David Wynter is currently offline David WynterFriend
Messages: 4624
Registered: July 2009
Senior Member
I discovered something just now. As above we managed to export to xmi from a corrupt repository by skipping the java.lang.ClassCastException: org.eclipse.emf.cdo.common.revision.CDORevisionUtil$uninitialized

The resultant xmi file is Imported into a empty CDO repo and opened in a Text editor

We get this, clearly were the problem lies.

  <model:MappingSubstitution xmi:id="t40167" substitutionFields="NNULL" name="Mapping BBG COLLAT_TYPE to collateraltype">
    <uuid xmi:id="t40168" lsb="-6140311635292653201" msb="9063455697632575823"/>
   ...
  </model:MappingSubstitution>



Note the NNULL

This is the equivalent input xmi element
  <edmmodel:MappingSubstitution name="Mapping BBG COLLAT_TYPE to collateraltype">
    <uuid lsb="-6140311635292653201" msb="9063455697632575823"/>
    <substitutionFields inputField="/936/@containedField.14" outputField="/1186/@containedField.0">
      <uuid lsb="-8198965334738203190" msb="-2815692950055403294"/>
    </substitutionFields>
...
  </edmmodel>


This suggests the /936 offset to the related object of Class TransformationNodePort is incorrect?

No idea how to fix this though, a weakness of the offset notation used is you cannot easily find the reference objects, much better to use something like the href.
Re: [CDO] Multi user collaborations [message #1449540 is a reply to message #1449423] Tue, 21 October 2014 13:59 Go to previous messageGo to next message
David Wynter is currently offline David WynterFriend
Messages: 4624
Registered: July 2009
Senior Member
The forum will not take the content of the attached file as a post
Re: [CDO] Multi user collaborations [message #1449543 is a reply to message #1449423] Tue, 21 October 2014 14:00 Go to previous messageGo to next message
David Wynter is currently offline David WynterFriend
Messages: 4624
Registered: July 2009
Senior Member
I discovered something just now. As above we managed to export to xmi from a corrupt repository by skipping the java.lang.ClassCastException: org.eclipse.emf.cdo.common.revision.CDORevisionUtil$uninitialized

The resultant xmi file is Imported into a empty CDO repo and opened in a Text editor

We get this, clearly were the problem lies.

  <model:MappingSubstitution xmi:id="t40167" substitutionFields="NNULL" name="Mapping BBG COLLAT_TYPE to collateraltype">
    <uuid xmi:id="t40168" lsb="-6140311635292653201" msb="9063455697632575823"/>
   ...
  </model:MappingSubstitution>



Note the NNULL

This is the equivalent input xmi element
  <edmmodel:MappingSubstitution name="Mapping BBG COLLAT_TYPE to collateraltype">
    <uuid lsb="-6140311635292653201" msb="9063455697632575823"/>
    <substitutionFields inputField="/936/@containedField.14" outputField="/1186/@containedField.0">
      <uuid lsb="-8198965334738203190" msb="-2815692950055403294"/>
    </substitutionFields>
...
  </edmmodel>


This suggests the /936 offset to the related object of Class TransformationNodePort is incorrect?

No idea how to fix this though, a weakness of the offset notation used is you cannot easily find the reference objects, much better to use something like the href.
Re: [CDO] Multi user collaborations [message #1449626 is a reply to message #1449543] Tue, 21 October 2014 16:27 Go to previous message
Eike Stepper is currently offline Eike StepperFriend
Messages: 6447
Registered: July 2009
Senior Member
Am 21.10.2014 um 16:00 schrieb David Wynter:
> I discovered something just now. As above we managed to export to xmi
The first XMI snippet below looks strange because it suggests that the containment reference (?) "substitutionFields" is
stored as an attribute. How exactly did you create this file?

> from a corrupt repository by skipping the java.lang.ClassCastException:
> org.eclipse.emf.cdo.common.revision.CDORevisionUtil$uninitialized
How did you manage to skip exceptions during the export?

>
> The resultant xmi file is Imported into a empty CDO repo and opened in a Text editor
How does this import operation relate to the XMI snippet you show below and a text editor? Do you mean you open the
exported file in a text editor?

>
> We get this, clearly were the problem lies.
>
>
> <model:MappingSubstitution xmi:id="t40167" substitutionFields="NNULL" name="Mapping BBG COLLAT_TYPE to collateraltype">
Do you register your namespace under multiple nsPrefixes? Here it's "model", beloe it's "edmmodel".

As mentioned above, the fact that "substitutionFields" is serialized as an attribute looks suspicious in the first
place. The value "NNULL", too. Both can not be understood without knowing how exactly this file has been created.

> <uuid xmi:id="t40168" lsb="-6140311635292653201" msb="9063455697632575823"/>
> ...
> </model:MappingSubstitution>
>
>
>
> Note the NNULL
>
> This is the equivalent input xmi element
>
> <edmmodel:MappingSubstitution name="Mapping BBG COLLAT_TYPE to collateraltype">
> <uuid lsb="-6140311635292653201" msb="9063455697632575823"/>
> <substitutionFields inputField="/936/@containedField.14" outputField="/1186/@containedField.0">
> <uuid lsb="-8198965334738203190" msb="-2815692950055403294"/>
> </substitutionFields>
> ..
> </edmmodel>
>
>
> This suggests the /936 offset to the related object of Class TransformationNodePort is incorrect?
Where is this suggestion? I don't understand what you imply with this sentence/question. But the containment reference
vs attribute question seems more fundamental.

>
> No idea how to fix this though, a weakness of the offset notation used is you cannot easily find the reference
> objects, much better to use something like the href.
This fragment path notation is under your control (but I'm not an XML expert). If you assign XMI IDs to your resource's
root objects they should also be used in serialized references to those objects.

Cheers
/Eike

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


Previous Topic:[CDO] Persisting CDORevisionCache to filesystem to improve user experience
Next Topic:Add duplicated elements to EList
Goto Forum:
  


Current Time: Wed Oct 23 18:11:53 GMT 2019

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

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

Back to the top