[CDO] is it abandoned? what is alternative? [message #1444026] |
Mon, 13 October 2014 14:51 |
ModelGeek Mising name 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 |
|
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!
>
>
Cheers
/Eike
----
http://www.esc-net.de
http://thegordian.blogspot.com
http://twitter.com/eikestepper
|
|
|
|
|
Re: [CDO] Multi user collaborations [message #1446202 is a reply to message #1446176] |
Thu, 16 October 2014 13:43 |
Christophe Bouhier 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 #1449626 is a reply to message #1449543] |
Tue, 21 October 2014 16:27 |
|
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
Cheers
/Eike
----
http://www.esc-net.de
http://thegordian.blogspot.com
http://twitter.com/eikestepper
|
|
|
Powered by
FUDForum. Page generated in 0.06328 seconds