Home » Modeling » EMF » Understanding CDO
| Understanding CDO [message #943228] |
Sun, 14 October 2012 09:16  |
 Mauro Condarelli
Messages: 428
Registered: September 2009 |
Senior Member |
|
|
Hi,
I browsed a lot, but I'm still unsure if CDO is the tool fitting my
needs. I would like some expert advice before I plunge into this
particular sea.
I need to write a database application from scratch; this is a
moderately complex DB (my current estimate is about 40 tables in a
single database, maximum table size in the range of a few hundred
thousand records).
Database is mostly static (at least half the tables will be "read only"
for clients, updated server-side about once a year).
Main Client activity will be to add records to a few specific tables,
modify records it added and print (possibly complex) reports.
Database should be accessed from multiple instances of the application;
as said clients are expected to add/modify disjointed sets of records
(exceptions *are* possible).
It would be nice to have the chance to implement some "detached mode"
where clients cache a relevant fraction of the whole database, work
without connection to the server and then "resync" somehow with it.
I was exposed to EMF in other projects and I think it would be useful
here, but I'm unsure if the EMF/CDO is the advised path for such
application.
I have worked with databases and SQL, but I'm nowhere near a DB guru.
Clients will be Eclipse RCP applications.
Server will be running under Linux (ubuntu) while clients will be
running under MSWindows (currently win7).
I'm currently using 3.8 Juno, but I am prepared to switch to 4.2.x, if
advised.
I was thinking about a plain, possibly embedded, JDBC (are derby or
SQLite suitable or should I use something more heavyweight?) for the server.
I tried to follow several tutorials (including the one at:
http://wiki.eclipse.org/CDO/Server_Configuration_Reference), but they
all seem outdated. In particular I was not able to access repository for
examples (e.g.:
http://dev.eclipse.org/svnroot/modeling/org.eclipse.emf.cdo/trunk/features/org.eclipse.emf.cdo.server.product-feature/...).
What am I doing wrong?
Thanks in Advance
Mauro
|
|
|
| Re: Understanding CDO [message #945941 is a reply to message #943228] |
Mon, 15 October 2012 20:10  |
Christophe Bouhier
Messages: 937
Registered: July 2009 |
Senior Member |
|
|
Hello Mauro,
for the last 2 years, I have been working on a client/server application using CDO. Depending on your needs, CDO could be the right fit.
What I like (a lot).
1 CDO == EMF, so you can model data first in .xsd or directly in .ecore, and you can tell CDO to use your generated packages, which will build the DB schema.
2 On the CDO Store, you can choose from the DBStore, which supports various DB's, I have worked with MySQL and Postgres. With Hibernate store, there is an additional ORM layer, which works with tons of other DB's supported by Hibernate.
3 As CDO == EMF, you can easily adapt a generated RCP Client EMF editor for CDO, but in practice you are likely better of to start UI design from scratch, but you can re-use the concept of an Editing domain and EMF.edit generated code, which is what I do. (ItemProviders and Commands).
4 JFace databinding supports EMF, so JFace Databinding + CDO is a great combination, you might want to watch loading large chunks of data into your UI widgets (tables + trees), but there are ways to limit the volumes.
5 I you need to do something with DSL's (Develop a textual syntax, which can interact with EMF/CDO models), this is also great with xtext.
6 CDO performs well, you can tweak it, to fetch more or less chunks of data for EReferences. If you don't like the behaviour you can fire CDO Queries to get exactly what you want. Also unused objects are garbage collected, so you can safely read a lot of data (As long as you don't keep a reference).
7 I am really fond that objects have a lifecycle, and all my object have a unique CDO ID. I actually present the CDOID, in the status line of the app. It's a great way to check what's going on.
8 Invalidations are great, basically when an object goes, remotely dirty, other views are notified and can get the latest status of an object.
What I could do without in CDO
9. Revisions & referential integrity, I loved it at first, but right now for the app. I have. it's a burden. The concept of revisions adds a lot of requirements in CDO, I think CDO should also have a simpler flat mode, without the revisions and checks on integrity. It adds to the complexity of the CDO middleware and the generated DB get's schema's. Some apps, don't need it or need it partially. In my case, I would need revisions for some classes only. It sometimes feels CDO is trying to mimic a Concurrent Version System like SVN or CVS, but for many apps you really don't need that.
10. In CDO there are CDOFolders and CDOResources. Both are also CDO objects, and stored in the DB. I went through great length to find the best way to use them, like the the names to give them, which is meta information you need to deal with in the application. (Remember which name you used for which resource to keep which data objects, in my case each eclass has its own cdoresource). Right now, I am not sure what the added value is of these, besides some additional grouping of objects, I think, without them it could keep CDO simpler and avoid additional DB data. (Note that in point 3, I mentioned the EMF Editing domain, which has a ResourceSet which can hold CDOResource objects. I use this, so without CDO Resources, I wouldn't be able to use an editing domain, so something else would be needed).
What I wish for in CDO.
11. Model migrations. There are initiatives like COPE, which could be applied with CDO, that would be great. So add a class in your model, and let the new feature deal with the migration and transit your data.
12. It's a hard learning curve, because most of the docs are outdated or not written, so mea-culpa, we could do better. I wish for a thriving community around a general purpose smart-object-persistence system like CDO.
Finally.
Eike Stepper and others, have been great in supporting me on this forum. Generally very quick and helpful!
Hope this helps!
|
|
|
| Re: Understanding CDO [message #946359 is a reply to message #945941] |
Tue, 16 October 2012 06:30 |
|
<html>
<head>
<meta content="text/html; charset=UTF-8" http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
Hi Christophe,<br>
<br>
Thank you very much for your detailed experience report. I like it
lot ;-)<br>
<br>
More comments below...<br>
<br>
<br>
<div class="moz-cite-prefix">Am 15.10.2012 22:10, schrieb Christophe
Bouhier:<br>
</div>
<blockquote cite="mid:k5hqjk$f3l$1@xxxxxxxxe.org" type="cite">Hello
Mauro, <br>
for the last 2 years, I have been working on a client/server
application using CDO. Depending on your needs, CDO could be the
right fit. <br>
What I like (a lot). <br>
1 CDO == EMF, so you can model data first in .xsd or directly in
.ecore, and you can tell CDO to use your generated packages, which
will build the DB schema. </blockquote>
EMF compliance is very important to us and we're proud to support
most of EMF's features. Among the few exceptions are:<br>
<br>
a) Feature maps are hard to deal with in RDBs<br>
<br>
b) Because CDOResources are EObjects (see point 10) a small number
of other frameworks may run into trouble when trying to find out the
concrete type of a Notifier because the result depends on a
particular order of instanceof checks (check Resources first).<br>
<br>
c) With remote change notifications enabled, i.e.,
view.options().addChangeSubscriptionPolicy(...), your own Adapters
often need to distinguish between local or remote changes. An
instanceof CDODeltaNotification does the trick.<br>
<br>
d) Some IDE applications (and some poorly designed frameworks such
as GMF) heavily rely on IResources which are probably impossible to
simulate for CDOResources. For example it's hard or impossible to
present problem markers for validation problems in CDOResources
because IMarkers are associated with IResources. This is not a CDO
problem but a platform/IMarker problem that other
non-"platform:resource" Resources share in common.<br>
<br>
<blockquote cite="mid:k5hqjk$f3l$1@xxxxxxxxe.org" type="cite">2
On the CDO Store, you can choose from the DBStore, which supports
various DB's, I have worked with MySQL and Postgres. With
Hibernate store, there is an additional ORM layer, which works
with tons of other DB's supported by Hibernate. </blockquote>
And there's support for some other backend types, such as DB4O,
MongoDB or Objectivity/DB. I've recently developed a
RandomAccessFile based journaling store, named LissomeStore. It
still uses an RDB for a small and fixed number of indexes into the
random access file(s). For commits it uses a journal file and
adjusts the index tables asynchronously. The performance of large
commits can typically be increased by factor 600 in my tests.<br>
<br>
IMHO the great value of the IStore design is that it becomes a snap
to *change* the backend choice at any time without much impact on
the application (except you're making heavy use of backend-specifc
IQueryHandlers such as SQL or HQL).<br>
<br>
<blockquote cite="mid:k5hqjk$f3l$1@xxxxxxxxe.org" type="cite">3
As CDO == EMF, you can easily adapt a generated RCP Client EMF
editor for CDO, but in practice you are likely better of to start
UI design from scratch, but you can re-use the concept of an
Editing domain and EMF.edit generated code, which is what I do.
(ItemProviders and Commands). </blockquote>
It's a major goal of CDO to better separate the functional from the
the technical design aspects/tasks. The only intrusive technical
aspect I can imagine of is large flat lists that should generally be
avoided in favour of a deeper object structure. IMHO this is a
useful rule even when only considering the usability of a graphical
application.<br>
<br>
<blockquote cite="mid:k5hqjk$f3l$1@xxxxxxxxe.org" type="cite">4
JFace databinding supports EMF, so JFace Databinding + CDO is a
great combination, you might want to watch loading large chunks of
data into your UI widgets (tables + trees), but there are ways to
limit the volumes. </blockquote>
I fully agree that EMF databinding is a totally cool thing. One
thing that tends to be problematic are remote deletions because the
databinding layer caches some strong references to objects that
might, all of a sudden, start to throw InvalidObjectExceptions or
ObjectNotFoundExceptions. You may appreciate that in CDO 4.2 we now
changed to:<br>
<br>
public static final CDOStaleReferencePolicy DEFAULT = PROXY;<br>
<br>
public static final CDOInvalidationPolicy DEFAULT = RELAXED;<br>
<br>
<br>
<blockquote cite="mid:k5hqjk$f3l$1@xxxxxxxxe.org" type="cite">5 I
you need to do something with DSL's (Develop a textual syntax,
which can interact with EMF/CDO models), this is also great with
xtext.
<br>
</blockquote>
Yes, because "CDO == EMF". But please keep in mind that editing DSL
instances stored *in* CDO with an Xtexteditor is problematic because
a text editor generally doesn't preserve the identities (e.g.
CDOIDs) of objects. That makes it hard to reconcile changes made in
a text editor back to CDO.<br>
<br>
<blockquote cite="mid:k5hqjk$f3l$1@xxxxxxxxe.org" type="cite">6
CDO performs well, you can tweak it, to fetch more or less chunks
of data for EReferences. If you don't like the behaviour you can
fire CDO Queries to get exactly what you want. Also unused objects
are garbage collected, so you can safely read a lot of data (As
long as you don't keep a reference). </blockquote>
Funnily this scalability originally came as a by-product of the
auditing functionality ;-)<br>
<br>
<blockquote cite="mid:k5hqjk$f3l$1@xxxxxxxxe.org" type="cite">7 I
am really fond that objects have a lifecycle, and all my object
have a unique CDO ID. I actually present the CDOID, in the status
line of the app. It's a great way to check what's going on. </blockquote>
And now you can even plug in your own CDOIDGenerator at the
client-side:<br>
<br>
public interface CDOIDGenerator<br>
{<br>
public static final CDOIDGenerator UUID = new CDOIDGenerator()<br>
{<br>
public CDOID generateCDOID(EObject object)<br>
{<br>
byte[] bytes = new byte[16];<br>
UUIDGenerator.DEFAULT.generate(bytes);<br>
return CDOIDUtil.createUUID(bytes);<br>
}<br>
<br>
public void reset()<br>
{<br>
// Do nothing<br>
}<br>
};<br>
<br>
/**<br>
* Generates a {@link CDOID}.<br>
* <br>
* @param object<br>
* the object to generate a new CDOID for if available,
<code>null</code> otherwise.<br>
*/<br>
public CDOID generateCDOID(EObject object);<br>
<br>
/**<br>
* Called at the end of a commit operation to give this ID
generator a chance to reset its sequence of IDs.<br>
*/<br>
public void reset();<br>
}<br>
<br>
<blockquote cite="mid:k5hqjk$f3l$1@xxxxxxxxe.org" type="cite">
8 Invalidations are great, basically when an object goes, remotely
dirty, other views are notified and can get the latest status of
an object. <br>
<br>
What I could do without in CDO
<br>
<br>
9. Revisions & referential integrity, I loved it at first, but
right now for the app. I have. it's a burden. The concept of
revisions adds a lot of requirements in CDO, I think CDO should
also have a simpler flat mode, without the revisions and checks on
integrity. It adds to the complexity of the CDO middleware and the
generated DB get's schema's. Some apps, don't need it or need it
partially. In my case, I would need revisions for some classes
only. </blockquote>
I suspect you don't refer to CDORevisions but to the auditing mode
in general? You know that it can be switched off. Granted, for the
DBStore in particular
<a class="moz-txt-link-freetext" href="https://bugs.eclipse.org/bugs/show_bug.cgi?id=351068">https://bugs.eclipse.org/bugs/show_bug.cgi?id=351068</a> is pending. I
really want to work on this soon.<br>
<br>
Partial auditing has been requested in the past. Conceptually I
don't like the idea because the framework couldn't guarantee the
logical consistency of the graph anymore. But I'm willing to
reconsider this when the DBStore gets its next design overhaul (not
scheduled, yet).<br>
<br>
What exact integrity checks are you referring to? Referential
integrity checks in the repository can be switched off (and they are
by default).<br>
<br>
<blockquote cite="mid:k5hqjk$f3l$1@xxxxxxxxe.org" type="cite">It
sometimes feels CDO is trying to mimic a Concurrent Version System
like SVN or CVS, but for many apps you really don't need that. <br>
</blockquote>
Yes, CDO tries to offer support in both worlds, the database
driven-like runtime applications and the more tool-like use cases
where design-time models need to be stored/managed in a repository.
You can imagine that this is sometimes hard but I think we've done a
pretty good job. Are there particular parts in CDO that are
problematic for you in this regard (i.e., not just unneeded)?<br>
<br>
BTW. an example of a cool new SCM-like feature is our new History
view support for repositories, branches or single objects:<br>
<br>
<img src="http://www.eclipse.org/forums/index.php?t=getfile&id=11865" alt=""><br>
<br>
<blockquote cite="mid:k5hqjk$f3l$1@xxxxxxxxe.org" type="cite">10.
In CDO there are CDOFolders and CDOResources. </blockquote>
Yes, and CDOTextResources and CDOBinaryResources, which are now
(almost) first class citizens of a CDO repository:<br>
<br>
<img src="http://www.eclipse.org/forums/index.php?t=getfile&id=11866" alt=""><br>
<br>
<blockquote cite="mid:k5hqjk$f3l$1@xxxxxxxxe.org" type="cite">Both
are also CDO objects, and stored in the DB. I went through great
length to find the best way to use them, like the the names to
give them, which is meta information you need to deal with in the
application. (Remember which name you used for which resource to
keep which data objects, in my case each eclass has its own
cdoresource). </blockquote>
Yes, that's the main value of Resources in general: They provide
well-known entry points into the (persistent) graph of objects.<br>
<br>
Apart from that they're an essential part of "CDO == EMF" (see point
1).<br>
<br>
<blockquote cite="mid:k5hqjk$f3l$1@xxxxxxxxe.org" type="cite">Right
now, I am not sure what the added value is of these, besides some
additional grouping of objects, I think, without them it could
keep CDO simpler and avoid additional DB data. </blockquote>
Please note that you absolutely don't need to use CDOResourceFolders
and CDOResources (except for a single one to contain all other
objects). The characteristics of a CDO model is the same when you
store all objects in a single resource.<br>
<br>
<blockquote cite="mid:k5hqjk$f3l$1@xxxxxxxxe.org" type="cite">(Note
that in point 3, I mentioned the EMF Editing domain, which has a
ResourceSet which can hold CDOResource objects. I use this, so
without CDO Resources, I wouldn't be able to use an editing
domain, so something else would be needed). <br>
</blockquote>
I think the generated editors also make heavy use of the assumption
that objects are contained by resources.<br>
<br>
<blockquote cite="mid:k5hqjk$f3l$1@xxxxxxxxe.org" type="cite">What
I wish for in CDO.
<br>
<br>
11. Model migrations. There are initiatives like COPE, which could
be applied with CDO, that would be great. So add a class in your
model, and let the new feature deal with the migration and transit
your data. </blockquote>
Fully agreed. If only someone would need it enough to open the
wallet and fund the development of this feature :P<br>
<br>
<blockquote cite="mid:k5hqjk$f3l$1@xxxxxxxxe.org" type="cite">12.
It's a hard learning curve, because most of the docs are outdated
or not written, so mea-culpa, we could do better. I wish for a
thriving community around a general purpose
smart-object-persistence system like CDO. <br>
</blockquote>
Yes! Technical writers in the world, here's a project that needs you
;-)<br>
<br>
<blockquote cite="mid:k5hqjk$f3l$1@xxxxxxxxe.org" type="cite">Finally.
Eike Stepper and others, have been great in supporting me on this
forum. Generally very quick and helpful!<br>
</blockquote>
Good docs would certainly be nicer but, while they're absent, good
online support is our attempt to compensate ;-)<br>
<br>
Cheers<br>
/Eike<br>
<br>
----<br>
<a class="moz-txt-link-freetext" href="http://www.esc-net.de">http://www.esc-net.de</a><br>
<a class="moz-txt-link-freetext" href="http://thegordian.blogspot.com">http://thegordian.blogspot.com</a><br>
<a class="moz-txt-link-freetext" href="http://twitter.com/eikestepper">http://twitter.com/eikestepper</a><br>
<br>
<br>
<br>
</body>
</html>
Attachment: bgchgghb.png
(Size: 83.23KB, Downloaded 136 times)-
Attachment: edjjaeef.png
(Size: 16.76KB, Downloaded 139 times)
Cheers
/Eike
----
http://www.esc-net.de
http://thegordian.blogspot.com
http://twitter.com/eikestepper
|
|
|
| Re: Understanding CDO [message #946363 is a reply to message #945941] |
Tue, 16 October 2012 06:30 |
|
<html>
<head>
<meta content="text/html; charset=UTF-8" http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
Hi Christophe,<br>
<br>
Thank you very much for your detailed experience report. I like it
lot ;-)<br>
<br>
More comments below...<br>
<br>
<br>
<div class="moz-cite-prefix">Am 15.10.2012 22:10, schrieb Christophe
Bouhier:<br>
</div>
<blockquote cite="mid:k5hqjk$f3l$1@xxxxxxxxe.org" type="cite">Hello
Mauro, <br>
for the last 2 years, I have been working on a client/server
application using CDO. Depending on your needs, CDO could be the
right fit. <br>
What I like (a lot). <br>
1 CDO == EMF, so you can model data first in .xsd or directly in
.ecore, and you can tell CDO to use your generated packages, which
will build the DB schema. </blockquote>
EMF compliance is very important to us and we're proud to support
most of EMF's features. Among the few exceptions are:<br>
<br>
a) Feature maps are hard to deal with in RDBs<br>
<br>
b) Because CDOResources are EObjects (see point 10) a small number
of other frameworks may run into trouble when trying to find out the
concrete type of a Notifier because the result depends on a
particular order of instanceof checks (check Resources first).<br>
<br>
c) With remote change notifications enabled, i.e.,
view.options().addChangeSubscriptionPolicy(...), your own Adapters
often need to distinguish between local or remote changes. An
instanceof CDODeltaNotification does the trick.<br>
<br>
d) Some IDE applications (and some poorly designed frameworks such
as GMF) heavily rely on IResources which are probably impossible to
simulate for CDOResources. For example it's hard or impossible to
present problem markers for validation problems in CDOResources
because IMarkers are associated with IResources. This is not a CDO
problem but a platform/IMarker problem that other
non-"platform:resource" Resources share in common.<br>
<br>
<blockquote cite="mid:k5hqjk$f3l$1@xxxxxxxxe.org" type="cite">2
On the CDO Store, you can choose from the DBStore, which supports
various DB's, I have worked with MySQL and Postgres. With
Hibernate store, there is an additional ORM layer, which works
with tons of other DB's supported by Hibernate. </blockquote>
And there's support for some other backend types, such as DB4O,
MongoDB or Objectivity/DB. I've recently developed a
RandomAccessFile based journaling store, named LissomeStore. It
still uses an RDB for a small and fixed number of indexes into the
random access file(s). For commits it uses a journal file and
adjusts the index tables asynchronously. The performance of large
commits can typically be increased by factor 600 in my tests.<br>
<br>
IMHO the great value of the IStore design is that it becomes a snap
to *change* the backend choice at any time without much impact on
the application (except you're making heavy use of backend-specifc
IQueryHandlers such as SQL or HQL).<br>
<br>
<blockquote cite="mid:k5hqjk$f3l$1@xxxxxxxxe.org" type="cite">3
As CDO == EMF, you can easily adapt a generated RCP Client EMF
editor for CDO, but in practice you are likely better of to start
UI design from scratch, but you can re-use the concept of an
Editing domain and EMF.edit generated code, which is what I do.
(ItemProviders and Commands). </blockquote>
It's a major goal of CDO to better separate the functional from the
the technical design aspects/tasks. The only intrusive technical
aspect I can imagine of is large flat lists that should generally be
avoided in favour of a deeper object structure. IMHO this is a
useful rule even when only considering the usability of a graphical
application.<br>
<br>
<blockquote cite="mid:k5hqjk$f3l$1@xxxxxxxxe.org" type="cite">4
JFace databinding supports EMF, so JFace Databinding + CDO is a
great combination, you might want to watch loading large chunks of
data into your UI widgets (tables + trees), but there are ways to
limit the volumes. </blockquote>
I fully agree that EMF databinding is a totally cool thing. One
thing that tends to be problematic are remote deletions because the
databinding layer caches some strong references to objects that
might, all of a sudden, start to throw InvalidObjectExceptions or
ObjectNotFoundExceptions. You may appreciate that in CDO 4.2 we now
changed to:<br>
<br>
public static final CDOStaleReferencePolicy DEFAULT = PROXY;<br>
<br>
public static final CDOInvalidationPolicy DEFAULT = RELAXED;<br>
<br>
<br>
<blockquote cite="mid:k5hqjk$f3l$1@xxxxxxxxe.org" type="cite">5 I
you need to do something with DSL's (Develop a textual syntax,
which can interact with EMF/CDO models), this is also great with
xtext.
<br>
</blockquote>
Yes, because "CDO == EMF". But please keep in mind that editing DSL
instances stored *in* CDO with an Xtexteditor is problematic because
a text editor generally doesn't preserve the identities (e.g.
CDOIDs) of objects. That makes it hard to reconcile changes made in
a text editor back to CDO.<br>
<br>
<blockquote cite="mid:k5hqjk$f3l$1@xxxxxxxxe.org" type="cite">6
CDO performs well, you can tweak it, to fetch more or less chunks
of data for EReferences. If you don't like the behaviour you can
fire CDO Queries to get exactly what you want. Also unused objects
are garbage collected, so you can safely read a lot of data (As
long as you don't keep a reference). </blockquote>
Funnily this scalability originally came as a by-product of the
auditing functionality ;-)<br>
<br>
<blockquote cite="mid:k5hqjk$f3l$1@xxxxxxxxe.org" type="cite">7 I
am really fond that objects have a lifecycle, and all my object
have a unique CDO ID. I actually present the CDOID, in the status
line of the app. It's a great way to check what's going on. </blockquote>
And now you can even plug in your own CDOIDGenerator at the
client-side:<br>
<br>
public interface CDOIDGenerator<br>
{<br>
public static final CDOIDGenerator UUID = new CDOIDGenerator()<br>
{<br>
public CDOID generateCDOID(EObject object)<br>
{<br>
byte[] bytes = new byte[16];<br>
UUIDGenerator.DEFAULT.generate(bytes);<br>
return CDOIDUtil.createUUID(bytes);<br>
}<br>
<br>
public void reset()<br>
{<br>
// Do nothing<br>
}<br>
};<br>
<br>
/**<br>
* Generates a {@link CDOID}.<br>
* <br>
* @param object<br>
* the object to generate a new CDOID for if available,
<code>null</code> otherwise.<br>
*/<br>
public CDOID generateCDOID(EObject object);<br>
<br>
/**<br>
* Called at the end of a commit operation to give this ID
generator a chance to reset its sequence of IDs.<br>
*/<br>
public void reset();<br>
}<br>
<br>
<blockquote cite="mid:k5hqjk$f3l$1@xxxxxxxxe.org" type="cite">
8 Invalidations are great, basically when an object goes, remotely
dirty, other views are notified and can get the latest status of
an object. <br>
<br>
What I could do without in CDO
<br>
<br>
9. Revisions & referential integrity, I loved it at first, but
right now for the app. I have. it's a burden. The concept of
revisions adds a lot of requirements in CDO, I think CDO should
also have a simpler flat mode, without the revisions and checks on
integrity. It adds to the complexity of the CDO middleware and the
generated DB get's schema's. Some apps, don't need it or need it
partially. In my case, I would need revisions for some classes
only. </blockquote>
I suspect you don't refer to CDORevisions but to the auditing mode
in general? You know that it can be switched off. Granted, for the
DBStore in particular
<a class="moz-txt-link-freetext" href="https://bugs.eclipse.org/bugs/show_bug.cgi?id=351068">https://bugs.eclipse.org/bugs/show_bug.cgi?id=351068</a> is pending. I
really want to work on this soon.<br>
<br>
Partial auditing has been requested in the past. Conceptually I
don't like the idea because the framework couldn't guarantee the
logical consistency of the graph anymore. But I'm willing to
reconsider this when the DBStore gets its next design overhaul (not
scheduled, yet).<br>
<br>
What exact integrity checks are you referring to? Referential
integrity checks in the repository can be switched off (and they are
by default).<br>
<br>
<blockquote cite="mid:k5hqjk$f3l$1@xxxxxxxxe.org" type="cite">It
sometimes feels CDO is trying to mimic a Concurrent Version System
like SVN or CVS, but for many apps you really don't need that. <br>
</blockquote>
Yes, CDO tries to offer support in both worlds, the database
driven-like runtime applications and the more tool-like use cases
where design-time models need to be stored/managed in a repository.
You can imagine that this is sometimes hard but I think we've done a
pretty good job. Are there particular parts in CDO that are
problematic for you in this regard (i.e., not just unneeded)?<br>
<br>
BTW. an example of a cool new SCM-like feature is our new History
view support for repositories, branches or single objects:<br>
<br>
<img src="http://www.eclipse.org/forums/index.php?t=getfile&id=11867" alt=""><br>
<br>
<blockquote cite="mid:k5hqjk$f3l$1@xxxxxxxxe.org" type="cite">10.
In CDO there are CDOFolders and CDOResources. </blockquote>
Yes, and CDOTextResources and CDOBinaryResources, which are now
(almost) first class citizens of a CDO repository:<br>
<br>
<img src="http://www.eclipse.org/forums/index.php?t=getfile&id=11868" alt=""><br>
<br>
<blockquote cite="mid:k5hqjk$f3l$1@xxxxxxxxe.org" type="cite">Both
are also CDO objects, and stored in the DB. I went through great
length to find the best way to use them, like the the names to
give them, which is meta information you need to deal with in the
application. (Remember which name you used for which resource to
keep which data objects, in my case each eclass has its own
cdoresource). </blockquote>
Yes, that's the main value of Resources in general: They provide
well-known entry points into the (persistent) graph of objects.<br>
<br>
Apart from that they're an essential part of "CDO == EMF" (see point
1).<br>
<br>
<blockquote cite="mid:k5hqjk$f3l$1@xxxxxxxxe.org" type="cite">Right
now, I am not sure what the added value is of these, besides some
additional grouping of objects, I think, without them it could
keep CDO simpler and avoid additional DB data. </blockquote>
Please note that you absolutely don't need to use CDOResourceFolders
and CDOResources (except for a single one to contain all other
objects). The characteristics of a CDO model is the same when you
store all objects in a single resource.<br>
<br>
<blockquote cite="mid:k5hqjk$f3l$1@xxxxxxxxe.org" type="cite">(Note
that in point 3, I mentioned the EMF Editing domain, which has a
ResourceSet which can hold CDOResource objects. I use this, so
without CDO Resources, I wouldn't be able to use an editing
domain, so something else would be needed). <br>
</blockquote>
I think the generated editors also make heavy use of the assumption
that objects are contained by resources.<br>
<br>
<blockquote cite="mid:k5hqjk$f3l$1@xxxxxxxxe.org" type="cite">What
I wish for in CDO.
<br>
<br>
11. Model migrations. There are initiatives like COPE, which could
be applied with CDO, that would be great. So add a class in your
model, and let the new feature deal with the migration and transit
your data. </blockquote>
Fully agreed. If only someone would need it enough to open the
wallet and fund the development of this feature :P<br>
<br>
<blockquote cite="mid:k5hqjk$f3l$1@xxxxxxxxe.org" type="cite">12.
It's a hard learning curve, because most of the docs are outdated
or not written, so mea-culpa, we could do better. I wish for a
thriving community around a general purpose
smart-object-persistence system like CDO. <br>
</blockquote>
Yes! Technical writers in the world, here's a project that needs you
;-)<br>
<br>
<blockquote cite="mid:k5hqjk$f3l$1@xxxxxxxxe.org" type="cite">Finally.
Eike Stepper and others, have been great in supporting me on this
forum. Generally very quick and helpful!<br>
</blockquote>
Good docs would certainly be nicer but, while they're absent, good
online support is our attempt to compensate ;-)<br>
<br>
Cheers<br>
/Eike<br>
<br>
----<br>
<a class="moz-txt-link-freetext" href="http://www.esc-net.de">http://www.esc-net.de</a><br>
<a class="moz-txt-link-freetext" href="http://thegordian.blogspot.com">http://thegordian.blogspot.com</a><br>
<a class="moz-txt-link-freetext" href="http://twitter.com/eikestepper">http://twitter.com/eikestepper</a><br>
<br>
<br>
<br>
</body>
</html>
-
Attachment: bgchgghb.png
(Size: 83.23KB, Downloaded 130 times) -
Attachment: edjjaeef.png
(Size: 16.76KB, Downloaded 163 times)
Cheers
/Eike
----
http://www.esc-net.de
http://thegordian.blogspot.com
http://twitter.com/eikestepper
|
|
|
| Re: Understanding CDO [message #946368 is a reply to message #945941] |
Tue, 16 October 2012 06:30 |
|
<html>
<head>
<meta content="text/html; charset=UTF-8" http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
Hi Christophe,<br>
<br>
Thank you very much for your detailed experience report. I like it
lot ;-)<br>
<br>
More comments below...<br>
<br>
<br>
<div class="moz-cite-prefix">Am 15.10.2012 22:10, schrieb Christophe
Bouhier:<br>
</div>
<blockquote cite="mid:k5hqjk$f3l$1@xxxxxxxxe.org" type="cite">Hello
Mauro, <br>
for the last 2 years, I have been working on a client/server
application using CDO. Depending on your needs, CDO could be the
right fit. <br>
What I like (a lot). <br>
1 CDO == EMF, so you can model data first in .xsd or directly in
.ecore, and you can tell CDO to use your generated packages, which
will build the DB schema. </blockquote>
EMF compliance is very important to us and we're proud to support
most of EMF's features. Among the few exceptions are:<br>
<br>
a) Feature maps are hard to deal with in RDBs<br>
<br>
b) Because CDOResources are EObjects (see point 10) a small number
of other frameworks may run into trouble when trying to find out the
concrete type of a Notifier because the result depends on a
particular order of instanceof checks (check Resources first).<br>
<br>
c) With remote change notifications enabled, i.e.,
view.options().addChangeSubscriptionPolicy(...), your own Adapters
often need to distinguish between local or remote changes. An
instanceof CDODeltaNotification does the trick.<br>
<br>
d) Some IDE applications (and some poorly designed frameworks such
as GMF) heavily rely on IResources which are probably impossible to
simulate for CDOResources. For example it's hard or impossible to
present problem markers for validation problems in CDOResources
because IMarkers are associated with IResources. This is not a CDO
problem but a platform/IMarker problem that other
non-"platform:resource" Resources share in common.<br>
<br>
<blockquote cite="mid:k5hqjk$f3l$1@xxxxxxxxe.org" type="cite">2
On the CDO Store, you can choose from the DBStore, which supports
various DB's, I have worked with MySQL and Postgres. With
Hibernate store, there is an additional ORM layer, which works
with tons of other DB's supported by Hibernate. </blockquote>
And there's support for some other backend types, such as DB4O,
MongoDB or Objectivity/DB. I've recently developed a
RandomAccessFile based journaling store, named LissomeStore. It
still uses an RDB for a small and fixed number of indexes into the
random access file(s). For commits it uses a journal file and
adjusts the index tables asynchronously. The performance of large
commits can typically be increased by factor 600 in my tests.<br>
<br>
IMHO the great value of the IStore design is that it becomes a snap
to *change* the backend choice at any time without much impact on
the application (except you're making heavy use of backend-specifc
IQueryHandlers such as SQL or HQL).<br>
<br>
<blockquote cite="mid:k5hqjk$f3l$1@xxxxxxxxe.org" type="cite">3
As CDO == EMF, you can easily adapt a generated RCP Client EMF
editor for CDO, but in practice you are likely better of to start
UI design from scratch, but you can re-use the concept of an
Editing domain and EMF.edit generated code, which is what I do.
(ItemProviders and Commands). </blockquote>
It's a major goal of CDO to better separate the functional from the
the technical design aspects/tasks. The only intrusive technical
aspect I can imagine of is large flat lists that should generally be
avoided in favour of a deeper object structure. IMHO this is a
useful rule even when only considering the usability of a graphical
application.<br>
<br>
<blockquote cite="mid:k5hqjk$f3l$1@xxxxxxxxe.org" type="cite">4
JFace databinding supports EMF, so JFace Databinding + CDO is a
great combination, you might want to watch loading large chunks of
data into your UI widgets (tables + trees), but there are ways to
limit the volumes. </blockquote>
I fully agree that EMF databinding is a totally cool thing. One
thing that tends to be problematic are remote deletions because the
databinding layer caches some strong references to objects that
might, all of a sudden, start to throw InvalidObjectExceptions or
ObjectNotFoundExceptions. You may appreciate that in CDO 4.2 we now
changed to:<br>
<br>
public static final CDOStaleReferencePolicy DEFAULT = PROXY;<br>
<br>
public static final CDOInvalidationPolicy DEFAULT = RELAXED;<br>
<br>
<br>
<blockquote cite="mid:k5hqjk$f3l$1@xxxxxxxxe.org" type="cite">5 I
you need to do something with DSL's (Develop a textual syntax,
which can interact with EMF/CDO models), this is also great with
xtext.
<br>
</blockquote>
Yes, because "CDO == EMF". But please keep in mind that editing DSL
instances stored *in* CDO with an Xtexteditor is problematic because
a text editor generally doesn't preserve the identities (e.g.
CDOIDs) of objects. That makes it hard to reconcile changes made in
a text editor back to CDO.<br>
<br>
<blockquote cite="mid:k5hqjk$f3l$1@xxxxxxxxe.org" type="cite">6
CDO performs well, you can tweak it, to fetch more or less chunks
of data for EReferences. If you don't like the behaviour you can
fire CDO Queries to get exactly what you want. Also unused objects
are garbage collected, so you can safely read a lot of data (As
long as you don't keep a reference). </blockquote>
Funnily this scalability originally came as a by-product of the
auditing functionality ;-)<br>
<br>
<blockquote cite="mid:k5hqjk$f3l$1@xxxxxxxxe.org" type="cite">7 I
am really fond that objects have a lifecycle, and all my object
have a unique CDO ID. I actually present the CDOID, in the status
line of the app. It's a great way to check what's going on. </blockquote>
And now you can even plug in your own CDOIDGenerator at the
client-side:<br>
<br>
public interface CDOIDGenerator<br>
{<br>
public static final CDOIDGenerator UUID = new CDOIDGenerator()<br>
{<br>
public CDOID generateCDOID(EObject object)<br>
{<br>
byte[] bytes = new byte[16];<br>
UUIDGenerator.DEFAULT.generate(bytes);<br>
return CDOIDUtil.createUUID(bytes);<br>
}<br>
<br>
public void reset()<br>
{<br>
// Do nothing<br>
}<br>
};<br>
<br>
/**<br>
* Generates a {@link CDOID}.<br>
* <br>
* @param object<br>
* the object to generate a new CDOID for if available,
<code>null</code> otherwise.<br>
*/<br>
public CDOID generateCDOID(EObject object);<br>
<br>
/**<br>
* Called at the end of a commit operation to give this ID
generator a chance to reset its sequence of IDs.<br>
*/<br>
public void reset();<br>
}<br>
<br>
<blockquote cite="mid:k5hqjk$f3l$1@xxxxxxxxe.org" type="cite">
8 Invalidations are great, basically when an object goes, remotely
dirty, other views are notified and can get the latest status of
an object. <br>
<br>
What I could do without in CDO
<br>
<br>
9. Revisions & referential integrity, I loved it at first, but
right now for the app. I have. it's a burden. The concept of
revisions adds a lot of requirements in CDO, I think CDO should
also have a simpler flat mode, without the revisions and checks on
integrity. It adds to the complexity of the CDO middleware and the
generated DB get's schema's. Some apps, don't need it or need it
partially. In my case, I would need revisions for some classes
only. </blockquote>
I suspect you don't refer to CDORevisions but to the auditing mode
in general? You know that it can be switched off. Granted, for the
DBStore in particular
<a class="moz-txt-link-freetext" href="https://bugs.eclipse.org/bugs/show_bug.cgi?id=351068">https://bugs.eclipse.org/bugs/show_bug.cgi?id=351068</a> is pending. I
really want to work on this soon.<br>
<br>
Partial auditing has been requested in the past. Conceptually I
don't like the idea because the framework couldn't guarantee the
logical consistency of the graph anymore. But I'm willing to
reconsider this when the DBStore gets its next design overhaul (not
scheduled, yet).<br>
<br>
What exact integrity checks are you referring to? Referential
integrity checks in the repository can be switched off (and they are
by default).<br>
<br>
<blockquote cite="mid:k5hqjk$f3l$1@xxxxxxxxe.org" type="cite">It
sometimes feels CDO is trying to mimic a Concurrent Version System
like SVN or CVS, but for many apps you really don't need that. <br>
</blockquote>
Yes, CDO tries to offer support in both worlds, the database
driven-like runtime applications and the more tool-like use cases
where design-time models need to be stored/managed in a repository.
You can imagine that this is sometimes hard but I think we've done a
pretty good job. Are there particular parts in CDO that are
problematic for you in this regard (i.e., not just unneeded)?<br>
<br>
BTW. an example of a cool new SCM-like feature is our new History
view support for repositories, branches or single objects:<br>
<br>
<img src="http://www.eclipse.org/forums/index.php?t=getfile&id=11869" alt=""><br>
<br>
<blockquote cite="mid:k5hqjk$f3l$1@xxxxxxxxe.org" type="cite">10.
In CDO there are CDOFolders and CDOResources. </blockquote>
Yes, and CDOTextResources and CDOBinaryResources, which are now
(almost) first class citizens of a CDO repository:<br>
<br>
<img src="http://www.eclipse.org/forums/index.php?t=getfile&id=11870" alt=""><br>
<br>
<blockquote cite="mid:k5hqjk$f3l$1@xxxxxxxxe.org" type="cite">Both
are also CDO objects, and stored in the DB. I went through great
length to find the best way to use them, like the the names to
give them, which is meta information you need to deal with in the
application. (Remember which name you used for which resource to
keep which data objects, in my case each eclass has its own
cdoresource). </blockquote>
Yes, that's the main value of Resources in general: They provide
well-known entry points into the (persistent) graph of objects.<br>
<br>
Apart from that they're an essential part of "CDO == EMF" (see point
1).<br>
<br>
<blockquote cite="mid:k5hqjk$f3l$1@xxxxxxxxe.org" type="cite">Right
now, I am not sure what the added value is of these, besides some
additional grouping of objects, I think, without them it could
keep CDO simpler and avoid additional DB data. </blockquote>
Please note that you absolutely don't need to use CDOResourceFolders
and CDOResources (except for a single one to contain all other
objects). The characteristics of a CDO model is the same when you
store all objects in a single resource.<br>
<br>
<blockquote cite="mid:k5hqjk$f3l$1@xxxxxxxxe.org" type="cite">(Note
that in point 3, I mentioned the EMF Editing domain, which has a
ResourceSet which can hold CDOResource objects. I use this, so
without CDO Resources, I wouldn't be able to use an editing
domain, so something else would be needed). <br>
</blockquote>
I think the generated editors also make heavy use of the assumption
that objects are contained by resources.<br>
<br>
<blockquote cite="mid:k5hqjk$f3l$1@xxxxxxxxe.org" type="cite">What
I wish for in CDO.
<br>
<br>
11. Model migrations. There are initiatives like COPE, which could
be applied with CDO, that would be great. So add a class in your
model, and let the new feature deal with the migration and transit
your data. </blockquote>
Fully agreed. If only someone would need it enough to open the
wallet and fund the development of this feature :P<br>
<br>
<blockquote cite="mid:k5hqjk$f3l$1@xxxxxxxxe.org" type="cite">12.
It's a hard learning curve, because most of the docs are outdated
or not written, so mea-culpa, we could do better. I wish for a
thriving community around a general purpose
smart-object-persistence system like CDO. <br>
</blockquote>
Yes! Technical writers in the world, here's a project that needs you
;-)<br>
<br>
<blockquote cite="mid:k5hqjk$f3l$1@xxxxxxxxe.org" type="cite">Finally.
Eike Stepper and others, have been great in supporting me on this
forum. Generally very quick and helpful!<br>
</blockquote>
Good docs would certainly be nicer but, while they're absent, good
online support is our attempt to compensate ;-)<br>
<br>
Cheers<br>
/Eike<br>
<br>
----<br>
<a class="moz-txt-link-freetext" href="http://www.esc-net.de">http://www.esc-net.de</a><br>
<a class="moz-txt-link-freetext" href="http://thegordian.blogspot.com">http://thegordian.blogspot.com</a><br>
<a class="moz-txt-link-freetext" href="http://twitter.com/eikestepper">http://twitter.com/eikestepper</a><br>
<br>
<br>
<br>
</body>
</html>
-
Attachment: edjjaeef.png
(Size: 16.76KB, Downloaded 159 times) -
Attachment: bgchgghb.png
(Size: 83.23KB, Downloaded 138 times)
Cheers
/Eike
----
http://www.esc-net.de
http://thegordian.blogspot.com
http://twitter.com/eikestepper
|
|
|
| Re: Understanding CDO [message #946373 is a reply to message #945941] |
Tue, 16 October 2012 06:30 |
|
<html>
<head>
<meta content="text/html; charset=UTF-8" http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
Hi Christophe,<br>
<br>
Thank you very much for your detailed experience report. I like it
lot ;-)<br>
<br>
More comments below...<br>
<br>
<br>
<div class="moz-cite-prefix">Am 15.10.2012 22:10, schrieb Christophe
Bouhier:<br>
</div>
<blockquote cite="mid:k5hqjk$f3l$1@xxxxxxxxe.org" type="cite">Hello
Mauro, <br>
for the last 2 years, I have been working on a client/server
application using CDO. Depending on your needs, CDO could be the
right fit. <br>
What I like (a lot). <br>
1 CDO == EMF, so you can model data first in .xsd or directly in
.ecore, and you can tell CDO to use your generated packages, which
will build the DB schema. </blockquote>
EMF compliance is very important to us and we're proud to support
most of EMF's features. Among the few exceptions are:<br>
<br>
a) Feature maps are hard to deal with in RDBs<br>
<br>
b) Because CDOResources are EObjects (see point 10) a small number
of other frameworks may run into trouble when trying to find out the
concrete type of a Notifier because the result depends on a
particular order of instanceof checks (check Resources first).<br>
<br>
c) With remote change notifications enabled, i.e.,
view.options().addChangeSubscriptionPolicy(...), your own Adapters
often need to distinguish between local or remote changes. An
instanceof CDODeltaNotification does the trick.<br>
<br>
d) Some IDE applications (and some poorly designed frameworks such
as GMF) heavily rely on IResources which are probably impossible to
simulate for CDOResources. For example it's hard or impossible to
present problem markers for validation problems in CDOResources
because IMarkers are associated with IResources. This is not a CDO
problem but a platform/IMarker problem that other
non-"platform:resource" Resources share in common.<br>
<br>
<blockquote cite="mid:k5hqjk$f3l$1@xxxxxxxxe.org" type="cite">2
On the CDO Store, you can choose from the DBStore, which supports
various DB's, I have worked with MySQL and Postgres. With
Hibernate store, there is an additional ORM layer, which works
with tons of other DB's supported by Hibernate. </blockquote>
And there's support for some other backend types, such as DB4O,
MongoDB or Objectivity/DB. I've recently developed a
RandomAccessFile based journaling store, named LissomeStore. It
still uses an RDB for a small and fixed number of indexes into the
random access file(s). For commits it uses a journal file and
adjusts the index tables asynchronously. The performance of large
commits can typically be increased by factor 600 in my tests.<br>
<br>
IMHO the great value of the IStore design is that it becomes a snap
to *change* the backend choice at any time without much impact on
the application (except you're making heavy use of backend-specifc
IQueryHandlers such as SQL or HQL).<br>
<br>
<blockquote cite="mid:k5hqjk$f3l$1@xxxxxxxxe.org" type="cite">3
As CDO == EMF, you can easily adapt a generated RCP Client EMF
editor for CDO, but in practice you are likely better of to start
UI design from scratch, but you can re-use the concept of an
Editing domain and EMF.edit generated code, which is what I do.
(ItemProviders and Commands). </blockquote>
It's a major goal of CDO to better separate the functional from the
the technical design aspects/tasks. The only intrusive technical
aspect I can imagine of is large flat lists that should generally be
avoided in favour of a deeper object structure. IMHO this is a
useful rule even when only considering the usability of a graphical
application.<br>
<br>
<blockquote cite="mid:k5hqjk$f3l$1@xxxxxxxxe.org" type="cite">4
JFace databinding supports EMF, so JFace Databinding + CDO is a
great combination, you might want to watch loading large chunks of
data into your UI widgets (tables + trees), but there are ways to
limit the volumes. </blockquote>
I fully agree that EMF databinding is a totally cool thing. One
thing that tends to be problematic are remote deletions because the
databinding layer caches some strong references to objects that
might, all of a sudden, start to throw InvalidObjectExceptions or
ObjectNotFoundExceptions. You may appreciate that in CDO 4.2 we now
changed to:<br>
<br>
public static final CDOStaleReferencePolicy DEFAULT = PROXY;<br>
<br>
public static final CDOInvalidationPolicy DEFAULT = RELAXED;<br>
<br>
<br>
<blockquote cite="mid:k5hqjk$f3l$1@xxxxxxxxe.org" type="cite">5 I
you need to do something with DSL's (Develop a textual syntax,
which can interact with EMF/CDO models), this is also great with
xtext.
<br>
</blockquote>
Yes, because "CDO == EMF". But please keep in mind that editing DSL
instances stored *in* CDO with an Xtexteditor is problematic because
a text editor generally doesn't preserve the identities (e.g.
CDOIDs) of objects. That makes it hard to reconcile changes made in
a text editor back to CDO.<br>
<br>
<blockquote cite="mid:k5hqjk$f3l$1@xxxxxxxxe.org" type="cite">6
CDO performs well, you can tweak it, to fetch more or less chunks
of data for EReferences. If you don't like the behaviour you can
fire CDO Queries to get exactly what you want. Also unused objects
are garbage collected, so you can safely read a lot of data (As
long as you don't keep a reference). </blockquote>
Funnily this scalability originally came as a by-product of the
auditing functionality ;-)<br>
<br>
<blockquote cite="mid:k5hqjk$f3l$1@xxxxxxxxe.org" type="cite">7 I
am really fond that objects have a lifecycle, and all my object
have a unique CDO ID. I actually present the CDOID, in the status
line of the app. It's a great way to check what's going on. </blockquote>
And now you can even plug in your own CDOIDGenerator at the
client-side:<br>
<br>
public interface CDOIDGenerator<br>
{<br>
public static final CDOIDGenerator UUID = new CDOIDGenerator()<br>
{<br>
public CDOID generateCDOID(EObject object)<br>
{<br>
byte[] bytes = new byte[16];<br>
UUIDGenerator.DEFAULT.generate(bytes);<br>
return CDOIDUtil.createUUID(bytes);<br>
}<br>
<br>
public void reset()<br>
{<br>
// Do nothing<br>
}<br>
};<br>
<br>
/**<br>
* Generates a {@link CDOID}.<br>
* <br>
* @param object<br>
* the object to generate a new CDOID for if available,
<code>null</code> otherwise.<br>
*/<br>
public CDOID generateCDOID(EObject object);<br>
<br>
/**<br>
* Called at the end of a commit operation to give this ID
generator a chance to reset its sequence of IDs.<br>
*/<br>
public void reset();<br>
}<br>
<br>
<blockquote cite="mid:k5hqjk$f3l$1@xxxxxxxxe.org" type="cite">
8 Invalidations are great, basically when an object goes, remotely
dirty, other views are notified and can get the latest status of
an object. <br>
<br>
What I could do without in CDO
<br>
<br>
9. Revisions & referential integrity, I loved it at first, but
right now for the app. I have. it's a burden. The concept of
revisions adds a lot of requirements in CDO, I think CDO should
also have a simpler flat mode, without the revisions and checks on
integrity. It adds to the complexity of the CDO middleware and the
generated DB get's schema's. Some apps, don't need it or need it
partially. In my case, I would need revisions for some classes
only. </blockquote>
I suspect you don't refer to CDORevisions but to the auditing mode
in general? You know that it can be switched off. Granted, for the
DBStore in particular
<a class="moz-txt-link-freetext" href="https://bugs.eclipse.org/bugs/show_bug.cgi?id=351068">https://bugs.eclipse.org/bugs/show_bug.cgi?id=351068</a> is pending. I
really want to work on this soon.<br>
<br>
Partial auditing has been requested in the past. Conceptually I
don't like the idea because the framework couldn't guarantee the
logical consistency of the graph anymore. But I'm willing to
reconsider this when the DBStore gets its next design overhaul (not
scheduled, yet).<br>
<br>
What exact integrity checks are you referring to? Referential
integrity checks in the repository can be switched off (and they are
by default).<br>
<br>
<blockquote cite="mid:k5hqjk$f3l$1@xxxxxxxxe.org" type="cite">It
sometimes feels CDO is trying to mimic a Concurrent Version System
like SVN or CVS, but for many apps you really don't need that. <br>
</blockquote>
Yes, CDO tries to offer support in both worlds, the database
driven-like runtime applications and the more tool-like use cases
where design-time models need to be stored/managed in a repository.
You can imagine that this is sometimes hard but I think we've done a
pretty good job. Are there particular parts in CDO that are
problematic for you in this regard (i.e., not just unneeded)?<br>
<br>
BTW. an example of a cool new SCM-like feature is our new History
view support for repositories, branches or single objects:<br>
<br>
<img src="http://www.eclipse.org/forums/index.php?t=getfile&id=11871" alt=""><br>
<br>
<blockquote cite="mid:k5hqjk$f3l$1@xxxxxxxxe.org" type="cite">10.
In CDO there are CDOFolders and CDOResources. </blockquote>
Yes, and CDOTextResources and CDOBinaryResources, which are now
(almost) first class citizens of a CDO repository:<br>
<br>
<img src="http://www.eclipse.org/forums/index.php?t=getfile&id=11872" alt=""><br>
<br>
<blockquote cite="mid:k5hqjk$f3l$1@xxxxxxxxe.org" type="cite">Both
are also CDO objects, and stored in the DB. I went through great
length to find the best way to use them, like the the names to
give them, which is meta information you need to deal with in the
application. (Remember which name you used for which resource to
keep which data objects, in my case each eclass has its own
cdoresource). </blockquote>
Yes, that's the main value of Resources in general: They provide
well-known entry points into the (persistent) graph of objects.<br>
<br>
Apart from that they're an essential part of "CDO == EMF" (see point
1).<br>
<br>
<blockquote cite="mid:k5hqjk$f3l$1@xxxxxxxxe.org" type="cite">Right
now, I am not sure what the added value is of these, besides some
additional grouping of objects, I think, without them it could
keep CDO simpler and avoid additional DB data. </blockquote>
Please note that you absolutely don't need to use CDOResourceFolders
and CDOResources (except for a single one to contain all other
objects). The characteristics of a CDO model is the same when you
store all objects in a single resource.<br>
<br>
<blockquote cite="mid:k5hqjk$f3l$1@xxxxxxxxe.org" type="cite">(Note
that in point 3, I mentioned the EMF Editing domain, which has a
ResourceSet which can hold CDOResource objects. I use this, so
without CDO Resources, I wouldn't be able to use an editing
domain, so something else would be needed). <br>
</blockquote>
I think the generated editors also make heavy use of the assumption
that objects are contained by resources.<br>
<br>
<blockquote cite="mid:k5hqjk$f3l$1@xxxxxxxxe.org" type="cite">What
I wish for in CDO.
<br>
<br>
11. Model migrations. There are initiatives like COPE, which could
be applied with CDO, that would be great. So add a class in your
model, and let the new feature deal with the migration and transit
your data. </blockquote>
Fully agreed. If only someone would need it enough to open the
wallet and fund the development of this feature :P<br>
<br>
<blockquote cite="mid:k5hqjk$f3l$1@xxxxxxxxe.org" type="cite">12.
It's a hard learning curve, because most of the docs are outdated
or not written, so mea-culpa, we could do better. I wish for a
thriving community around a general purpose
smart-object-persistence system like CDO. <br>
</blockquote>
Yes! Technical writers in the world, here's a project that needs you
;-)<br>
<br>
<blockquote cite="mid:k5hqjk$f3l$1@xxxxxxxxe.org" type="cite">Finally.
Eike Stepper and others, have been great in supporting me on this
forum. Generally very quick and helpful!<br>
</blockquote>
Good docs would certainly be nicer but, while they're absent, good
online support is our attempt to compensate ;-)<br>
<br>
Cheers<br>
/Eike<br>
<br>
----<br>
<a class="moz-txt-link-freetext" href="http://www.esc-net.de">http://www.esc-net.de</a><br>
<a class="moz-txt-link-freetext" href="http://thegordian.blogspot.com">http://thegordian.blogspot.com</a><br>
<a class="moz-txt-link-freetext" href="http://twitter.com/eikestepper">http://twitter.com/eikestepper</a><br>
<br>
<br>
<br>
</body>
</html>
-
Attachment: bgchgghb.png
(Size: 83.23KB, Downloaded 148 times) -
Attachment: edjjaeef.png
(Size: 16.76KB, Downloaded 130 times)
Cheers
/Eike
----
http://www.esc-net.de
http://thegordian.blogspot.com
http://twitter.com/eikestepper
|
|
|
| Re: Understanding CDO [message #946378 is a reply to message #945941] |
Tue, 16 October 2012 06:30 |
|
<html>
<head>
<meta content="text/html; charset=UTF-8" http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
Hi Christophe,<br>
<br>
Thank you very much for your detailed experience report. I like it
lot ;-)<br>
<br>
More comments below...<br>
<br>
<br>
<div class="moz-cite-prefix">Am 15.10.2012 22:10, schrieb Christophe
Bouhier:<br>
</div>
<blockquote cite="mid:k5hqjk$f3l$1@xxxxxxxxe.org" type="cite">Hello
Mauro, <br>
for the last 2 years, I have been working on a client/server
application using CDO. Depending on your needs, CDO could be the
right fit. <br>
What I like (a lot). <br>
1 CDO == EMF, so you can model data first in .xsd or directly in
.ecore, and you can tell CDO to use your generated packages, which
will build the DB schema. </blockquote>
EMF compliance is very important to us and we're proud to support
most of EMF's features. Among the few exceptions are:<br>
<br>
a) Feature maps are hard to deal with in RDBs<br>
<br>
b) Because CDOResources are EObjects (see point 10) a small number
of other frameworks may run into trouble when trying to find out the
concrete type of a Notifier because the result depends on a
particular order of instanceof checks (check Resources first).<br>
<br>
c) With remote change notifications enabled, i.e.,
view.options().addChangeSubscriptionPolicy(...), your own Adapters
often need to distinguish between local or remote changes. An
instanceof CDODeltaNotification does the trick.<br>
<br>
d) Some IDE applications (and some poorly designed frameworks such
as GMF) heavily rely on IResources which are probably impossible to
simulate for CDOResources. For example it's hard or impossible to
present problem markers for validation problems in CDOResources
because IMarkers are associated with IResources. This is not a CDO
problem but a platform/IMarker problem that other
non-"platform:resource" Resources share in common.<br>
<br>
<blockquote cite="mid:k5hqjk$f3l$1@xxxxxxxxe.org" type="cite">2
On the CDO Store, you can choose from the DBStore, which supports
various DB's, I have worked with MySQL and Postgres. With
Hibernate store, there is an additional ORM layer, which works
with tons of other DB's supported by Hibernate. </blockquote>
And there's support for some other backend types, such as DB4O,
MongoDB or Objectivity/DB. I've recently developed a
RandomAccessFile based journaling store, named LissomeStore. It
still uses an RDB for a small and fixed number of indexes into the
random access file(s). For commits it uses a journal file and
adjusts the index tables asynchronously. The performance of large
commits can typically be increased by factor 600 in my tests.<br>
<br>
IMHO the great value of the IStore design is that it becomes a snap
to *change* the backend choice at any time without much impact on
the application (except you're making heavy use of backend-specifc
IQueryHandlers such as SQL or HQL).<br>
<br>
<blockquote cite="mid:k5hqjk$f3l$1@xxxxxxxxe.org" type="cite">3
As CDO == EMF, you can easily adapt a generated RCP Client EMF
editor for CDO, but in practice you are likely better of to start
UI design from scratch, but you can re-use the concept of an
Editing domain and EMF.edit generated code, which is what I do.
(ItemProviders and Commands). </blockquote>
It's a major goal of CDO to better separate the functional from the
the technical design aspects/tasks. The only intrusive technical
aspect I can imagine of is large flat lists that should generally be
avoided in favour of a deeper object structure. IMHO this is a
useful rule even when only considering the usability of a graphical
application.<br>
<br>
<blockquote cite="mid:k5hqjk$f3l$1@xxxxxxxxe.org" type="cite">4
JFace databinding supports EMF, so JFace Databinding + CDO is a
great combination, you might want to watch loading large chunks of
data into your UI widgets (tables + trees), but there are ways to
limit the volumes. </blockquote>
I fully agree that EMF databinding is a totally cool thing. One
thing that tends to be problematic are remote deletions because the
databinding layer caches some strong references to objects that
might, all of a sudden, start to throw InvalidObjectExceptions or
ObjectNotFoundExceptions. You may appreciate that in CDO 4.2 we now
changed to:<br>
<br>
public static final CDOStaleReferencePolicy DEFAULT = PROXY;<br>
<br>
public static final CDOInvalidationPolicy DEFAULT = RELAXED;<br>
<br>
<br>
<blockquote cite="mid:k5hqjk$f3l$1@xxxxxxxxe.org" type="cite">5 I
you need to do something with DSL's (Develop a textual syntax,
which can interact with EMF/CDO models), this is also great with
xtext.
<br>
</blockquote>
Yes, because "CDO == EMF". But please keep in mind that editing DSL
instances stored *in* CDO with an Xtexteditor is problematic because
a text editor generally doesn't preserve the identities (e.g.
CDOIDs) of objects. That makes it hard to reconcile changes made in
a text editor back to CDO.<br>
<br>
<blockquote cite="mid:k5hqjk$f3l$1@xxxxxxxxe.org" type="cite">6
CDO performs well, you can tweak it, to fetch more or less chunks
of data for EReferences. If you don't like the behaviour you can
fire CDO Queries to get exactly what you want. Also unused objects
are garbage collected, so you can safely read a lot of data (As
long as you don't keep a reference). </blockquote>
Funnily this scalability originally came as a by-product of the
auditing functionality ;-)<br>
<br>
<blockquote cite="mid:k5hqjk$f3l$1@xxxxxxxxe.org" type="cite">7 I
am really fond that objects have a lifecycle, and all my object
have a unique CDO ID. I actually present the CDOID, in the status
line of the app. It's a great way to check what's going on. </blockquote>
And now you can even plug in your own CDOIDGenerator at the
client-side:<br>
<br>
public interface CDOIDGenerator<br>
{<br>
public static final CDOIDGenerator UUID = new CDOIDGenerator()<br>
{<br>
public CDOID generateCDOID(EObject object)<br>
{<br>
byte[] bytes = new byte[16];<br>
UUIDGenerator.DEFAULT.generate(bytes);<br>
return CDOIDUtil.createUUID(bytes);<br>
}<br>
<br>
public void reset()<br>
{<br>
// Do nothing<br>
}<br>
};<br>
<br>
/**<br>
* Generates a {@link CDOID}.<br>
* <br>
* @param object<br>
* the object to generate a new CDOID for if available,
<code>null</code> otherwise.<br>
*/<br>
public CDOID generateCDOID(EObject object);<br>
<br>
/**<br>
* Called at the end of a commit operation to give this ID
generator a chance to reset its sequence of IDs.<br>
*/<br>
public void reset();<br>
}<br>
<br>
<blockquote cite="mid:k5hqjk$f3l$1@xxxxxxxxe.org" type="cite">
8 Invalidations are great, basically when an object goes, remotely
dirty, other views are notified and can get the latest status of
an object. <br>
<br>
What I could do without in CDO
<br>
<br>
9. Revisions & referential integrity, I loved it at first, but
right now for the app. I have. it's a burden. The concept of
revisions adds a lot of requirements in CDO, I think CDO should
also have a simpler flat mode, without the revisions and checks on
integrity. It adds to the complexity of the CDO middleware and the
generated DB get's schema's. Some apps, don't need it or need it
partially. In my case, I would need revisions for some classes
only. </blockquote>
I suspect you don't refer to CDORevisions but to the auditing mode
in general? You know that it can be switched off. Granted, for the
DBStore in particular
<a class="moz-txt-link-freetext" href="https://bugs.eclipse.org/bugs/show_bug.cgi?id=351068">https://bugs.eclipse.org/bugs/show_bug.cgi?id=351068</a> is pending. I
really want to work on this soon.<br>
<br>
Partial auditing has been requested in the past. Conceptually I
don't like the idea because the framework couldn't guarantee the
logical consistency of the graph anymore. But I'm willing to
reconsider this when the DBStore gets its next design overhaul (not
scheduled, yet).<br>
<br>
What exact integrity checks are you referring to? Referential
integrity checks in the repository can be switched off (and they are
by default).<br>
<br>
<blockquote cite="mid:k5hqjk$f3l$1@xxxxxxxxe.org" type="cite">It
sometimes feels CDO is trying to mimic a Concurrent Version System
like SVN or CVS, but for many apps you really don't need that. <br>
</blockquote>
Yes, CDO tries to offer support in both worlds, the database
driven-like runtime applications and the more tool-like use cases
where design-time models need to be stored/managed in a repository.
You can imagine that this is sometimes hard but I think we've done a
pretty good job. Are there particular parts in CDO that are
problematic for you in this regard (i.e., not just unneeded)?<br>
<br>
BTW. an example of a cool new SCM-like feature is our new History
view support for repositories, branches or single objects:<br>
<br>
<img src="http://www.eclipse.org/forums/index.php?t=getfile&id=11873" alt=""><br>
<br>
<blockquote cite="mid:k5hqjk$f3l$1@xxxxxxxxe.org" type="cite">10.
In CDO there are CDOFolders and CDOResources. </blockquote>
Yes, and CDOTextResources and CDOBinaryResources, which are now
(almost) first class citizens of a CDO repository:<br>
<br>
<img src="http://www.eclipse.org/forums/index.php?t=getfile&id=11874" alt=""><br>
<br>
<blockquote cite="mid:k5hqjk$f3l$1@xxxxxxxxe.org" type="cite">Both
are also CDO objects, and stored in the DB. I went through great
length to find the best way to use them, like the the names to
give them, which is meta information you need to deal with in the
application. (Remember which name you used for which resource to
keep which data objects, in my case each eclass has its own
cdoresource). </blockquote>
Yes, that's the main value of Resources in general: They provide
well-known entry points into the (persistent) graph of objects.<br>
<br>
Apart from that they're an essential part of "CDO == EMF" (see point
1).<br>
<br>
<blockquote cite="mid:k5hqjk$f3l$1@xxxxxxxxe.org" type="cite">Right
now, I am not sure what the added value is of these, besides some
additional grouping of objects, I think, without them it could
keep CDO simpler and avoid additional DB data. </blockquote>
Please note that you absolutely don't need to use CDOResourceFolders
and CDOResources (except for a single one to contain all other
objects). The characteristics of a CDO model is the same when you
store all objects in a single resource.<br>
<br>
<blockquote cite="mid:k5hqjk$f3l$1@xxxxxxxxe.org" type="cite">(Note
that in point 3, I mentioned the EMF Editing domain, which has a
ResourceSet which can hold CDOResource objects. I use this, so
without CDO Resources, I wouldn't be able to use an editing
domain, so something else would be needed). <br>
</blockquote>
I think the generated editors also make heavy use of the assumption
that objects are contained by resources.<br>
<br>
<blockquote cite="mid:k5hqjk$f3l$1@xxxxxxxxe.org" type="cite">What
I wish for in CDO.
<br>
<br>
11. Model migrations. There are initiatives like COPE, which could
be applied with CDO, that would be great. So add a class in your
model, and let the new feature deal with the migration and transit
your data. </blockquote>
Fully agreed. If only someone would need it enough to open the
wallet and fund the development of this feature :P<br>
<br>
<blockquote cite="mid:k5hqjk$f3l$1@xxxxxxxxe.org" type="cite">12.
It's a hard learning curve, because most of the docs are outdated
or not written, so mea-culpa, we could do better. I wish for a
thriving community around a general purpose
smart-object-persistence system like CDO. <br>
</blockquote>
Yes! Technical writers in the world, here's a project that needs you
;-)<br>
<br>
<blockquote cite="mid:k5hqjk$f3l$1@xxxxxxxxe.org" type="cite">Finally.
Eike Stepper and others, have been great in supporting me on this
forum. Generally very quick and helpful!<br>
</blockquote>
Good docs would certainly be nicer but, while they're absent, good
online support is our attempt to compensate ;-)<br>
<br>
Cheers<br>
/Eike<br>
<br>
----<br>
<a class="moz-txt-link-freetext" href="http://www.esc-net.de">http://www.esc-net.de</a><br>
<a class="moz-txt-link-freetext" href="http://thegordian.blogspot.com">http://thegordian.blogspot.com</a><br>
<a class="moz-txt-link-freetext" href="http://twitter.com/eikestepper">http://twitter.com/eikestepper</a><br>
<br>
<br>
<br>
</body>
</html>
-
Attachment: bgchgghb.png
(Size: 83.23KB, Downloaded 148 times) -
Attachment: edjjaeef.png
(Size: 16.76KB, Downloaded 136 times)
Cheers
/Eike
----
http://www.esc-net.de
http://thegordian.blogspot.com
http://twitter.com/eikestepper
|
|
|
| Re: Understanding CDO [message #946384 is a reply to message #945941] |
Tue, 16 October 2012 06:30 |
|
<html>
<head>
<meta content="text/html; charset=UTF-8" http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
Hi Christophe,<br>
<br>
Thank you very much for your detailed experience report. I like it
lot ;-)<br>
<br>
More comments below...<br>
<br>
<br>
<div class="moz-cite-prefix">Am 15.10.2012 22:10, schrieb Christophe
Bouhier:<br>
</div>
<blockquote cite="mid:k5hqjk$f3l$1@xxxxxxxxe.org" type="cite">Hello
Mauro, <br>
for the last 2 years, I have been working on a client/server
application using CDO. Depending on your needs, CDO could be the
right fit. <br>
What I like (a lot). <br>
1 CDO == EMF, so you can model data first in .xsd or directly in
.ecore, and you can tell CDO to use your generated packages, which
will build the DB schema. </blockquote>
EMF compliance is very important to us and we're proud to support
most of EMF's features. Among the few exceptions are:<br>
<br>
a) Feature maps are hard to deal with in RDBs<br>
<br>
b) Because CDOResources are EObjects (see point 10) a small number
of other frameworks may run into trouble when trying to find out the
concrete type of a Notifier because the result depends on a
particular order of instanceof checks (check Resources first).<br>
<br>
c) With remote change notifications enabled, i.e.,
view.options().addChangeSubscriptionPolicy(...), your own Adapters
often need to distinguish between local or remote changes. An
instanceof CDODeltaNotification does the trick.<br>
<br>
d) Some IDE applications (and some poorly designed frameworks such
as GMF) heavily rely on IResources which are probably impossible to
simulate for CDOResources. For example it's hard or impossible to
present problem markers for validation problems in CDOResources
because IMarkers are associated with IResources. This is not a CDO
problem but a platform/IMarker problem that other
non-"platform:resource" Resources share in common.<br>
<br>
<blockquote cite="mid:k5hqjk$f3l$1@xxxxxxxxe.org" type="cite">2
On the CDO Store, you can choose from the DBStore, which supports
various DB's, I have worked with MySQL and Postgres. With
Hibernate store, there is an additional ORM layer, which works
with tons of other DB's supported by Hibernate. </blockquote>
And there's support for some other backend types, such as DB4O,
MongoDB or Objectivity/DB. I've recently developed a
RandomAccessFile based journaling store, named LissomeStore. It
still uses an RDB for a small and fixed number of indexes into the
random access file(s). For commits it uses a journal file and
adjusts the index tables asynchronously. The performance of large
commits can typically be increased by factor 600 in my tests.<br>
<br>
IMHO the great value of the IStore design is that it becomes a snap
to *change* the backend choice at any time without much impact on
the application (except you're making heavy use of backend-specifc
IQueryHandlers such as SQL or HQL).<br>
<br>
<blockquote cite="mid:k5hqjk$f3l$1@xxxxxxxxe.org" type="cite">3
As CDO == EMF, you can easily adapt a generated RCP Client EMF
editor for CDO, but in practice you are likely better of to start
UI design from scratch, but you can re-use the concept of an
Editing domain and EMF.edit generated code, which is what I do.
(ItemProviders and Commands). </blockquote>
It's a major goal of CDO to better separate the functional from the
the technical design aspects/tasks. The only intrusive technical
aspect I can imagine of is large flat lists that should generally be
avoided in favour of a deeper object structure. IMHO this is a
useful rule even when only considering the usability of a graphical
application.<br>
<br>
<blockquote cite="mid:k5hqjk$f3l$1@xxxxxxxxe.org" type="cite">4
JFace databinding supports EMF, so JFace Databinding + CDO is a
great combination, you might want to watch loading large chunks of
data into your UI widgets (tables + trees), but there are ways to
limit the volumes. </blockquote>
I fully agree that EMF databinding is a totally cool thing. One
thing that tends to be problematic are remote deletions because the
databinding layer caches some strong references to objects that
might, all of a sudden, start to throw InvalidObjectExceptions or
ObjectNotFoundExceptions. You may appreciate that in CDO 4.2 we now
changed to:<br>
<br>
public static final CDOStaleReferencePolicy DEFAULT = PROXY;<br>
<br>
public static final CDOInvalidationPolicy DEFAULT = RELAXED;<br>
<br>
<br>
<blockquote cite="mid:k5hqjk$f3l$1@xxxxxxxxe.org" type="cite">5 I
you need to do something with DSL's (Develop a textual syntax,
which can interact with EMF/CDO models), this is also great with
xtext.
<br>
</blockquote>
Yes, because "CDO == EMF". But please keep in mind that editing DSL
instances stored *in* CDO with an Xtexteditor is problematic because
a text editor generally doesn't preserve the identities (e.g.
CDOIDs) of objects. That makes it hard to reconcile changes made in
a text editor back to CDO.<br>
<br>
<blockquote cite="mid:k5hqjk$f3l$1@xxxxxxxxe.org" type="cite">6
CDO performs well, you can tweak it, to fetch more or less chunks
of data for EReferences. If you don't like the behaviour you can
fire CDO Queries to get exactly what you want. Also unused objects
are garbage collected, so you can safely read a lot of data (As
long as you don't keep a reference). </blockquote>
Funnily this scalability originally came as a by-product of the
auditing functionality ;-)<br>
<br>
<blockquote cite="mid:k5hqjk$f3l$1@xxxxxxxxe.org" type="cite">7 I
am really fond that objects have a lifecycle, and all my object
have a unique CDO ID. I actually present the CDOID, in the status
line of the app. It's a great way to check what's going on. </blockquote>
And now you can even plug in your own CDOIDGenerator at the
client-side:<br>
<br>
public interface CDOIDGenerator<br>
{<br>
public static final CDOIDGenerator UUID = new CDOIDGenerator()<br>
{<br>
public CDOID generateCDOID(EObject object)<br>
{<br>
byte[] bytes = new byte[16];<br>
UUIDGenerator.DEFAULT.generate(bytes);<br>
return CDOIDUtil.createUUID(bytes);<br>
}<br>
<br>
public void reset()<br>
{<br>
// Do nothing<br>
}<br>
};<br>
<br>
/**<br>
* Generates a {@link CDOID}.<br>
* <br>
* @param object<br>
* the object to generate a new CDOID for if available,
<code>null</code> otherwise.<br>
*/<br>
public CDOID generateCDOID(EObject object);<br>
<br>
/**<br>
* Called at the end of a commit operation to give this ID
generator a chance to reset its sequence of IDs.<br>
*/<br>
public void reset();<br>
}<br>
<br>
<blockquote cite="mid:k5hqjk$f3l$1@xxxxxxxxe.org" type="cite">
8 Invalidations are great, basically when an object goes, remotely
dirty, other views are notified and can get the latest status of
an object. <br>
<br>
What I could do without in CDO
<br>
<br>
9. Revisions & referential integrity, I loved it at first, but
right now for the app. I have. it's a burden. The concept of
revisions adds a lot of requirements in CDO, I think CDO should
also have a simpler flat mode, without the revisions and checks on
integrity. It adds to the complexity of the CDO middleware and the
generated DB get's schema's. Some apps, don't need it or need it
partially. In my case, I would need revisions for some classes
only. </blockquote>
I suspect you don't refer to CDORevisions but to the auditing mode
in general? You know that it can be switched off. Granted, for the
DBStore in particular
<a class="moz-txt-link-freetext" href="https://bugs.eclipse.org/bugs/show_bug.cgi?id=351068">https://bugs.eclipse.org/bugs/show_bug.cgi?id=351068</a> is pending. I
really want to work on this soon.<br>
<br>
Partial auditing has been requested in the past. Conceptually I
don't like the idea because the framework couldn't guarantee the
logical consistency of the graph anymore. But I'm willing to
reconsider this when the DBStore gets its next design overhaul (not
scheduled, yet).<br>
<br>
What exact integrity checks are you referring to? Referential
integrity checks in the repository can be switched off (and they are
by default).<br>
<br>
<blockquote cite="mid:k5hqjk$f3l$1@xxxxxxxxe.org" type="cite">It
sometimes feels CDO is trying to mimic a Concurrent Version System
like SVN or CVS, but for many apps you really don't need that. <br>
</blockquote>
Yes, CDO tries to offer support in both worlds, the database
driven-like runtime applications and the more tool-like use cases
where design-time models need to be stored/managed in a repository.
You can imagine that this is sometimes hard but I think we've done a
pretty good job. Are there particular parts in CDO that are
problematic for you in this regard (i.e., not just unneeded)?<br>
<br>
BTW. an example of a cool new SCM-like feature is our new History
view support for repositories, branches or single objects:<br>
<br>
<img src="http://www.eclipse.org/forums/index.php?t=getfile&id=11875" alt=""><br>
<br>
<blockquote cite="mid:k5hqjk$f3l$1@xxxxxxxxe.org" type="cite">10.
In CDO there are CDOFolders and CDOResources. </blockquote>
Yes, and CDOTextResources and CDOBinaryResources, which are now
(almost) first class citizens of a CDO repository:<br>
<br>
<img src="http://www.eclipse.org/forums/index.php?t=getfile&id=11876" alt=""><br>
<br>
<blockquote cite="mid:k5hqjk$f3l$1@xxxxxxxxe.org" type="cite">Both
are also CDO objects, and stored in the DB. I went through great
length to find the best way to use them, like the the names to
give them, which is meta information you need to deal with in the
application. (Remember which name you used for which resource to
keep which data objects, in my case each eclass has its own
cdoresource). </blockquote>
Yes, that's the main value of Resources in general: They provide
well-known entry points into the (persistent) graph of objects.<br>
<br>
Apart from that they're an essential part of "CDO == EMF" (see point
1).<br>
<br>
<blockquote cite="mid:k5hqjk$f3l$1@xxxxxxxxe.org" type="cite">Right
now, I am not sure what the added value is of these, besides some
additional grouping of objects, I think, without them it could
keep CDO simpler and avoid additional DB data. </blockquote>
Please note that you absolutely don't need to use CDOResourceFolders
and CDOResources (except for a single one to contain all other
objects). The characteristics of a CDO model is the same when you
store all objects in a single resource.<br>
<br>
<blockquote cite="mid:k5hqjk$f3l$1@xxxxxxxxe.org" type="cite">(Note
that in point 3, I mentioned the EMF Editing domain, which has a
ResourceSet which can hold CDOResource objects. I use this, so
without CDO Resources, I wouldn't be able to use an editing
domain, so something else would be needed). <br>
</blockquote>
I think the generated editors also make heavy use of the assumption
that objects are contained by resources.<br>
<br>
<blockquote cite="mid:k5hqjk$f3l$1@xxxxxxxxe.org" type="cite">What
I wish for in CDO.
<br>
<br>
11. Model migrations. There are initiatives like COPE, which could
be applied with CDO, that would be great. So add a class in your
model, and let the new feature deal with the migration and transit
your data. </blockquote>
Fully agreed. If only someone would need it enough to open the
wallet and fund the development of this feature :P<br>
<br>
<blockquote cite="mid:k5hqjk$f3l$1@xxxxxxxxe.org" type="cite">12.
It's a hard learning curve, because most of the docs are outdated
or not written, so mea-culpa, we could do better. I wish for a
thriving community around a general purpose
smart-object-persistence system like CDO. <br>
</blockquote>
Yes! Technical writers in the world, here's a project that needs you
;-)<br>
<br>
<blockquote cite="mid:k5hqjk$f3l$1@xxxxxxxxe.org" type="cite">Finally.
Eike Stepper and others, have been great in supporting me on this
forum. Generally very quick and helpful!<br>
</blockquote>
Good docs would certainly be nicer but, while they're absent, good
online support is our attempt to compensate ;-)<br>
<br>
Cheers<br>
/Eike<br>
<br>
----<br>
<a class="moz-txt-link-freetext" href="http://www.esc-net.de">http://www.esc-net.de</a><br>
<a class="moz-txt-link-freetext" href="http://thegordian.blogspot.com">http://thegordian.blogspot.com</a><br>
<a class="moz-txt-link-freetext" href="http://twitter.com/eikestepper">http://twitter.com/eikestepper</a><br>
<br>
<br>
<br>
</body>
</html>
-
Attachment: bgchgghb.png
(Size: 83.23KB, Downloaded 126 times) -
Attachment: edjjaeef.png
(Size: 16.76KB, Downloaded 132 times)
Cheers
/Eike
----
http://www.esc-net.de
http://thegordian.blogspot.com
http://twitter.com/eikestepper
|
|
|
| Re: Understanding CDO [message #946391 is a reply to message #945941] |
Tue, 16 October 2012 06:30 |
|
<html>
<head>
<meta content="text/html; charset=UTF-8" http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
Hi Christophe,<br>
<br>
Thank you very much for your detailed experience report. I like it
lot ;-)<br>
<br>
More comments below...<br>
<br>
<br>
<div class="moz-cite-prefix">Am 15.10.2012 22:10, schrieb Christophe
Bouhier:<br>
</div>
<blockquote cite="mid:k5hqjk$f3l$1@xxxxxxxxe.org" type="cite">Hello
Mauro, <br>
for the last 2 years, I have been working on a client/server
application using CDO. Depending on your needs, CDO could be the
right fit. <br>
What I like (a lot). <br>
1 CDO == EMF, so you can model data first in .xsd or directly in
.ecore, and you can tell CDO to use your generated packages, which
will build the DB schema. </blockquote>
EMF compliance is very important to us and we're proud to support
most of EMF's features. Among the few exceptions are:<br>
<br>
a) Feature maps are hard to deal with in RDBs<br>
<br>
b) Because CDOResources are EObjects (see point 10) a small number
of other frameworks may run into trouble when trying to find out the
concrete type of a Notifier because the result depends on a
particular order of instanceof checks (check Resources first).<br>
<br>
c) With remote change notifications enabled, i.e.,
view.options().addChangeSubscriptionPolicy(...), your own Adapters
often need to distinguish between local or remote changes. An
instanceof CDODeltaNotification does the trick.<br>
<br>
d) Some IDE applications (and some poorly designed frameworks such
as GMF) heavily rely on IResources which are probably impossible to
simulate for CDOResources. For example it's hard or impossible to
present problem markers for validation problems in CDOResources
because IMarkers are associated with IResources. This is not a CDO
problem but a platform/IMarker problem that other
non-"platform:resource" Resources share in common.<br>
<br>
<blockquote cite="mid:k5hqjk$f3l$1@xxxxxxxxe.org" type="cite">2
On the CDO Store, you can choose from the DBStore, which supports
various DB's, I have worked with MySQL and Postgres. With
Hibernate store, there is an additional ORM layer, which works
with tons of other DB's supported by Hibernate. </blockquote>
And there's support for some other backend types, such as DB4O,
MongoDB or Objectivity/DB. I've recently developed a
RandomAccessFile based journaling store, named LissomeStore. It
still uses an RDB for a small and fixed number of indexes into the
random access file(s). For commits it uses a journal file and
adjusts the index tables asynchronously. The performance of large
commits can typically be increased by factor 600 in my tests.<br>
<br>
IMHO the great value of the IStore design is that it becomes a snap
to *change* the backend choice at any time without much impact on
the application (except you're making heavy use of backend-specifc
IQueryHandlers such as SQL or HQL).<br>
<br>
<blockquote cite="mid:k5hqjk$f3l$1@xxxxxxxxe.org" type="cite">3
As CDO == EMF, you can easily adapt a generated RCP Client EMF
editor for CDO, but in practice you are likely better of to start
UI design from scratch, but you can re-use the concept of an
Editing domain and EMF.edit generated code, which is what I do.
(ItemProviders and Commands). </blockquote>
It's a major goal of CDO to better separate the functional from the
the technical design aspects/tasks. The only intrusive technical
aspect I can imagine of is large flat lists that should generally be
avoided in favour of a deeper object structure. IMHO this is a
useful rule even when only considering the usability of a graphical
application.<br>
<br>
<blockquote cite="mid:k5hqjk$f3l$1@xxxxxxxxe.org" type="cite">4
JFace databinding supports EMF, so JFace Databinding + CDO is a
great combination, you might want to watch loading large chunks of
data into your UI widgets (tables + trees), but there are ways to
limit the volumes. </blockquote>
I fully agree that EMF databinding is a totally cool thing. One
thing that tends to be problematic are remote deletions because the
databinding layer caches some strong references to objects that
might, all of a sudden, start to throw InvalidObjectExceptions or
ObjectNotFoundExceptions. You may appreciate that in CDO 4.2 we now
changed to:<br>
<br>
public static final CDOStaleReferencePolicy DEFAULT = PROXY;<br>
<br>
public static final CDOInvalidationPolicy DEFAULT = RELAXED;<br>
<br>
<br>
<blockquote cite="mid:k5hqjk$f3l$1@xxxxxxxxe.org" type="cite">5 I
you need to do something with DSL's (Develop a textual syntax,
which can interact with EMF/CDO models), this is also great with
xtext.
<br>
</blockquote>
Yes, because "CDO == EMF". But please keep in mind that editing DSL
instances stored *in* CDO with an Xtexteditor is problematic because
a text editor generally doesn't preserve the identities (e.g.
CDOIDs) of objects. That makes it hard to reconcile changes made in
a text editor back to CDO.<br>
<br>
<blockquote cite="mid:k5hqjk$f3l$1@xxxxxxxxe.org" type="cite">6
CDO performs well, you can tweak it, to fetch more or less chunks
of data for EReferences. If you don't like the behaviour you can
fire CDO Queries to get exactly what you want. Also unused objects
are garbage collected, so you can safely read a lot of data (As
long as you don't keep a reference). </blockquote>
Funnily this scalability originally came as a by-product of the
auditing functionality ;-)<br>
<br>
<blockquote cite="mid:k5hqjk$f3l$1@xxxxxxxxe.org" type="cite">7 I
am really fond that objects have a lifecycle, and all my object
have a unique CDO ID. I actually present the CDOID, in the status
line of the app. It's a great way to check what's going on. </blockquote>
And now you can even plug in your own CDOIDGenerator at the
client-side:<br>
<br>
public interface CDOIDGenerator<br>
{<br>
public static final CDOIDGenerator UUID = new CDOIDGenerator()<br>
{<br>
public CDOID generateCDOID(EObject object)<br>
{<br>
byte[] bytes = new byte[16];<br>
UUIDGenerator.DEFAULT.generate(bytes);<br>
return CDOIDUtil.createUUID(bytes);<br>
}<br>
<br>
public void reset()<br>
{<br>
// Do nothing<br>
}<br>
};<br>
<br>
/**<br>
* Generates a {@link CDOID}.<br>
* <br>
* @param object<br>
* the object to generate a new CDOID for if available,
<code>null</code> otherwise.<br>
*/<br>
public CDOID generateCDOID(EObject object);<br>
<br>
/**<br>
* Called at the end of a commit operation to give this ID
generator a chance to reset its sequence of IDs.<br>
*/<br>
public void reset();<br>
}<br>
<br>
<blockquote cite="mid:k5hqjk$f3l$1@xxxxxxxxe.org" type="cite">
8 Invalidations are great, basically when an object goes, remotely
dirty, other views are notified and can get the latest status of
an object. <br>
<br>
What I could do without in CDO
<br>
<br>
9. Revisions & referential integrity, I loved it at first, but
right now for the app. I have. it's a burden. The concept of
revisions adds a lot of requirements in CDO, I think CDO should
also have a simpler flat mode, without the revisions and checks on
integrity. It adds to the complexity of the CDO middleware and the
generated DB get's schema's. Some apps, don't need it or need it
partially. In my case, I would need revisions for some classes
only. </blockquote>
I suspect you don't refer to CDORevisions but to the auditing mode
in general? You know that it can be switched off. Granted, for the
DBStore in particular
<a class="moz-txt-link-freetext" href="https://bugs.eclipse.org/bugs/show_bug.cgi?id=351068">https://bugs.eclipse.org/bugs/show_bug.cgi?id=351068</a> is pending. I
really want to work on this soon.<br>
<br>
Partial auditing has been requested in the past. Conceptually I
don't like the idea because the framework couldn't guarantee the
logical consistency of the graph anymore. But I'm willing to
reconsider this when the DBStore gets its next design overhaul (not
scheduled, yet).<br>
<br>
What exact integrity checks are you referring to? Referential
integrity checks in the repository can be switched off (and they are
by default).<br>
<br>
<blockquote cite="mid:k5hqjk$f3l$1@xxxxxxxxe.org" type="cite">It
sometimes feels CDO is trying to mimic a Concurrent Version System
like SVN or CVS, but for many apps you really don't need that. <br>
</blockquote>
Yes, CDO tries to offer support in both worlds, the database
driven-like runtime applications and the more tool-like use cases
where design-time models need to be stored/managed in a repository.
You can imagine that this is sometimes hard but I think we've done a
pretty good job. Are there particular parts in CDO that are
problematic for you in this regard (i.e., not just unneeded)?<br>
<br>
BTW. an example of a cool new SCM-like feature is our new History
view support for repositories, branches or single objects:<br>
<br>
<img src="http://www.eclipse.org/forums/index.php?t=getfile&id=11877" alt=""><br>
<br>
<blockquote cite="mid:k5hqjk$f3l$1@xxxxxxxxe.org" type="cite">10.
In CDO there are CDOFolders and CDOResources. </blockquote>
Yes, and CDOTextResources and CDOBinaryResources, which are now
(almost) first class citizens of a CDO repository:<br>
<br>
<img src="http://www.eclipse.org/forums/index.php?t=getfile&id=11878" alt=""><br>
<br>
<blockquote cite="mid:k5hqjk$f3l$1@xxxxxxxxe.org" type="cite">Both
are also CDO objects, and stored in the DB. I went through great
length to find the best way to use them, like the the names to
give them, which is meta information you need to deal with in the
application. (Remember which name you used for which resource to
keep which data objects, in my case each eclass has its own
cdoresource). </blockquote>
Yes, that's the main value of Resources in general: They provide
well-known entry points into the (persistent) graph of objects.<br>
<br>
Apart from that they're an essential part of "CDO == EMF" (see point
1).<br>
<br>
<blockquote cite="mid:k5hqjk$f3l$1@xxxxxxxxe.org" type="cite">Right
now, I am not sure what the added value is of these, besides some
additional grouping of objects, I think, without them it could
keep CDO simpler and avoid additional DB data. </blockquote>
Please note that you absolutely don't need to use CDOResourceFolders
and CDOResources (except for a single one to contain all other
objects). The characteristics of a CDO model is the same when you
store all objects in a single resource.<br>
<br>
<blockquote cite="mid:k5hqjk$f3l$1@xxxxxxxxe.org" type="cite">(Note
that in point 3, I mentioned the EMF Editing domain, which has a
ResourceSet which can hold CDOResource objects. I use this, so
without CDO Resources, I wouldn't be able to use an editing
domain, so something else would be needed). <br>
</blockquote>
I think the generated editors also make heavy use of the assumption
that objects are contained by resources.<br>
<br>
<blockquote cite="mid:k5hqjk$f3l$1@xxxxxxxxe.org" type="cite">What
I wish for in CDO.
<br>
<br>
11. Model migrations. There are initiatives like COPE, which could
be applied with CDO, that would be great. So add a class in your
model, and let the new feature deal with the migration and transit
your data. </blockquote>
Fully agreed. If only someone would need it enough to open the
wallet and fund the development of this feature :P<br>
<br>
<blockquote cite="mid:k5hqjk$f3l$1@xxxxxxxxe.org" type="cite">12.
It's a hard learning curve, because most of the docs are outdated
or not written, so mea-culpa, we could do better. I wish for a
thriving community around a general purpose
smart-object-persistence system like CDO. <br>
</blockquote>
Yes! Technical writers in the world, here's a project that needs you
;-)<br>
<br>
<blockquote cite="mid:k5hqjk$f3l$1@xxxxxxxxe.org" type="cite">Finally.
Eike Stepper and others, have been great in supporting me on this
forum. Generally very quick and helpful!<br>
</blockquote>
Good docs would certainly be nicer but, while they're absent, good
online support is our attempt to compensate ;-)<br>
<br>
Cheers<br>
/Eike<br>
<br>
----<br>
<a class="moz-txt-link-freetext" href="http://www.esc-net.de">http://www.esc-net.de</a><br>
<a class="moz-txt-link-freetext" href="http://thegordian.blogspot.com">http://thegordian.blogspot.com</a><br>
<a class="moz-txt-link-freetext" href="http://twitter.com/eikestepper">http://twitter.com/eikestepper</a><br>
<br>
<br>
<br>
</body>
</html>
-
Attachment: bgchgghb.png
(Size: 83.23KB, Downloaded 147 times) -
Attachment: edjjaeef.png
(Size: 16.76KB, Downloaded 133 times)
Cheers
/Eike
----
http://www.esc-net.de
http://thegordian.blogspot.com
http://twitter.com/eikestepper
|
|
|
| Re: Understanding CDO [message #946397 is a reply to message #945941] |
Tue, 16 October 2012 06:30 |
|
<html>
<head>
<meta content="text/html; charset=UTF-8" http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
Hi Christophe,<br>
<br>
Thank you very much for your detailed experience report. I like it
lot ;-)<br>
<br>
More comments below...<br>
<br>
<br>
<div class="moz-cite-prefix">Am 15.10.2012 22:10, schrieb Christophe
Bouhier:<br>
</div>
<blockquote cite="mid:k5hqjk$f3l$1@xxxxxxxxe.org" type="cite">Hello
Mauro, <br>
for the last 2 years, I have been working on a client/server
application using CDO. Depending on your needs, CDO could be the
right fit. <br>
What I like (a lot). <br>
1 CDO == EMF, so you can model data first in .xsd or directly in
.ecore, and you can tell CDO to use your generated packages, which
will build the DB schema. </blockquote>
EMF compliance is very important to us and we're proud to support
most of EMF's features. Among the few exceptions are:<br>
<br>
a) Feature maps are hard to deal with in RDBs<br>
<br>
b) Because CDOResources are EObjects (see point 10) a small number
of other frameworks may run into trouble when trying to find out the
concrete type of a Notifier because the result depends on a
particular order of instanceof checks (check Resources first).<br>
<br>
c) With remote change notifications enabled, i.e.,
view.options().addChangeSubscriptionPolicy(...), your own Adapters
often need to distinguish between local or remote changes. An
instanceof CDODeltaNotification does the trick.<br>
<br>
d) Some IDE applications (and some poorly designed frameworks such
as GMF) heavily rely on IResources which are probably impossible to
simulate for CDOResources. For example it's hard or impossible to
present problem markers for validation problems in CDOResources
because IMarkers are associated with IResources. This is not a CDO
problem but a platform/IMarker problem that other
non-"platform:resource" Resources share in common.<br>
<br>
<blockquote cite="mid:k5hqjk$f3l$1@xxxxxxxxe.org" type="cite">2
On the CDO Store, you can choose from the DBStore, which supports
various DB's, I have worked with MySQL and Postgres. With
Hibernate store, there is an additional ORM layer, which works
with tons of other DB's supported by Hibernate. </blockquote>
And there's support for some other backend types, such as DB4O,
MongoDB or Objectivity/DB. I've recently developed a
RandomAccessFile based journaling store, named LissomeStore. It
still uses an RDB for a small and fixed number of indexes into the
random access file(s). For commits it uses a journal file and
adjusts the index tables asynchronously. The performance of large
commits can typically be increased by factor 600 in my tests.<br>
<br>
IMHO the great value of the IStore design is that it becomes a snap
to *change* the backend choice at any time without much impact on
the application (except you're making heavy use of backend-specifc
IQueryHandlers such as SQL or HQL).<br>
<br>
<blockquote cite="mid:k5hqjk$f3l$1@xxxxxxxxe.org" type="cite">3
As CDO == EMF, you can easily adapt a generated RCP Client EMF
editor for CDO, but in practice you are likely better of to start
UI design from scratch, but you can re-use the concept of an
Editing domain and EMF.edit generated code, which is what I do.
(ItemProviders and Commands). </blockquote>
It's a major goal of CDO to better separate the functional from the
the technical design aspects/tasks. The only intrusive technical
aspect I can imagine of is large flat lists that should generally be
avoided in favour of a deeper object structure. IMHO this is a
useful rule even when only considering the usability of a graphical
application.<br>
<br>
<blockquote cite="mid:k5hqjk$f3l$1@xxxxxxxxe.org" type="cite">4
JFace databinding supports EMF, so JFace Databinding + CDO is a
great combination, you might want to watch loading large chunks of
data into your UI widgets (tables + trees), but there are ways to
limit the volumes. </blockquote>
I fully agree that EMF databinding is a totally cool thing. One
thing that tends to be problematic are remote deletions because the
databinding layer caches some strong references to objects that
might, all of a sudden, start to throw InvalidObjectExceptions or
ObjectNotFoundExceptions. You may appreciate that in CDO 4.2 we now
changed to:<br>
<br>
public static final CDOStaleReferencePolicy DEFAULT = PROXY;<br>
<br>
public static final CDOInvalidationPolicy DEFAULT = RELAXED;<br>
<br>
<br>
<blockquote cite="mid:k5hqjk$f3l$1@xxxxxxxxe.org" type="cite">5 I
you need to do something with DSL's (Develop a textual syntax,
which can interact with EMF/CDO models), this is also great with
xtext.
<br>
</blockquote>
Yes, because "CDO == EMF". But please keep in mind that editing DSL
instances stored *in* CDO with an Xtexteditor is problematic because
a text editor generally doesn't preserve the identities (e.g.
CDOIDs) of objects. That makes it hard to reconcile changes made in
a text editor back to CDO.<br>
<br>
<blockquote cite="mid:k5hqjk$f3l$1@xxxxxxxxe.org" type="cite">6
CDO performs well, you can tweak it, to fetch more or less chunks
of data for EReferences. If you don't like the behaviour you can
fire CDO Queries to get exactly what you want. Also unused objects
are garbage collected, so you can safely read a lot of data (As
long as you don't keep a reference). </blockquote>
Funnily this scalability originally came as a by-product of the
auditing functionality ;-)<br>
<br>
<blockquote cite="mid:k5hqjk$f3l$1@xxxxxxxxe.org" type="cite">7 I
am really fond that objects have a lifecycle, and all my object
have a unique CDO ID. I actually present the CDOID, in the status
line of the app. It's a great way to check what's going on. </blockquote>
And now you can even plug in your own CDOIDGenerator at the
client-side:<br>
<br>
public interface CDOIDGenerator<br>
{<br>
public static final CDOIDGenerator UUID = new CDOIDGenerator()<br>
{<br>
public CDOID generateCDOID(EObject object)<br>
{<br>
byte[] bytes = new byte[16];<br>
UUIDGenerator.DEFAULT.generate(bytes);<br>
return CDOIDUtil.createUUID(bytes);<br>
}<br>
<br>
public void reset()<br>
{<br>
// Do nothing<br>
}<br>
};<br>
<br>
/**<br>
* Generates a {@link CDOID}.<br>
* <br>
* @param object<br>
* the object to generate a new CDOID for if available,
<code>null</code> otherwise.<br>
*/<br>
public CDOID generateCDOID(EObject object);<br>
<br>
/**<br>
* Called at the end of a commit operation to give this ID
generator a chance to reset its sequence of IDs.<br>
*/<br>
public void reset();<br>
}<br>
<br>
<blockquote cite="mid:k5hqjk$f3l$1@xxxxxxxxe.org" type="cite">
8 Invalidations are great, basically when an object goes, remotely
dirty, other views are notified and can get the latest status of
an object. <br>
<br>
What I could do without in CDO
<br>
<br>
9. Revisions & referential integrity, I loved it at first, but
right now for the app. I have. it's a burden. The concept of
revisions adds a lot of requirements in CDO, I think CDO should
also have a simpler flat mode, without the revisions and checks on
integrity. It adds to the complexity of the CDO middleware and the
generated DB get's schema's. Some apps, don't need it or need it
partially. In my case, I would need revisions for some classes
only. </blockquote>
I suspect you don't refer to CDORevisions but to the auditing mode
in general? You know that it can be switched off. Granted, for the
DBStore in particular
<a class="moz-txt-link-freetext" href="https://bugs.eclipse.org/bugs/show_bug.cgi?id=351068">https://bugs.eclipse.org/bugs/show_bug.cgi?id=351068</a> is pending. I
really want to work on this soon.<br>
<br>
Partial auditing has been requested in the past. Conceptually I
don't like the idea because the framework couldn't guarantee the
logical consistency of the graph anymore. But I'm willing to
reconsider this when the DBStore gets its next design overhaul (not
scheduled, yet).<br>
<br>
What exact integrity checks are you referring to? Referential
integrity checks in the repository can be switched off (and they are
by default).<br>
<br>
<blockquote cite="mid:k5hqjk$f3l$1@xxxxxxxxe.org" type="cite">It
sometimes feels CDO is trying to mimic a Concurrent Version System
like SVN or CVS, but for many apps you really don't need that. <br>
</blockquote>
Yes, CDO tries to offer support in both worlds, the database
driven-like runtime applications and the more tool-like use cases
where design-time models need to be stored/managed in a repository.
You can imagine that this is sometimes hard but I think we've done a
pretty good job. Are there particular parts in CDO that are
problematic for you in this regard (i.e., not just unneeded)?<br>
<br>
BTW. an example of a cool new SCM-like feature is our new History
view support for repositories, branches or single objects:<br>
<br>
<img src="http://www.eclipse.org/forums/index.php?t=getfile&id=11879" alt=""><br>
<br>
<blockquote cite="mid:k5hqjk$f3l$1@xxxxxxxxe.org" type="cite">10.
In CDO there are CDOFolders and CDOResources. </blockquote>
Yes, and CDOTextResources and CDOBinaryResources, which are now
(almost) first class citizens of a CDO repository:<br>
<br>
<img src="http://www.eclipse.org/forums/index.php?t=getfile&id=11880" alt=""><br>
<br>
<blockquote cite="mid:k5hqjk$f3l$1@xxxxxxxxe.org" type="cite">Both
are also CDO objects, and stored in the DB. I went through great
length to find the best way to use them, like the the names to
give them, which is meta information you need to deal with in the
application. (Remember which name you used for which resource to
keep which data objects, in my case each eclass has its own
cdoresource). </blockquote>
Yes, that's the main value of Resources in general: They provide
well-known entry points into the (persistent) graph of objects.<br>
<br>
Apart from that they're an essential part of "CDO == EMF" (see point
1).<br>
<br>
<blockquote cite="mid:k5hqjk$f3l$1@xxxxxxxxe.org" type="cite">Right
now, I am not sure what the added value is of these, besides some
additional grouping of objects, I think, without them it could
keep CDO simpler and avoid additional DB data. </blockquote>
Please note that you absolutely don't need to use CDOResourceFolders
and CDOResources (except for a single one to contain all other
objects). The characteristics of a CDO model is the same when you
store all objects in a single resource.<br>
<br>
<blockquote cite="mid:k5hqjk$f3l$1@xxxxxxxxe.org" type="cite">(Note
that in point 3, I mentioned the EMF Editing domain, which has a
ResourceSet which can hold CDOResource objects. I use this, so
without CDO Resources, I wouldn't be able to use an editing
domain, so something else would be needed). <br>
</blockquote>
I think the generated editors also make heavy use of the assumption
that objects are contained by resources.<br>
<br>
<blockquote cite="mid:k5hqjk$f3l$1@xxxxxxxxe.org" type="cite">What
I wish for in CDO.
<br>
<br>
11. Model migrations. There are initiatives like COPE, which could
be applied with CDO, that would be great. So add a class in your
model, and let the new feature deal with the migration and transit
your data. </blockquote>
Fully agreed. If only someone would need it enough to open the
wallet and fund the development of this feature :P<br>
<br>
<blockquote cite="mid:k5hqjk$f3l$1@xxxxxxxxe.org" type="cite">12.
It's a hard learning curve, because most of the docs are outdated
or not written, so mea-culpa, we could do better. I wish for a
thriving community around a general purpose
smart-object-persistence system like CDO. <br>
</blockquote>
Yes! Technical writers in the world, here's a project that needs you
;-)<br>
<br>
<blockquote cite="mid:k5hqjk$f3l$1@xxxxxxxxe.org" type="cite">Finally.
Eike Stepper and others, have been great in supporting me on this
forum. Generally very quick and helpful!<br>
</blockquote>
Good docs would certainly be nicer but, while they're absent, good
online support is our attempt to compensate ;-)<br>
<br>
Cheers<br>
/Eike<br>
<br>
----<br>
<a class="moz-txt-link-freetext" href="http://www.esc-net.de">http://www.esc-net.de</a><br>
<a class="moz-txt-link-freetext" href="http://thegordian.blogspot.com">http://thegordian.blogspot.com</a><br>
<a class="moz-txt-link-freetext" href="http://twitter.com/eikestepper">http://twitter.com/eikestepper</a><br>
<br>
<br>
<br>
</body>
</html>
-
Attachment: bgchgghb.png
(Size: 83.23KB, Downloaded 135 times) -
Attachment: edjjaeef.png
(Size: 16.76KB, Downloaded 137 times)
Cheers
/Eike
----
http://www.esc-net.de
http://thegordian.blogspot.com
http://twitter.com/eikestepper
|
|
|
| Re: Understanding CDO [message #946401 is a reply to message #945941] |
Tue, 16 October 2012 06:30 |
|
<html>
<head>
<meta content="text/html; charset=UTF-8" http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
Hi Christophe,<br>
<br>
Thank you very much for your detailed experience report. I like it
lot ;-)<br>
<br>
More comments below...<br>
<br>
<br>
<div class="moz-cite-prefix">Am 15.10.2012 22:10, schrieb Christophe
Bouhier:<br>
</div>
<blockquote cite="mid:k5hqjk$f3l$1@xxxxxxxxe.org" type="cite">Hello
Mauro, <br>
for the last 2 years, I have been working on a client/server
application using CDO. Depending on your needs, CDO could be the
right fit. <br>
What I like (a lot). <br>
1 CDO == EMF, so you can model data first in .xsd or directly in
.ecore, and you can tell CDO to use your generated packages, which
will build the DB schema. </blockquote>
EMF compliance is very important to us and we're proud to support
most of EMF's features. Among the few exceptions are:<br>
<br>
a) Feature maps are hard to deal with in RDBs<br>
<br>
b) Because CDOResources are EObjects (see point 10) a small number
of other frameworks may run into trouble when trying to find out the
concrete type of a Notifier because the result depends on a
particular order of instanceof checks (check Resources first).<br>
<br>
c) With remote change notifications enabled, i.e.,
view.options().addChangeSubscriptionPolicy(...), your own Adapters
often need to distinguish between local or remote changes. An
instanceof CDODeltaNotification does the trick.<br>
<br>
d) Some IDE applications (and some poorly designed frameworks such
as GMF) heavily rely on IResources which are probably impossible to
simulate for CDOResources. For example it's hard or impossible to
present problem markers for validation problems in CDOResources
because IMarkers are associated with IResources. This is not a CDO
problem but a platform/IMarker problem that other
non-"platform:resource" Resources share in common.<br>
<br>
<blockquote cite="mid:k5hqjk$f3l$1@xxxxxxxxe.org" type="cite">2
On the CDO Store, you can choose from the DBStore, which supports
various DB's, I have worked with MySQL and Postgres. With
Hibernate store, there is an additional ORM layer, which works
with tons of other DB's supported by Hibernate. </blockquote>
And there's support for some other backend types, such as DB4O,
MongoDB or Objectivity/DB. I've recently developed a
RandomAccessFile based journaling store, named LissomeStore. It
still uses an RDB for a small and fixed number of indexes into the
random access file(s). For commits it uses a journal file and
adjusts the index tables asynchronously. The performance of large
commits can typically be increased by factor 600 in my tests.<br>
<br>
IMHO the great value of the IStore design is that it becomes a snap
to *change* the backend choice at any time without much impact on
the application (except you're making heavy use of backend-specifc
IQueryHandlers such as SQL or HQL).<br>
<br>
<blockquote cite="mid:k5hqjk$f3l$1@xxxxxxxxe.org" type="cite">3
As CDO == EMF, you can easily adapt a generated RCP Client EMF
editor for CDO, but in practice you are likely better of to start
UI design from scratch, but you can re-use the concept of an
Editing domain and EMF.edit generated code, which is what I do.
(ItemProviders and Commands). </blockquote>
It's a major goal of CDO to better separate the functional from the
the technical design aspects/tasks. The only intrusive technical
aspect I can imagine of is large flat lists that should generally be
avoided in favour of a deeper object structure. IMHO this is a
useful rule even when only considering the usability of a graphical
application.<br>
<br>
<blockquote cite="mid:k5hqjk$f3l$1@xxxxxxxxe.org" type="cite">4
JFace databinding supports EMF, so JFace Databinding + CDO is a
great combination, you might want to watch loading large chunks of
data into your UI widgets (tables + trees), but there are ways to
limit the volumes. </blockquote>
I fully agree that EMF databinding is a totally cool thing. One
thing that tends to be problematic are remote deletions because the
databinding layer caches some strong references to objects that
might, all of a sudden, start to throw InvalidObjectExceptions or
ObjectNotFoundExceptions. You may appreciate that in CDO 4.2 we now
changed to:<br>
<br>
public static final CDOStaleReferencePolicy DEFAULT = PROXY;<br>
<br>
public static final CDOInvalidationPolicy DEFAULT = RELAXED;<br>
<br>
<br>
<blockquote cite="mid:k5hqjk$f3l$1@xxxxxxxxe.org" type="cite">5 I
you need to do something with DSL's (Develop a textual syntax,
which can interact with EMF/CDO models), this is also great with
xtext.
<br>
</blockquote>
Yes, because "CDO == EMF". But please keep in mind that editing DSL
instances stored *in* CDO with an Xtexteditor is problematic because
a text editor generally doesn't preserve the identities (e.g.
CDOIDs) of objects. That makes it hard to reconcile changes made in
a text editor back to CDO.<br>
<br>
<blockquote cite="mid:k5hqjk$f3l$1@xxxxxxxxe.org" type="cite">6
CDO performs well, you can tweak it, to fetch more or less chunks
of data for EReferences. If you don't like the behaviour you can
fire CDO Queries to get exactly what you want. Also unused objects
are garbage collected, so you can safely read a lot of data (As
long as you don't keep a reference). </blockquote>
Funnily this scalability originally came as a by-product of the
auditing functionality ;-)<br>
<br>
<blockquote cite="mid:k5hqjk$f3l$1@xxxxxxxxe.org" type="cite">7 I
am really fond that objects have a lifecycle, and all my object
have a unique CDO ID. I actually present the CDOID, in the status
line of the app. It's a great way to check what's going on. </blockquote>
And now you can even plug in your own CDOIDGenerator at the
client-side:<br>
<br>
public interface CDOIDGenerator<br>
{<br>
public static final CDOIDGenerator UUID = new CDOIDGenerator()<br>
{<br>
public CDOID generateCDOID(EObject object)<br>
{<br>
byte[] bytes = new byte[16];<br>
UUIDGenerator.DEFAULT.generate(bytes);<br>
return CDOIDUtil.createUUID(bytes);<br>
}<br>
<br>
public void reset()<br>
{<br>
// Do nothing<br>
}<br>
};<br>
<br>
/**<br>
* Generates a {@link CDOID}.<br>
* <br>
* @param object<br>
* the object to generate a new CDOID for if available,
<code>null</code> otherwise.<br>
*/<br>
public CDOID generateCDOID(EObject object);<br>
<br>
/**<br>
* Called at the end of a commit operation to give this ID
generator a chance to reset its sequence of IDs.<br>
*/<br>
public void reset();<br>
}<br>
<br>
<blockquote cite="mid:k5hqjk$f3l$1@xxxxxxxxe.org" type="cite">
8 Invalidations are great, basically when an object goes, remotely
dirty, other views are notified and can get the latest status of
an object. <br>
<br>
What I could do without in CDO
<br>
<br>
9. Revisions & referential integrity, I loved it at first, but
right now for the app. I have. it's a burden. The concept of
revisions adds a lot of requirements in CDO, I think CDO should
also have a simpler flat mode, without the revisions and checks on
integrity. It adds to the complexity of the CDO middleware and the
generated DB get's schema's. Some apps, don't need it or need it
partially. In my case, I would need revisions for some classes
only. </blockquote>
I suspect you don't refer to CDORevisions but to the auditing mode
in general? You know that it can be switched off. Granted, for the
DBStore in particular
<a class="moz-txt-link-freetext" href="https://bugs.eclipse.org/bugs/show_bug.cgi?id=351068">https://bugs.eclipse.org/bugs/show_bug.cgi?id=351068</a> is pending. I
really want to work on this soon.<br>
<br>
Partial auditing has been requested in the past. Conceptually I
don't like the idea because the framework couldn't guarantee the
logical consistency of the graph anymore. But I'm willing to
reconsider this when the DBStore gets its next design overhaul (not
scheduled, yet).<br>
<br>
What exact integrity checks are you referring to? Referential
integrity checks in the repository can be switched off (and they are
by default).<br>
<br>
<blockquote cite="mid:k5hqjk$f3l$1@xxxxxxxxe.org" type="cite">It
sometimes feels CDO is trying to mimic a Concurrent Version System
like SVN or CVS, but for many apps you really don't need that. <br>
</blockquote>
Yes, CDO tries to offer support in both worlds, the database
driven-like runtime applications and the more tool-like use cases
where design-time models need to be stored/managed in a repository.
You can imagine that this is sometimes hard but I think we've done a
pretty good job. Are there particular parts in CDO that are
problematic for you in this regard (i.e., not just unneeded)?<br>
<br>
BTW. an example of a cool new SCM-like feature is our new History
view support for repositories, branches or single objects:<br>
<br>
<img src="http://www.eclipse.org/forums/index.php?t=getfile&id=11881" alt=""><br>
<br>
<blockquote cite="mid:k5hqjk$f3l$1@xxxxxxxxe.org" type="cite">10.
In CDO there are CDOFolders and CDOResources. </blockquote>
Yes, and CDOTextResources and CDOBinaryResources, which are now
(almost) first class citizens of a CDO repository:<br>
<br>
<img src="http://www.eclipse.org/forums/index.php?t=getfile&id=11882" alt=""><br>
<br>
<blockquote cite="mid:k5hqjk$f3l$1@xxxxxxxxe.org" type="cite">Both
are also CDO objects, and stored in the DB. I went through great
length to find the best way to use them, like the the names to
give them, which is meta information you need to deal with in the
application. (Remember which name you used for which resource to
keep which data objects, in my case each eclass has its own
cdoresource). </blockquote>
Yes, that's the main value of Resources in general: They provide
well-known entry points into the (persistent) graph of objects.<br>
<br>
Apart from that they're an essential part of "CDO == EMF" (see point
1).<br>
<br>
<blockquote cite="mid:k5hqjk$f3l$1@xxxxxxxxe.org" type="cite">Right
now, I am not sure what the added value is of these, besides some
additional grouping of objects, I think, without them it could
keep CDO simpler and avoid additional DB data. </blockquote>
Please note that you absolutely don't need to use CDOResourceFolders
and CDOResources (except for a single one to contain all other
objects). The characteristics of a CDO model is the same when you
store all objects in a single resource.<br>
<br>
<blockquote cite="mid:k5hqjk$f3l$1@xxxxxxxxe.org" type="cite">(Note
that in point 3, I mentioned the EMF Editing domain, which has a
ResourceSet which can hold CDOResource objects. I use this, so
without CDO Resources, I wouldn't be able to use an editing
domain, so something else would be needed). <br>
</blockquote>
I think the generated editors also make heavy use of the assumption
that objects are contained by resources.<br>
<br>
<blockquote cite="mid:k5hqjk$f3l$1@xxxxxxxxe.org" type="cite">What
I wish for in CDO.
<br>
<br>
11. Model migrations. There are initiatives like COPE, which could
be applied with CDO, that would be great. So add a class in your
model, and let the new feature deal with the migration and transit
your data. </blockquote>
Fully agreed. If only someone would need it enough to open the
wallet and fund the development of this feature :P<br>
<br>
<blockquote cite="mid:k5hqjk$f3l$1@xxxxxxxxe.org" type="cite">12.
It's a hard learning curve, because most of the docs are outdated
or not written, so mea-culpa, we could do better. I wish for a
thriving community around a general purpose
smart-object-persistence system like CDO. <br>
</blockquote>
Yes! Technical writers in the world, here's a project that needs you
;-)<br>
<br>
<blockquote cite="mid:k5hqjk$f3l$1@xxxxxxxxe.org" type="cite">Finally.
Eike Stepper and others, have been great in supporting me on this
forum. Generally very quick and helpful!<br>
</blockquote>
Good docs would certainly be nicer but, while they're absent, good
online support is our attempt to compensate ;-)<br>
<br>
Cheers<br>
/Eike<br>
<br>
----<br>
<a class="moz-txt-link-freetext" href="http://www.esc-net.de">http://www.esc-net.de</a><br>
<a class="moz-txt-link-freetext" href="http://thegordian.blogspot.com">http://thegordian.blogspot.com</a><br>
<a class="moz-txt-link-freetext" href="http://twitter.com/eikestepper">http://twitter.com/eikestepper</a><br>
<br>
<br>
<br>
</body>
</html>
-
Attachment: bgchgghb.png
(Size: 83.23KB, Downloaded 131 times) -
Attachment: edjjaeef.png
(Size: 16.76KB, Downloaded 126 times)
Cheers
/Eike
----
http://www.esc-net.de
http://thegordian.blogspot.com
http://twitter.com/eikestepper
|
|
|
| Re: Understanding CDO [message #946406 is a reply to message #945941] |
Tue, 16 October 2012 06:30 |
|
<html>
<head>
<meta content="text/html; charset=UTF-8" http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
Hi Christophe,<br>
<br>
Thank you very much for your detailed experience report. I like it
lot ;-)<br>
<br>
More comments below...<br>
<br>
<br>
<div class="moz-cite-prefix">Am 15.10.2012 22:10, schrieb Christophe
Bouhier:<br>
</div>
<blockquote cite="mid:k5hqjk$f3l$1@xxxxxxxxe.org" type="cite">Hello
Mauro, <br>
for the last 2 years, I have been working on a client/server
application using CDO. Depending on your needs, CDO could be the
right fit. <br>
What I like (a lot). <br>
1 CDO == EMF, so you can model data first in .xsd or directly in
.ecore, and you can tell CDO to use your generated packages, which
will build the DB schema. </blockquote>
EMF compliance is very important to us and we're proud to support
most of EMF's features. Among the few exceptions are:<br>
<br>
a) Feature maps are hard to deal with in RDBs<br>
<br>
b) Because CDOResources are EObjects (see point 10) a small number
of other frameworks may run into trouble when trying to find out the
concrete type of a Notifier because the result depends on a
particular order of instanceof checks (check Resources first).<br>
<br>
c) With remote change notifications enabled, i.e.,
view.options().addChangeSubscriptionPolicy(...), your own Adapters
often need to distinguish between local or remote changes. An
instanceof CDODeltaNotification does the trick.<br>
<br>
d) Some IDE applications (and some poorly designed frameworks such
as GMF) heavily rely on IResources which are probably impossible to
simulate for CDOResources. For example it's hard or impossible to
present problem markers for validation problems in CDOResources
because IMarkers are associated with IResources. This is not a CDO
problem but a platform/IMarker problem that other
non-"platform:resource" Resources share in common.<br>
<br>
<blockquote cite="mid:k5hqjk$f3l$1@xxxxxxxxe.org" type="cite">2
On the CDO Store, you can choose from the DBStore, which supports
various DB's, I have worked with MySQL and Postgres. With
Hibernate store, there is an additional ORM layer, which works
with tons of other DB's supported by Hibernate. </blockquote>
And there's support for some other backend types, such as DB4O,
MongoDB or Objectivity/DB. I've recently developed a
RandomAccessFile based journaling store, named LissomeStore. It
still uses an RDB for a small and fixed number of indexes into the
random access file(s). For commits it uses a journal file and
adjusts the index tables asynchronously. The performance of large
commits can typically be increased by factor 600 in my tests.<br>
<br>
IMHO the great value of the IStore design is that it becomes a snap
to *change* the backend choice at any time without much impact on
the application (except you're making heavy use of backend-specifc
IQueryHandlers such as SQL or HQL).<br>
<br>
<blockquote cite="mid:k5hqjk$f3l$1@xxxxxxxxe.org" type="cite">3
As CDO == EMF, you can easily adapt a generated RCP Client EMF
editor for CDO, but in practice you are likely better of to start
UI design from scratch, but you can re-use the concept of an
Editing domain and EMF.edit generated code, which is what I do.
(ItemProviders and Commands). </blockquote>
It's a major goal of CDO to better separate the functional from the
the technical design aspects/tasks. The only intrusive technical
aspect I can imagine of is large flat lists that should generally be
avoided in favour of a deeper object structure. IMHO this is a
useful rule even when only considering the usability of a graphical
application.<br>
<br>
<blockquote cite="mid:k5hqjk$f3l$1@xxxxxxxxe.org" type="cite">4
JFace databinding supports EMF, so JFace Databinding + CDO is a
great combination, you might want to watch loading large chunks of
data into your UI widgets (tables + trees), but there are ways to
limit the volumes. </blockquote>
I fully agree that EMF databinding is a totally cool thing. One
thing that tends to be problematic are remote deletions because the
databinding layer caches some strong references to objects that
might, all of a sudden, start to throw InvalidObjectExceptions or
ObjectNotFoundExceptions. You may appreciate that in CDO 4.2 we now
changed to:<br>
<br>
public static final CDOStaleReferencePolicy DEFAULT = PROXY;<br>
<br>
public static final CDOInvalidationPolicy DEFAULT = RELAXED;<br>
<br>
<br>
<blockquote cite="mid:k5hqjk$f3l$1@xxxxxxxxe.org" type="cite">5 I
you need to do something with DSL's (Develop a textual syntax,
which can interact with EMF/CDO models), this is also great with
xtext.
<br>
</blockquote>
Yes, because "CDO == EMF". But please keep in mind that editing DSL
instances stored *in* CDO with an Xtexteditor is problematic because
a text editor generally doesn't preserve the identities (e.g.
CDOIDs) of objects. That makes it hard to reconcile changes made in
a text editor back to CDO.<br>
<br>
<blockquote cite="mid:k5hqjk$f3l$1@xxxxxxxxe.org" type="cite">6
CDO performs well, you can tweak it, to fetch more or less chunks
of data for EReferences. If you don't like the behaviour you can
fire CDO Queries to get exactly what you want. Also unused objects
are garbage collected, so you can safely read a lot of data (As
long as you don't keep a reference). </blockquote>
Funnily this scalability originally came as a by-product of the
auditing functionality ;-)<br>
<br>
<blockquote cite="mid:k5hqjk$f3l$1@xxxxxxxxe.org" type="cite">7 I
am really fond that objects have a lifecycle, and all my object
have a unique CDO ID. I actually present the CDOID, in the status
line of the app. It's a great way to check what's going on. </blockquote>
And now you can even plug in your own CDOIDGenerator at the
client-side:<br>
<br>
public interface CDOIDGenerator<br>
{<br>
public static final CDOIDGenerator UUID = new CDOIDGenerator()<br>
{<br>
public CDOID generateCDOID(EObject object)<br>
{<br>
byte[] bytes = new byte[16];<br>
UUIDGenerator.DEFAULT.generate(bytes);<br>
return CDOIDUtil.createUUID(bytes);<br>
}<br>
<br>
public void reset()<br>
{<br>
// Do nothing<br>
}<br>
};<br>
<br>
/**<br>
* Generates a {@link CDOID}.<br>
* <br>
* @param object<br>
* the object to generate a new CDOID for if available,
<code>null</code> otherwise.<br>
*/<br>
public CDOID generateCDOID(EObject object);<br>
<br>
/**<br>
* Called at the end of a commit operation to give this ID
generator a chance to reset its sequence of IDs.<br>
*/<br>
public void reset();<br>
}<br>
<br>
<blockquote cite="mid:k5hqjk$f3l$1@xxxxxxxxe.org" type="cite">
8 Invalidations are great, basically when an object goes, remotely
dirty, other views are notified and can get the latest status of
an object. <br>
<br>
What I could do without in CDO
<br>
<br>
9. Revisions & referential integrity, I loved it at first, but
right now for the app. I have. it's a burden. The concept of
revisions adds a lot of requirements in CDO, I think CDO should
also have a simpler flat mode, without the revisions and checks on
integrity. It adds to the complexity of the CDO middleware and the
generated DB get's schema's. Some apps, don't need it or need it
partially. In my case, I would need revisions for some classes
only. </blockquote>
I suspect you don't refer to CDORevisions but to the auditing mode
in general? You know that it can be switched off. Granted, for the
DBStore in particular
<a class="moz-txt-link-freetext" href="https://bugs.eclipse.org/bugs/show_bug.cgi?id=351068">https://bugs.eclipse.org/bugs/show_bug.cgi?id=351068</a> is pending. I
really want to work on this soon.<br>
<br>
Partial auditing has been requested in the past. Conceptually I
don't like the idea because the framework couldn't guarantee the
logical consistency of the graph anymore. But I'm willing to
reconsider this when the DBStore gets its next design overhaul (not
scheduled, yet).<br>
<br>
What exact integrity checks are you referring to? Referential
integrity checks in the repository can be switched off (and they are
by default).<br>
<br>
<blockquote cite="mid:k5hqjk$f3l$1@xxxxxxxxe.org" type="cite">It
sometimes feels CDO is trying to mimic a Concurrent Version System
like SVN or CVS, but for many apps you really don't need that. <br>
</blockquote>
Yes, CDO tries to offer support in both worlds, the database
driven-like runtime applications and the more tool-like use cases
where design-time models need to be stored/managed in a repository.
You can imagine that this is sometimes hard but I think we've done a
pretty good job. Are there particular parts in CDO that are
problematic for you in this regard (i.e., not just unneeded)?<br>
<br>
BTW. an example of a cool new SCM-like feature is our new History
view support for repositories, branches or single objects:<br>
<br>
<img src="http://www.eclipse.org/forums/index.php?t=getfile&id=11883" alt=""><br>
<br>
<blockquote cite="mid:k5hqjk$f3l$1@xxxxxxxxe.org" type="cite">10.
In CDO there are CDOFolders and CDOResources. </blockquote>
Yes, and CDOTextResources and CDOBinaryResources, which are now
(almost) first class citizens of a CDO repository:<br>
<br>
<img src="http://www.eclipse.org/forums/index.php?t=getfile&id=11884" alt=""><br>
<br>
<blockquote cite="mid:k5hqjk$f3l$1@xxxxxxxxe.org" type="cite">Both
are also CDO objects, and stored in the DB. I went through great
length to find the best way to use them, like the the names to
give them, which is meta information you need to deal with in the
application. (Remember which name you used for which resource to
keep which data objects, in my case each eclass has its own
cdoresource). </blockquote>
Yes, that's the main value of Resources in general: They provide
well-known entry points into the (persistent) graph of objects.<br>
<br>
Apart from that they're an essential part of "CDO == EMF" (see point
1).<br>
<br>
<blockquote cite="mid:k5hqjk$f3l$1@xxxxxxxxe.org" type="cite">Right
now, I am not sure what the added value is of these, besides some
additional grouping of objects, I think, without them it could
keep CDO simpler and avoid additional DB data. </blockquote>
Please note that you absolutely don't need to use CDOResourceFolders
and CDOResources (except for a single one to contain all other
objects). The characteristics of a CDO model is the same when you
store all objects in a single resource.<br>
<br>
<blockquote cite="mid:k5hqjk$f3l$1@xxxxxxxxe.org" type="cite">(Note
that in point 3, I mentioned the EMF Editing domain, which has a
ResourceSet which can hold CDOResource objects. I use this, so
without CDO Resources, I wouldn't be able to use an editing
domain, so something else would be needed). <br>
</blockquote>
I think the generated editors also make heavy use of the assumption
that objects are contained by resources.<br>
<br>
<blockquote cite="mid:k5hqjk$f3l$1@xxxxxxxxe.org" type="cite">What
I wish for in CDO.
<br>
<br>
11. Model migrations. There are initiatives like COPE, which could
be applied with CDO, that would be great. So add a class in your
model, and let the new feature deal with the migration and transit
your data. </blockquote>
Fully agreed. If only someone would need it enough to open the
wallet and fund the development of this feature :P<br>
<br>
<blockquote cite="mid:k5hqjk$f3l$1@xxxxxxxxe.org" type="cite">12.
It's a hard learning curve, because most of the docs are outdated
or not written, so mea-culpa, we could do better. I wish for a
thriving community around a general purpose
smart-object-persistence system like CDO. <br>
</blockquote>
Yes! Technical writers in the world, here's a project that needs you
;-)<br>
<br>
<blockquote cite="mid:k5hqjk$f3l$1@xxxxxxxxe.org" type="cite">Finally.
Eike Stepper and others, have been great in supporting me on this
forum. Generally very quick and helpful!<br>
</blockquote>
Good docs would certainly be nicer but, while they're absent, good
online support is our attempt to compensate ;-)<br>
<br>
Cheers<br>
/Eike<br>
<br>
----<br>
<a class="moz-txt-link-freetext" href="http://www.esc-net.de">http://www.esc-net.de</a><br>
<a class="moz-txt-link-freetext" href="http://thegordian.blogspot.com">http://thegordian.blogspot.com</a><br>
<a class="moz-txt-link-freetext" href="http://twitter.com/eikestepper">http://twitter.com/eikestepper</a><br>
<br>
<br>
<br>
</body>
</html>
-
Attachment: bgchgghb.png
(Size: 83.23KB, Downloaded 120 times) -
Attachment: edjjaeef.png
(Size: 16.76KB, Downloaded 142 times)
Cheers
/Eike
----
http://www.esc-net.de
http://thegordian.blogspot.com
http://twitter.com/eikestepper
|
|
|
| Re: Understanding CDO [message #946412 is a reply to message #945941] |
Tue, 16 October 2012 06:30 |
|
<html>
<head>
<meta content="text/html; charset=UTF-8" http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
Hi Christophe,<br>
<br>
Thank you very much for your detailed experience report. I like it
lot ;-)<br>
<br>
More comments below...<br>
<br>
<br>
<div class="moz-cite-prefix">Am 15.10.2012 22:10, schrieb Christophe
Bouhier:<br>
</div>
<blockquote cite="mid:k5hqjk$f3l$1@xxxxxxxxe.org" type="cite">Hello
Mauro, <br>
for the last 2 years, I have been working on a client/server
application using CDO. Depending on your needs, CDO could be the
right fit. <br>
What I like (a lot). <br>
1 CDO == EMF, so you can model data first in .xsd or directly in
.ecore, and you can tell CDO to use your generated packages, which
will build the DB schema. </blockquote>
EMF compliance is very important to us and we're proud to support
most of EMF's features. Among the few exceptions are:<br>
<br>
a) Feature maps are hard to deal with in RDBs<br>
<br>
b) Because CDOResources are EObjects (see point 10) a small number
of other frameworks may run into trouble when trying to find out the
concrete type of a Notifier because the result depends on a
particular order of instanceof checks (check Resources first).<br>
<br>
c) With remote change notifications enabled, i.e.,
view.options().addChangeSubscriptionPolicy(...), your own Adapters
often need to distinguish between local or remote changes. An
instanceof CDODeltaNotification does the trick.<br>
<br>
d) Some IDE applications (and some poorly designed frameworks such
as GMF) heavily rely on IResources which are probably impossible to
simulate for CDOResources. For example it's hard or impossible to
present problem markers for validation problems in CDOResources
because IMarkers are associated with IResources. This is not a CDO
problem but a platform/IMarker problem that other
non-"platform:resource" Resources share in common.<br>
<br>
<blockquote cite="mid:k5hqjk$f3l$1@xxxxxxxxe.org" type="cite">2
On the CDO Store, you can choose from the DBStore, which supports
various DB's, I have worked with MySQL and Postgres. With
Hibernate store, there is an additional ORM layer, which works
with tons of other DB's supported by Hibernate. </blockquote>
And there's support for some other backend types, such as DB4O,
MongoDB or Objectivity/DB. I've recently developed a
RandomAccessFile based journaling store, named LissomeStore. It
still uses an RDB for a small and fixed number of indexes into the
random access file(s). For commits it uses a journal file and
adjusts the index tables asynchronously. The performance of large
commits can typically be increased by factor 600 in my tests.<br>
<br>
IMHO the great value of the IStore design is that it becomes a snap
to *change* the backend choice at any time without much impact on
the application (except you're making heavy use of backend-specifc
IQueryHandlers such as SQL or HQL).<br>
<br>
<blockquote cite="mid:k5hqjk$f3l$1@xxxxxxxxe.org" type="cite">3
As CDO == EMF, you can easily adapt a generated RCP Client EMF
editor for CDO, but in practice you are likely better of to start
UI design from scratch, but you can re-use the concept of an
Editing domain and EMF.edit generated code, which is what I do.
(ItemProviders and Commands). </blockquote>
It's a major goal of CDO to better separate the functional from the
the technical design aspects/tasks. The only intrusive technical
aspect I can imagine of is large flat lists that should generally be
avoided in favour of a deeper object structure. IMHO this is a
useful rule even when only considering the usability of a graphical
application.<br>
<br>
<blockquote cite="mid:k5hqjk$f3l$1@xxxxxxxxe.org" type="cite">4
JFace databinding supports EMF, so JFace Databinding + CDO is a
great combination, you might want to watch loading large chunks of
data into your UI widgets (tables + trees), but there are ways to
limit the volumes. </blockquote>
I fully agree that EMF databinding is a totally cool thing. One
thing that tends to be problematic are remote deletions because the
databinding layer caches some strong references to objects that
might, all of a sudden, start to throw InvalidObjectExceptions or
ObjectNotFoundExceptions. You may appreciate that in CDO 4.2 we now
changed to:<br>
<br>
public static final CDOStaleReferencePolicy DEFAULT = PROXY;<br>
<br>
public static final CDOInvalidationPolicy DEFAULT = RELAXED;<br>
<br>
<br>
<blockquote cite="mid:k5hqjk$f3l$1@xxxxxxxxe.org" type="cite">5 I
you need to do something with DSL's (Develop a textual syntax,
which can interact with EMF/CDO models), this is also great with
xtext.
<br>
</blockquote>
Yes, because "CDO == EMF". But please keep in mind that editing DSL
instances stored *in* CDO with an Xtexteditor is problematic because
a text editor generally doesn't preserve the identities (e.g.
CDOIDs) of objects. That makes it hard to reconcile changes made in
a text editor back to CDO.<br>
<br>
<blockquote cite="mid:k5hqjk$f3l$1@xxxxxxxxe.org" type="cite">6
CDO performs well, you can tweak it, to fetch more or less chunks
of data for EReferences. If you don't like the behaviour you can
fire CDO Queries to get exactly what you want. Also unused objects
are garbage collected, so you can safely read a lot of data (As
long as you don't keep a reference). </blockquote>
Funnily this scalability originally came as a by-product of the
auditing functionality ;-)<br>
<br>
<blockquote cite="mid:k5hqjk$f3l$1@xxxxxxxxe.org" type="cite">7 I
am really fond that objects have a lifecycle, and all my object
have a unique CDO ID. I actually present the CDOID, in the status
line of the app. It's a great way to check what's going on. </blockquote>
And now you can even plug in your own CDOIDGenerator at the
client-side:<br>
<br>
public interface CDOIDGenerator<br>
{<br>
public static final CDOIDGenerator UUID = new CDOIDGenerator()<br>
{<br>
public CDOID generateCDOID(EObject object)<br>
{<br>
byte[] bytes = new byte[16];<br>
UUIDGenerator.DEFAULT.generate(bytes);<br>
return CDOIDUtil.createUUID(bytes);<br>
}<br>
<br>
public void reset()<br>
{<br>
// Do nothing<br>
}<br>
};<br>
<br>
/**<br>
* Generates a {@link CDOID}.<br>
* <br>
* @param object<br>
* the object to generate a new CDOID for if available,
<code>null</code> otherwise.<br>
*/<br>
public CDOID generateCDOID(EObject object);<br>
<br>
/**<br>
* Called at the end of a commit operation to give this ID
generator a chance to reset its sequence of IDs.<br>
*/<br>
public void reset();<br>
}<br>
<br>
<blockquote cite="mid:k5hqjk$f3l$1@xxxxxxxxe.org" type="cite">
8 Invalidations are great, basically when an object goes, remotely
dirty, other views are notified and can get the latest status of
an object. <br>
<br>
What I could do without in CDO
<br>
<br>
9. Revisions & referential integrity, I loved it at first, but
right now for the app. I have. it's a burden. The concept of
revisions adds a lot of requirements in CDO, I think CDO should
also have a simpler flat mode, without the revisions and checks on
integrity. It adds to the complexity of the CDO middleware and the
generated DB get's schema's. Some apps, don't need it or need it
partially. In my case, I would need revisions for some classes
only. </blockquote>
I suspect you don't refer to CDORevisions but to the auditing mode
in general? You know that it can be switched off. Granted, for the
DBStore in particular
<a class="moz-txt-link-freetext" href="https://bugs.eclipse.org/bugs/show_bug.cgi?id=351068">https://bugs.eclipse.org/bugs/show_bug.cgi?id=351068</a> is pending. I
really want to work on this soon.<br>
<br>
Partial auditing has been requested in the past. Conceptually I
don't like the idea because the framework couldn't guarantee the
logical consistency of the graph anymore. But I'm willing to
reconsider this when the DBStore gets its next design overhaul (not
scheduled, yet).<br>
<br>
What exact integrity checks are you referring to? Referential
integrity checks in the repository can be switched off (and they are
by default).<br>
<br>
<blockquote cite="mid:k5hqjk$f3l$1@xxxxxxxxe.org" type="cite">It
sometimes feels CDO is trying to mimic a Concurrent Version System
like SVN or CVS, but for many apps you really don't need that. <br>
</blockquote>
Yes, CDO tries to offer support in both worlds, the database
driven-like runtime applications and the more tool-like use cases
where design-time models need to be stored/managed in a repository.
You can imagine that this is sometimes hard but I think we've done a
pretty good job. Are there particular parts in CDO that are
problematic for you in this regard (i.e., not just unneeded)?<br>
<br>
BTW. an example of a cool new SCM-like feature is our new History
view support for repositories, branches or single objects:<br>
<br>
<img src="http://www.eclipse.org/forums/index.php?t=getfile&id=11885" alt=""><br>
<br>
<blockquote cite="mid:k5hqjk$f3l$1@xxxxxxxxe.org" type="cite">10.
In CDO there are CDOFolders and CDOResources. </blockquote>
Yes, and CDOTextResources and CDOBinaryResources, which are now
(almost) first class citizens of a CDO repository:<br>
<br>
<img src="http://www.eclipse.org/forums/index.php?t=getfile&id=11886" alt=""><br>
<br>
<blockquote cite="mid:k5hqjk$f3l$1@xxxxxxxxe.org" type="cite">Both
are also CDO objects, and stored in the DB. I went through great
length to find the best way to use them, like the the names to
give them, which is meta information you need to deal with in the
application. (Remember which name you used for which resource to
keep which data objects, in my case each eclass has its own
cdoresource). </blockquote>
Yes, that's the main value of Resources in general: They provide
well-known entry points into the (persistent) graph of objects.<br>
<br>
Apart from that they're an essential part of "CDO == EMF" (see point
1).<br>
<br>
<blockquote cite="mid:k5hqjk$f3l$1@xxxxxxxxe.org" type="cite">Right
now, I am not sure what the added value is of these, besides some
additional grouping of objects, I think, without them it could
keep CDO simpler and avoid additional DB data. </blockquote>
Please note that you absolutely don't need to use CDOResourceFolders
and CDOResources (except for a single one to contain all other
objects). The characteristics of a CDO model is the same when you
store all objects in a single resource.<br>
<br>
<blockquote cite="mid:k5hqjk$f3l$1@xxxxxxxxe.org" type="cite">(Note
that in point 3, I mentioned the EMF Editing domain, which has a
ResourceSet which can hold CDOResource objects. I use this, so
without CDO Resources, I wouldn't be able to use an editing
domain, so something else would be needed). <br>
</blockquote>
I think the generated editors also make heavy use of the assumption
that objects are contained by resources.<br>
<br>
<blockquote cite="mid:k5hqjk$f3l$1@xxxxxxxxe.org" type="cite">What
I wish for in CDO.
<br>
<br>
11. Model migrations. There are initiatives like COPE, which could
be applied with CDO, that would be great. So add a class in your
model, and let the new feature deal with the migration and transit
your data. </blockquote>
Fully agreed. If only someone would need it enough to open the
wallet and fund the development of this feature :P<br>
<br>
<blockquote cite="mid:k5hqjk$f3l$1@xxxxxxxxe.org" type="cite">12.
It's a hard learning curve, because most of the docs are outdated
or not written, so mea-culpa, we could do better. I wish for a
thriving community around a general purpose
smart-object-persistence system like CDO. <br>
</blockquote>
Yes! Technical writers in the world, here's a project that needs you
;-)<br>
<br>
<blockquote cite="mid:k5hqjk$f3l$1@xxxxxxxxe.org" type="cite">Finally.
Eike Stepper and others, have been great in supporting me on this
forum. Generally very quick and helpful!<br>
</blockquote>
Good docs would certainly be nicer but, while they're absent, good
online support is our attempt to compensate ;-)<br>
<br>
Cheers<br>
/Eike<br>
<br>
----<br>
<a class="moz-txt-link-freetext" href="http://www.esc-net.de">http://www.esc-net.de</a><br>
<a class="moz-txt-link-freetext" href="http://thegordian.blogspot.com">http://thegordian.blogspot.com</a><br>
<a class="moz-txt-link-freetext" href="http://twitter.com/eikestepper">http://twitter.com/eikestepper</a><br>
<br>
<br>
<br>
</body>
</html>
-
Attachment: bgchgghb.png
(Size: 83.23KB, Downloaded 129 times) -
Attachment: edjjaeef.png
(Size: 16.76KB, Downloaded 135 times)
Cheers
/Eike
----
http://www.esc-net.de
http://thegordian.blogspot.com
http://twitter.com/eikestepper
|
|
|
| Re: Understanding CDO [message #946416 is a reply to message #945941] |
Tue, 16 October 2012 06:30 |
|
<html>
<head>
<meta content="text/html; charset=UTF-8" http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
Hi Christophe,<br>
<br>
Thank you very much for your detailed experience report. I like it
lot ;-)<br>
<br>
More comments below...<br>
<br>
<br>
<div class="moz-cite-prefix">Am 15.10.2012 22:10, schrieb Christophe
Bouhier:<br>
</div>
<blockquote cite="mid:k5hqjk$f3l$1@xxxxxxxxe.org" type="cite">Hello
Mauro, <br>
for the last 2 years, I have been working on a client/server
application using CDO. Depending on your needs, CDO could be the
right fit. <br>
What I like (a lot). <br>
1 CDO == EMF, so you can model data first in .xsd or directly in
.ecore, and you can tell CDO to use your generated packages, which
will build the DB schema. </blockquote>
EMF compliance is very important to us and we're proud to support
most of EMF's features. Among the few exceptions are:<br>
<br>
a) Feature maps are hard to deal with in RDBs<br>
<br>
b) Because CDOResources are EObjects (see point 10) a small number
of other frameworks may run into trouble when trying to find out the
concrete type of a Notifier because the result depends on a
particular order of instanceof checks (check Resources first).<br>
<br>
c) With remote change notifications enabled, i.e.,
view.options().addChangeSubscriptionPolicy(...), your own Adapters
often need to distinguish between local or remote changes. An
instanceof CDODeltaNotification does the trick.<br>
<br>
d) Some IDE applications (and some poorly designed frameworks such
as GMF) heavily rely on IResources which are probably impossible to
simulate for CDOResources. For example it's hard or impossible to
present problem markers for validation problems in CDOResources
because IMarkers are associated with IResources. This is not a CDO
problem but a platform/IMarker problem that other
non-"platform:resource" Resources share in common.<br>
<br>
<blockquote cite="mid:k5hqjk$f3l$1@xxxxxxxxe.org" type="cite">2
On the CDO Store, you can choose from the DBStore, which supports
various DB's, I have worked with MySQL and Postgres. With
Hibernate store, there is an additional ORM layer, which works
with tons of other DB's supported by Hibernate. </blockquote>
And there's support for some other backend types, such as DB4O,
MongoDB or Objectivity/DB. I've recently developed a
RandomAccessFile based journaling store, named LissomeStore. It
still uses an RDB for a small and fixed number of indexes into the
random access file(s). For commits it uses a journal file and
adjusts the index tables asynchronously. The performance of large
commits can typically be increased by factor 600 in my tests.<br>
<br>
IMHO the great value of the IStore design is that it becomes a snap
to *change* the backend choice at any time without much impact on
the application (except you're making heavy use of backend-specifc
IQueryHandlers such as SQL or HQL).<br>
<br>
<blockquote cite="mid:k5hqjk$f3l$1@xxxxxxxxe.org" type="cite">3
As CDO == EMF, you can easily adapt a generated RCP Client EMF
editor for CDO, but in practice you are likely better of to start
UI design from scratch, but you can re-use the concept of an
Editing domain and EMF.edit generated code, which is what I do.
(ItemProviders and Commands). </blockquote>
It's a major goal of CDO to better separate the functional from the
the technical design aspects/tasks. The only intrusive technical
aspect I can imagine of is large flat lists that should generally be
avoided in favour of a deeper object structure. IMHO this is a
useful rule even when only considering the usability of a graphical
application.<br>
<br>
<blockquote cite="mid:k5hqjk$f3l$1@xxxxxxxxe.org" type="cite">4
JFace databinding supports EMF, so JFace Databinding + CDO is a
great combination, you might want to watch loading large chunks of
data into your UI widgets (tables + trees), but there are ways to
limit the volumes. </blockquote>
I fully agree that EMF databinding is a totally cool thing. One
thing that tends to be problematic are remote deletions because the
databinding layer caches some strong references to objects that
might, all of a sudden, start to throw InvalidObjectExceptions or
ObjectNotFoundExceptions. You may appreciate that in CDO 4.2 we now
changed to:<br>
<br>
public static final CDOStaleReferencePolicy DEFAULT = PROXY;<br>
<br>
public static final CDOInvalidationPolicy DEFAULT = RELAXED;<br>
<br>
<br>
<blockquote cite="mid:k5hqjk$f3l$1@xxxxxxxxe.org" type="cite">5 I
you need to do something with DSL's (Develop a textual syntax,
which can interact with EMF/CDO models), this is also great with
xtext.
<br>
</blockquote>
Yes, because "CDO == EMF". But please keep in mind that editing DSL
instances stored *in* CDO with an Xtexteditor is problematic because
a text editor generally doesn't preserve the identities (e.g.
CDOIDs) of objects. That makes it hard to reconcile changes made in
a text editor back to CDO.<br>
<br>
<blockquote cite="mid:k5hqjk$f3l$1@xxxxxxxxe.org" type="cite">6
CDO performs well, you can tweak it, to fetch more or less chunks
of data for EReferences. If you don't like the behaviour you can
fire CDO Queries to get exactly what you want. Also unused objects
are garbage collected, so you can safely read a lot of data (As
long as you don't keep a reference). </blockquote>
Funnily this scalability originally came as a by-product of the
auditing functionality ;-)<br>
<br>
<blockquote cite="mid:k5hqjk$f3l$1@xxxxxxxxe.org" type="cite">7 I
am really fond that objects have a lifecycle, and all my object
have a unique CDO ID. I actually present the CDOID, in the status
line of the app. It's a great way to check what's going on. </blockquote>
And now you can even plug in your own CDOIDGenerator at the
client-side:<br>
<br>
public interface CDOIDGenerator<br>
{<br>
public static final CDOIDGenerator UUID = new CDOIDGenerator()<br>
{<br>
public CDOID generateCDOID(EObject object)<br>
{<br>
byte[] bytes = new byte[16];<br>
UUIDGenerator.DEFAULT.generate(bytes);<br>
return CDOIDUtil.createUUID(bytes);<br>
}<br>
<br>
public void reset()<br>
{<br>
// Do nothing<br>
}<br>
};<br>
<br>
/**<br>
* Generates a {@link CDOID}.<br>
* <br>
* @param object<br>
* the object to generate a new CDOID for if available,
<code>null</code> otherwise.<br>
*/<br>
public CDOID generateCDOID(EObject object);<br>
<br>
/**<br>
* Called at the end of a commit operation to give this ID
generator a chance to reset its sequence of IDs.<br>
*/<br>
public void reset();<br>
}<br>
<br>
<blockquote cite="mid:k5hqjk$f3l$1@xxxxxxxxe.org" type="cite">
8 Invalidations are great, basically when an object goes, remotely
dirty, other views are notified and can get the latest status of
an object. <br>
<br>
What I could do without in CDO
<br>
<br>
9. Revisions & referential integrity, I loved it at first, but
right now for the app. I have. it's a burden. The concept of
revisions adds a lot of requirements in CDO, I think CDO should
also have a simpler flat mode, without the revisions and checks on
integrity. It adds to the complexity of the CDO middleware and the
generated DB get's schema's. Some apps, don't need it or need it
partially. In my case, I would need revisions for some classes
only. </blockquote>
I suspect you don't refer to CDORevisions but to the auditing mode
in general? You know that it can be switched off. Granted, for the
DBStore in particular
<a class="moz-txt-link-freetext" href="https://bugs.eclipse.org/bugs/show_bug.cgi?id=351068">https://bugs.eclipse.org/bugs/show_bug.cgi?id=351068</a> is pending. I
really want to work on this soon.<br>
<br>
Partial auditing has been requested in the past. Conceptually I
don't like the idea because the framework couldn't guarantee the
logical consistency of the graph anymore. But I'm willing to
reconsider this when the DBStore gets its next design overhaul (not
scheduled, yet).<br>
<br>
What exact integrity checks are you referring to? Referential
integrity checks in the repository can be switched off (and they are
by default).<br>
<br>
<blockquote cite="mid:k5hqjk$f3l$1@xxxxxxxxe.org" type="cite">It
sometimes feels CDO is trying to mimic a Concurrent Version System
like SVN or CVS, but for many apps you really don't need that. <br>
</blockquote>
Yes, CDO tries to offer support in both worlds, the database
driven-like runtime applications and the more tool-like use cases
where design-time models need to be stored/managed in a repository.
You can imagine that this is sometimes hard but I think we've done a
pretty good job. Are there particular parts in CDO that are
problematic for you in this regard (i.e., not just unneeded)?<br>
<br>
BTW. an example of a cool new SCM-like feature is our new History
view support for repositories, branches or single objects:<br>
<br>
<img src="http://www.eclipse.org/forums/index.php?t=getfile&id=11887" alt=""><br>
<br>
<blockquote cite="mid:k5hqjk$f3l$1@xxxxxxxxe.org" type="cite">10.
In CDO there are CDOFolders and CDOResources. </blockquote>
Yes, and CDOTextResources and CDOBinaryResources, which are now
(almost) first class citizens of a CDO repository:<br>
<br>
<img src="http://www.eclipse.org/forums/index.php?t=getfile&id=11888" alt=""><br>
<br>
<blockquote cite="mid:k5hqjk$f3l$1@xxxxxxxxe.org" type="cite">Both
are also CDO objects, and stored in the DB. I went through great
length to find the best way to use them, like the the names to
give them, which is meta information you need to deal with in the
application. (Remember which name you used for which resource to
keep which data objects, in my case each eclass has its own
cdoresource). </blockquote>
Yes, that's the main value of Resources in general: They provide
well-known entry points into the (persistent) graph of objects.<br>
<br>
Apart from that they're an essential part of "CDO == EMF" (see point
1).<br>
<br>
<blockquote cite="mid:k5hqjk$f3l$1@xxxxxxxxe.org" type="cite">Right
now, I am not sure what the added value is of these, besides some
additional grouping of objects, I think, without them it could
keep CDO simpler and avoid additional DB data. </blockquote>
Please note that you absolutely don't need to use CDOResourceFolders
and CDOResources (except for a single one to contain all other
objects). The characteristics of a CDO model is the same when you
store all objects in a single resource.<br>
<br>
<blockquote cite="mid:k5hqjk$f3l$1@xxxxxxxxe.org" type="cite">(Note
that in point 3, I mentioned the EMF Editing domain, which has a
ResourceSet which can hold CDOResource objects. I use this, so
without CDO Resources, I wouldn't be able to use an editing
domain, so something else would be needed). <br>
</blockquote>
I think the generated editors also make heavy use of the assumption
that objects are contained by resources.<br>
<br>
<blockquote cite="mid:k5hqjk$f3l$1@xxxxxxxxe.org" type="cite">What
I wish for in CDO.
<br>
<br>
11. Model migrations. There are initiatives like COPE, which could
be applied with CDO, that would be great. So add a class in your
model, and let the new feature deal with the migration and transit
your data. </blockquote>
Fully agreed. If only someone would need it enough to open the
wallet and fund the development of this feature :P<br>
<br>
<blockquote cite="mid:k5hqjk$f3l$1@xxxxxxxxe.org" type="cite">12.
It's a hard learning curve, because most of the docs are outdated
or not written, so mea-culpa, we could do better. I wish for a
thriving community around a general purpose
smart-object-persistence system like CDO. <br>
</blockquote>
Yes! Technical writers in the world, here's a project that needs you
;-)<br>
<br>
<blockquote cite="mid:k5hqjk$f3l$1@xxxxxxxxe.org" type="cite">Finally.
Eike Stepper and others, have been great in supporting me on this
forum. Generally very quick and helpful!<br>
</blockquote>
Good docs would certainly be nicer but, while they're absent, good
online support is our attempt to compensate ;-)<br>
<br>
Cheers<br>
/Eike<br>
<br>
----<br>
<a class="moz-txt-link-freetext" href="http://www.esc-net.de">http://www.esc-net.de</a><br>
<a class="moz-txt-link-freetext" href="http://thegordian.blogspot.com">http://thegordian.blogspot.com</a><br>
<a class="moz-txt-link-freetext" href="http://twitter.com/eikestepper">http://twitter.com/eikestepper</a><br>
<br>
<br>
<br>
</body>
</html>
-
Attachment: bgchgghb.png
(Size: 83.23KB, Downloaded 145 times) -
Attachment: edjjaeef.png
(Size: 16.76KB, Downloaded 141 times)
Cheers
/Eike
----
http://www.esc-net.de
http://thegordian.blogspot.com
http://twitter.com/eikestepper
|
|
|
| Re: Understanding CDO [message #946420 is a reply to message #945941] |
Tue, 16 October 2012 06:30 |
|
<html>
<head>
<meta content="text/html; charset=UTF-8" http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
Hi Christophe,<br>
<br>
Thank you very much for your detailed experience report. I like it
lot ;-)<br>
<br>
More comments below...<br>
<br>
<br>
<div class="moz-cite-prefix">Am 15.10.2012 22:10, schrieb Christophe
Bouhier:<br>
</div>
<blockquote cite="mid:k5hqjk$f3l$1@xxxxxxxxe.org" type="cite">Hello
Mauro, <br>
for the last 2 years, I have been working on a client/server
application using CDO. Depending on your needs, CDO could be the
right fit. <br>
What I like (a lot). <br>
1 CDO == EMF, so you can model data first in .xsd or directly in
.ecore, and you can tell CDO to use your generated packages, which
will build the DB schema. </blockquote>
EMF compliance is very important to us and we're proud to support
most of EMF's features. Among the few exceptions are:<br>
<br>
a) Feature maps are hard to deal with in RDBs<br>
<br>
b) Because CDOResources are EObjects (see point 10) a small number
of other frameworks may run into trouble when trying to find out the
concrete type of a Notifier because the result depends on a
particular order of instanceof checks (check Resources first).<br>
<br>
c) With remote change notifications enabled, i.e.,
view.options().addChangeSubscriptionPolicy(...), your own Adapters
often need to distinguish between local or remote changes. An
instanceof CDODeltaNotification does the trick.<br>
<br>
d) Some IDE applications (and some poorly designed frameworks such
as GMF) heavily rely on IResources which are probably impossible to
simulate for CDOResources. For example it's hard or impossible to
present problem markers for validation problems in CDOResources
because IMarkers are associated with IResources. This is not a CDO
problem but a platform/IMarker problem that other
non-"platform:resource" Resources share in common.<br>
<br>
<blockquote cite="mid:k5hqjk$f3l$1@xxxxxxxxe.org" type="cite">2
On the CDO Store, you can choose from the DBStore, which supports
various DB's, I have worked with MySQL and Postgres. With
Hibernate store, there is an additional ORM layer, which works
with tons of other DB's supported by Hibernate. </blockquote>
And there's support for some other backend types, such as DB4O,
MongoDB or Objectivity/DB. I've recently developed a
RandomAccessFile based journaling store, named LissomeStore. It
still uses an RDB for a small and fixed number of indexes into the
random access file(s). For commits it uses a journal file and
adjusts the index tables asynchronously. The performance of large
commits can typically be increased by factor 600 in my tests.<br>
<br>
IMHO the great value of the IStore design is that it becomes a snap
to *change* the backend choice at any time without much impact on
the application (except you're making heavy use of backend-specifc
IQueryHandlers such as SQL or HQL).<br>
<br>
<blockquote cite="mid:k5hqjk$f3l$1@xxxxxxxxe.org" type="cite">3
As CDO == EMF, you can easily adapt a generated RCP Client EMF
editor for CDO, but in practice you are likely better of to start
UI design from scratch, but you can re-use the concept of an
Editing domain and EMF.edit generated code, which is what I do.
(ItemProviders and Commands). </blockquote>
It's a major goal of CDO to better separate the functional from the
the technical design aspects/tasks. The only intrusive technical
aspect I can imagine of is large flat lists that should generally be
avoided in favour of a deeper object structure. IMHO this is a
useful rule even when only considering the usability of a graphical
application.<br>
<br>
<blockquote cite="mid:k5hqjk$f3l$1@xxxxxxxxe.org" type="cite">4
JFace databinding supports EMF, so JFace Databinding + CDO is a
great combination, you might want to watch loading large chunks of
data into your UI widgets (tables + trees), but there are ways to
limit the volumes. </blockquote>
I fully agree that EMF databinding is a totally cool thing. One
thing that tends to be problematic are remote deletions because the
databinding layer caches some strong references to objects that
might, all of a sudden, start to throw InvalidObjectExceptions or
ObjectNotFoundExceptions. You may appreciate that in CDO 4.2 we now
changed to:<br>
<br>
public static final CDOStaleReferencePolicy DEFAULT = PROXY;<br>
<br>
public static final CDOInvalidationPolicy DEFAULT = RELAXED;<br>
<br>
<br>
<blockquote cite="mid:k5hqjk$f3l$1@xxxxxxxxe.org" type="cite">5 I
you need to do something with DSL's (Develop a textual syntax,
which can interact with EMF/CDO models), this is also great with
xtext.
<br>
</blockquote>
Yes, because "CDO == EMF". But please keep in mind that editing DSL
instances stored *in* CDO with an Xtexteditor is problematic because
a text editor generally doesn't preserve the identities (e.g.
CDOIDs) of objects. That makes it hard to reconcile changes made in
a text editor back to CDO.<br>
<br>
<blockquote cite="mid:k5hqjk$f3l$1@xxxxxxxxe.org" type="cite">6
CDO performs well, you can tweak it, to fetch more or less chunks
of data for EReferences. If you don't like the behaviour you can
fire CDO Queries to get exactly what you want. Also unused objects
are garbage collected, so you can safely read a lot of data (As
long as you don't keep a reference). </blockquote>
Funnily this scalability originally came as a by-product of the
auditing functionality ;-)<br>
<br>
<blockquote cite="mid:k5hqjk$f3l$1@xxxxxxxxe.org" type="cite">7 I
am really fond that objects have a lifecycle, and all my object
have a unique CDO ID. I actually present the CDOID, in the status
line of the app. It's a great way to check what's going on. </blockquote>
And now you can even plug in your own CDOIDGenerator at the
client-side:<br>
<br>
public interface CDOIDGenerator<br>
{<br>
public static final CDOIDGenerator UUID = new CDOIDGenerator()<br>
{<br>
public CDOID generateCDOID(EObject object)<br>
{<br>
byte[] bytes = new byte[16];<br>
UUIDGenerator.DEFAULT.generate(bytes);<br>
return CDOIDUtil.createUUID(bytes);<br>
}<br>
<br>
public void reset()<br>
{<br>
// Do nothing<br>
}<br>
};<br>
<br>
/**<br>
* Generates a {@link CDOID}.<br>
* <br>
* @param object<br>
* the object to generate a new CDOID for if available,
<code>null</code> otherwise.<br>
*/<br>
public CDOID generateCDOID(EObject object);<br>
<br>
/**<br>
* Called at the end of a commit operation to give this ID
generator a chance to reset its sequence of IDs.<br>
*/<br>
public void reset();<br>
}<br>
<br>
<blockquote cite="mid:k5hqjk$f3l$1@xxxxxxxxe.org" type="cite">
8 Invalidations are great, basically when an object goes, remotely
dirty, other views are notified and can get the latest status of
an object. <br>
<br>
What I could do without in CDO
<br>
<br>
9. Revisions & referential integrity, I loved it at first, but
right now for the app. I have. it's a burden. The concept of
revisions adds a lot of requirements in CDO, I think CDO should
also have a simpler flat mode, without the revisions and checks on
integrity. It adds to the complexity of the CDO middleware and the
generated DB get's schema's. Some apps, don't need it or need it
partially. In my case, I would need revisions for some classes
only. </blockquote>
I suspect you don't refer to CDORevisions but to the auditing mode
in general? You know that it can be switched off. Granted, for the
DBStore in particular
<a class="moz-txt-link-freetext" href="https://bugs.eclipse.org/bugs/show_bug.cgi?id=351068">https://bugs.eclipse.org/bugs/show_bug.cgi?id=351068</a> is pending. I
really want to work on this soon.<br>
<br>
Partial auditing has been requested in the past. Conceptually I
don't like the idea because the framework couldn't guarantee the
logical consistency of the graph anymore. But I'm willing to
reconsider this when the DBStore gets its next design overhaul (not
scheduled, yet).<br>
<br>
What exact integrity checks are you referring to? Referential
integrity checks in the repository can be switched off (and they are
by default).<br>
<br>
<blockquote cite="mid:k5hqjk$f3l$1@xxxxxxxxe.org" type="cite">It
sometimes feels CDO is trying to mimic a Concurrent Version System
like SVN or CVS, but for many apps you really don't need that. <br>
</blockquote>
Yes, CDO tries to offer support in both worlds, the database
driven-like runtime applications and the more tool-like use cases
where design-time models need to be stored/managed in a repository.
You can imagine that this is sometimes hard but I think we've done a
pretty good job. Are there particular parts in CDO that are
problematic for you in this regard (i.e., not just unneeded)?<br>
<br>
BTW. an example of a cool new SCM-like feature is our new History
view support for repositories, branches or single objects:<br>
<br>
<img src="http://www.eclipse.org/forums/index.php?t=getfile&id=11889" alt=""><br>
<br>
<blockquote cite="mid:k5hqjk$f3l$1@xxxxxxxxe.org" type="cite">10.
In CDO there are CDOFolders and CDOResources. </blockquote>
Yes, and CDOTextResources and CDOBinaryResources, which are now
(almost) first class citizens of a CDO repository:<br>
<br>
<img src="http://www.eclipse.org/forums/index.php?t=getfile&id=11890" alt=""><br>
<br>
<blockquote cite="mid:k5hqjk$f3l$1@xxxxxxxxe.org" type="cite">Both
are also CDO objects, and stored in the DB. I went through great
length to find the best way to use them, like the the names to
give them, which is meta information you need to deal with in the
application. (Remember which name you used for which resource to
keep which data objects, in my case each eclass has its own
cdoresource). </blockquote>
Yes, that's the main value of Resources in general: They provide
well-known entry points into the (persistent) graph of objects.<br>
<br>
Apart from that they're an essential part of "CDO == EMF" (see point
1).<br>
<br>
<blockquote cite="mid:k5hqjk$f3l$1@xxxxxxxxe.org" type="cite">Right
now, I am not sure what the added value is of these, besides some
additional grouping of objects, I think, without them it could
keep CDO simpler and avoid additional DB data. </blockquote>
Please note that you absolutely don't need to use CDOResourceFolders
and CDOResources (except for a single one to contain all other
objects). The characteristics of a CDO model is the same when you
store all objects in a single resource.<br>
<br>
<blockquote cite="mid:k5hqjk$f3l$1@xxxxxxxxe.org" type="cite">(Note
that in point 3, I mentioned the EMF Editing domain, which has a
ResourceSet which can hold CDOResource objects. I use this, so
without CDO Resources, I wouldn't be able to use an editing
domain, so something else would be needed). <br>
</blockquote>
I think the generated editors also make heavy use of the assumption
that objects are contained by resources.<br>
<br>
<blockquote cite="mid:k5hqjk$f3l$1@xxxxxxxxe.org" type="cite">What
I wish for in CDO.
<br>
<br>
11. Model migrations. There are initiatives like COPE, which could
be applied with CDO, that would be great. So add a class in your
model, and let the new feature deal with the migration and transit
your data. </blockquote>
Fully agreed. If only someone would need it enough to open the
wallet and fund the development of this feature :P<br>
<br>
<blockquote cite="mid:k5hqjk$f3l$1@xxxxxxxxe.org" type="cite">12.
It's a hard learning curve, because most of the docs are outdated
or not written, so mea-culpa, we could do better. I wish for a
thriving community around a general purpose
smart-object-persistence system like CDO. <br>
</blockquote>
Yes! Technical writers in the world, here's a project that needs you
;-)<br>
<br>
<blockquote cite="mid:k5hqjk$f3l$1@xxxxxxxxe.org" type="cite">Finally.
Eike Stepper and others, have been great in supporting me on this
forum. Generally very quick and helpful!<br>
</blockquote>
Good docs would certainly be nicer but, while they're absent, good
online support is our attempt to compensate ;-)<br>
<br>
Cheers<br>
/Eike<br>
<br>
----<br>
<a class="moz-txt-link-freetext" href="http://www.esc-net.de">http://www.esc-net.de</a><br>
<a class="moz-txt-link-freetext" href="http://thegordian.blogspot.com">http://thegordian.blogspot.com</a><br>
<a class="moz-txt-link-freetext" href="http://twitter.com/eikestepper">http://twitter.com/eikestepper</a><br>
<br>
<br>
<br>
</body>
</html>
-
Attachment: bgchgghb.png
(Size: 83.23KB, Downloaded 140 times) -
Attachment: edjjaeef.png
(Size: 16.76KB, Downloaded 121 times)
Cheers
/Eike
----
http://www.esc-net.de
http://thegordian.blogspot.com
http://twitter.com/eikestepper
|
|
|
| Re: Understanding CDO [message #946424 is a reply to message #945941] |
Tue, 16 October 2012 06:30 |
|
<html>
<head>
<meta content="text/html; charset=UTF-8" http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
Hi Christophe,<br>
<br>
Thank you very much for your detailed experience report. I like it
lot ;-)<br>
<br>
More comments below...<br>
<br>
<br>
<div class="moz-cite-prefix">Am 15.10.2012 22:10, schrieb Christophe
Bouhier:<br>
</div>
<blockquote cite="mid:k5hqjk$f3l$1@xxxxxxxxe.org" type="cite">Hello
Mauro, <br>
for the last 2 years, I have been working on a client/server
application using CDO. Depending on your needs, CDO could be the
right fit. <br>
What I like (a lot). <br>
1 CDO == EMF, so you can model data first in .xsd or directly in
.ecore, and you can tell CDO to use your generated packages, which
will build the DB schema. </blockquote>
EMF compliance is very important to us and we're proud to support
most of EMF's features. Among the few exceptions are:<br>
<br>
a) Feature maps are hard to deal with in RDBs<br>
<br>
b) Because CDOResources are EObjects (see point 10) a small number
of other frameworks may run into trouble when trying to find out the
concrete type of a Notifier because the result depends on a
particular order of instanceof checks (check Resources first).<br>
<br>
c) With remote change notifications enabled, i.e.,
view.options().addChangeSubscriptionPolicy(...), your own Adapters
often need to distinguish between local or remote changes. An
instanceof CDODeltaNotification does the trick.<br>
<br>
d) Some IDE applications (and some poorly designed frameworks such
as GMF) heavily rely on IResources which are probably impossible to
simulate for CDOResources. For example it's hard or impossible to
present problem markers for validation problems in CDOResources
because IMarkers are associated with IResources. This is not a CDO
problem but a platform/IMarker problem that other
non-"platform:resource" Resources share in common.<br>
<br>
<blockquote cite="mid:k5hqjk$f3l$1@xxxxxxxxe.org" type="cite">2
On the CDO Store, you can choose from the DBStore, which supports
various DB's, I have worked with MySQL and Postgres. With
Hibernate store, there is an additional ORM layer, which works
with tons of other DB's supported by Hibernate. </blockquote>
And there's support for some other backend types, such as DB4O,
MongoDB or Objectivity/DB. I've recently developed a
RandomAccessFile based journaling store, named LissomeStore. It
still uses an RDB for a small and fixed number of indexes into the
random access file(s). For commits it uses a journal file and
adjusts the index tables asynchronously. The performance of large
commits can typically be increased by factor 600 in my tests.<br>
<br>
IMHO the great value of the IStore design is that it becomes a snap
to *change* the backend choice at any time without much impact on
the application (except you're making heavy use of backend-specifc
IQueryHandlers such as SQL or HQL).<br>
<br>
<blockquote cite="mid:k5hqjk$f3l$1@xxxxxxxxe.org" type="cite">3
As CDO == EMF, you can easily adapt a generated RCP Client EMF
editor for CDO, but in practice you are likely better of to start
UI design from scratch, but you can re-use the concept of an
Editing domain and EMF.edit generated code, which is what I do.
(ItemProviders and Commands). </blockquote>
It's a major goal of CDO to better separate the functional from the
the technical design aspects/tasks. The only intrusive technical
aspect I can imagine of is large flat lists that should generally be
avoided in favour of a deeper object structure. IMHO this is a
useful rule even when only considering the usability of a graphical
application.<br>
<br>
<blockquote cite="mid:k5hqjk$f3l$1@xxxxxxxxe.org" type="cite">4
JFace databinding supports EMF, so JFace Databinding + CDO is a
great combination, you might want to watch loading large chunks of
data into your UI widgets (tables + trees), but there are ways to
limit the volumes. </blockquote>
I fully agree that EMF databinding is a totally cool thing. One
thing that tends to be problematic are remote deletions because the
databinding layer caches some strong references to objects that
might, all of a sudden, start to throw InvalidObjectExceptions or
ObjectNotFoundExceptions. You may appreciate that in CDO 4.2 we now
changed to:<br>
<br>
public static final CDOStaleReferencePolicy DEFAULT = PROXY;<br>
<br>
public static final CDOInvalidationPolicy DEFAULT = RELAXED;<br>
<br>
<br>
<blockquote cite="mid:k5hqjk$f3l$1@xxxxxxxxe.org" type="cite">5 I
you need to do something with DSL's (Develop a textual syntax,
which can interact with EMF/CDO models), this is also great with
xtext.
<br>
</blockquote>
Yes, because "CDO == EMF". But please keep in mind that editing DSL
instances stored *in* CDO with an Xtexteditor is problematic because
a text editor generally doesn't preserve the identities (e.g.
CDOIDs) of objects. That makes it hard to reconcile changes made in
a text editor back to CDO.<br>
<br>
<blockquote cite="mid:k5hqjk$f3l$1@xxxxxxxxe.org" type="cite">6
CDO performs well, you can tweak it, to fetch more or less chunks
of data for EReferences. If you don't like the behaviour you can
fire CDO Queries to get exactly what you want. Also unused objects
are garbage collected, so you can safely read a lot of data (As
long as you don't keep a reference). </blockquote>
Funnily this scalability originally came as a by-product of the
auditing functionality ;-)<br>
<br>
<blockquote cite="mid:k5hqjk$f3l$1@xxxxxxxxe.org" type="cite">7 I
am really fond that objects have a lifecycle, and all my object
have a unique CDO ID. I actually present the CDOID, in the status
line of the app. It's a great way to check what's going on. </blockquote>
And now you can even plug in your own CDOIDGenerator at the
client-side:<br>
<br>
public interface CDOIDGenerator<br>
{<br>
public static final CDOIDGenerator UUID = new CDOIDGenerator()<br>
{<br>
public CDOID generateCDOID(EObject object)<br>
{<br>
byte[] bytes = new byte[16];<br>
UUIDGenerator.DEFAULT.generate(bytes);<br>
return CDOIDUtil.createUUID(bytes);<br>
}<br>
<br>
public void reset()<br>
{<br>
// Do nothing<br>
}<br>
};<br>
<br>
/**<br>
* Generates a {@link CDOID}.<br>
* <br>
* @param object<br>
* the object to generate a new CDOID for if available,
<code>null</code> otherwise.<br>
*/<br>
public CDOID generateCDOID(EObject object);<br>
<br>
/**<br>
* Called at the end of a commit operation to give this ID
generator a chance to reset its sequence of IDs.<br>
*/<br>
public void reset();<br>
}<br>
<br>
<blockquote cite="mid:k5hqjk$f3l$1@xxxxxxxxe.org" type="cite">
8 Invalidations are great, basically when an object goes, remotely
dirty, other views are notified and can get the latest status of
an object. <br>
<br>
What I could do without in CDO
<br>
<br>
9. Revisions & referential integrity, I loved it at first, but
right now for the app. I have. it's a burden. The concept of
revisions adds a lot of requirements in CDO, I think CDO should
also have a simpler flat mode, without the revisions and checks on
integrity. It adds to the complexity of the CDO middleware and the
generated DB get's schema's. Some apps, don't need it or need it
partially. In my case, I would need revisions for some classes
only. </blockquote>
I suspect you don't refer to CDORevisions but to the auditing mode
in general? You know that it can be switched off. Granted, for the
DBStore in particular
<a class="moz-txt-link-freetext" href="https://bugs.eclipse.org/bugs/show_bug.cgi?id=351068">https://bugs.eclipse.org/bugs/show_bug.cgi?id=351068</a> is pending. I
really want to work on this soon.<br>
<br>
Partial auditing has been requested in the past. Conceptually I
don't like the idea because the framework couldn't guarantee the
logical consistency of the graph anymore. But I'm willing to
reconsider this when the DBStore gets its next design overhaul (not
scheduled, yet).<br>
<br>
What exact integrity checks are you referring to? Referential
integrity checks in the repository can be switched off (and they are
by default).<br>
<br>
<blockquote cite="mid:k5hqjk$f3l$1@xxxxxxxxe.org" type="cite">It
sometimes feels CDO is trying to mimic a Concurrent Version System
like SVN or CVS, but for many apps you really don't need that. <br>
</blockquote>
Yes, CDO tries to offer support in both worlds, the database
driven-like runtime applications and the more tool-like use cases
where design-time models need to be stored/managed in a repository.
You can imagine that this is sometimes hard but I think we've done a
pretty good job. Are there particular parts in CDO that are
problematic for you in this regard (i.e., not just unneeded)?<br>
<br>
BTW. an example of a cool new SCM-like feature is our new History
view support for repositories, branches or single objects:<br>
<br>
<img src="http://www.eclipse.org/forums/index.php?t=getfile&id=11891" alt=""><br>
<br>
<blockquote cite="mid:k5hqjk$f3l$1@xxxxxxxxe.org" type="cite">10.
In CDO there are CDOFolders and CDOResources. </blockquote>
Yes, and CDOTextResources and CDOBinaryResources, which are now
(almost) first class citizens of a CDO repository:<br>
<br>
<img src="http://www.eclipse.org/forums/index.php?t=getfile&id=11892" alt=""><br>
<br>
<blockquote cite="mid:k5hqjk$f3l$1@xxxxxxxxe.org" type="cite">Both
are also CDO objects, and stored in the DB. I went through great
length to find the best way to use them, like the the names to
give them, which is meta information you need to deal with in the
application. (Remember which name you used for which resource to
keep which data objects, in my case each eclass has its own
cdoresource). </blockquote>
Yes, that's the main value of Resources in general: They provide
well-known entry points into the (persistent) graph of objects.<br>
<br>
Apart from that they're an essential part of "CDO == EMF" (see point
1).<br>
<br>
<blockquote cite="mid:k5hqjk$f3l$1@xxxxxxxxe.org" type="cite">Right
now, I am not sure what the added value is of these, besides some
additional grouping of objects, I think, without them it could
keep CDO simpler and avoid additional DB data. </blockquote>
Please note that you absolutely don't need to use CDOResourceFolders
and CDOResources (except for a single one to contain all other
objects). The characteristics of a CDO model is the same when you
store all objects in a single resource.<br>
<br>
<blockquote cite="mid:k5hqjk$f3l$1@xxxxxxxxe.org" type="cite">(Note
that in point 3, I mentioned the EMF Editing domain, which has a
ResourceSet which can hold CDOResource objects. I use this, so
without CDO Resources, I wouldn't be able to use an editing
domain, so something else would be needed). <br>
</blockquote>
I think the generated editors also make heavy use of the assumption
that objects are contained by resources.<br>
<br>
<blockquote cite="mid:k5hqjk$f3l$1@xxxxxxxxe.org" type="cite">What
I wish for in CDO.
<br>
<br>
11. Model migrations. There are initiatives like COPE, which could
be applied with CDO, that would be great. So add a class in your
model, and let the new feature deal with the migration and transit
your data. </blockquote>
Fully agreed. If only someone would need it enough to open the
wallet and fund the development of this feature :P<br>
<br>
<blockquote cite="mid:k5hqjk$f3l$1@xxxxxxxxe.org" type="cite">12.
It's a hard learning curve, because most of the docs are outdated
or not written, so mea-culpa, we could do better. I wish for a
thriving community around a general purpose
smart-object-persistence system like CDO. <br>
</blockquote>
Yes! Technical writers in the world, here's a project that needs you
;-)<br>
<br>
<blockquote cite="mid:k5hqjk$f3l$1@xxxxxxxxe.org" type="cite">Finally.
Eike Stepper and others, have been great in supporting me on this
forum. Generally very quick and helpful!<br>
</blockquote>
Good docs would certainly be nicer but, while they're absent, good
online support is our attempt to compensate ;-)<br>
<br>
Cheers<br>
/Eike<br>
<br>
----<br>
<a class="moz-txt-link-freetext" href="http://www.esc-net.de">http://www.esc-net.de</a><br>
<a class="moz-txt-link-freetext" href="http://thegordian.blogspot.com">http://thegordian.blogspot.com</a><br>
<a class="moz-txt-link-freetext" href="http://twitter.com/eikestepper">http://twitter.com/eikestepper</a><br>
<br>
<br>
<br>
</body>
</html>
-
Attachment: bgchgghb.png
(Size: 83.23KB, Downloaded 135 times) -
Attachment: edjjaeef.png
(Size: 16.76KB, Downloaded 134 times)
Cheers
/Eike
----
http://www.esc-net.de
http://thegordian.blogspot.com
http://twitter.com/eikestepper
|
|
|
| Re: Understanding CDO [message #946430 is a reply to message #945941] |
Tue, 16 October 2012 06:30 |
|
<html>
<head>
<meta content="text/html; charset=UTF-8" http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
Hi Christophe,<br>
<br>
Thank you very much for your detailed experience report. I like it
lot ;-)<br>
<br>
More comments below...<br>
<br>
<br>
<div class="moz-cite-prefix">Am 15.10.2012 22:10, schrieb Christophe
Bouhier:<br>
</div>
<blockquote cite="mid:k5hqjk$f3l$1@xxxxxxxxe.org" type="cite">Hello
Mauro, <br>
for the last 2 years, I have been working on a client/server
application using CDO. Depending on your needs, CDO could be the
right fit. <br>
What I like (a lot). <br>
1 CDO == EMF, so you can model data first in .xsd or directly in
.ecore, and you can tell CDO to use your generated packages, which
will build the DB schema. </blockquote>
EMF compliance is very important to us and we're proud to support
most of EMF's features. Among the few exceptions are:<br>
<br>
a) Feature maps are hard to deal with in RDBs<br>
<br>
b) Because CDOResources are EObjects (see point 10) a small number
of other frameworks may run into trouble when trying to find out the
concrete type of a Notifier because the result depends on a
particular order of instanceof checks (check Resources first).<br>
<br>
c) With remote change notifications enabled, i.e.,
view.options().addChangeSubscriptionPolicy(...), your own Adapters
often need to distinguish between local or remote changes. An
instanceof CDODeltaNotification does the trick.<br>
<br>
d) Some IDE applications (and some poorly designed frameworks such
as GMF) heavily rely on IResources which are probably impossible to
simulate for CDOResources. For example it's hard or impossible to
present problem markers for validation problems in CDOResources
because IMarkers are associated with IResources. This is not a CDO
problem but a platform/IMarker problem that other
non-"platform:resource" Resources share in common.<br>
<br>
<blockquote cite="mid:k5hqjk$f3l$1@xxxxxxxxe.org" type="cite">2
On the CDO Store, you can choose from the DBStore, which supports
various DB's, I have worked with MySQL and Postgres. With
Hibernate store, there is an additional ORM layer, which works
with tons of other DB's supported by Hibernate. </blockquote>
And there's support for some other backend types, such as DB4O,
MongoDB or Objectivity/DB. I've recently developed a
RandomAccessFile based journaling store, named LissomeStore. It
still uses an RDB for a small and fixed number of indexes into the
random access file(s). For commits it uses a journal file and
adjusts the index tables asynchronously. The performance of large
commits can typically be increased by factor 600 in my tests.<br>
<br>
IMHO the great value of the IStore design is that it becomes a snap
to *change* the backend choice at any time without much impact on
the application (except you're making heavy use of backend-specifc
IQueryHandlers such as SQL or HQL).<br>
<br>
<blockquote cite="mid:k5hqjk$f3l$1@xxxxxxxxe.org" type="cite">3
As CDO == EMF, you can easily adapt a generated RCP Client EMF
editor for CDO, but in practice you are likely better of to start
UI design from scratch, but you can re-use the concept of an
Editing domain and EMF.edit generated code, which is what I do.
(ItemProviders and Commands). </blockquote>
It's a major goal of CDO to better separate the functional from the
the technical design aspects/tasks. The only intrusive technical
aspect I can imagine of is large flat lists that should generally be
avoided in favour of a deeper object structure. IMHO this is a
useful rule even when only considering the usability of a graphical
application.<br>
<br>
<blockquote cite="mid:k5hqjk$f3l$1@xxxxxxxxe.org" type="cite">4
JFace databinding supports EMF, so JFace Databinding + CDO is a
great combination, you might want to watch loading large chunks of
data into your UI widgets (tables + trees), but there are ways to
limit the volumes. </blockquote>
I fully agree that EMF databinding is a totally cool thing. One
thing that tends to be problematic are remote deletions because the
databinding layer caches some strong references to objects that
might, all of a sudden, start to throw InvalidObjectExceptions or
ObjectNotFoundExceptions. You may appreciate that in CDO 4.2 we now
changed to:<br>
<br>
public static final CDOStaleReferencePolicy DEFAULT = PROXY;<br>
<br>
public static final CDOInvalidationPolicy DEFAULT = RELAXED;<br>
<br>
<br>
<blockquote cite="mid:k5hqjk$f3l$1@xxxxxxxxe.org" type="cite">5 I
you need to do something with DSL's (Develop a textual syntax,
which can interact with EMF/CDO models), this is also great with
xtext.
<br>
</blockquote>
Yes, because "CDO == EMF". But please keep in mind that editing DSL
instances stored *in* CDO with an Xtexteditor is problematic because
a text editor generally doesn't preserve the identities (e.g.
CDOIDs) of objects. That makes it hard to reconcile changes made in
a text editor back to CDO.<br>
<br>
<blockquote cite="mid:k5hqjk$f3l$1@xxxxxxxxe.org" type="cite">6
CDO performs well, you can tweak it, to fetch more or less chunks
of data for EReferences. If you don't like the behaviour you can
fire CDO Queries to get exactly what you want. Also unused objects
are garbage collected, so you can safely read a lot of data (As
long as you don't keep a reference). </blockquote>
Funnily this scalability originally came as a by-product of the
auditing functionality ;-)<br>
<br>
<blockquote cite="mid:k5hqjk$f3l$1@xxxxxxxxe.org" type="cite">7 I
am really fond that objects have a lifecycle, and all my object
have a unique CDO ID. I actually present the CDOID, in the status
line of the app. It's a great way to check what's going on. </blockquote>
And now you can even plug in your own CDOIDGenerator at the
client-side:<br>
<br>
public interface CDOIDGenerator<br>
{<br>
public static final CDOIDGenerator UUID = new CDOIDGenerator()<br>
{<br>
public CDOID generateCDOID(EObject object)<br>
{<br>
byte[] bytes = new byte[16];<br>
UUIDGenerator.DEFAULT.generate(bytes);<br>
return CDOIDUtil.createUUID(bytes);<br>
}<br>
<br>
public void reset()<br>
{<br>
// Do nothing<br>
}<br>
};<br>
<br>
/**<br>
* Generates a {@link CDOID}.<br>
* <br>
* @param object<br>
* the object to generate a new CDOID for if available,
<code>null</code> otherwise.<br>
*/<br>
public CDOID generateCDOID(EObject object);<br>
<br>
/**<br>
* Called at the end of a commit operation to give this ID
generator a chance to reset its sequence of IDs.<br>
*/<br>
public void reset();<br>
}<br>
<br>
<blockquote cite="mid:k5hqjk$f3l$1@xxxxxxxxe.org" type="cite">
8 Invalidations are great, basically when an object goes, remotely
dirty, other views are notified and can get the latest status of
an object. <br>
<br>
What I could do without in CDO
<br>
<br>
9. Revisions & referential integrity, I loved it at first, but
right now for the app. I have. it's a burden. The concept of
revisions adds a lot of requirements in CDO, I think CDO should
also have a simpler flat mode, without the revisions and checks on
integrity. It adds to the complexity of the CDO middleware and the
generated DB get's schema's. Some apps, don't need it or need it
partially. In my case, I would need revisions for some classes
only. </blockquote>
I suspect you don't refer to CDORevisions but to the auditing mode
in general? You know that it can be switched off. Granted, for the
DBStore in particular
<a class="moz-txt-link-freetext" href="https://bugs.eclipse.org/bugs/show_bug.cgi?id=351068">https://bugs.eclipse.org/bugs/show_bug.cgi?id=351068</a> is pending. I
really want to work on this soon.<br>
<br>
Partial auditing has been requested in the past. Conceptually I
don't like the idea because the framework couldn't guarantee the
logical consistency of the graph anymore. But I'm willing to
reconsider this when the DBStore gets its next design overhaul (not
scheduled, yet).<br>
<br>
What exact integrity checks are you referring to? Referential
integrity checks in the repository can be switched off (and they are
by default).<br>
<br>
<blockquote cite="mid:k5hqjk$f3l$1@xxxxxxxxe.org" type="cite">It
sometimes feels CDO is trying to mimic a Concurrent Version System
like SVN or CVS, but for many apps you really don't need that. <br>
</blockquote>
Yes, CDO tries to offer support in both worlds, the database
driven-like runtime applications and the more tool-like use cases
where design-time models need to be stored/managed in a repository.
You can imagine that this is sometimes hard but I think we've done a
pretty good job. Are there particular parts in CDO that are
problematic for you in this regard (i.e., not just unneeded)?<br>
<br>
BTW. an example of a cool new SCM-like feature is our new History
view support for repositories, branches or single objects:<br>
<br>
<img src="http://www.eclipse.org/forums/index.php?t=getfile&id=11893" alt=""><br>
<br>
<blockquote cite="mid:k5hqjk$f3l$1@xxxxxxxxe.org" type="cite">10.
In CDO there are CDOFolders and CDOResources. </blockquote>
Yes, and CDOTextResources and CDOBinaryResources, which are now
(almost) first class citizens of a CDO repository:<br>
<br>
<img src="http://www.eclipse.org/forums/index.php?t=getfile&id=11894" alt=""><br>
<br>
<blockquote cite="mid:k5hqjk$f3l$1@xxxxxxxxe.org" type="cite">Both
are also CDO objects, and stored in the DB. I went through great
length to find the best way to use them, like the the names to
give them, which is meta information you need to deal with in the
application. (Remember which name you used for which resource to
keep which data objects, in my case each eclass has its own
cdoresource). </blockquote>
Yes, that's the main value of Resources in general: They provide
well-known entry points into the (persistent) graph of objects.<br>
<br>
Apart from that they're an essential part of "CDO == EMF" (see point
1).<br>
<br>
<blockquote cite="mid:k5hqjk$f3l$1@xxxxxxxxe.org" type="cite">Right
now, I am not sure what the added value is of these, besides some
additional grouping of objects, I think, without them it could
keep CDO simpler and avoid additional DB data. </blockquote>
Please note that you absolutely don't need to use CDOResourceFolders
and CDOResources (except for a single one to contain all other
objects). The characteristics of a CDO model is the same when you
store all objects in a single resource.<br>
<br>
<blockquote cite="mid:k5hqjk$f3l$1@xxxxxxxxe.org" type="cite">(Note
that in point 3, I mentioned the EMF Editing domain, which has a
ResourceSet which can hold CDOResource objects. I use this, so
without CDO Resources, I wouldn't be able to use an editing
domain, so something else would be needed). <br>
</blockquote>
I think the generated editors also make heavy use of the assumption
that objects are contained by resources.<br>
<br>
<blockquote cite="mid:k5hqjk$f3l$1@xxxxxxxxe.org" type="cite">What
I wish for in CDO.
<br>
<br>
11. Model migrations. There are initiatives like COPE, which could
be applied with CDO, that would be great. So add a class in your
model, and let the new feature deal with the migration and transit
your data. </blockquote>
Fully agreed. If only someone would need it enough to open the
wallet and fund the development of this feature :P<br>
<br>
<blockquote cite="mid:k5hqjk$f3l$1@xxxxxxxxe.org" type="cite">12.
It's a hard learning curve, because most of the docs are outdated
or not written, so mea-culpa, we could do better. I wish for a
thriving community around a general purpose
smart-object-persistence system like CDO. <br>
</blockquote>
Yes! Technical writers in the world, here's a project that needs you
;-)<br>
<br>
<blockquote cite="mid:k5hqjk$f3l$1@xxxxxxxxe.org" type="cite">Finally.
Eike Stepper and others, have been great in supporting me on this
forum. Generally very quick and helpful!<br>
</blockquote>
Good docs would certainly be nicer but, while they're absent, good
online support is our attempt to compensate ;-)<br>
<br>
Cheers<br>
/Eike<br>
<br>
----<br>
<a class="moz-txt-link-freetext" href="http://www.esc-net.de">http://www.esc-net.de</a><br>
<a class="moz-txt-link-freetext" href="http://thegordian.blogspot.com">http://thegordian.blogspot.com</a><br>
<a class="moz-txt-link-freetext" href="http://twitter.com/eikestepper">http://twitter.com/eikestepper</a><br>
<br>
<br>
<br>
</body>
</html>
-
Attachment: bgchgghb.png
(Size: 83.23KB, Downloaded 134 times) -
Attachment: edjjaeef.png
(Size: 16.76KB, Downloaded 131 times)
Cheers
/Eike
----
http://www.esc-net.de
http://thegordian.blogspot.com
http://twitter.com/eikestepper
|
|
|
| Re: Understanding CDO [message #946436 is a reply to message #945941] |
Tue, 16 October 2012 06:30 |
|
<html>
<head>
<meta content="text/html; charset=UTF-8" http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
Hi Christophe,<br>
<br>
Thank you very much for your detailed experience report. I like it
lot ;-)<br>
<br>
More comments below...<br>
<br>
<br>
<div class="moz-cite-prefix">Am 15.10.2012 22:10, schrieb Christophe
Bouhier:<br>
</div>
<blockquote cite="mid:k5hqjk$f3l$1@xxxxxxxxe.org" type="cite">Hello
Mauro, <br>
for the last 2 years, I have been working on a client/server
application using CDO. Depending on your needs, CDO could be the
right fit. <br>
What I like (a lot). <br>
1 CDO == EMF, so you can model data first in .xsd or directly in
.ecore, and you can tell CDO to use your generated packages, which
will build the DB schema. </blockquote>
EMF compliance is very important to us and we're proud to support
most of EMF's features. Among the few exceptions are:<br>
<br>
a) Feature maps are hard to deal with in RDBs<br>
<br>
b) Because CDOResources are EObjects (see point 10) a small number
of other frameworks may run into trouble when trying to find out the
concrete type of a Notifier because the result depends on a
particular order of instanceof checks (check Resources first).<br>
<br>
c) With remote change notifications enabled, i.e.,
view.options().addChangeSubscriptionPolicy(...), your own Adapters
often need to distinguish between local or remote changes. An
instanceof CDODeltaNotification does the trick.<br>
<br>
d) Some IDE applications (and some poorly designed frameworks such
as GMF) heavily rely on IResources which are probably impossible to
simulate for CDOResources. For example it's hard or impossible to
present problem markers for validation problems in CDOResources
because IMarkers are associated with IResources. This is not a CDO
problem but a platform/IMarker problem that other
non-"platform:resource" Resources share in common.<br>
<br>
<blockquote cite="mid:k5hqjk$f3l$1@xxxxxxxxe.org" type="cite">2
On the CDO Store, you can choose from the DBStore, which supports
various DB's, I have worked with MySQL and Postgres. With
Hibernate store, there is an additional ORM layer, which works
with tons of other DB's supported by Hibernate. </blockquote>
And there's support for some other backend types, such as DB4O,
MongoDB or Objectivity/DB. I've recently developed a
RandomAccessFile based journaling store, named LissomeStore. It
still uses an RDB for a small and fixed number of indexes into the
random access file(s). For commits it uses a journal file and
adjusts the index tables asynchronously. The performance of large
commits can typically be increased by factor 600 in my tests.<br>
<br>
IMHO the great value of the IStore design is that it becomes a snap
to *change* the backend choice at any time without much impact on
the application (except you're making heavy use of backend-specifc
IQueryHandlers such as SQL or HQL).<br>
<br>
<blockquote cite="mid:k5hqjk$f3l$1@xxxxxxxxe.org" type="cite">3
As CDO == EMF, you can easily adapt a generated RCP Client EMF
editor for CDO, but in practice you are likely better of to start
UI design from scratch, but you can re-use the concept of an
Editing domain and EMF.edit generated code, which is what I do.
(ItemProviders and Commands). </blockquote>
It's a major goal of CDO to better separate the functional from the
the technical design aspects/tasks. The only intrusive technical
aspect I can imagine of is large flat lists that should generally be
avoided in favour of a deeper object structure. IMHO this is a
useful rule even when only considering the usability of a graphical
application.<br>
<br>
<blockquote cite="mid:k5hqjk$f3l$1@xxxxxxxxe.org" type="cite">4
JFace databinding supports EMF, so JFace Databinding + CDO is a
great combination, you might want to watch loading large chunks of
data into your UI widgets (tables + trees), but there are ways to
limit the volumes. </blockquote>
I fully agree that EMF databinding is a totally cool thing. One
thing that tends to be problematic are remote deletions because the
databinding layer caches some strong references to objects that
might, all of a sudden, start to throw InvalidObjectExceptions or
ObjectNotFoundExceptions. You may appreciate that in CDO 4.2 we now
changed to:<br>
<br>
public static final CDOStaleReferencePolicy DEFAULT = PROXY;<br>
<br>
public static final CDOInvalidationPolicy DEFAULT = RELAXED;<br>
<br>
<br>
<blockquote cite="mid:k5hqjk$f3l$1@xxxxxxxxe.org" type="cite">5 I
you need to do something with DSL's (Develop a textual syntax,
which can interact with EMF/CDO models), this is also great with
xtext.
<br>
</blockquote>
Yes, because "CDO == EMF". But please keep in mind that editing DSL
instances stored *in* CDO with an Xtexteditor is problematic because
a text editor generally doesn't preserve the identities (e.g.
CDOIDs) of objects. That makes it hard to reconcile changes made in
a text editor back to CDO.<br>
<br>
<blockquote cite="mid:k5hqjk$f3l$1@xxxxxxxxe.org" type="cite">6
CDO performs well, you can tweak it, to fetch more or less chunks
of data for EReferences. If you don't like the behaviour you can
fire CDO Queries to get exactly what you want. Also unused objects
are garbage collected, so you can safely read a lot of data (As
long as you don't keep a reference). </blockquote>
Funnily this scalability originally came as a by-product of the
auditing functionality ;-)<br>
<br>
<blockquote cite="mid:k5hqjk$f3l$1@xxxxxxxxe.org" type="cite">7 I
am really fond that objects have a lifecycle, and all my object
have a unique CDO ID. I actually present the CDOID, in the status
line of the app. It's a great way to check what's going on. </blockquote>
And now you can even plug in your own CDOIDGenerator at the
client-side:<br>
<br>
public interface CDOIDGenerator<br>
{<br>
public static final CDOIDGenerator UUID = new CDOIDGenerator()<br>
{<br>
public CDOID generateCDOID(EObject object)<br>
{<br>
byte[] bytes = new byte[16];<br>
UUIDGenerator.DEFAULT.generate(bytes);<br>
return CDOIDUtil.createUUID(bytes);<br>
}<br>
<br>
public void reset()<br>
{<br>
// Do nothing<br>
}<br>
};<br>
<br>
/**<br>
* Generates a {@link CDOID}.<br>
* <br>
* @param object<br>
* the object to generate a new CDOID for if available,
<code>null</code> otherwise.<br>
*/<br>
public CDOID generateCDOID(EObject object);<br>
<br>
/**<br>
* Called at the end of a commit operation to give this ID
generator a chance to reset its sequence of IDs.<br>
*/<br>
public void reset();<br>
}<br>
<br>
<blockquote cite="mid:k5hqjk$f3l$1@xxxxxxxxe.org" type="cite">
8 Invalidations are great, basically when an object goes, remotely
dirty, other views are notified and can get the latest status of
an object. <br>
<br>
What I could do without in CDO
<br>
<br>
9. Revisions & referential integrity, I loved it at first, but
right now for the app. I have. it's a burden. The concept of
revisions adds a lot of requirements in CDO, I think CDO should
also have a simpler flat mode, without the revisions and checks on
integrity. It adds to the complexity of the CDO middleware and the
generated DB get's schema's. Some apps, don't need it or need it
partially. In my case, I would need revisions for some classes
only. </blockquote>
I suspect you don't refer to CDORevisions but to the auditing mode
in general? You know that it can be switched off. Granted, for the
DBStore in particular
<a class="moz-txt-link-freetext" href="https://bugs.eclipse.org/bugs/show_bug.cgi?id=351068">https://bugs.eclipse.org/bugs/show_bug.cgi?id=351068</a> is pending. I
really want to work on this soon.<br>
<br>
Partial auditing has been requested in the past. Conceptually I
don't like the idea because the framework couldn't guarantee the
logical consistency of the graph anymore. But I'm willing to
reconsider this when the DBStore gets its next design overhaul (not
scheduled, yet).<br>
<br>
What exact integrity checks are you referring to? Referential
integrity checks in the repository can be switched off (and they are
by default).<br>
<br>
<blockquote cite="mid:k5hqjk$f3l$1@xxxxxxxxe.org" type="cite">It
sometimes feels CDO is trying to mimic a Concurrent Version System
like SVN or CVS, but for many apps you really don't need that. <br>
</blockquote>
Yes, CDO tries to offer support in both worlds, the database
driven-like runtime applications and the more tool-like use cases
where design-time models need to be stored/managed in a repository.
You can imagine that this is sometimes hard but I think we've done a
pretty good job. Are there particular parts in CDO that are
problematic for you in this regard (i.e., not just unneeded)?<br>
<br>
BTW. an example of a cool new SCM-like feature is our new History
view support for repositories, branches or single objects:<br>
<br>
<img src="http://www.eclipse.org/forums/index.php?t=getfile&id=11895" alt=""><br>
<br>
<blockquote cite="mid:k5hqjk$f3l$1@xxxxxxxxe.org" type="cite">10.
In CDO there are CDOFolders and CDOResources. </blockquote>
Yes, and CDOTextResources and CDOBinaryResources, which are now
(almost) first class citizens of a CDO repository:<br>
<br>
<img src="http://www.eclipse.org/forums/index.php?t=getfile&id=11896" alt=""><br>
<br>
<blockquote cite="mid:k5hqjk$f3l$1@xxxxxxxxe.org" type="cite">Both
are also CDO objects, and stored in the DB. I went through great
length to find the best way to use them, like the the names to
give them, which is meta information you need to deal with in the
application. (Remember which name you used for which resource to
keep which data objects, in my case each eclass has its own
cdoresource). </blockquote>
Yes, that's the main value of Resources in general: They provide
well-known entry points into the (persistent) graph of objects.<br>
<br>
Apart from that they're an essential part of "CDO == EMF" (see point
1).<br>
<br>
<blockquote cite="mid:k5hqjk$f3l$1@xxxxxxxxe.org" type="cite">Right
now, I am not sure what the added value is of these, besides some
additional grouping of objects, I think, without them it could
keep CDO simpler and avoid additional DB data. </blockquote>
Please note that you absolutely don't need to use CDOResourceFolders
and CDOResources (except for a single one to contain all other
objects). The characteristics of a CDO model is the same when you
store all objects in a single resource.<br>
<br>
<blockquote cite="mid:k5hqjk$f3l$1@xxxxxxxxe.org" type="cite">(Note
that in point 3, I mentioned the EMF Editing domain, which has a
ResourceSet which can hold CDOResource objects. I use this, so
without CDO Resources, I wouldn't be able to use an editing
domain, so something else would be needed). <br>
</blockquote>
I think the generated editors also make heavy use of the assumption
that objects are contained by resources.<br>
<br>
<blockquote cite="mid:k5hqjk$f3l$1@xxxxxxxxe.org" type="cite">What
I wish for in CDO.
<br>
<br>
11. Model migrations. There are initiatives like COPE, which could
be applied with CDO, that would be great. So add a class in your
model, and let the new feature deal with the migration and transit
your data. </blockquote>
Fully agreed. If only someone would need it enough to open the
wallet and fund the development of this feature :P<br>
<br>
<blockquote cite="mid:k5hqjk$f3l$1@xxxxxxxxe.org" type="cite">12.
It's a hard learning curve, because most of the docs are outdated
or not written, so mea-culpa, we could do better. I wish for a
thriving community around a general purpose
smart-object-persistence system like CDO. <br>
</blockquote>
Yes! Technical writers in the world, here's a project that needs you
;-)<br>
<br>
<blockquote cite="mid:k5hqjk$f3l$1@xxxxxxxxe.org" type="cite">Finally.
Eike Stepper and others, have been great in supporting me on this
forum. Generally very quick and helpful!<br>
</blockquote>
Good docs would certainly be nicer but, while they're absent, good
online support is our attempt to compensate ;-)<br>
<br>
Cheers<br>
/Eike<br>
<br>
----<br>
<a class="moz-txt-link-freetext" href="http://www.esc-net.de">http://www.esc-net.de</a><br>
<a class="moz-txt-link-freetext" href="http://thegordian.blogspot.com">http://thegordian.blogspot.com</a><br>
<a class="moz-txt-link-freetext" href="http://twitter.com/eikestepper">http://twitter.com/eikestepper</a><br>
<br>
<br>
<br>
</body>
</html>
-
Attachment: bgchgghb.png
(Size: 83.23KB, Downloaded 135 times) -
Attachment: edjjaeef.png
(Size: 16.76KB, Downloaded 161 times)
Cheers
/Eike
----
http://www.esc-net.de
http://thegordian.blogspot.com
http://twitter.com/eikestepper
|
|
|
| Re: Understanding CDO [message #946440 is a reply to message #945941] |
Tue, 16 October 2012 06:30 |
|
<html>
<head>
<meta content="text/html; charset=UTF-8" http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
Hi Christophe,<br>
<br>
Thank you very much for your detailed experience report. I like it
lot ;-)<br>
<br>
More comments below...<br>
<br>
<br>
<div class="moz-cite-prefix">Am 15.10.2012 22:10, schrieb Christophe
Bouhier:<br>
</div>
<blockquote cite="mid:k5hqjk$f3l$1@xxxxxxxxe.org" type="cite">Hello
Mauro, <br>
for the last 2 years, I have been working on a client/server
application using CDO. Depending on your needs, CDO could be the
right fit. <br>
What I like (a lot). <br>
1 CDO == EMF, so you can model data first in .xsd or directly in
.ecore, and you can tell CDO to use your generated packages, which
will build the DB schema. </blockquote>
EMF compliance is very important to us and we're proud to support
most of EMF's features. Among the few exceptions are:<br>
<br>
a) Feature maps are hard to deal with in RDBs<br>
<br>
b) Because CDOResources are EObjects (see point 10) a small number
of other frameworks may run into trouble when trying to find out the
concrete type of a Notifier because the result depends on a
particular order of instanceof checks (check Resources first).<br>
<br>
c) With remote change notifications enabled, i.e.,
view.options().addChangeSubscriptionPolicy(...), your own Adapters
often need to distinguish between local or remote changes. An
instanceof CDODeltaNotification does the trick.<br>
<br>
d) Some IDE applications (and some poorly designed frameworks such
as GMF) heavily rely on IResources which are probably impossible to
simulate for CDOResources. For example it's hard or impossible to
present problem markers for validation problems in CDOResources
because IMarkers are associated with IResources. This is not a CDO
problem but a platform/IMarker problem that other
non-"platform:resource" Resources share in common.<br>
<br>
<blockquote cite="mid:k5hqjk$f3l$1@xxxxxxxxe.org" type="cite">2
On the CDO Store, you can choose from the DBStore, which supports
various DB's, I have worked with MySQL and Postgres. With
Hibernate store, there is an additional ORM layer, which works
with tons of other DB's supported by Hibernate. </blockquote>
And there's support for some other backend types, such as DB4O,
MongoDB or Objectivity/DB. I've recently developed a
RandomAccessFile based journaling store, named LissomeStore. It
still uses an RDB for a small and fixed number of indexes into the
random access file(s). For commits it uses a journal file and
adjusts the index tables asynchronously. The performance of large
commits can typically be increased by factor 600 in my tests.<br>
<br>
IMHO the great value of the IStore design is that it becomes a snap
to *change* the backend choice at any time without much impact on
the application (except you're making heavy use of backend-specifc
IQueryHandlers such as SQL or HQL).<br>
<br>
<blockquote cite="mid:k5hqjk$f3l$1@xxxxxxxxe.org" type="cite">3
As CDO == EMF, you can easily adapt a generated RCP Client EMF
editor for CDO, but in practice you are likely better of to start
UI design from scratch, but you can re-use the concept of an
Editing domain and EMF.edit generated code, which is what I do.
(ItemProviders and Commands). </blockquote>
It's a major goal of CDO to better separate the functional from the
the technical design aspects/tasks. The only intrusive technical
aspect I can imagine of is large flat lists that should generally be
avoided in favour of a deeper object structure. IMHO this is a
useful rule even when only considering the usability of a graphical
application.<br>
<br>
<blockquote cite="mid:k5hqjk$f3l$1@xxxxxxxxe.org" type="cite">4
JFace databinding supports EMF, so JFace Databinding + CDO is a
great combination, you might want to watch loading large chunks of
data into your UI widgets (tables + trees), but there are ways to
limit the volumes. </blockquote>
I fully agree that EMF databinding is a totally cool thing. One
thing that tends to be problematic are remote deletions because the
databinding layer caches some strong references to objects that
might, all of a sudden, start to throw InvalidObjectExceptions or
ObjectNotFoundExceptions. You may appreciate that in CDO 4.2 we now
changed to:<br>
<br>
public static final CDOStaleReferencePolicy DEFAULT = PROXY;<br>
<br>
public static final CDOInvalidationPolicy DEFAULT = RELAXED;<br>
<br>
<br>
<blockquote cite="mid:k5hqjk$f3l$1@xxxxxxxxe.org" type="cite">5 I
you need to do something with DSL's (Develop a textual syntax,
which can interact with EMF/CDO models), this is also great with
xtext.
<br>
</blockquote>
Yes, because "CDO == EMF". But please keep in mind that editing DSL
instances stored *in* CDO with an Xtexteditor is problematic because
a text editor generally doesn't preserve the identities (e.g.
CDOIDs) of objects. That makes it hard to reconcile changes made in
a text editor back to CDO.<br>
<br>
<blockquote cite="mid:k5hqjk$f3l$1@xxxxxxxxe.org" type="cite">6
CDO performs well, you can tweak it, to fetch more or less chunks
of data for EReferences. If you don't like the behaviour you can
fire CDO Queries to get exactly what you want. Also unused objects
are garbage collected, so you can safely read a lot of data (As
long as you don't keep a reference). </blockquote>
Funnily this scalability originally came as a by-product of the
auditing functionality ;-)<br>
<br>
<blockquote cite="mid:k5hqjk$f3l$1@xxxxxxxxe.org" type="cite">7 I
am really fond that objects have a lifecycle, and all my object
have a unique CDO ID. I actually present the CDOID, in the status
line of the app. It's a great way to check what's going on. </blockquote>
And now you can even plug in your own CDOIDGenerator at the
client-side:<br>
<br>
public interface CDOIDGenerator<br>
{<br>
public static final CDOIDGenerator UUID = new CDOIDGenerator()<br>
{<br>
public CDOID generateCDOID(EObject object)<br>
{<br>
byte[] bytes = new byte[16];<br>
UUIDGenerator.DEFAULT.generate(bytes);<br>
return CDOIDUtil.createUUID(bytes);<br>
}<br>
<br>
public void reset()<br>
{<br>
// Do nothing<br>
}<br>
};<br>
<br>
/**<br>
* Generates a {@link CDOID}.<br>
* <br>
* @param object<br>
* the object to generate a new CDOID for if available,
<code>null</code> otherwise.<br>
*/<br>
public CDOID generateCDOID(EObject object);<br>
<br>
/**<br>
* Called at the end of a commit operation to give this ID
generator a chance to reset its sequence of IDs.<br>
*/<br>
public void reset();<br>
}<br>
<br>
<blockquote cite="mid:k5hqjk$f3l$1@xxxxxxxxe.org" type="cite">
8 Invalidations are great, basically when an object goes, remotely
dirty, other views are notified and can get the latest status of
an object. <br>
<br>
What I could do without in CDO
<br>
<br>
9. Revisions & referential integrity, I loved it at first, but
right now for the app. I have. it's a burden. The concept of
revisions adds a lot of requirements in CDO, I think CDO should
also have a simpler flat mode, without the revisions and checks on
integrity. It adds to the complexity of the CDO middleware and the
generated DB get's schema's. Some apps, don't need it or need it
partially. In my case, I would need revisions for some classes
only. </blockquote>
I suspect you don't refer to CDORevisions but to the auditing mode
in general? You know that it can be switched off. Granted, for the
DBStore in particular
<a class="moz-txt-link-freetext" href="https://bugs.eclipse.org/bugs/show_bug.cgi?id=351068">https://bugs.eclipse.org/bugs/show_bug.cgi?id=351068</a> is pending. I
really want to work on this soon.<br>
<br>
Partial auditing has been requested in the past. Conceptually I
don't like the idea because the framework couldn't guarantee the
logical consistency of the graph anymore. But I'm willing to
reconsider this when the DBStore gets its next design overhaul (not
scheduled, yet).<br>
<br>
What exact integrity checks are you referring to? Referential
integrity checks in the repository can be switched off (and they are
by default).<br>
<br>
<blockquote cite="mid:k5hqjk$f3l$1@xxxxxxxxe.org" type="cite">It
sometimes feels CDO is trying to mimic a Concurrent Version System
like SVN or CVS, but for many apps you really don't need that. <br>
</blockquote>
Yes, CDO tries to offer support in both worlds, the database
driven-like runtime applications and the more tool-like use cases
where design-time models need to be stored/managed in a repository.
You can imagine that this is sometimes hard but I think we've done a
pretty good job. Are there particular parts in CDO that are
problematic for you in this regard (i.e., not just unneeded)?<br>
<br>
BTW. an example of a cool new SCM-like feature is our new History
view support for repositories, branches or single objects:<br>
<br>
<img src="http://www.eclipse.org/forums/index.php?t=getfile&id=11897" alt=""><br>
<br>
<blockquote cite="mid:k5hqjk$f3l$1@xxxxxxxxe.org" type="cite">10.
In CDO there are CDOFolders and CDOResources. </blockquote>
Yes, and CDOTextResources and CDOBinaryResources, which are now
(almost) first class citizens of a CDO repository:<br>
<br>
<img src="http://www.eclipse.org/forums/index.php?t=getfile&id=11898" alt=""><br>
<br>
<blockquote cite="mid:k5hqjk$f3l$1@xxxxxxxxe.org" type="cite">Both
are also CDO objects, and stored in the DB. I went through great
length to find the best way to use them, like the the names to
give them, which is meta information you need to deal with in the
application. (Remember which name you used for which resource to
keep which data objects, in my case each eclass has its own
cdoresource). </blockquote>
Yes, that's the main value of Resources in general: They provide
well-known entry points into the (persistent) graph of objects.<br>
<br>
Apart from that they're an essential part of "CDO == EMF" (see point
1).<br>
<br>
<blockquote cite="mid:k5hqjk$f3l$1@xxxxxxxxe.org" type="cite">Right
now, I am not sure what the added value is of these, besides some
additional grouping of objects, I think, without them it could
keep CDO simpler and avoid additional DB data. </blockquote>
Please note that you absolutely don't need to use CDOResourceFolders
and CDOResources (except for a single one to contain all other
objects). The characteristics of a CDO model is the same when you
store all objects in a single resource.<br>
<br>
<blockquote cite="mid:k5hqjk$f3l$1@xxxxxxxxe.org" type="cite">(Note
that in point 3, I mentioned the EMF Editing domain, which has a
ResourceSet which can hold CDOResource objects. I use this, so
without CDO Resources, I wouldn't be able to use an editing
domain, so something else would be needed). <br>
</blockquote>
I think the generated editors also make heavy use of the assumption
that objects are contained by resources.<br>
<br>
<blockquote cite="mid:k5hqjk$f3l$1@xxxxxxxxe.org" type="cite">What
I wish for in CDO.
<br>
<br>
11. Model migrations. There are initiatives like COPE, which could
be applied with CDO, that would be great. So add a class in your
model, and let the new feature deal with the migration and transit
your data. </blockquote>
Fully agreed. If only someone would need it enough to open the
wallet and fund the development of this feature :P<br>
<br>
<blockquote cite="mid:k5hqjk$f3l$1@xxxxxxxxe.org" type="cite">12.
It's a hard learning curve, because most of the docs are outdated
or not written, so mea-culpa, we could do better. I wish for a
thriving community around a general purpose
smart-object-persistence system like CDO. <br>
</blockquote>
Yes! Technical writers in the world, here's a project that needs you
;-)<br>
<br>
<blockquote cite="mid:k5hqjk$f3l$1@xxxxxxxxe.org" type="cite">Finally.
Eike Stepper and others, have been great in supporting me on this
forum. Generally very quick and helpful!<br>
</blockquote>
Good docs would certainly be nicer but, while they're absent, good
online support is our attempt to compensate ;-)<br>
<br>
Cheers<br>
/Eike<br>
<br>
----<br>
<a class="moz-txt-link-freetext" href="http://www.esc-net.de">http://www.esc-net.de</a><br>
<a class="moz-txt-link-freetext" href="http://thegordian.blogspot.com">http://thegordian.blogspot.com</a><br>
<a class="moz-txt-link-freetext" href="http://twitter.com/eikestepper">http://twitter.com/eikestepper</a><br>
<br>
<br>
<br>
</body>
</html>
-
Attachment: bgchgghb.png
(Size: 83.23KB, Downloaded 129 times) -
Attachment: edjjaeef.png
(Size: 16.76KB, Downloaded 136 times)
Cheers
/Eike
----
http://www.esc-net.de
http://thegordian.blogspot.com
http://twitter.com/eikestepper
|
|
|
| Re: Understanding CDO [message #946447 is a reply to message #945941] |
Tue, 16 October 2012 06:30 |
|
<html>
<head>
<meta content="text/html; charset=UTF-8" http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
Hi Christophe,<br>
<br>
Thank you very much for your detailed experience report. I like it
lot ;-)<br>
<br>
More comments below...<br>
<br>
<br>
<div class="moz-cite-prefix">Am 15.10.2012 22:10, schrieb Christophe
Bouhier:<br>
</div>
<blockquote cite="mid:k5hqjk$f3l$1@xxxxxxxxe.org" type="cite">Hello
Mauro, <br>
for the last 2 years, I have been working on a client/server
application using CDO. Depending on your needs, CDO could be the
right fit. <br>
What I like (a lot). <br>
1 CDO == EMF, so you can model data first in .xsd or directly in
.ecore, and you can tell CDO to use your generated packages, which
will build the DB schema. </blockquote>
EMF compliance is very important to us and we're proud to support
most of EMF's features. Among the few exceptions are:<br>
<br>
a) Feature maps are hard to deal with in RDBs<br>
<br>
b) Because CDOResources are EObjects (see point 10) a small number
of other frameworks may run into trouble when trying to find out the
concrete type of a Notifier because the result depends on a
particular order of instanceof checks (check Resources first).<br>
<br>
c) With remote change notifications enabled, i.e.,
view.options().addChangeSubscriptionPolicy(...), your own Adapters
often need to distinguish between local or remote changes. An
instanceof CDODeltaNotification does the trick.<br>
<br>
d) Some IDE applications (and some poorly designed frameworks such
as GMF) heavily rely on IResources which are probably impossible to
simulate for CDOResources. For example it's hard or impossible to
present problem markers for validation problems in CDOResources
because IMarkers are associated with IResources. This is not a CDO
problem but a platform/IMarker problem that other
non-"platform:resource" Resources share in common.<br>
<br>
<blockquote cite="mid:k5hqjk$f3l$1@xxxxxxxxe.org" type="cite">2
On the CDO Store, you can choose from the DBStore, which supports
various DB's, I have worked with MySQL and Postgres. With
Hibernate store, there is an additional ORM layer, which works
with tons of other DB's supported by Hibernate. </blockquote>
And there's support for some other backend types, such as DB4O,
MongoDB or Objectivity/DB. I've recently developed a
RandomAccessFile based journaling store, named LissomeStore. It
still uses an RDB for a small and fixed number of indexes into the
random access file(s). For commits it uses a journal file and
adjusts the index tables asynchronously. The performance of large
commits can typically be increased by factor 600 in my tests.<br>
<br>
IMHO the great value of the IStore design is that it becomes a snap
to *change* the backend choice at any time without much impact on
the application (except you're making heavy use of backend-specifc
IQueryHandlers such as SQL or HQL).<br>
<br>
<blockquote cite="mid:k5hqjk$f3l$1@xxxxxxxxe.org" type="cite">3
As CDO == EMF, you can easily adapt a generated RCP Client EMF
editor for CDO, but in practice you are likely better of to start
UI design from scratch, but you can re-use the concept of an
Editing domain and EMF.edit generated code, which is what I do.
(ItemProviders and Commands). </blockquote>
It's a major goal of CDO to better separate the functional from the
the technical design aspects/tasks. The only intrusive technical
aspect I can imagine of is large flat lists that should generally be
avoided in favour of a deeper object structure. IMHO this is a
useful rule even when only considering the usability of a graphical
application.<br>
<br>
<blockquote cite="mid:k5hqjk$f3l$1@xxxxxxxxe.org" type="cite">4
JFace databinding supports EMF, so JFace Databinding + CDO is a
great combination, you might want to watch loading large chunks of
data into your UI widgets (tables + trees), but there are ways to
limit the volumes. </blockquote>
I fully agree that EMF databinding is a totally cool thing. One
thing that tends to be problematic are remote deletions because the
databinding layer caches some strong references to objects that
might, all of a sudden, start to throw InvalidObjectExceptions or
ObjectNotFoundExceptions. You may appreciate that in CDO 4.2 we now
changed to:<br>
<br>
public static final CDOStaleReferencePolicy DEFAULT = PROXY;<br>
<br>
public static final CDOInvalidationPolicy DEFAULT = RELAXED;<br>
<br>
<br>
<blockquote cite="mid:k5hqjk$f3l$1@xxxxxxxxe.org" type="cite">5 I
you need to do something with DSL's (Develop a textual syntax,
which can interact with EMF/CDO models), this is also great with
xtext.
<br>
</blockquote>
Yes, because "CDO == EMF". But please keep in mind that editing DSL
instances stored *in* CDO with an Xtexteditor is problematic because
a text editor generally doesn't preserve the identities (e.g.
CDOIDs) of objects. That makes it hard to reconcile changes made in
a text editor back to CDO.<br>
<br>
<blockquote cite="mid:k5hqjk$f3l$1@xxxxxxxxe.org" type="cite">6
CDO performs well, you can tweak it, to fetch more or less chunks
of data for EReferences. If you don't like the behaviour you can
fire CDO Queries to get exactly what you want. Also unused objects
are garbage collected, so you can safely read a lot of data (As
long as you don't keep a reference). </blockquote>
Funnily this scalability originally came as a by-product of the
auditing functionality ;-)<br>
<br>
<blockquote cite="mid:k5hqjk$f3l$1@xxxxxxxxe.org" type="cite">7 I
am really fond that objects have a lifecycle, and all my object
have a unique CDO ID. I actually present the CDOID, in the status
line of the app. It's a great way to check what's going on. </blockquote>
And now you can even plug in your own CDOIDGenerator at the
client-side:<br>
<br>
public interface CDOIDGenerator<br>
{<br>
public static final CDOIDGenerator UUID = new CDOIDGenerator()<br>
{<br>
public CDOID generateCDOID(EObject object)<br>
{<br>
byte[] bytes = new byte[16];<br>
UUIDGenerator.DEFAULT.generate(bytes);<br>
return CDOIDUtil.createUUID(bytes);<br>
}<br>
<br>
public void reset()<br>
{<br>
// Do nothing<br>
}<br>
};<br>
<br>
/**<br>
* Generates a {@link CDOID}.<br>
* <br>
* @param object<br>
* the object to generate a new CDOID for if available,
<code>null</code> otherwise.<br>
*/<br>
public CDOID generateCDOID(EObject object);<br>
<br>
/**<br>
* Called at the end of a commit operation to give this ID
generator a chance to reset its sequence of IDs.<br>
*/<br>
public void reset();<br>
}<br>
<br>
<blockquote cite="mid:k5hqjk$f3l$1@xxxxxxxxe.org" type="cite">
8 Invalidations are great, basically when an object goes, remotely
dirty, other views are notified and can get the latest status of
an object. <br>
<br>
What I could do without in CDO
<br>
<br>
9. Revisions & referential integrity, I loved it at first, but
right now for the app. I have. it's a burden. The concept of
revisions adds a lot of requirements in CDO, I think CDO should
also have a simpler flat mode, without the revisions and checks on
integrity. It adds to the complexity of the CDO middleware and the
generated DB get's schema's. Some apps, don't need it or need it
partially. In my case, I would need revisions for some classes
only. </blockquote>
I suspect you don't refer to CDORevisions but to the auditing mode
in general? You know that it can be switched off. Granted, for the
DBStore in particular
<a class="moz-txt-link-freetext" href="https://bugs.eclipse.org/bugs/show_bug.cgi?id=351068">https://bugs.eclipse.org/bugs/show_bug.cgi?id=351068</a> is pending. I
really want to work on this soon.<br>
<br>
Partial auditing has been requested in the past. Conceptually I
don't like the idea because the framework couldn't guarantee the
logical consistency of the graph anymore. But I'm willing to
reconsider this when the DBStore gets its next design overhaul (not
scheduled, yet).<br>
<br>
What exact integrity checks are you referring to? Referential
integrity checks in the repository can be switched off (and they are
by default).<br>
<br>
<blockquote cite="mid:k5hqjk$f3l$1@xxxxxxxxe.org" type="cite">It
sometimes feels CDO is trying to mimic a Concurrent Version System
like SVN or CVS, but for many apps you really don't need that. <br>
</blockquote>
Yes, CDO tries to offer support in both worlds, the database
driven-like runtime applications and the more tool-like use cases
where design-time models need to be stored/managed in a repository.
You can imagine that this is sometimes hard but I think we've done a
pretty good job. Are there particular parts in CDO that are
problematic for you in this regard (i.e., not just unneeded)?<br>
<br>
BTW. an example of a cool new SCM-like feature is our new History
view support for repositories, branches or single objects:<br>
<br>
<img src="http://www.eclipse.org/forums/index.php?t=getfile&id=11899" alt=""><br>
<br>
<blockquote cite="mid:k5hqjk$f3l$1@xxxxxxxxe.org" type="cite">10.
In CDO there are CDOFolders and CDOResources. </blockquote>
Yes, and CDOTextResources and CDOBinaryResources, which are now
(almost) first class citizens of a CDO repository:<br>
<br>
<img src="http://www.eclipse.org/forums/index.php?t=getfile&id=11900" alt=""><br>
<br>
<blockquote cite="mid:k5hqjk$f3l$1@xxxxxxxxe.org" type="cite">Both
are also CDO objects, and stored in the DB. I went through great
length to find the best way to use them, like the the names to
give them, which is meta information you need to deal with in the
application. (Remember which name you used for which resource to
keep which data objects, in my case each eclass has its own
cdoresource). </blockquote>
Yes, that's the main value of Resources in general: They provide
well-known entry points into the (persistent) graph of objects.<br>
<br>
Apart from that they're an essential part of "CDO == EMF" (see point
1).<br>
<br>
<blockquote cite="mid:k5hqjk$f3l$1@xxxxxxxxe.org" type="cite">Right
now, I am not sure what the added value is of these, besides some
additional grouping of objects, I think, without them it could
keep CDO simpler and avoid additional DB data. </blockquote>
Please note that you absolutely don't need to use CDOResourceFolders
and CDOResources (except for a single one to contain all other
objects). The characteristics of a CDO model is the same when you
store all objects in a single resource.<br>
<br>
<blockquote cite="mid:k5hqjk$f3l$1@xxxxxxxxe.org" type="cite">(Note
that in point 3, I mentioned the EMF Editing domain, which has a
ResourceSet which can hold CDOResource objects. I use this, so
without CDO Resources, I wouldn't be able to use an editing
domain, so something else would be needed). <br>
</blockquote>
I think the generated editors also make heavy use of the assumption
that objects are contained by resources.<br>
<br>
<blockquote cite="mid:k5hqjk$f3l$1@xxxxxxxxe.org" type="cite">What
I wish for in CDO.
<br>
<br>
11. Model migrations. There are initiatives like COPE, which could
be applied with CDO, that would be great. So add a class in your
model, and let the new feature deal with the migration and transit
your data. </blockquote>
Fully agreed. If only someone would need it enough to open the
wallet and fund the development of this feature :P<br>
<br>
<blockquote cite="mid:k5hqjk$f3l$1@xxxxxxxxe.org" type="cite">12.
It's a hard learning curve, because most of the docs are outdated
or not written, so mea-culpa, we could do better. I wish for a
thriving community around a general purpose
smart-object-persistence system like CDO. <br>
</blockquote>
Yes! Technical writers in the world, here's a project that needs you
;-)<br>
<br>
<blockquote cite="mid:k5hqjk$f3l$1@xxxxxxxxe.org" type="cite">Finally.
Eike Stepper and others, have been great in supporting me on this
forum. Generally very quick and helpful!<br>
</blockquote>
Good docs would certainly be nicer but, while they're absent, good
online support is our attempt to compensate ;-)<br>
<br>
Cheers<br>
/Eike<br>
<br>
----<br>
<a class="moz-txt-link-freetext" href="http://www.esc-net.de">http://www.esc-net.de</a><br>
<a class="moz-txt-link-freetext" href="http://thegordian.blogspot.com">http://thegordian.blogspot.com</a><br>
<a class="moz-txt-link-freetext" href="http://twitter.com/eikestepper">http://twitter.com/eikestepper</a><br>
<br>
<br>
<br>
</body>
</html>
-
Attachment: bgchgghb.png
(Size: 83.23KB, Downloaded 134 times) -
Attachment: edjjaeef.png
(Size: 16.76KB, Downloaded 133 times)
Cheers
/Eike
----
http://www.esc-net.de
http://thegordian.blogspot.com
http://twitter.com/eikestepper
|
|
|
| Re: Understanding CDO [message #946452 is a reply to message #945941] |
Tue, 16 October 2012 06:30 |
|
<html>
<head>
<meta content="text/html; charset=UTF-8" http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
Hi Christophe,<br>
<br>
Thank you very much for your detailed experience report. I like it
lot ;-)<br>
<br>
More comments below...<br>
<br>
<br>
<div class="moz-cite-prefix">Am 15.10.2012 22:10, schrieb Christophe
Bouhier:<br>
</div>
<blockquote cite="mid:k5hqjk$f3l$1@xxxxxxxxe.org" type="cite">Hello
Mauro, <br>
for the last 2 years, I have been working on a client/server
application using CDO. Depending on your needs, CDO could be the
right fit. <br>
What I like (a lot). <br>
1 CDO == EMF, so you can model data first in .xsd or directly in
.ecore, and you can tell CDO to use your generated packages, which
will build the DB schema. </blockquote>
EMF compliance is very important to us and we're proud to support
most of EMF's features. Among the few exceptions are:<br>
<br>
a) Feature maps are hard to deal with in RDBs<br>
<br>
b) Because CDOResources are EObjects (see point 10) a small number
of other frameworks may run into trouble when trying to find out the
concrete type of a Notifier because the result depends on a
particular order of instanceof checks (check Resources first).<br>
<br>
c) With remote change notifications enabled, i.e.,
view.options().addChangeSubscriptionPolicy(...), your own Adapters
often need to distinguish between local or remote changes. An
instanceof CDODeltaNotification does the trick.<br>
<br>
d) Some IDE applications (and some poorly designed frameworks such
as GMF) heavily rely on IResources which are probably impossible to
simulate for CDOResources. For example it's hard or impossible to
present problem markers for validation problems in CDOResources
because IMarkers are associated with IResources. This is not a CDO
problem but a platform/IMarker problem that other
non-"platform:resource" Resources share in common.<br>
<br>
<blockquote cite="mid:k5hqjk$f3l$1@xxxxxxxxe.org" type="cite">2
On the CDO Store, you can choose from the DBStore, which supports
various DB's, I have worked with MySQL and Postgres. With
Hibernate store, there is an additional ORM layer, which works
with tons of other DB's supported by Hibernate. </blockquote>
And there's support for some other backend types, such as DB4O,
MongoDB or Objectivity/DB. I've recently developed a
RandomAccessFile based journaling store, named LissomeStore. It
still uses an RDB for a small and fixed number of indexes into the
random access file(s). For commits it uses a journal file and
adjusts the index tables asynchronously. The performance of large
commits can typically be increased by factor 600 in my tests.<br>
<br>
IMHO the great value of the IStore design is that it becomes a snap
to *change* the backend choice at any time without much impact on
the application (except you're making heavy use of backend-specifc
IQueryHandlers such as SQL or HQL).<br>
<br>
<blockquote cite="mid:k5hqjk$f3l$1@xxxxxxxxe.org" type="cite">3
As CDO == EMF, you can easily adapt a generated RCP Client EMF
editor for CDO, but in practice you are likely better of to start
UI design from scratch, but you can re-use the concept of an
Editing domain and EMF.edit generated code, which is what I do.
(ItemProviders and Commands). </blockquote>
It's a major goal of CDO to better separate the functional from the
the technical design aspects/tasks. The only intrusive technical
aspect I can imagine of is large flat lists that should generally be
avoided in favour of a deeper object structure. IMHO this is a
useful rule even when only considering the usability of a graphical
application.<br>
<br>
<blockquote cite="mid:k5hqjk$f3l$1@xxxxxxxxe.org" type="cite">4
JFace databinding supports EMF, so JFace Databinding + CDO is a
great combination, you might want to watch loading large chunks of
data into your UI widgets (tables + trees), but there are ways to
limit the volumes. </blockquote>
I fully agree that EMF databinding is a totally cool thing. One
thing that tends to be problematic are remote deletions because the
databinding layer caches some strong references to objects that
might, all of a sudden, start to throw InvalidObjectExceptions or
ObjectNotFoundExceptions. You may appreciate that in CDO 4.2 we now
changed to:<br>
<br>
public static final CDOStaleReferencePolicy DEFAULT = PROXY;<br>
<br>
public static final CDOInvalidationPolicy DEFAULT = RELAXED;<br>
<br>
<br>
<blockquote cite="mid:k5hqjk$f3l$1@xxxxxxxxe.org" type="cite">5 I
you need to do something with DSL's (Develop a textual syntax,
which can interact with EMF/CDO models), this is also great with
xtext.
<br>
</blockquote>
Yes, because "CDO == EMF". But please keep in mind that editing DSL
instances stored *in* CDO with an Xtexteditor is problematic because
a text editor generally doesn't preserve the identities (e.g.
CDOIDs) of objects. That makes it hard to reconcile changes made in
a text editor back to CDO.<br>
<br>
<blockquote cite="mid:k5hqjk$f3l$1@xxxxxxxxe.org" type="cite">6
CDO performs well, you can tweak it, to fetch more or less chunks
of data for EReferences. If you don't like the behaviour you can
fire CDO Queries to get exactly what you want. Also unused objects
are garbage collected, so you can safely read a lot of data (As
long as you don't keep a reference). </blockquote>
Funnily this scalability originally came as a by-product of the
auditing functionality ;-)<br>
<br>
<blockquote cite="mid:k5hqjk$f3l$1@xxxxxxxxe.org" type="cite">7 I
am really fond that objects have a lifecycle, and all my object
have a unique CDO ID. I actually present the CDOID, in the status
line of the app. It's a great way to check what's going on. </blockquote>
And now you can even plug in your own CDOIDGenerator at the
client-side:<br>
<br>
public interface CDOIDGenerator<br>
{<br>
public static final CDOIDGenerator UUID = new CDOIDGenerator()<br>
{<br>
public CDOID generateCDOID(EObject object)<br>
{<br>
byte[] bytes = new byte[16];<br>
UUIDGenerator.DEFAULT.generate(bytes);<br>
return CDOIDUtil.createUUID(bytes);<br>
}<br>
<br>
public void reset()<br>
{<br>
// Do nothing<br>
}<br>
};<br>
<br>
/**<br>
* Generates a {@link CDOID}.<br>
* <br>
* @param object<br>
* the object to generate a new CDOID for if available,
<code>null</code> otherwise.<br>
*/<br>
public CDOID generateCDOID(EObject object);<br>
<br>
/**<br>
* Called at the end of a commit operation to give this ID
generator a chance to reset its sequence of IDs.<br>
*/<br>
public void reset();<br>
}<br>
<br>
<blockquote cite="mid:k5hqjk$f3l$1@xxxxxxxxe.org" type="cite">
8 Invalidations are great, basically when an object goes, remotely
dirty, other views are notified and can get the latest status of
an object. <br>
<br>
What I could do without in CDO
<br>
<br>
9. Revisions & referential integrity, I loved it at first, but
right now for the app. I have. it's a burden. The concept of
revisions adds a lot of requirements in CDO, I think CDO should
also have a simpler flat mode, without the revisions and checks on
integrity. It adds to the complexity of the CDO middleware and the
generated DB get's schema's. Some apps, don't need it or need it
partially. In my case, I would need revisions for some classes
only. </blockquote>
I suspect you don't refer to CDORevisions but to the auditing mode
in general? You know that it can be switched off. Granted, for the
DBStore in particular
<a class="moz-txt-link-freetext" href="https://bugs.eclipse.org/bugs/show_bug.cgi?id=351068">https://bugs.eclipse.org/bugs/show_bug.cgi?id=351068</a> is pending. I
really want to work on this soon.<br>
<br>
Partial auditing has been requested in the past. Conceptually I
don't like the idea because the framework couldn't guarantee the
logical consistency of the graph anymore. But I'm willing to
reconsider this when the DBStore gets its next design overhaul (not
scheduled, yet).<br>
<br>
What exact integrity checks are you referring to? Referential
integrity checks in the repository can be switched off (and they are
by default).<br>
<br>
<blockquote cite="mid:k5hqjk$f3l$1@xxxxxxxxe.org" type="cite">It
sometimes feels CDO is trying to mimic a Concurrent Version System
like SVN or CVS, but for many apps you really don't need that. <br>
</blockquote>
Yes, CDO tries to offer support in both worlds, the database
driven-like runtime applications and the more tool-like use cases
where design-time models need to be stored/managed in a repository.
You can imagine that this is sometimes hard but I think we've done a
pretty good job. Are there particular parts in CDO that are
problematic for you in this regard (i.e., not just unneeded)?<br>
<br>
BTW. an example of a cool new SCM-like feature is our new History
view support for repositories, branches or single objects:<br>
<br>
<img src="http://www.eclipse.org/forums/index.php?t=getfile&id=11901" alt=""><br>
<br>
<blockquote cite="mid:k5hqjk$f3l$1@xxxxxxxxe.org" type="cite">10.
In CDO there are CDOFolders and CDOResources. </blockquote>
Yes, and CDOTextResources and CDOBinaryResources, which are now
(almost) first class citizens of a CDO repository:<br>
<br>
<img src="http://www.eclipse.org/forums/index.php?t=getfile&id=11902" alt=""><br>
<br>
<blockquote cite="mid:k5hqjk$f3l$1@xxxxxxxxe.org" type="cite">Both
are also CDO objects, and stored in the DB. I went through great
length to find the best way to use them, like the the names to
give them, which is meta information you need to deal with in the
application. (Remember which name you used for which resource to
keep which data objects, in my case each eclass has its own
cdoresource). </blockquote>
Yes, that's the main value of Resources in general: They provide
well-known entry points into the (persistent) graph of objects.<br>
<br>
Apart from that they're an essential part of "CDO == EMF" (see point
1).<br>
<br>
<blockquote cite="mid:k5hqjk$f3l$1@xxxxxxxxe.org" type="cite">Right
now, I am not sure what the added value is of these, besides some
additional grouping of objects, I think, without them it could
keep CDO simpler and avoid additional DB data. </blockquote>
Please note that you absolutely don't need to use CDOResourceFolders
and CDOResources (except for a single one to contain all other
objects). The characteristics of a CDO model is the same when you
store all objects in a single resource.<br>
<br>
<blockquote cite="mid:k5hqjk$f3l$1@xxxxxxxxe.org" type="cite">(Note
that in point 3, I mentioned the EMF Editing domain, which has a
ResourceSet which can hold CDOResource objects. I use this, so
without CDO Resources, I wouldn't be able to use an editing
domain, so something else would be needed). <br>
</blockquote>
I think the generated editors also make heavy use of the assumption
that objects are contained by resources.<br>
<br>
<blockquote cite="mid:k5hqjk$f3l$1@xxxxxxxxe.org" type="cite">What
I wish for in CDO.
<br>
<br>
11. Model migrations. There are initiatives like COPE, which could
be applied with CDO, that would be great. So add a class in your
model, and let the new feature deal with the migration and transit
your data. </blockquote>
Fully agreed. If only someone would need it enough to open the
wallet and fund the development of this feature :P<br>
<br>
<blockquote cite="mid:k5hqjk$f3l$1@xxxxxxxxe.org" type="cite">12.
It's a hard learning curve, because most of the docs are outdated
or not written, so mea-culpa, we could do better. I wish for a
thriving community around a general purpose
smart-object-persistence system like CDO. <br>
</blockquote>
Yes! Technical writers in the world, here's a project that needs you
;-)<br>
<br>
<blockquote cite="mid:k5hqjk$f3l$1@xxxxxxxxe.org" type="cite">Finally.
Eike Stepper and others, have been great in supporting me on this
forum. Generally very quick and helpful!<br>
</blockquote>
Good docs would certainly be nicer but, while they're absent, good
online support is our attempt to compensate ;-)<br>
<br>
Cheers<br>
/Eike<br>
<br>
----<br>
<a class="moz-txt-link-freetext" href="http://www.esc-net.de">http://www.esc-net.de</a><br>
<a class="moz-txt-link-freetext" href="http://thegordian.blogspot.com">http://thegordian.blogspot.com</a><br>
<a class="moz-txt-link-freetext" href="http://twitter.com/eikestepper">http://twitter.com/eikestepper</a><br>
<br>
<br>
<br>
</body>
</html>
-
Attachment: bgchgghb.png
(Size: 83.23KB, Downloaded 129 times) -
Attachment: edjjaeef.png
(Size: 16.76KB, Downloaded 154 times)
Cheers
/Eike
----
http://www.esc-net.de
http://thegordian.blogspot.com
http://twitter.com/eikestepper
|
|
|
| Re: Understanding CDO [message #946459 is a reply to message #945941] |
Tue, 16 October 2012 06:30 |
|
<html>
<head>
<meta content="text/html; charset=UTF-8" http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
Hi Christophe,<br>
<br>
Thank you very much for your detailed experience report. I like it
lot ;-)<br>
<br>
More comments below...<br>
<br>
<br>
<div class="moz-cite-prefix">Am 15.10.2012 22:10, schrieb Christophe
Bouhier:<br>
</div>
<blockquote cite="mid:k5hqjk$f3l$1@xxxxxxxxe.org" type="cite">Hello
Mauro, <br>
for the last 2 years, I have been working on a client/server
application using CDO. Depending on your needs, CDO could be the
right fit. <br>
What I like (a lot). <br>
1 CDO == EMF, so you can model data first in .xsd or directly in
.ecore, and you can tell CDO to use your generated packages, which
will build the DB schema. </blockquote>
EMF compliance is very important to us and we're proud to support
most of EMF's features. Among the few exceptions are:<br>
<br>
a) Feature maps are hard to deal with in RDBs<br>
<br>
b) Because CDOResources are EObjects (see point 10) a small number
of other frameworks may run into trouble when trying to find out the
concrete type of a Notifier because the result depends on a
particular order of instanceof checks (check Resources first).<br>
<br>
c) With remote change notifications enabled, i.e.,
view.options().addChangeSubscriptionPolicy(...), your own Adapters
often need to distinguish between local or remote changes. An
instanceof CDODeltaNotification does the trick.<br>
<br>
d) Some IDE applications (and some poorly designed frameworks such
as GMF) heavily rely on IResources which are probably impossible to
simulate for CDOResources. For example it's hard or impossible to
present problem markers for validation problems in CDOResources
because IMarkers are associated with IResources. This is not a CDO
problem but a platform/IMarker problem that other
non-"platform:resource" Resources share in common.<br>
<br>
<blockquote cite="mid:k5hqjk$f3l$1@xxxxxxxxe.org" type="cite">2
On the CDO Store, you can choose from the DBStore, which supports
various DB's, I have worked with MySQL and Postgres. With
Hibernate store, there is an additional ORM layer, which works
with tons of other DB's supported by Hibernate. </blockquote>
And there's support for some other backend types, such as DB4O,
MongoDB or Objectivity/DB. I've recently developed a
RandomAccessFile based journaling store, named LissomeStore. It
still uses an RDB for a small and fixed number of indexes into the
random access file(s). For commits it uses a journal file and
adjusts the index tables asynchronously. The performance of large
commits can typically be increased by factor 600 in my tests.<br>
<br>
IMHO the great value of the IStore design is that it becomes a snap
to *change* the backend choice at any time without much impact on
the application (except you're making heavy use of backend-specifc
IQueryHandlers such as SQL or HQL).<br>
<br>
<blockquote cite="mid:k5hqjk$f3l$1@xxxxxxxxe.org" type="cite">3
As CDO == EMF, you can easily adapt a generated RCP Client EMF
editor for CDO, but in practice you are likely better of to start
UI design from scratch, but you can re-use the concept of an
Editing domain and EMF.edit generated code, which is what I do.
(ItemProviders and Commands). </blockquote>
It's a major goal of CDO to better separate the functional from the
the technical design aspects/tasks. The only intrusive technical
aspect I can imagine of is large flat lists that should generally be
avoided in favour of a deeper object structure. IMHO this is a
useful rule even when only considering the usability of a graphical
application.<br>
<br>
<blockquote cite="mid:k5hqjk$f3l$1@xxxxxxxxe.org" type="cite">4
JFace databinding supports EMF, so JFace Databinding + CDO is a
great combination, you might want to watch loading large chunks of
data into your UI widgets (tables + trees), but there are ways to
limit the volumes. </blockquote>
I fully agree that EMF databinding is a totally cool thing. One
thing that tends to be problematic are remote deletions because the
databinding layer caches some strong references to objects that
might, all of a sudden, start to throw InvalidObjectExceptions or
ObjectNotFoundExceptions. You may appreciate that in CDO 4.2 we now
changed to:<br>
<br>
public static final CDOStaleReferencePolicy DEFAULT = PROXY;<br>
<br>
public static final CDOInvalidationPolicy DEFAULT = RELAXED;<br>
<br>
<br>
<blockquote cite="mid:k5hqjk$f3l$1@xxxxxxxxe.org" type="cite">5 I
you need to do something with DSL's (Develop a textual syntax,
which can interact with EMF/CDO models), this is also great with
xtext.
<br>
</blockquote>
Yes, because "CDO == EMF". But please keep in mind that editing DSL
instances stored *in* CDO with an Xtexteditor is problematic because
a text editor generally doesn't preserve the identities (e.g.
CDOIDs) of objects. That makes it hard to reconcile changes made in
a text editor back to CDO.<br>
<br>
<blockquote cite="mid:k5hqjk$f3l$1@xxxxxxxxe.org" type="cite">6
CDO performs well, you can tweak it, to fetch more or less chunks
of data for EReferences. If you don't like the behaviour you can
fire CDO Queries to get exactly what you want. Also unused objects
are garbage collected, so you can safely read a lot of data (As
long as you don't keep a reference). </blockquote>
Funnily this scalability originally came as a by-product of the
auditing functionality ;-)<br>
<br>
<blockquote cite="mid:k5hqjk$f3l$1@xxxxxxxxe.org" type="cite">7 I
am really fond that objects have a lifecycle, and all my object
have a unique CDO ID. I actually present the CDOID, in the status
line of the app. It's a great way to check what's going on. </blockquote>
And now you can even plug in your own CDOIDGenerator at the
client-side:<br>
<br>
public interface CDOIDGenerator<br>
{<br>
public static final CDOIDGenerator UUID = new CDOIDGenerator()<br>
{<br>
public CDOID generateCDOID(EObject object)<br>
{<br>
byte[] bytes = new byte[16];<br>
UUIDGenerator.DEFAULT.generate(bytes);<br>
return CDOIDUtil.createUUID(bytes);<br>
}<br>
<br>
public void reset()<br>
{<br>
// Do nothing<br>
}<br>
};<br>
<br>
/**<br>
* Generates a {@link CDOID}.<br>
* <br>
* @param object<br>
* the object to generate a new CDOID for if available,
<code>null</code> otherwise.<br>
*/<br>
public CDOID generateCDOID(EObject object);<br>
<br>
/**<br>
* Called at the end of a commit operation to give this ID
generator a chance to reset its sequence of IDs.<br>
*/<br>
public void reset();<br>
}<br>
<br>
<blockquote cite="mid:k5hqjk$f3l$1@xxxxxxxxe.org" type="cite">
8 Invalidations are great, basically when an object goes, remotely
dirty, other views are notified and can get the latest status of
an object. <br>
<br>
What I could do without in CDO
<br>
<br>
9. Revisions & referential integrity, I loved it at first, but
right now for the app. I have. it's a burden. The concept of
revisions adds a lot of requirements in CDO, I think CDO should
also have a simpler flat mode, without the revisions and checks on
integrity. It adds to the complexity of the CDO middleware and the
generated DB get's schema's. Some apps, don't need it or need it
partially. In my case, I would need revisions for some classes
only. </blockquote>
I suspect you don't refer to CDORevisions but to the auditing mode
in general? You know that it can be switched off. Granted, for the
DBStore in particular
<a class="moz-txt-link-freetext" href="https://bugs.eclipse.org/bugs/show_bug.cgi?id=351068">https://bugs.eclipse.org/bugs/show_bug.cgi?id=351068</a> is pending. I
really want to work on this soon.<br>
<br>
Partial auditing has been requested in the past. Conceptually I
don't like the idea because the framework couldn't guarantee the
logical consistency of the graph anymore. But I'm willing to
reconsider this when the DBStore gets its next design overhaul (not
scheduled, yet).<br>
<br>
What exact integrity checks are you referring to? Referential
integrity checks in the repository can be switched off (and they are
by default).<br>
<br>
<blockquote cite="mid:k5hqjk$f3l$1@xxxxxxxxe.org" type="cite">It
sometimes feels CDO is trying to mimic a Concurrent Version System
like SVN or CVS, but for many apps you really don't need that. <br>
</blockquote>
Yes, CDO tries to offer support in both worlds, the database
driven-like runtime applications and the more tool-like use cases
where design-time models need to be stored/managed in a repository.
You can imagine that this is sometimes hard but I think we've done a
pretty good job. Are there particular parts in CDO that are
problematic for you in this regard (i.e., not just unneeded)?<br>
<br>
BTW. an example of a cool new SCM-like feature is our new History
view support for repositories, branches or single objects:<br>
<br>
<img src="http://www.eclipse.org/forums/index.php?t=getfile&id=11903" alt=""><br>
<br>
<blockquote cite="mid:k5hqjk$f3l$1@xxxxxxxxe.org" type="cite">10.
In CDO there are CDOFolders and CDOResources. </blockquote>
Yes, and CDOTextResources and CDOBinaryResources, which are now
(almost) first class citizens of a CDO repository:<br>
<br>
<img src="http://www.eclipse.org/forums/index.php?t=getfile&id=11904" alt=""><br>
<br>
<blockquote cite="mid:k5hqjk$f3l$1@xxxxxxxxe.org" type="cite">Both
are also CDO objects, and stored in the DB. I went through great
length to find the best way to use them, like the the names to
give them, which is meta information you need to deal with in the
application. (Remember which name you used for which resource to
keep which data objects, in my case each eclass has its own
cdoresource). </blockquote>
Yes, that's the main value of Resources in general: They provide
well-known entry points into the (persistent) graph of objects.<br>
<br>
Apart from that they're an essential part of "CDO == EMF" (see point
1).<br>
<br>
<blockquote cite="mid:k5hqjk$f3l$1@xxxxxxxxe.org" type="cite">Right
now, I am not sure what the added value is of these, besides some
additional grouping of objects, I think, without them it could
keep CDO simpler and avoid additional DB data. </blockquote>
Please note that you absolutely don't need to use CDOResourceFolders
and CDOResources (except for a single one to contain all other
objects). The characteristics of a CDO model is the same when you
store all objects in a single resource.<br>
<br>
<blockquote cite="mid:k5hqjk$f3l$1@xxxxxxxxe.org" type="cite">(Note
that in point 3, I mentioned the EMF Editing domain, which has a
ResourceSet which can hold CDOResource objects. I use this, so
without CDO Resources, I wouldn't be able to use an editing
domain, so something else would be needed). <br>
</blockquote>
I think the generated editors also make heavy use of the assumption
that objects are contained by resources.<br>
<br>
<blockquote cite="mid:k5hqjk$f3l$1@xxxxxxxxe.org" type="cite">What
I wish for in CDO.
<br>
<br>
11. Model migrations. There are initiatives like COPE, which could
be applied with CDO, that would be great. So add a class in your
model, and let the new feature deal with the migration and transit
your data. </blockquote>
Fully agreed. If only someone would need it enough to open the
wallet and fund the development of this feature :P<br>
<br>
<blockquote cite="mid:k5hqjk$f3l$1@xxxxxxxxe.org" type="cite">12.
It's a hard learning curve, because most of the docs are outdated
or not written, so mea-culpa, we could do better. I wish for a
thriving community around a general purpose
smart-object-persistence system like CDO. <br>
</blockquote>
Yes! Technical writers in the world, here's a project that needs you
;-)<br>
<br>
<blockquote cite="mid:k5hqjk$f3l$1@xxxxxxxxe.org" type="cite">Finally.
Eike Stepper and others, have been great in supporting me on this
forum. Generally very quick and helpful!<br>
</blockquote>
Good docs would certainly be nicer but, while they're absent, good
online support is our attempt to compensate ;-)<br>
<br>
Cheers<br>
/Eike<br>
<br>
----<br>
<a class="moz-txt-link-freetext" href="http://www.esc-net.de">http://www.esc-net.de</a><br>
<a class="moz-txt-link-freetext" href="http://thegordian.blogspot.com">http://thegordian.blogspot.com</a><br>
<a class="moz-txt-link-freetext" href="http://twitter.com/eikestepper">http://twitter.com/eikestepper</a><br>
<br>
<br>
<br>
</body>
</html>
-
Attachment: bgchgghb.png
(Size: 83.23KB, Downloaded 125 times) -
Attachment: edjjaeef.png
(Size: 16.76KB, Downloaded 140 times)
Cheers
/Eike
----
http://www.esc-net.de
http://thegordian.blogspot.com
http://twitter.com/eikestepper
|
|
|
| Re: Understanding CDO [message #946464 is a reply to message #945941] |
Tue, 16 October 2012 06:30 |
|
<html>
<head>
<meta content="text/html; charset=UTF-8" http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
Hi Christophe,<br>
<br>
Thank you very much for your detailed experience report. I like it
lot ;-)<br>
<br>
More comments below...<br>
<br>
<br>
<div class="moz-cite-prefix">Am 15.10.2012 22:10, schrieb Christophe
Bouhier:<br>
</div>
<blockquote cite="mid:k5hqjk$f3l$1@xxxxxxxxe.org" type="cite">Hello
Mauro, <br>
for the last 2 years, I have been working on a client/server
application using CDO. Depending on your needs, CDO could be the
right fit. <br>
What I like (a lot). <br>
1 CDO == EMF, so you can model data first in .xsd or directly in
.ecore, and you can tell CDO to use your generated packages, which
will build the DB schema. </blockquote>
EMF compliance is very important to us and we're proud to support
most of EMF's features. Among the few exceptions are:<br>
<br>
a) Feature maps are hard to deal with in RDBs<br>
<br>
b) Because CDOResources are EObjects (see point 10) a small number
of other frameworks may run into trouble when trying to find out the
concrete type of a Notifier because the result depends on a
particular order of instanceof checks (check Resources first).<br>
<br>
c) With remote change notifications enabled, i.e.,
view.options().addChangeSubscriptionPolicy(...), your own Adapters
often need to distinguish between local or remote changes. An
instanceof CDODeltaNotification does the trick.<br>
<br>
d) Some IDE applications (and some poorly designed frameworks such
as GMF) heavily rely on IResources which are probably impossible to
simulate for CDOResources. For example it's hard or impossible to
present problem markers for validation problems in CDOResources
because IMarkers are associated with IResources. This is not a CDO
problem but a platform/IMarker problem that other
non-"platform:resource" Resources share in common.<br>
<br>
<blockquote cite="mid:k5hqjk$f3l$1@xxxxxxxxe.org" type="cite">2
On the CDO Store, you can choose from the DBStore, which supports
various DB's, I have worked with MySQL and Postgres. With
Hibernate store, there is an additional ORM layer, which works
with tons of other DB's supported by Hibernate. </blockquote>
And there's support for some other backend types, such as DB4O,
MongoDB or Objectivity/DB. I've recently developed a
RandomAccessFile based journaling store, named LissomeStore. It
still uses an RDB for a small and fixed number of indexes into the
random access file(s). For commits it uses a journal file and
adjusts the index tables asynchronously. The performance of large
commits can typically be increased by factor 600 in my tests.<br>
<br>
IMHO the great value of the IStore design is that it becomes a snap
to *change* the backend choice at any time without much impact on
the application (except you're making heavy use of backend-specifc
IQueryHandlers such as SQL or HQL).<br>
<br>
<blockquote cite="mid:k5hqjk$f3l$1@xxxxxxxxe.org" type="cite">3
As CDO == EMF, you can easily adapt a generated RCP Client EMF
editor for CDO, but in practice you are likely better of to start
UI design from scratch, but you can re-use the concept of an
Editing domain and EMF.edit generated code, which is what I do.
(ItemProviders and Commands). </blockquote>
It's a major goal of CDO to better separate the functional from the
the technical design aspects/tasks. The only intrusive technical
aspect I can imagine of is large flat lists that should generally be
avoided in favour of a deeper object structure. IMHO this is a
useful rule even when only considering the usability of a graphical
application.<br>
<br>
<blockquote cite="mid:k5hqjk$f3l$1@xxxxxxxxe.org" type="cite">4
JFace databinding supports EMF, so JFace Databinding + CDO is a
great combination, you might want to watch loading large chunks of
data into your UI widgets (tables + trees), but there are ways to
limit the volumes. </blockquote>
I fully agree that EMF databinding is a totally cool thing. One
thing that tends to be problematic are remote deletions because the
databinding layer caches some strong references to objects that
might, all of a sudden, start to throw InvalidObjectExceptions or
ObjectNotFoundExceptions. You may appreciate that in CDO 4.2 we now
changed to:<br>
<br>
public static final CDOStaleReferencePolicy DEFAULT = PROXY;<br>
<br>
public static final CDOInvalidationPolicy DEFAULT = RELAXED;<br>
<br>
<br>
<blockquote cite="mid:k5hqjk$f3l$1@xxxxxxxxe.org" type="cite">5 I
you need to do something with DSL's (Develop a textual syntax,
which can interact with EMF/CDO models), this is also great with
xtext.
<br>
</blockquote>
Yes, because "CDO == EMF". But please keep in mind that editing DSL
instances stored *in* CDO with an Xtexteditor is problematic because
a text editor generally doesn't preserve the identities (e.g.
CDOIDs) of objects. That makes it hard to reconcile changes made in
a text editor back to CDO.<br>
<br>
<blockquote cite="mid:k5hqjk$f3l$1@xxxxxxxxe.org" type="cite">6
CDO performs well, you can tweak it, to fetch more or less chunks
of data for EReferences. If you don't like the behaviour you can
fire CDO Queries to get exactly what you want. Also unused objects
are garbage collected, so you can safely read a lot of data (As
long as you don't keep a reference). </blockquote>
Funnily this scalability originally came as a by-product of the
auditing functionality ;-)<br>
<br>
<blockquote cite="mid:k5hqjk$f3l$1@xxxxxxxxe.org" type="cite">7 I
am really fond that objects have a lifecycle, and all my object
have a unique CDO ID. I actually present the CDOID, in the status
line of the app. It's a great way to check what's going on. </blockquote>
And now you can even plug in your own CDOIDGenerator at the
client-side:<br>
<br>
public interface CDOIDGenerator<br>
{<br>
public static final CDOIDGenerator UUID = new CDOIDGenerator()<br>
{<br>
public CDOID generateCDOID(EObject object)<br>
{<br>
byte[] bytes = new byte[16];<br>
UUIDGenerator.DEFAULT.generate(bytes);<br>
return CDOIDUtil.createUUID(bytes);<br>
}<br>
<br>
public void reset()<br>
{<br>
// Do nothing<br>
}<br>
};<br>
<br>
/**<br>
* Generates a {@link CDOID}.<br>
* <br>
* @param object<br>
* the object to generate a new CDOID for if available,
<code>null</code> otherwise.<br>
*/<br>
public CDOID generateCDOID(EObject object);<br>
<br>
/**<br>
* Called at the end of a commit operation to give this ID
generator a chance to reset its sequence of IDs.<br>
*/<br>
public void reset();<br>
}<br>
<br>
<blockquote cite="mid:k5hqjk$f3l$1@xxxxxxxxe.org" type="cite">
8 Invalidations are great, basically when an object goes, remotely
dirty, other views are notified and can get the latest status of
an object. <br>
<br>
What I could do without in CDO
<br>
<br>
9. Revisions & referential integrity, I loved it at first, but
right now for the app. I have. it's a burden. The concept of
revisions adds a lot of requirements in CDO, I think CDO should
also have a simpler flat mode, without the revisions and checks on
integrity. It adds to the complexity of the CDO middleware and the
generated DB get's schema's. Some apps, don't need it or need it
partially. In my case, I would need revisions for some classes
only. </blockquote>
I suspect you don't refer to CDORevisions but to the auditing mode
in general? You know that it can be switched off. Granted, for the
DBStore in particular
<a class="moz-txt-link-freetext" href="https://bugs.eclipse.org/bugs/show_bug.cgi?id=351068">https://bugs.eclipse.org/bugs/show_bug.cgi?id=351068</a> is pending. I
really want to work on this soon.<br>
<br>
Partial auditing has been requested in the past. Conceptually I
don't like the idea because the framework couldn't guarantee the
logical consistency of the graph anymore. But I'm willing to
reconsider this when the DBStore gets its next design overhaul (not
scheduled, yet).<br>
<br>
What exact integrity checks are you referring to? Referential
integrity checks in the repository can be switched off (and they are
by default).<br>
<br>
<blockquote cite="mid:k5hqjk$f3l$1@xxxxxxxxe.org" type="cite">It
sometimes feels CDO is trying to mimic a Concurrent Version System
like SVN or CVS, but for many apps you really don't need that. <br>
</blockquote>
Yes, CDO tries to offer support in both worlds, the database
driven-like runtime applications and the more tool-like use cases
where design-time models need to be stored/managed in a repository.
You can imagine that this is sometimes hard but I think we've done a
pretty good job. Are there particular parts in CDO that are
problematic for you in this regard (i.e., not just unneeded)?<br>
<br>
BTW. an example of a cool new SCM-like feature is our new History
view support for repositories, branches or single objects:<br>
<br>
<img src="http://www.eclipse.org/forums/index.php?t=getfile&id=11905" alt=""><br>
<br>
<blockquote cite="mid:k5hqjk$f3l$1@xxxxxxxxe.org" type="cite">10.
In CDO there are CDOFolders and CDOResources. </blockquote>
Yes, and CDOTextResources and CDOBinaryResources, which are now
(almost) first class citizens of a CDO repository:<br>
<br>
<img src="http://www.eclipse.org/forums/index.php?t=getfile&id=11906" alt=""><br>
<br>
<blockquote cite="mid:k5hqjk$f3l$1@xxxxxxxxe.org" type="cite">Both
are also CDO objects, and stored in the DB. I went through great
length to find the best way to use them, like the the names to
give them, which is meta information you need to deal with in the
application. (Remember which name you used for which resource to
keep which data objects, in my case each eclass has its own
cdoresource). </blockquote>
Yes, that's the main value of Resources in general: They provide
well-known entry points into the (persistent) graph of objects.<br>
<br>
Apart from that they're an essential part of "CDO == EMF" (see point
1).<br>
<br>
<blockquote cite="mid:k5hqjk$f3l$1@xxxxxxxxe.org" type="cite">Right
now, I am not sure what the added value is of these, besides some
additional grouping of objects, I think, without them it could
keep CDO simpler and avoid additional DB data. </blockquote>
Please note that you absolutely don't need to use CDOResourceFolders
and CDOResources (except for a single one to contain all other
objects). The characteristics of a CDO model is the same when you
store all objects in a single resource.<br>
<br>
<blockquote cite="mid:k5hqjk$f3l$1@xxxxxxxxe.org" type="cite">(Note
that in point 3, I mentioned the EMF Editing domain, which has a
ResourceSet which can hold CDOResource objects. I use this, so
without CDO Resources, I wouldn't be able to use an editing
domain, so something else would be needed). <br>
</blockquote>
I think the generated editors also make heavy use of the assumption
that objects are contained by resources.<br>
<br>
<blockquote cite="mid:k5hqjk$f3l$1@xxxxxxxxe.org" type="cite">What
I wish for in CDO.
<br>
<br>
11. Model migrations. There are initiatives like COPE, which could
be applied with CDO, that would be great. So add a class in your
model, and let the new feature deal with the migration and transit
your data. </blockquote>
Fully agreed. If only someone would need it enough to open the
wallet and fund the development of this feature :P<br>
<br>
<blockquote cite="mid:k5hqjk$f3l$1@xxxxxxxxe.org" type="cite">12.
It's a hard learning curve, because most of the docs are outdated
or not written, so mea-culpa, we could do better. I wish for a
thriving community around a general purpose
smart-object-persistence system like CDO. <br>
</blockquote>
Yes! Technical writers in the world, here's a project that needs you
;-)<br>
<br>
<blockquote cite="mid:k5hqjk$f3l$1@xxxxxxxxe.org" type="cite">Finally.
Eike Stepper and others, have been great in supporting me on this
forum. Generally very quick and helpful!<br>
</blockquote>
Good docs would certainly be nicer but, while they're absent, good
online support is our attempt to compensate ;-)<br>
<br>
Cheers<br>
/Eike<br>
<br>
----<br>
<a class="moz-txt-link-freetext" href="http://www.esc-net.de">http://www.esc-net.de</a><br>
<a class="moz-txt-link-freetext" href="http://thegordian.blogspot.com">http://thegordian.blogspot.com</a><br>
<a class="moz-txt-link-freetext" href="http://twitter.com/eikestepper">http://twitter.com/eikestepper</a><br>
<br>
<br>
<br>
</body>
</html>
-
Attachment: bgchgghb.png
(Size: 83.23KB, Downloaded 128 times) -
Attachment: edjjaeef.png
(Size: 16.76KB, Downloaded 132 times)
Cheers
/Eike
----
http://www.esc-net.de
http://thegordian.blogspot.com
http://twitter.com/eikestepper
|
|
|
| Re: Understanding CDO [message #946469 is a reply to message #945941] |
Tue, 16 October 2012 06:30 |
|
<html>
<head>
<meta content="text/html; charset=UTF-8" http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
Hi Christophe,<br>
<br>
Thank you very much for your detailed experience report. I like it
lot ;-)<br>
<br>
More comments below...<br>
<br>
<br>
<div class="moz-cite-prefix">Am 15.10.2012 22:10, schrieb Christophe
Bouhier:<br>
</div>
<blockquote cite="mid:k5hqjk$f3l$1@xxxxxxxxe.org" type="cite">Hello
Mauro, <br>
for the last 2 years, I have been working on a client/server
application using CDO. Depending on your needs, CDO could be the
right fit. <br>
What I like (a lot). <br>
1 CDO == EMF, so you can model data first in .xsd or directly in
.ecore, and you can tell CDO to use your generated packages, which
will build the DB schema. </blockquote>
EMF compliance is very important to us and we're proud to support
most of EMF's features. Among the few exceptions are:<br>
<br>
a) Feature maps are hard to deal with in RDBs<br>
<br>
b) Because CDOResources are EObjects (see point 10) a small number
of other frameworks may run into trouble when trying to find out the
concrete type of a Notifier because the result depends on a
particular order of instanceof checks (check Resources first).<br>
<br>
c) With remote change notifications enabled, i.e.,
view.options().addChangeSubscriptionPolicy(...), your own Adapters
often need to distinguish between local or remote changes. An
instanceof CDODeltaNotification does the trick.<br>
<br>
d) Some IDE applications (and some poorly designed frameworks such
as GMF) heavily rely on IResources which are probably impossible to
simulate for CDOResources. For example it's hard or impossible to
present problem markers for validation problems in CDOResources
because IMarkers are associated with IResources. This is not a CDO
problem but a platform/IMarker problem that other
non-"platform:resource" Resources share in common.<br>
<br>
<blockquote cite="mid:k5hqjk$f3l$1@xxxxxxxxe.org" type="cite">2
On the CDO Store, you can choose from the DBStore, which supports
various DB's, I have worked with MySQL and Postgres. With
Hibernate store, there is an additional ORM layer, which works
with tons of other DB's supported by Hibernate. </blockquote>
And there's support for some other backend types, such as DB4O,
MongoDB or Objectivity/DB. I've recently developed a
RandomAccessFile based journaling store, named LissomeStore. It
still uses an RDB for a small and fixed number of indexes into the
random access file(s). For commits it uses a journal file and
adjusts the index tables asynchronously. The performance of large
commits can typically be increased by factor 600 in my tests.<br>
<br>
IMHO the great value of the IStore design is that it becomes a snap
to *change* the backend choice at any time without much impact on
the application (except you're making heavy use of backend-specifc
IQueryHandlers such as SQL or HQL).<br>
<br>
<blockquote cite="mid:k5hqjk$f3l$1@xxxxxxxxe.org" type="cite">3
As CDO == EMF, you can easily adapt a generated RCP Client EMF
editor for CDO, but in practice you are likely better of to start
UI design from scratch, but you can re-use the concept of an
Editing domain and EMF.edit generated code, which is what I do.
(ItemProviders and Commands). </blockquote>
It's a major goal of CDO to better separate the functional from the
the technical design aspects/tasks. The only intrusive technical
aspect I can imagine of is large flat lists that should generally be
avoided in favour of a deeper object structure. IMHO this is a
useful rule even when only considering the usability of a graphical
application.<br>
<br>
<blockquote cite="mid:k5hqjk$f3l$1@xxxxxxxxe.org" type="cite">4
JFace databinding supports EMF, so JFace Databinding + CDO is a
great combination, you might want to watch loading large chunks of
data into your UI widgets (tables + trees), but there are ways to
limit the volumes. </blockquote>
I fully agree that EMF databinding is a totally cool thing. One
thing that tends to be problematic are remote deletions because the
databinding layer caches some strong references to objects that
might, all of a sudden, start to throw InvalidObjectExceptions or
ObjectNotFoundExceptions. You may appreciate that in CDO 4.2 we now
changed to:<br>
<br>
public static final CDOStaleReferencePolicy DEFAULT = PROXY;<br>
<br>
public static final CDOInvalidationPolicy DEFAULT = RELAXED;<br>
<br>
<br>
<blockquote cite="mid:k5hqjk$f3l$1@xxxxxxxxe.org" type="cite">5 I
you need to do something with DSL's (Develop a textual syntax,
which can interact with EMF/CDO models), this is also great with
xtext.
<br>
</blockquote>
Yes, because "CDO == EMF". But please keep in mind that editing DSL
instances stored *in* CDO with an Xtexteditor is problematic because
a text editor generally doesn't preserve the identities (e.g.
CDOIDs) of objects. That makes it hard to reconcile changes made in
a text editor back to CDO.<br>
<br>
<blockquote cite="mid:k5hqjk$f3l$1@xxxxxxxxe.org" type="cite">6
CDO performs well, you can tweak it, to fetch more or less chunks
of data for EReferences. If you don't like the behaviour you can
fire CDO Queries to get exactly what you want. Also unused objects
are garbage collected, so you can safely read a lot of data (As
long as you don't keep a reference). </blockquote>
Funnily this scalability originally came as a by-product of the
auditing functionality ;-)<br>
<br>
<blockquote cite="mid:k5hqjk$f3l$1@xxxxxxxxe.org" type="cite">7 I
am really fond that objects have a lifecycle, and all my object
have a unique CDO ID. I actually present the CDOID, in the status
line of the app. It's a great way to check what's going on. </blockquote>
And now you can even plug in your own CDOIDGenerator at the
client-side:<br>
<br>
public interface CDOIDGenerator<br>
{<br>
public static final CDOIDGenerator UUID = new CDOIDGenerator()<br>
{<br>
public CDOID generateCDOID(EObject object)<br>
{<br>
byte[] bytes = new byte[16];<br>
UUIDGenerator.DEFAULT.generate(bytes);<br>
return CDOIDUtil.createUUID(bytes);<br>
}<br>
<br>
public void reset()<br>
{<br>
// Do nothing<br>
}<br>
};<br>
<br>
/**<br>
* Generates a {@link CDOID}.<br>
* <br>
* @param object<br>
* the object to generate a new CDOID for if available,
<code>null</code> otherwise.<br>
*/<br>
public CDOID generateCDOID(EObject object);<br>
<br>
/**<br>
* Called at the end of a commit operation to give this ID
generator a chance to reset its sequence of IDs.<br>
*/<br>
public void reset();<br>
}<br>
<br>
<blockquote cite="mid:k5hqjk$f3l$1@xxxxxxxxe.org" type="cite">
8 Invalidations are great, basically when an object goes, remotely
dirty, other views are notified and can get the latest status of
an object. <br>
<br>
What I could do without in CDO
<br>
<br>
9. Revisions & referential integrity, I loved it at first, but
right now for the app. I have. it's a burden. The concept of
revisions adds a lot of requirements in CDO, I think CDO should
also have a simpler flat mode, without the revisions and checks on
integrity. It adds to the complexity of the CDO middleware and the
generated DB get's schema's. Some apps, don't need it or need it
partially. In my case, I would need revisions for some classes
only. </blockquote>
I suspect you don't refer to CDORevisions but to the auditing mode
in general? You know that it can be switched off. Granted, for the
DBStore in particular
<a class="moz-txt-link-freetext" href="https://bugs.eclipse.org/bugs/show_bug.cgi?id=351068">https://bugs.eclipse.org/bugs/show_bug.cgi?id=351068</a> is pending. I
really want to work on this soon.<br>
<br>
Partial auditing has been requested in the past. Conceptually I
don't like the idea because the framework couldn't guarantee the
logical consistency of the graph anymore. But I'm willing to
reconsider this when the DBStore gets its next design overhaul (not
scheduled, yet).<br>
<br>
What exact integrity checks are you referring to? Referential
integrity checks in the repository can be switched off (and they are
by default).<br>
<br>
<blockquote cite="mid:k5hqjk$f3l$1@xxxxxxxxe.org" type="cite">It
sometimes feels CDO is trying to mimic a Concurrent Version System
like SVN or CVS, but for many apps you really don't need that. <br>
</blockquote>
Yes, CDO tries to offer support in both worlds, the database
driven-like runtime applications and the more tool-like use cases
where design-time models need to be stored/managed in a repository.
You can imagine that this is sometimes hard but I think we've done a
pretty good job. Are there particular parts in CDO that are
problematic for you in this regard (i.e., not just unneeded)?<br>
<br>
BTW. an example of a cool new SCM-like feature is our new History
view support for repositories, branches or single objects:<br>
<br>
<img src="http://www.eclipse.org/forums/index.php?t=getfile&id=11907" alt=""><br>
<br>
<blockquote cite="mid:k5hqjk$f3l$1@xxxxxxxxe.org" type="cite">10.
In CDO there are CDOFolders and CDOResources. </blockquote>
Yes, and CDOTextResources and CDOBinaryResources, which are now
(almost) first class citizens of a CDO repository:<br>
<br>
<img src="http://www.eclipse.org/forums/index.php?t=getfile&id=11908" alt=""><br>
<br>
<blockquote cite="mid:k5hqjk$f3l$1@xxxxxxxxe.org" type="cite">Both
are also CDO objects, and stored in the DB. I went through great
length to find the best way to use them, like the the names to
give them, which is meta information you need to deal with in the
application. (Remember which name you used for which resource to
keep which data objects, in my case each eclass has its own
cdoresource). </blockquote>
Yes, that's the main value of Resources in general: They provide
well-known entry points into the (persistent) graph of objects.<br>
<br>
Apart from that they're an essential part of "CDO == EMF" (see point
1).<br>
<br>
<blockquote cite="mid:k5hqjk$f3l$1@xxxxxxxxe.org" type="cite">Right
now, I am not sure what the added value is of these, besides some
additional grouping of objects, I think, without them it could
keep CDO simpler and avoid additional DB data. </blockquote>
Please note that you absolutely don't need to use CDOResourceFolders
and CDOResources (except for a single one to contain all other
objects). The characteristics of a CDO model is the same when you
store all objects in a single resource.<br>
<br>
<blockquote cite="mid:k5hqjk$f3l$1@xxxxxxxxe.org" type="cite">(Note
that in point 3, I mentioned the EMF Editing domain, which has a
ResourceSet which can hold CDOResource objects. I use this, so
without CDO Resources, I wouldn't be able to use an editing
domain, so something else would be needed). <br>
</blockquote>
I think the generated editors also make heavy use of the assumption
that objects are contained by resources.<br>
<br>
<blockquote cite="mid:k5hqjk$f3l$1@xxxxxxxxe.org" type="cite">What
I wish for in CDO.
<br>
<br>
11. Model migrations. There are initiatives like COPE, which could
be applied with CDO, that would be great. So add a class in your
model, and let the new feature deal with the migration and transit
your data. </blockquote>
Fully agreed. If only someone would need it enough to open the
wallet and fund the development of this feature :P<br>
<br>
<blockquote cite="mid:k5hqjk$f3l$1@xxxxxxxxe.org" type="cite">12.
It's a hard learning curve, because most of the docs are outdated
or not written, so mea-culpa, we could do better. I wish for a
thriving community around a general purpose
smart-object-persistence system like CDO. <br>
</blockquote>
Yes! Technical writers in the world, here's a project that needs you
;-)<br>
<br>
<blockquote cite="mid:k5hqjk$f3l$1@xxxxxxxxe.org" type="cite">Finally.
Eike Stepper and others, have been great in supporting me on this
forum. Generally very quick and helpful!<br>
</blockquote>
Good docs would certainly be nicer but, while they're absent, good
online support is our attempt to compensate ;-)<br>
<br>
Cheers<br>
/Eike<br>
<br>
----<br>
<a class="moz-txt-link-freetext" href="http://www.esc-net.de">http://www.esc-net.de</a><br>
<a class="moz-txt-link-freetext" href="http://thegordian.blogspot.com">http://thegordian.blogspot.com</a><br>
<a class="moz-txt-link-freetext" href="http://twitter.com/eikestepper">http://twitter.com/eikestepper</a><br>
<br>
<br>
<br>
</body>
</html>
-
Attachment: bgchgghb.png
(Size: 83.23KB, Downloaded 137 times) -
Attachment: edjjaeef.png
(Size: 16.76KB, Downloaded 129 times)
Cheers
/Eike
----
http://www.esc-net.de
http://thegordian.blogspot.com
http://twitter.com/eikestepper
|
|
|
| Re: Understanding CDO [message #946476 is a reply to message #945941] |
Tue, 16 October 2012 06:30 |
|
<html>
<head>
<meta content="text/html; charset=UTF-8" http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
Hi Christophe,<br>
<br>
Thank you very much for your detailed experience report. I like it
lot ;-)<br>
<br>
More comments below...<br>
<br>
<br>
<div class="moz-cite-prefix">Am 15.10.2012 22:10, schrieb Christophe
Bouhier:<br>
</div>
<blockquote cite="mid:k5hqjk$f3l$1@xxxxxxxxe.org" type="cite">Hello
Mauro, <br>
for the last 2 years, I have been working on a client/server
application using CDO. Depending on your needs, CDO could be the
right fit. <br>
What I like (a lot). <br>
1 CDO == EMF, so you can model data first in .xsd or directly in
.ecore, and you can tell CDO to use your generated packages, which
will build the DB schema. </blockquote>
EMF compliance is very important to us and we're proud to support
most of EMF's features. Among the few exceptions are:<br>
<br>
a) Feature maps are hard to deal with in RDBs<br>
<br>
b) Because CDOResources are EObjects (see point 10) a small number
of other frameworks may run into trouble when trying to find out the
concrete type of a Notifier because the result depends on a
particular order of instanceof checks (check Resources first).<br>
<br>
c) With remote change notifications enabled, i.e.,
view.options().addChangeSubscriptionPolicy(...), your own Adapters
often need to distinguish between local or remote changes. An
instanceof CDODeltaNotification does the trick.<br>
<br>
d) Some IDE applications (and some poorly designed frameworks such
as GMF) heavily rely on IResources which are probably impossible to
simulate for CDOResources. For example it's hard or impossible to
present problem markers for validation problems in CDOResources
because IMarkers are associated with IResources. This is not a CDO
problem but a platform/IMarker problem that other
non-"platform:resource" Resources share in common.<br>
<br>
<blockquote cite="mid:k5hqjk$f3l$1@xxxxxxxxe.org" type="cite">2
On the CDO Store, you can choose from the DBStore, which supports
various DB's, I have worked with MySQL and Postgres. With
Hibernate store, there is an additional ORM layer, which works
with tons of other DB's supported by Hibernate. </blockquote>
And there's support for some other backend types, such as DB4O,
MongoDB or Objectivity/DB. I've recently developed a
RandomAccessFile based journaling store, named LissomeStore. It
still uses an RDB for a small and fixed number of indexes into the
random access file(s). For commits it uses a journal file and
adjusts the index tables asynchronously. The performance of large
commits can typically be increased by factor 600 in my tests.<br>
<br>
IMHO the great value of the IStore design is that it becomes a snap
to *change* the backend choice at any time without much impact on
the application (except you're making heavy use of backend-specifc
IQueryHandlers such as SQL or HQL).<br>
<br>
<blockquote cite="mid:k5hqjk$f3l$1@xxxxxxxxe.org" type="cite">3
As CDO == EMF, you can easily adapt a generated RCP Client EMF
editor for CDO, but in practice you are likely better of to start
UI design from scratch, but you can re-use the concept of an
Editing domain and EMF.edit generated code, which is what I do.
(ItemProviders and Commands). </blockquote>
It's a major goal of CDO to better separate the functional from the
the technical design aspects/tasks. The only intrusive technical
aspect I can imagine of is large flat lists that should generally be
avoided in favour of a deeper object structure. IMHO this is a
useful rule even when only considering the usability of a graphical
application.<br>
<br>
<blockquote cite="mid:k5hqjk$f3l$1@xxxxxxxxe.org" type="cite">4
JFace databinding supports EMF, so JFace Databinding + CDO is a
great combination, you might want to watch loading large chunks of
data into your UI widgets (tables + trees), but there are ways to
limit the volumes. </blockquote>
I fully agree that EMF databinding is a totally cool thing. One
thing that tends to be problematic are remote deletions because the
databinding layer caches some strong references to objects that
might, all of a sudden, start to throw InvalidObjectExceptions or
ObjectNotFoundExceptions. You may appreciate that in CDO 4.2 we now
changed to:<br>
<br>
public static final CDOStaleReferencePolicy DEFAULT = PROXY;<br>
<br>
public static final CDOInvalidationPolicy DEFAULT = RELAXED;<br>
<br>
<br>
<blockquote cite="mid:k5hqjk$f3l$1@xxxxxxxxe.org" type="cite">5 I
you need to do something with DSL's (Develop a textual syntax,
which can interact with EMF/CDO models), this is also great with
xtext.
<br>
</blockquote>
Yes, because "CDO == EMF". But please keep in mind that editing DSL
instances stored *in* CDO with an Xtexteditor is problematic because
a text editor generally doesn't preserve the identities (e.g.
CDOIDs) of objects. That makes it hard to reconcile changes made in
a text editor back to CDO.<br>
<br>
<blockquote cite="mid:k5hqjk$f3l$1@xxxxxxxxe.org" type="cite">6
CDO performs well, you can tweak it, to fetch more or less chunks
of data for EReferences. If you don't like the behaviour you can
fire CDO Queries to get exactly what you want. Also unused objects
are garbage collected, so you can safely read a lot of data (As
long as you don't keep a reference). </blockquote>
Funnily this scalability originally came as a by-product of the
auditing functionality ;-)<br>
<br>
<blockquote cite="mid:k5hqjk$f3l$1@xxxxxxxxe.org" type="cite">7 I
am really fond that objects have a lifecycle, and all my object
have a unique CDO ID. I actually present the CDOID, in the status
line of the app. It's a great way to check what's going on. </blockquote>
And now you can even plug in your own CDOIDGenerator at the
client-side:<br>
<br>
public interface CDOIDGenerator<br>
{<br>
public static final CDOIDGenerator UUID = new CDOIDGenerator()<br>
{<br>
public CDOID generateCDOID(EObject object)<br>
{<br>
byte[] bytes = new byte[16];<br>
UUIDGenerator.DEFAULT.generate(bytes);<br>
return CDOIDUtil.createUUID(bytes);<br>
}<br>
<br>
public void reset()<br>
{<br>
// Do nothing<br>
}<br>
};<br>
<br>
/**<br>
* Generates a {@link CDOID}.<br>
* <br>
* @param object<br>
* the object to generate a new CDOID for if available,
<code>null</code> otherwise.<br>
*/<br>
public CDOID generateCDOID(EObject object);<br>
<br>
/**<br>
* Called at the end of a commit operation to give this ID
generator a chance to reset its sequence of IDs.<br>
*/<br>
public void reset();<br>
}<br>
<br>
<blockquote cite="mid:k5hqjk$f3l$1@xxxxxxxxe.org" type="cite">
8 Invalidations are great, basically when an object goes, remotely
dirty, other views are notified and can get the latest status of
an object. <br>
<br>
What I could do without in CDO
<br>
<br>
9. Revisions & referential integrity, I loved it at first, but
right now for the app. I have. it's a burden. The concept of
revisions adds a lot of requirements in CDO, I think CDO should
also have a simpler flat mode, without the revisions and checks on
integrity. It adds to the complexity of the CDO middleware and the
generated DB get's schema's. Some apps, don't need it or need it
partially. In my case, I would need revisions for some classes
only. </blockquote>
I suspect you don't refer to CDORevisions but to the auditing mode
in general? You know that it can be switched off. Granted, for the
DBStore in particular
<a class="moz-txt-link-freetext" href="https://bugs.eclipse.org/bugs/show_bug.cgi?id=351068">https://bugs.eclipse.org/bugs/show_bug.cgi?id=351068</a> is pending. I
really want to work on this soon.<br>
<br>
Partial auditing has been requested in the past. Conceptually I
don't like the idea because the framework couldn't guarantee the
logical consistency of the graph anymore. But I'm willing to
reconsider this when the DBStore gets its next design overhaul (not
scheduled, yet).<br>
<br>
What exact integrity checks are you referring to? Referential
integrity checks in the repository can be switched off (and they are
by default).<br>
<br>
<blockquote cite="mid:k5hqjk$f3l$1@xxxxxxxxe.org" type="cite">It
sometimes feels CDO is trying to mimic a Concurrent Version System
like SVN or CVS, but for many apps you really don't need that. <br>
</blockquote>
Yes, CDO tries to offer support in both worlds, the database
driven-like runtime applications and the more tool-like use cases
where design-time models need to be stored/managed in a repository.
You can imagine that this is sometimes hard but I think we've done a
pretty good job. Are there particular parts in CDO that are
problematic for you in this regard (i.e., not just unneeded)?<br>
<br>
BTW. an example of a cool new SCM-like feature is our new History
view support for repositories, branches or single objects:<br>
<br>
<img src="http://www.eclipse.org/forums/index.php?t=getfile&id=11909" alt=""><br>
<br>
<blockquote cite="mid:k5hqjk$f3l$1@xxxxxxxxe.org" type="cite">10.
In CDO there are CDOFolders and CDOResources. </blockquote>
Yes, and CDOTextResources and CDOBinaryResources, which are now
(almost) first class citizens of a CDO repository:<br>
<br>
<img src="http://www.eclipse.org/forums/index.php?t=getfile&id=11910" alt=""><br>
<br>
<blockquote cite="mid:k5hqjk$f3l$1@xxxxxxxxe.org" type="cite">Both
are also CDO objects, and stored in the DB. I went through great
length to find the best way to use them, like the the names to
give them, which is meta information you need to deal with in the
application. (Remember which name you used for which resource to
keep which data objects, in my case each eclass has its own
cdoresource). </blockquote>
Yes, that's the main value of Resources in general: They provide
well-known entry points into the (persistent) graph of objects.<br>
<br>
Apart from that they're an essential part of "CDO == EMF" (see point
1).<br>
<br>
<blockquote cite="mid:k5hqjk$f3l$1@xxxxxxxxe.org" type="cite">Right
now, I am not sure what the added value is of these, besides some
additional grouping of objects, I think, without them it could
keep CDO simpler and avoid additional DB data. </blockquote>
Please note that you absolutely don't need to use CDOResourceFolders
and CDOResources (except for a single one to contain all other
objects). The characteristics of a CDO model is the same when you
store all objects in a single resource.<br>
<br>
<blockquote cite="mid:k5hqjk$f3l$1@xxxxxxxxe.org" type="cite">(Note
that in point 3, I mentioned the EMF Editing domain, which has a
ResourceSet which can hold CDOResource objects. I use this, so
without CDO Resources, I wouldn't be able to use an editing
domain, so something else would be needed). <br>
</blockquote>
I think the generated editors also make heavy use of the assumption
that objects are contained by resources.<br>
<br>
<blockquote cite="mid:k5hqjk$f3l$1@xxxxxxxxe.org" type="cite">What
I wish for in CDO.
<br>
<br>
11. Model migrations. There are initiatives like COPE, which could
be applied with CDO, that would be great. So add a class in your
model, and let the new feature deal with the migration and transit
your data. </blockquote>
Fully agreed. If only someone would need it enough to open the
wallet and fund the development of this feature :P<br>
<br>
<blockquote cite="mid:k5hqjk$f3l$1@xxxxxxxxe.org" type="cite">12.
It's a hard learning curve, because most of the docs are outdated
or not written, so mea-culpa, we could do better. I wish for a
thriving community around a general purpose
smart-object-persistence system like CDO. <br>
</blockquote>
Yes! Technical writers in the world, here's a project that needs you
;-)<br>
<br>
<blockquote cite="mid:k5hqjk$f3l$1@xxxxxxxxe.org" type="cite">Finally.
Eike Stepper and others, have been great in supporting me on this
forum. Generally very quick and helpful!<br>
</blockquote>
Good docs would certainly be nicer but, while they're absent, good
online support is our attempt to compensate ;-)<br>
<br>
Cheers<br>
/Eike<br>
<br>
----<br>
<a class="moz-txt-link-freetext" href="http://www.esc-net.de">http://www.esc-net.de</a><br>
<a class="moz-txt-link-freetext" href="http://thegordian.blogspot.com">http://thegordian.blogspot.com</a><br>
<a class="moz-txt-link-freetext" href="http://twitter.com/eikestepper">http://twitter.com/eikestepper</a><br>
<br>
<br>
<br>
</body>
</html>
-
Attachment: bgchgghb.png
(Size: 83.23KB, Downloaded 131 times) -
Attachment: edjjaeef.png
(Size: 16.76KB, Downloaded 150 times)
Cheers
/Eike
----
http://www.esc-net.de
http://thegordian.blogspot.com
http://twitter.com/eikestepper
|
|
|
| Re: Understanding CDO [message #946480 is a reply to message #945941] |
Tue, 16 October 2012 06:30 |
|
<html>
<head>
<meta content="text/html; charset=UTF-8" http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
Hi Christophe,<br>
<br>
Thank you very much for your detailed experience report. I like it
lot ;-)<br>
<br>
More comments below...<br>
<br>
<br>
<div class="moz-cite-prefix">Am 15.10.2012 22:10, schrieb Christophe
Bouhier:<br>
</div>
<blockquote cite="mid:k5hqjk$f3l$1@xxxxxxxxe.org" type="cite">Hello
Mauro, <br>
for the last 2 years, I have been working on a client/server
application using CDO. Depending on your needs, CDO could be the
right fit. <br>
What I like (a lot). <br>
1 CDO == EMF, so you can model data first in .xsd or directly in
.ecore, and you can tell CDO to use your generated packages, which
will build the DB schema. </blockquote>
EMF compliance is very important to us and we're proud to support
most of EMF's features. Among the few exceptions are:<br>
<br>
a) Feature maps are hard to deal with in RDBs<br>
<br>
b) Because CDOResources are EObjects (see point 10) a small number
of other frameworks may run into trouble when trying to find out the
concrete type of a Notifier because the result depends on a
particular order of instanceof checks (check Resources first).<br>
<br>
c) With remote change notifications enabled, i.e.,
view.options().addChangeSubscriptionPolicy(...), your own Adapters
often need to distinguish between local or remote changes. An
instanceof CDODeltaNotification does the trick.<br>
<br>
d) Some IDE applications (and some poorly designed frameworks such
as GMF) heavily rely on IResources which are probably impossible to
simulate for CDOResources. For example it's hard or impossible to
present problem markers for validation problems in CDOResources
because IMarkers are associated with IResources. This is not a CDO
problem but a platform/IMarker problem that other
non-"platform:resource" Resources share in common.<br>
<br>
<blockquote cite="mid:k5hqjk$f3l$1@xxxxxxxxe.org" type="cite">2
On the CDO Store, you can choose from the DBStore, which supports
various DB's, I have worked with MySQL and Postgres. With
Hibernate store, there is an additional ORM layer, which works
with tons of other DB's supported by Hibernate. </blockquote>
And there's support for some other backend types, such as DB4O,
MongoDB or Objectivity/DB. I've recently developed a
RandomAccessFile based journaling store, named LissomeStore. It
still uses an RDB for a small and fixed number of indexes into the
random access file(s). For commits it uses a journal file and
adjusts the index tables asynchronously. The performance of large
commits can typically be increased by factor 600 in my tests.<br>
<br>
IMHO the great value of the IStore design is that it becomes a snap
to *change* the backend choice at any time without much impact on
the application (except you're making heavy use of backend-specifc
IQueryHandlers such as SQL or HQL).<br>
<br>
<blockquote cite="mid:k5hqjk$f3l$1@xxxxxxxxe.org" type="cite">3
As CDO == EMF, you can easily adapt a generated RCP Client EMF
editor for CDO, but in practice you are likely better of to start
UI design from scratch, but you can re-use the concept of an
Editing domain and EMF.edit generated code, which is what I do.
(ItemProviders and Commands). </blockquote>
It's a major goal of CDO to better separate the functional from the
the technical design aspects/tasks. The only intrusive technical
aspect I can imagine of is large flat lists that should generally be
avoided in favour of a deeper object structure. IMHO this is a
useful rule even when only considering the usability of a graphical
application.<br>
<br>
<blockquote cite="mid:k5hqjk$f3l$1@xxxxxxxxe.org" type="cite">4
JFace databinding supports EMF, so JFace Databinding + CDO is a
great combination, you might want to watch loading large chunks of
data into your UI widgets (tables + trees), but there are ways to
limit the volumes. </blockquote>
I fully agree that EMF databinding is a totally cool thing. One
thing that tends to be problematic are remote deletions because the
databinding layer caches some strong references to objects that
might, all of a sudden, start to throw InvalidObjectExceptions or
ObjectNotFoundExceptions. You may appreciate that in CDO 4.2 we now
changed to:<br>
<br>
public static final CDOStaleReferencePolicy DEFAULT = PROXY;<br>
<br>
public static final CDOInvalidationPolicy DEFAULT = RELAXED;<br>
<br>
<br>
<blockquote cite="mid:k5hqjk$f3l$1@xxxxxxxxe.org" type="cite">5 I
you need to do something with DSL's (Develop a textual syntax,
which can interact with EMF/CDO models), this is also great with
xtext.
<br>
</blockquote>
Yes, because "CDO == EMF". But please keep in mind that editing DSL
instances stored *in* CDO with an Xtexteditor is problematic because
a text editor generally doesn't preserve the identities (e.g.
CDOIDs) of objects. That makes it hard to reconcile changes made in
a text editor back to CDO.<br>
<br>
<blockquote cite="mid:k5hqjk$f3l$1@xxxxxxxxe.org" type="cite">6
CDO performs well, you can tweak it, to fetch more or less chunks
of data for EReferences. If you don't like the behaviour you can
fire CDO Queries to get exactly what you want. Also unused objects
are garbage collected, so you can safely read a lot of data (As
long as you don't keep a reference). </blockquote>
Funnily this scalability originally came as a by-product of the
auditing functionality ;-)<br>
<br>
<blockquote cite="mid:k5hqjk$f3l$1@xxxxxxxxe.org" type="cite">7 I
am really fond that objects have a lifecycle, and all my object
have a unique CDO ID. I actually present the CDOID, in the status
line of the app. It's a great way to check what's going on. </blockquote>
And now you can even plug in your own CDOIDGenerator at the
client-side:<br>
<br>
public interface CDOIDGenerator<br>
{<br>
public static final CDOIDGenerator UUID = new CDOIDGenerator()<br>
{<br>
public CDOID generateCDOID(EObject object)<br>
{<br>
byte[] bytes = new byte[16];<br>
UUIDGenerator.DEFAULT.generate(bytes);<br>
return CDOIDUtil.createUUID(bytes);<br>
}<br>
<br>
public void reset()<br>
{<br>
// Do nothing<br>
}<br>
};<br>
<br>
/**<br>
* Generates a {@link CDOID}.<br>
* <br>
* @param object<br>
* the object to generate a new CDOID for if available,
<code>null</code> otherwise.<br>
*/<br>
public CDOID generateCDOID(EObject object);<br>
<br>
/**<br>
* Called at the end of a commit operation to give this ID
generator a chance to reset its sequence of IDs.<br>
*/<br>
public void reset();<br>
}<br>
<br>
<blockquote cite="mid:k5hqjk$f3l$1@xxxxxxxxe.org" type="cite">
8 Invalidations are great, basically when an object goes, remotely
dirty, other views are notified and can get the latest status of
an object. <br>
<br>
What I could do without in CDO
<br>
<br>
9. Revisions & referential integrity, I loved it at first, but
right now for the app. I have. it's a burden. The concept of
revisions adds a lot of requirements in CDO, I think CDO should
also have a simpler flat mode, without the revisions and checks on
integrity. It adds to the complexity of the CDO middleware and the
generated DB get's schema's. Some apps, don't need it or need it
partially. In my case, I would need revisions for some classes
only. </blockquote>
I suspect you don't refer to CDORevisions but to the auditing mode
in general? You know that it can be switched off. Granted, for the
DBStore in particular
<a class="moz-txt-link-freetext" href="https://bugs.eclipse.org/bugs/show_bug.cgi?id=351068">https://bugs.eclipse.org/bugs/show_bug.cgi?id=351068</a> is pending. I
really want to work on this soon.<br>
<br>
Partial auditing has been requested in the past. Conceptually I
don't like the idea because the framework couldn't guarantee the
logical consistency of the graph anymore. But I'm willing to
reconsider this when the DBStore gets its next design overhaul (not
scheduled, yet).<br>
<br>
What exact integrity checks are you referring to? Referential
integrity checks in the repository can be switched off (and they are
by default).<br>
<br>
<blockquote cite="mid:k5hqjk$f3l$1@xxxxxxxxe.org" type="cite">It
sometimes feels CDO is trying to mimic a Concurrent Version System
like SVN or CVS, but for many apps you really don't need that. <br>
</blockquote>
Yes, CDO tries to offer support in both worlds, the database
driven-like runtime applications and the more tool-like use cases
where design-time models need to be stored/managed in a repository.
You can imagine that this is sometimes hard but I think we've done a
pretty good job. Are there particular parts in CDO that are
problematic for you in this regard (i.e., not just unneeded)?<br>
<br>
BTW. an example of a cool new SCM-like feature is our new History
view support for repositories, branches or single objects:<br>
<br>
<img src="http://www.eclipse.org/forums/index.php?t=getfile&id=11911" alt=""><br>
<br>
<blockquote cite="mid:k5hqjk$f3l$1@xxxxxxxxe.org" type="cite">10.
In CDO there are CDOFolders and CDOResources. </blockquote>
Yes, and CDOTextResources and CDOBinaryResources, which are now
(almost) first class citizens of a CDO repository:<br>
<br>
<img src="http://www.eclipse.org/forums/index.php?t=getfile&id=11912" alt=""><br>
<br>
<blockquote cite="mid:k5hqjk$f3l$1@xxxxxxxxe.org" type="cite">Both
are also CDO objects, and stored in the DB. I went through great
length to find the best way to use them, like the the names to
give them, which is meta information you need to deal with in the
application. (Remember which name you used for which resource to
keep which data objects, in my case each eclass has its own
cdoresource). </blockquote>
Yes, that's the main value of Resources in general: They provide
well-known entry points into the (persistent) graph of objects.<br>
<br>
Apart from that they're an essential part of "CDO == EMF" (see point
1).<br>
<br>
<blockquote cite="mid:k5hqjk$f3l$1@xxxxxxxxe.org" type="cite">Right
now, I am not sure what the added value is of these, besides some
additional grouping of objects, I think, without them it could
keep CDO simpler and avoid additional DB data. </blockquote>
Please note that you absolutely don't need to use CDOResourceFolders
and CDOResources (except for a single one to contain all other
objects). The characteristics of a CDO model is the same when you
store all objects in a single resource.<br>
<br>
<blockquote cite="mid:k5hqjk$f3l$1@xxxxxxxxe.org" type="cite">(Note
that in point 3, I mentioned the EMF Editing domain, which has a
ResourceSet which can hold CDOResource objects. I use this, so
without CDO Resources, I wouldn't be able to use an editing
domain, so something else would be needed). <br>
</blockquote>
I think the generated editors also make heavy use of the assumption
that objects are contained by resources.<br>
<br>
<blockquote cite="mid:k5hqjk$f3l$1@xxxxxxxxe.org" type="cite">What
I wish for in CDO.
<br>
<br>
11. Model migrations. There are initiatives like COPE, which could
be applied with CDO, that would be great. So add a class in your
model, and let the new feature deal with the migration and transit
your data. </blockquote>
Fully agreed. If only someone would need it enough to open the
wallet and fund the development of this feature :P<br>
<br>
<blockquote cite="mid:k5hqjk$f3l$1@xxxxxxxxe.org" type="cite">12.
It's a hard learning curve, because most of the docs are outdated
or not written, so mea-culpa, we could do better. I wish for a
thriving community around a general purpose
smart-object-persistence system like CDO. <br>
</blockquote>
Yes! Technical writers in the world, here's a project that needs you
;-)<br>
<br>
<blockquote cite="mid:k5hqjk$f3l$1@xxxxxxxxe.org" type="cite">Finally.
Eike Stepper and others, have been great in supporting me on this
forum. Generally very quick and helpful!<br>
</blockquote>
Good docs would certainly be nicer but, while they're absent, good
online support is our attempt to compensate ;-)<br>
<br>
Cheers<br>
/Eike<br>
<br>
----<br>
<a class="moz-txt-link-freetext" href="http://www.esc-net.de">http://www.esc-net.de</a><br>
<a class="moz-txt-link-freetext" href="http://thegordian.blogspot.com">http://thegordian.blogspot.com</a><br>
<a class="moz-txt-link-freetext" href="http://twitter.com/eikestepper">http://twitter.com/eikestepper</a><br>
<br>
<br>
<br>
</body>
</html>
-
Attachment: bgchgghb.png
(Size: 83.23KB, Downloaded 99 times) -
Attachment: edjjaeef.png
(Size: 16.76KB, Downloaded 122 times)
Cheers
/Eike
----
http://www.esc-net.de
http://thegordian.blogspot.com
http://twitter.com/eikestepper
|
|
|
| Re: Understanding CDO [message #946484 is a reply to message #945941] |
Tue, 16 October 2012 06:30 |
|
<html>
<head>
<meta content="text/html; charset=UTF-8" http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
Hi Christophe,<br>
<br>
Thank you very much for your detailed experience report. I like it
lot ;-)<br>
<br>
More comments below...<br>
<br>
<br>
<div class="moz-cite-prefix">Am 15.10.2012 22:10, schrieb Christophe
Bouhier:<br>
</div>
<blockquote cite="mid:k5hqjk$f3l$1@xxxxxxxxe.org" type="cite">Hello
Mauro, <br>
for the last 2 years, I have been working on a client/server
application using CDO. Depending on your needs, CDO could be the
right fit. <br>
What I like (a lot). <br>
1 CDO == EMF, so you can model data first in .xsd or directly in
.ecore, and you can tell CDO to use your generated packages, which
will build the DB schema. </blockquote>
EMF compliance is very important to us and we're proud to support
most of EMF's features. Among the few exceptions are:<br>
<br>
a) Feature maps are hard to deal with in RDBs<br>
<br>
b) Because CDOResources are EObjects (see point 10) a small number
of other frameworks may run into trouble when trying to find out the
concrete type of a Notifier because the result depends on a
particular order of instanceof checks (check Resources first).<br>
<br>
c) With remote change notifications enabled, i.e.,
view.options().addChangeSubscriptionPolicy(...), your own Adapters
often need to distinguish between local or remote changes. An
instanceof CDODeltaNotification does the trick.<br>
<br>
d) Some IDE applications (and some poorly designed frameworks such
as GMF) heavily rely on IResources which are probably impossible to
simulate for CDOResources. For example it's hard or impossible to
present problem markers for validation problems in CDOResources
because IMarkers are associated with IResources. This is not a CDO
problem but a platform/IMarker problem that other
non-"platform:resource" Resources share in common.<br>
<br>
<blockquote cite="mid:k5hqjk$f3l$1@xxxxxxxxe.org" type="cite">2
On the CDO Store, you can choose from the DBStore, which supports
various DB's, I have worked with MySQL and Postgres. With
Hibernate store, there is an additional ORM layer, which works
with tons of other DB's supported by Hibernate. </blockquote>
And there's support for some other backend types, such as DB4O,
MongoDB or Objectivity/DB. I've recently developed a
RandomAccessFile based journaling store, named LissomeStore. It
still uses an RDB for a small and fixed number of indexes into the
random access file(s). For commits it uses a journal file and
adjusts the index tables asynchronously. The performance of large
commits can typically be increased by factor 600 in my tests.<br>
<br>
IMHO the great value of the IStore design is that it becomes a snap
to *change* the backend choice at any time without much impact on
the application (except you're making heavy use of backend-specifc
IQueryHandlers such as SQL or HQL).<br>
<br>
<blockquote cite="mid:k5hqjk$f3l$1@xxxxxxxxe.org" type="cite">3
As CDO == EMF, you can easily adapt a generated RCP Client EMF
editor for CDO, but in practice you are likely better of to start
UI design from scratch, but you can re-use the concept of an
Editing domain and EMF.edit generated code, which is what I do.
(ItemProviders and Commands). </blockquote>
It's a major goal of CDO to better separate the functional from the
the technical design aspects/tasks. The only intrusive technical
aspect I can imagine of is large flat lists that should generally be
avoided in favour of a deeper object structure. IMHO this is a
useful rule even when only considering the usability of a graphical
application.<br>
<br>
<blockquote cite="mid:k5hqjk$f3l$1@xxxxxxxxe.org" type="cite">4
JFace databinding supports EMF, so JFace Databinding + CDO is a
great combination, you might want to watch loading large chunks of
data into your UI widgets (tables + trees), but there are ways to
limit the volumes. </blockquote>
I fully agree that EMF databinding is a totally cool thing. One
thing that tends to be problematic are remote deletions because the
databinding layer caches some strong references to objects that
might, all of a sudden, start to throw InvalidObjectExceptions or
ObjectNotFoundExceptions. You may appreciate that in CDO 4.2 we now
changed to:<br>
<br>
public static final CDOStaleReferencePolicy DEFAULT = PROXY;<br>
<br>
public static final CDOInvalidationPolicy DEFAULT = RELAXED;<br>
<br>
<br>
<blockquote cite="mid:k5hqjk$f3l$1@xxxxxxxxe.org" type="cite">5 I
you need to do something with DSL's (Develop a textual syntax,
which can interact with EMF/CDO models), this is also great with
xtext.
<br>
</blockquote>
Yes, because "CDO == EMF". But please keep in mind that editing DSL
instances stored *in* CDO with an Xtexteditor is problematic because
a text editor generally doesn't preserve the identities (e.g.
CDOIDs) of objects. That makes it hard to reconcile changes made in
a text editor back to CDO.<br>
<br>
<blockquote cite="mid:k5hqjk$f3l$1@xxxxxxxxe.org" type="cite">6
CDO performs well, you can tweak it, to fetch more or less chunks
of data for EReferences. If you don't like the behaviour you can
fire CDO Queries to get exactly what you want. Also unused objects
are garbage collected, so you can safely read a lot of data (As
long as you don't keep a reference). </blockquote>
Funnily this scalability originally came as a by-product of the
auditing functionality ;-)<br>
<br>
<blockquote cite="mid:k5hqjk$f3l$1@xxxxxxxxe.org" type="cite">7 I
am really fond that objects have a lifecycle, and all my object
have a unique CDO ID. I actually present the CDOID, in the status
line of the app. It's a great way to check what's going on. </blockquote>
And now you can even plug in your own CDOIDGenerator at the
client-side:<br>
<br>
public interface CDOIDGenerator<br>
{<br>
public static final CDOIDGenerator UUID = new CDOIDGenerator()<br>
{<br>
public CDOID generateCDOID(EObject object)<br>
{<br>
byte[] bytes = new byte[16];<br>
UUIDGenerator.DEFAULT.generate(bytes);<br>
return CDOIDUtil.createUUID(bytes);<br>
}<br>
<br>
public void reset()<br>
{<br>
// Do nothing<br>
}<br>
};<br>
<br>
/**<br>
* Generates a {@link CDOID}.<br>
* <br>
* @param object<br>
* the object to generate a new CDOID for if available,
<code>null</code> otherwise.<br>
*/<br>
public CDOID generateCDOID(EObject object);<br>
<br>
/**<br>
* Called at the end of a commit operation to give this ID
generator a chance to reset its sequence of IDs.<br>
*/<br>
public void reset();<br>
}<br>
<br>
<blockquote cite="mid:k5hqjk$f3l$1@xxxxxxxxe.org" type="cite">
8 Invalidations are great, basically when an object goes, remotely
dirty, other views are notified and can get the latest status of
an object. <br>
<br>
What I could do without in CDO
<br>
<br>
9. Revisions & referential integrity, I loved it at first, but
right now for the app. I have. it's a burden. The concept of
revisions adds a lot of requirements in CDO, I think CDO should
also have a simpler flat mode, without the revisions and checks on
integrity. It adds to the complexity of the CDO middleware and the
generated DB get's schema's. Some apps, don't need it or need it
partially. In my case, I would need revisions for some classes
only. </blockquote>
I suspect you don't refer to CDORevisions but to the auditing mode
in general? You know that it can be switched off. Granted, for the
DBStore in particular
<a class="moz-txt-link-freetext" href="https://bugs.eclipse.org/bugs/show_bug.cgi?id=351068">https://bugs.eclipse.org/bugs/show_bug.cgi?id=351068</a> is pending. I
really want to work on this soon.<br>
<br>
Partial auditing has been requested in the past. Conceptually I
don't like the idea because the framework couldn't guarantee the
logical consistency of the graph anymore. But I'm willing to
reconsider this when the DBStore gets its next design overhaul (not
scheduled, yet).<br>
<br>
What exact integrity checks are you referring to? Referential
integrity checks in the repository can be switched off (and they are
by default).<br>
<br>
<blockquote cite="mid:k5hqjk$f3l$1@xxxxxxxxe.org" type="cite">It
sometimes feels CDO is trying to mimic a Concurrent Version System
like SVN or CVS, but for many apps you really don't need that. <br>
</blockquote>
Yes, CDO tries to offer support in both worlds, the database
driven-like runtime applications and the more tool-like use cases
where design-time models need to be stored/managed in a repository.
You can imagine that this is sometimes hard but I think we've done a
pretty good job. Are there particular parts in CDO that are
problematic for you in this regard (i.e., not just unneeded)?<br>
<br>
BTW. an example of a cool new SCM-like feature is our new History
view support for repositories, branches or single objects:<br>
<br>
<img src="http://www.eclipse.org/forums/index.php?t=getfile&id=11913" alt=""><br>
<br>
<blockquote cite="mid:k5hqjk$f3l$1@xxxxxxxxe.org" type="cite">10.
In CDO there are CDOFolders and CDOResources. </blockquote>
Yes, and CDOTextResources and CDOBinaryResources, which are now
(almost) first class citizens of a CDO repository:<br>
<br>
<img src="http://www.eclipse.org/forums/index.php?t=getfile&id=11914" alt=""><br>
<br>
<blockquote cite="mid:k5hqjk$f3l$1@xxxxxxxxe.org" type="cite">Both
are also CDO objects, and stored in the DB. I went through great
length to find the best way to use them, like the the names to
give them, which is meta information you need to deal with in the
application. (Remember which name you used for which resource to
keep which data objects, in my case each eclass has its own
cdoresource). </blockquote>
Yes, that's the main value of Resources in general: They provide
well-known entry points into the (persistent) graph of objects.<br>
<br>
Apart from that they're an essential part of "CDO == EMF" (see point
1).<br>
<br>
<blockquote cite="mid:k5hqjk$f3l$1@xxxxxxxxe.org" type="cite">Right
now, I am not sure what the added value is of these, besides some
additional grouping of objects, I think, without them it could
keep CDO simpler and avoid additional DB data. </blockquote>
Please note that you absolutely don't need to use CDOResourceFolders
and CDOResources (except for a single one to contain all other
objects). The characteristics of a CDO model is the same when you
store all objects in a single resource.<br>
<br>
<blockquote cite="mid:k5hqjk$f3l$1@xxxxxxxxe.org" type="cite">(Note
that in point 3, I mentioned the EMF Editing domain, which has a
ResourceSet which can hold CDOResource objects. I use this, so
without CDO Resources, I wouldn't be able to use an editing
domain, so something else would be needed). <br>
</blockquote>
I think the generated editors also make heavy use of the assumption
that objects are contained by resources.<br>
<br>
<blockquote cite="mid:k5hqjk$f3l$1@xxxxxxxxe.org" type="cite">What
I wish for in CDO.
<br>
<br>
11. Model migrations. There are initiatives like COPE, which could
be applied with CDO, that would be great. So add a class in your
model, and let the new feature deal with the migration and transit
your data. </blockquote>
Fully agreed. If only someone would need it enough to open the
wallet and fund the development of this feature :P<br>
<br>
<blockquote cite="mid:k5hqjk$f3l$1@xxxxxxxxe.org" type="cite">12.
It's a hard learning curve, because most of the docs are outdated
or not written, so mea-culpa, we could do better. I wish for a
thriving community around a general purpose
smart-object-persistence system like CDO. <br>
</blockquote>
Yes! Technical writers in the world, here's a project that needs you
;-)<br>
<br>
<blockquote cite="mid:k5hqjk$f3l$1@xxxxxxxxe.org" type="cite">Finally.
Eike Stepper and others, have been great in supporting me on this
forum. Generally very quick and helpful!<br>
</blockquote>
Good docs would certainly be nicer but, while they're absent, good
online support is our attempt to compensate ;-)<br>
<br>
Cheers<br>
/Eike<br>
<br>
----<br>
<a class="moz-txt-link-freetext" href="http://www.esc-net.de">http://www.esc-net.de</a><br>
<a class="moz-txt-link-freetext" href="http://thegordian.blogspot.com">http://thegordian.blogspot.com</a><br>
<a class="moz-txt-link-freetext" href="http://twitter.com/eikestepper">http://twitter.com/eikestepper</a><br>
<br>
<br>
<br>
</body>
</html>
-
Attachment: bgchgghb.png
(Size: 83.23KB, Downloaded 120 times) -
Attachment: edjjaeef.png
(Size: 16.76KB, Downloaded 111 times)
Cheers
/Eike
----
http://www.esc-net.de
http://thegordian.blogspot.com
http://twitter.com/eikestepper
|
|
|
| Re: Understanding CDO [message #946492 is a reply to message #945941] |
Tue, 16 October 2012 06:30 |
|
<html>
<head>
<meta content="text/html; charset=UTF-8" http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
Hi Christophe,<br>
<br>
Thank you very much for your detailed experience report. I like it
lot ;-)<br>
<br>
More comments below...<br>
<br>
<br>
<div class="moz-cite-prefix">Am 15.10.2012 22:10, schrieb Christophe
Bouhier:<br>
</div>
<blockquote cite="mid:k5hqjk$f3l$1@xxxxxxxxe.org" type="cite">Hello
Mauro, <br>
for the last 2 years, I have been working on a client/server
application using CDO. Depending on your needs, CDO could be the
right fit. <br>
What I like (a lot). <br>
1 CDO == EMF, so you can model data first in .xsd or directly in
.ecore, and you can tell CDO to use your generated packages, which
will build the DB schema. </blockquote>
EMF compliance is very important to us and we're proud to support
most of EMF's features. Among the few exceptions are:<br>
<br>
a) Feature maps are hard to deal with in RDBs<br>
<br>
b) Because CDOResources are EObjects (see point 10) a small number
of other frameworks may run into trouble when trying to find out the
concrete type of a Notifier because the result depends on a
particular order of instanceof checks (check Resources first).<br>
<br>
c) With remote change notifications enabled, i.e.,
view.options().addChangeSubscriptionPolicy(...), your own Adapters
often need to distinguish between local or remote changes. An
instanceof CDODeltaNotification does the trick.<br>
<br>
d) Some IDE applications (and some poorly designed frameworks such
as GMF) heavily rely on IResources which are probably impossible to
simulate for CDOResources. For example it's hard or impossible to
present problem markers for validation problems in CDOResources
because IMarkers are associated with IResources. This is not a CDO
problem but a platform/IMarker problem that other
non-"platform:resource" Resources share in common.<br>
<br>
<blockquote cite="mid:k5hqjk$f3l$1@xxxxxxxxe.org" type="cite">2
On the CDO Store, you can choose from the DBStore, which supports
various DB's, I have worked with MySQL and Postgres. With
Hibernate store, there is an additional ORM layer, which works
with tons of other DB's supported by Hibernate. </blockquote>
And there's support for some other backend types, such as DB4O,
MongoDB or Objectivity/DB. I've recently developed a
RandomAccessFile based journaling store, named LissomeStore. It
still uses an RDB for a small and fixed number of indexes into the
random access file(s). For commits it uses a journal file and
adjusts the index tables asynchronously. The performance of large
commits can typically be increased by factor 600 in my tests.<br>
<br>
IMHO the great value of the IStore design is that it becomes a snap
to *change* the backend choice at any time without much impact on
the application (except you're making heavy use of backend-specifc
IQueryHandlers such as SQL or HQL).<br>
<br>
<blockquote cite="mid:k5hqjk$f3l$1@xxxxxxxxe.org" type="cite">3
As CDO == EMF, you can easily adapt a generated RCP Client EMF
editor for CDO, but in practice you are likely better of to start
UI design from scratch, but you can re-use the concept of an
Editing domain and EMF.edit generated code, which is what I do.
(ItemProviders and Commands). </blockquote>
It's a major goal of CDO to better separate the functional from the
the technical design aspects/tasks. The only intrusive technical
aspect I can imagine of is large flat lists that should generally be
avoided in favour of a deeper object structure. IMHO this is a
useful rule even when only considering the usability of a graphical
application.<br>
<br>
<blockquote cite="mid:k5hqjk$f3l$1@xxxxxxxxe.org" type="cite">4
JFace databinding supports EMF, so JFace Databinding + CDO is a
great combination, you might want to watch loading large chunks of
data into your UI widgets (tables + trees), but there are ways to
limit the volumes. </blockquote>
I fully agree that EMF databinding is a totally cool thing. One
thing that tends to be problematic are remote deletions because the
databinding layer caches some strong references to objects that
might, all of a sudden, start to throw InvalidObjectExceptions or
ObjectNotFoundExceptions. You may appreciate that in CDO 4.2 we now
changed to:<br>
<br>
public static final CDOStaleReferencePolicy DEFAULT = PROXY;<br>
<br>
public static final CDOInvalidationPolicy DEFAULT = RELAXED;<br>
<br>
<br>
<blockquote cite="mid:k5hqjk$f3l$1@xxxxxxxxe.org" type="cite">5 I
you need to do something with DSL's (Develop a textual syntax,
which can interact with EMF/CDO models), this is also great with
xtext.
<br>
</blockquote>
Yes, because "CDO == EMF". But please keep in mind that editing DSL
instances stored *in* CDO with an Xtexteditor is problematic because
a text editor generally doesn't preserve the identities (e.g.
CDOIDs) of objects. That makes it hard to reconcile changes made in
a text editor back to CDO.<br>
<br>
<blockquote cite="mid:k5hqjk$f3l$1@xxxxxxxxe.org" type="cite">6
CDO performs well, you can tweak it, to fetch more or less chunks
of data for EReferences. If you don't like the behaviour you can
fire CDO Queries to get exactly what you want. Also unused objects
are garbage collected, so you can safely read a lot of data (As
long as you don't keep a reference). </blockquote>
Funnily this scalability originally came as a by-product of the
auditing functionality ;-)<br>
<br>
<blockquote cite="mid:k5hqjk$f3l$1@xxxxxxxxe.org" type="cite">7 I
am really fond that objects have a lifecycle, and all my object
have a unique CDO ID. I actually present the CDOID, in the status
line of the app. It's a great way to check what's going on. </blockquote>
And now you can even plug in your own CDOIDGenerator at the
client-side:<br>
<br>
public interface CDOIDGenerator<br>
{<br>
public static final CDOIDGenerator UUID = new CDOIDGenerator()<br>
{<br>
public CDOID generateCDOID(EObject object)<br>
{<br>
byte[] bytes = new byte[16];<br>
UUIDGenerator.DEFAULT.generate(bytes);<br>
return CDOIDUtil.createUUID(bytes);<br>
}<br>
<br>
public void reset()<br>
{<br>
// Do nothing<br>
}<br>
};<br>
<br>
/**<br>
* Generates a {@link CDOID}.<br>
* <br>
* @param object<br>
* the object to generate a new CDOID for if available,
<code>null</code> otherwise.<br>
*/<br>
public CDOID generateCDOID(EObject object);<br>
<br>
/**<br>
* Called at the end of a commit operation to give this ID
generator a chance to reset its sequence of IDs.<br>
*/<br>
public void reset();<br>
}<br>
<br>
<blockquote cite="mid:k5hqjk$f3l$1@xxxxxxxxe.org" type="cite">
8 Invalidations are great, basically when an object goes, remotely
dirty, other views are notified and can get the latest status of
an object. <br>
<br>
What I could do without in CDO
<br>
<br>
9. Revisions & referential integrity, I loved it at first, but
right now for the app. I have. it's a burden. The concept of
revisions adds a lot of requirements in CDO, I think CDO should
also have a simpler flat mode, without the revisions and checks on
integrity. It adds to the complexity of the CDO middleware and the
generated DB get's schema's. Some apps, don't need it or need it
partially. In my case, I would need revisions for some classes
only. </blockquote>
I suspect you don't refer to CDORevisions but to the auditing mode
in general? You know that it can be switched off. Granted, for the
DBStore in particular
<a class="moz-txt-link-freetext" href="https://bugs.eclipse.org/bugs/show_bug.cgi?id=351068">https://bugs.eclipse.org/bugs/show_bug.cgi?id=351068</a> is pending. I
really want to work on this soon.<br>
<br>
Partial auditing has been requested in the past. Conceptually I
don't like the idea because the framework couldn't guarantee the
logical consistency of the graph anymore. But I'm willing to
reconsider this when the DBStore gets its next design overhaul (not
scheduled, yet).<br>
<br>
What exact integrity checks are you referring to? Referential
integrity checks in the repository can be switched off (and they are
by default).<br>
<br>
<blockquote cite="mid:k5hqjk$f3l$1@xxxxxxxxe.org" type="cite">It
sometimes feels CDO is trying to mimic a Concurrent Version System
like SVN or CVS, but for many apps you really don't need that. <br>
</blockquote>
Yes, CDO tries to offer support in both worlds, the database
driven-like runtime applications and the more tool-like use cases
where design-time models need to be stored/managed in a repository.
You can imagine that this is sometimes hard but I think we've done a
pretty good job. Are there particular parts in CDO that are
problematic for you in this regard (i.e., not just unneeded)?<br>
<br>
BTW. an example of a cool new SCM-like feature is our new History
view support for repositories, branches or single objects:<br>
<br>
<img src="http://www.eclipse.org/forums/index.php?t=getfile&id=11915" alt=""><br>
<br>
<blockquote cite="mid:k5hqjk$f3l$1@xxxxxxxxe.org" type="cite">10.
In CDO there are CDOFolders and CDOResources. </blockquote>
Yes, and CDOTextResources and CDOBinaryResources, which are now
(almost) first class citizens of a CDO repository:<br>
<br>
<img src="http://www.eclipse.org/forums/index.php?t=getfile&id=11916" alt=""><br>
<br>
<blockquote cite="mid:k5hqjk$f3l$1@xxxxxxxxe.org" type="cite">Both
are also CDO objects, and stored in the DB. I went through great
length to find the best way to use them, like the the names to
give them, which is meta information you need to deal with in the
application. (Remember which name you used for which resource to
keep which data objects, in my case each eclass has its own
cdoresource). </blockquote>
Yes, that's the main value of Resources in general: They provide
well-known entry points into the (persistent) graph of objects.<br>
<br>
Apart from that they're an essential part of "CDO == EMF" (see point
1).<br>
<br>
<blockquote cite="mid:k5hqjk$f3l$1@xxxxxxxxe.org" type="cite">Right
now, I am not sure what the added value is of these, besides some
additional grouping of objects, I think, without them it could
keep CDO simpler and avoid additional DB data. </blockquote>
Please note that you absolutely don't need to use CDOResourceFolders
and CDOResources (except for a single one to contain all other
objects). The characteristics of a CDO model is the same when you
store all objects in a single resource.<br>
<br>
<blockquote cite="mid:k5hqjk$f3l$1@xxxxxxxxe.org" type="cite">(Note
that in point 3, I mentioned the EMF Editing domain, which has a
ResourceSet which can hold CDOResource objects. I use this, so
without CDO Resources, I wouldn't be able to use an editing
domain, so something else would be needed). <br>
</blockquote>
I think the generated editors also make heavy use of the assumption
that objects are contained by resources.<br>
<br>
<blockquote cite="mid:k5hqjk$f3l$1@xxxxxxxxe.org" type="cite">What
I wish for in CDO.
<br>
<br>
11. Model migrations. There are initiatives like COPE, which could
be applied with CDO, that would be great. So add a class in your
model, and let the new feature deal with the migration and transit
your data. </blockquote>
Fully agreed. If only someone would need it enough to open the
wallet and fund the development of this feature :P<br>
<br>
<blockquote cite="mid:k5hqjk$f3l$1@xxxxxxxxe.org" type="cite">12.
It's a hard learning curve, because most of the docs are outdated
or not written, so mea-culpa, we could do better. I wish for a
thriving community around a general purpose
smart-object-persistence system like CDO. <br>
</blockquote>
Yes! Technical writers in the world, here's a project that needs you
;-)<br>
<br>
<blockquote cite="mid:k5hqjk$f3l$1@xxxxxxxxe.org" type="cite">Finally.
Eike Stepper and others, have been great in supporting me on this
forum. Generally very quick and helpful!<br>
</blockquote>
Good docs would certainly be nicer but, while they're absent, good
online support is our attempt to compensate ;-)<br>
<br>
Cheers<br>
/Eike<br>
<br>
----<br>
<a class="moz-txt-link-freetext" href="http://www.esc-net.de">http://www.esc-net.de</a><br>
<a class="moz-txt-link-freetext" href="http://thegordian.blogspot.com">http://thegordian.blogspot.com</a><br>
<a class="moz-txt-link-freetext" href="http://twitter.com/eikestepper">http://twitter.com/eikestepper</a><br>
<br>
<br>
<br>
</body>
</html>
-
Attachment: bgchgghb.png
(Size: 83.23KB, Downloaded 119 times) -
Attachment: edjjaeef.png
(Size: 16.76KB, Downloaded 115 times)
Cheers
/Eike
----
http://www.esc-net.de
http://thegordian.blogspot.com
http://twitter.com/eikestepper
|
|
|
| Re: Understanding CDO [message #946498 is a reply to message #945941] |
Tue, 16 October 2012 06:30 |
|
<html>
<head>
<meta content="text/html; charset=UTF-8" http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
Hi Christophe,<br>
<br>
Thank you very much for your detailed experience report. I like it
lot ;-)<br>
<br>
More comments below...<br>
<br>
<br>
<div class="moz-cite-prefix">Am 15.10.2012 22:10, schrieb Christophe
Bouhier:<br>
</div>
<blockquote cite="mid:k5hqjk$f3l$1@xxxxxxxxe.org" type="cite">Hello
Mauro, <br>
for the last 2 years, I have been working on a client/server
application using CDO. Depending on your needs, CDO could be the
right fit. <br>
What I like (a lot). <br>
1 CDO == EMF, so you can model data first in .xsd or directly in
.ecore, and you can tell CDO to use your generated packages, which
will build the DB schema. </blockquote>
EMF compliance is very important to us and we're proud to support
most of EMF's features. Among the few exceptions are:<br>
<br>
a) Feature maps are hard to deal with in RDBs<br>
<br>
b) Because CDOResources are EObjects (see point 10) a small number
of other frameworks may run into trouble when trying to find out the
concrete type of a Notifier because the result depends on a
particular order of instanceof checks (check Resources first).<br>
<br>
c) With remote change notifications enabled, i.e.,
view.options().addChangeSubscriptionPolicy(...), your own Adapters
often need to distinguish between local or remote changes. An
instanceof CDODeltaNotification does the trick.<br>
<br>
d) Some IDE applications (and some poorly designed frameworks such
as GMF) heavily rely on IResources which are probably impossible to
simulate for CDOResources. For example it's hard or impossible to
present problem markers for validation problems in CDOResources
because IMarkers are associated with IResources. This is not a CDO
problem but a platform/IMarker problem that other
non-"platform:resource" Resources share in common.<br>
<br>
<blockquote cite="mid:k5hqjk$f3l$1@xxxxxxxxe.org" type="cite">2
On the CDO Store, you can choose from the DBStore, which supports
various DB's, I have worked with MySQL and Postgres. With
Hibernate store, there is an additional ORM layer, which works
with tons of other DB's supported by Hibernate. </blockquote>
And there's support for some other backend types, such as DB4O,
MongoDB or Objectivity/DB. I've recently developed a
RandomAccessFile based journaling store, named LissomeStore. It
still uses an RDB for a small and fixed number of indexes into the
random access file(s). For commits it uses a journal file and
adjusts the index tables asynchronously. The performance of large
commits can typically be increased by factor 600 in my tests.<br>
<br>
IMHO the great value of the IStore design is that it becomes a snap
to *change* the backend choice at any time without much impact on
the application (except you're making heavy use of backend-specifc
IQueryHandlers such as SQL or HQL).<br>
<br>
<blockquote cite="mid:k5hqjk$f3l$1@xxxxxxxxe.org" type="cite">3
As CDO == EMF, you can easily adapt a generated RCP Client EMF
editor for CDO, but in practice you are likely better of to start
UI design from scratch, but you can re-use the concept of an
Editing domain and EMF.edit generated code, which is what I do.
(ItemProviders and Commands). </blockquote>
It's a major goal of CDO to better separate the functional from the
the technical design aspects/tasks. The only intrusive technical
aspect I can imagine of is large flat lists that should generally be
avoided in favour of a deeper object structure. IMHO this is a
useful rule even when only considering the usability of a graphical
application.<br>
<br>
<blockquote cite="mid:k5hqjk$f3l$1@xxxxxxxxe.org" type="cite">4
JFace databinding supports EMF, so JFace Databinding + CDO is a
great combination, you might want to watch loading large chunks of
data into your UI widgets (tables + trees), but there are ways to
limit the volumes. </blockquote>
I fully agree that EMF databinding is a totally cool thing. One
thing that tends to be problematic are remote deletions because the
databinding layer caches some strong references to objects that
might, all of a sudden, start to throw InvalidObjectExceptions or
ObjectNotFoundExceptions. You may appreciate that in CDO 4.2 we now
changed to:<br>
<br>
public static final CDOStaleReferencePolicy DEFAULT = PROXY;<br>
<br>
public static final CDOInvalidationPolicy DEFAULT = RELAXED;<br>
<br>
<br>
<blockquote cite="mid:k5hqjk$f3l$1@xxxxxxxxe.org" type="cite">5 I
you need to do something with DSL's (Develop a textual syntax,
which can interact with EMF/CDO models), this is also great with
xtext.
<br>
</blockquote>
Yes, because "CDO == EMF". But please keep in mind that editing DSL
instances stored *in* CDO with an Xtexteditor is problematic because
a text editor generally doesn't preserve the identities (e.g.
CDOIDs) of objects. That makes it hard to reconcile changes made in
a text editor back to CDO.<br>
<br>
<blockquote cite="mid:k5hqjk$f3l$1@xxxxxxxxe.org" type="cite">6
CDO performs well, you can tweak it, to fetch more or less chunks
of data for EReferences. If you don't like the behaviour you can
fire CDO Queries to get exactly what you want. Also unused objects
are garbage collected, so you can safely read a lot of data (As
long as you don't keep a reference). </blockquote>
Funnily this scalability originally came as a by-product of the
auditing functionality ;-)<br>
<br>
<blockquote cite="mid:k5hqjk$f3l$1@xxxxxxxxe.org" type="cite">7 I
am really fond that objects have a lifecycle, and all my object
have a unique CDO ID. I actually present the CDOID, in the status
line of the app. It's a great way to check what's going on. </blockquote>
And now you can even plug in your own CDOIDGenerator at the
client-side:<br>
<br>
public interface CDOIDGenerator<br>
{<br>
public static final CDOIDGenerator UUID = new CDOIDGenerator()<br>
{<br>
public CDOID generateCDOID(EObject object)<br>
{<br>
byte[] bytes = new byte[16];<br>
UUIDGenerator.DEFAULT.generate(bytes);<br>
return CDOIDUtil.createUUID(bytes);<br>
}<br>
<br>
public void reset()<br>
{<br>
// Do nothing<br>
}<br>
};<br>
<br>
/**<br>
* Generates a {@link CDOID}.<br>
* <br>
* @param object<br>
* the object to generate a new CDOID for if available,
<code>null</code> otherwise.<br>
*/<br>
public CDOID generateCDOID(EObject object);<br>
<br>
/**<br>
* Called at the end of a commit operation to give this ID
generator a chance to reset its sequence of IDs.<br>
*/<br>
public void reset();<br>
}<br>
<br>
<blockquote cite="mid:k5hqjk$f3l$1@xxxxxxxxe.org" type="cite">
8 Invalidations are great, basically when an object goes, remotely
dirty, other views are notified and can get the latest status of
an object. <br>
<br>
What I could do without in CDO
<br>
<br>
9. Revisions & referential integrity, I loved it at first, but
right now for the app. I have. it's a burden. The concept of
revisions adds a lot of requirements in CDO, I think CDO should
also have a simpler flat mode, without the revisions and checks on
integrity. It adds to the complexity of the CDO middleware and the
generated DB get's schema's. Some apps, don't need it or need it
partially. In my case, I would need revisions for some classes
only. </blockquote>
I suspect you don't refer to CDORevisions but to the auditing mode
in general? You know that it can be switched off. Granted, for the
DBStore in particular
<a class="moz-txt-link-freetext" href="https://bugs.eclipse.org/bugs/show_bug.cgi?id=351068">https://bugs.eclipse.org/bugs/show_bug.cgi?id=351068</a> is pending. I
really want to work on this soon.<br>
<br>
Partial auditing has been requested in the past. Conceptually I
don't like the idea because the framework couldn't guarantee the
logical consistency of the graph anymore. But I'm willing to
reconsider this when the DBStore gets its next design overhaul (not
scheduled, yet).<br>
<br>
What exact integrity checks are you referring to? Referential
integrity checks in the repository can be switched off (and they are
by default).<br>
<br>
<blockquote cite="mid:k5hqjk$f3l$1@xxxxxxxxe.org" type="cite">It
sometimes feels CDO is trying to mimic a Concurrent Version System
like SVN or CVS, but for many apps you really don't need that. <br>
</blockquote>
Yes, CDO tries to offer support in both worlds, the database
driven-like runtime applications and the more tool-like use cases
where design-time models need to be stored/managed in a repository.
You can imagine that this is sometimes hard but I think we've done a
pretty good job. Are there particular parts in CDO that are
problematic for you in this regard (i.e., not just unneeded)?<br>
<br>
BTW. an example of a cool new SCM-like feature is our new History
view support for repositories, branches or single objects:<br>
<br>
<img src="http://www.eclipse.org/forums/index.php?t=getfile&id=11917" alt=""><br>
<br>
<blockquote cite="mid:k5hqjk$f3l$1@xxxxxxxxe.org" type="cite">10.
In CDO there are CDOFolders and CDOResources. </blockquote>
Yes, and CDOTextResources and CDOBinaryResources, which are now
(almost) first class citizens of a CDO repository:<br>
<br>
<img src="http://www.eclipse.org/forums/index.php?t=getfile&id=11918" alt=""><br>
<br>
<blockquote cite="mid:k5hqjk$f3l$1@xxxxxxxxe.org" type="cite">Both
are also CDO objects, and stored in the DB. I went through great
length to find the best way to use them, like the the names to
give them, which is meta information you need to deal with in the
application. (Remember which name you used for which resource to
keep which data objects, in my case each eclass has its own
cdoresource). </blockquote>
Yes, that's the main value of Resources in general: They provide
well-known entry points into the (persistent) graph of objects.<br>
<br>
Apart from that they're an essential part of "CDO == EMF" (see point
1).<br>
<br>
<blockquote cite="mid:k5hqjk$f3l$1@xxxxxxxxe.org" type="cite">Right
now, I am not sure what the added value is of these, besides some
additional grouping of objects, I think, without them it could
keep CDO simpler and avoid additional DB data. </blockquote>
Please note that you absolutely don't need to use CDOResourceFolders
and CDOResources (except for a single one to contain all other
objects). The characteristics of a CDO model is the same when you
store all objects in a single resource.<br>
<br>
<blockquote cite="mid:k5hqjk$f3l$1@xxxxxxxxe.org" type="cite">(Note
that in point 3, I mentioned the EMF Editing domain, which has a
ResourceSet which can hold CDOResource objects. I use this, so
without CDO Resources, I wouldn't be able to use an editing
domain, so something else would be needed). <br>
</blockquote>
I think the generated editors also make heavy use of the assumption
that objects are contained by resources.<br>
<br>
<blockquote cite="mid:k5hqjk$f3l$1@xxxxxxxxe.org" type="cite">What
I wish for in CDO.
<br>
<br>
11. Model migrations. There are initiatives like COPE, which could
be applied with CDO, that would be great. So add a class in your
model, and let the new feature deal with the migration and transit
your data. </blockquote>
Fully agreed. If only someone would need it enough to open the
wallet and fund the development of this feature :P<br>
<br>
<blockquote cite="mid:k5hqjk$f3l$1@xxxxxxxxe.org" type="cite">12.
It's a hard learning curve, because most of the docs are outdated
or not written, so mea-culpa, we could do better. I wish for a
thriving community around a general purpose
smart-object-persistence system like CDO. <br>
</blockquote>
Yes! Technical writers in the world, here's a project that needs you
;-)<br>
<br>
<blockquote cite="mid:k5hqjk$f3l$1@xxxxxxxxe.org" type="cite">Finally.
Eike Stepper and others, have been great in supporting me on this
forum. Generally very quick and helpful!<br>
</blockquote>
Good docs would certainly be nicer but, while they're absent, good
online support is our attempt to compensate ;-)<br>
<br>
Cheers<br>
/Eike<br>
<br>
----<br>
<a class="moz-txt-link-freetext" href="http://www.esc-net.de">http://www.esc-net.de</a><br>
<a class="moz-txt-link-freetext" href="http://thegordian.blogspot.com">http://thegordian.blogspot.com</a><br>
<a class="moz-txt-link-freetext" href="http://twitter.com/eikestepper">http://twitter.com/eikestepper</a><br>
<br>
<br>
<br>
</body>
</html>
-
Attachment: bgchgghb.png
(Size: 83.23KB, Downloaded 123 times) -
Attachment: edjjaeef.png
(Size: 16.76KB, Downloaded 121 times)
Cheers
/Eike
----
http://www.esc-net.de
http://thegordian.blogspot.com
http://twitter.com/eikestepper
|
|
|
| Re: Understanding CDO [message #946502 is a reply to message #945941] |
Tue, 16 October 2012 06:30 |
|
<html>
<head>
<meta content="text/html; charset=UTF-8" http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
Hi Christophe,<br>
<br>
Thank you very much for your detailed experience report. I like it
lot ;-)<br>
<br>
More comments below...<br>
<br>
<br>
<div class="moz-cite-prefix">Am 15.10.2012 22:10, schrieb Christophe
Bouhier:<br>
</div>
<blockquote cite="mid:k5hqjk$f3l$1@xxxxxxxxe.org" type="cite">Hello
Mauro, <br>
for the last 2 years, I have been working on a client/server
application using CDO. Depending on your needs, CDO could be the
right fit. <br>
What I like (a lot). <br>
1 CDO == EMF, so you can model data first in .xsd or directly in
.ecore, and you can tell CDO to use your generated packages, which
will build the DB schema. </blockquote>
EMF compliance is very important to us and we're proud to support
most of EMF's features. Among the few exceptions are:<br>
<br>
a) Feature maps are hard to deal with in RDBs<br>
<br>
b) Because CDOResources are EObjects (see point 10) a small number
of other frameworks may run into trouble when trying to find out the
concrete type of a Notifier because the result depends on a
particular order of instanceof checks (check Resources first).<br>
<br>
c) With remote change notifications enabled, i.e.,
view.options().addChangeSubscriptionPolicy(...), your own Adapters
often need to distinguish between local or remote changes. An
instanceof CDODeltaNotification does the trick.<br>
<br>
d) Some IDE applications (and some poorly designed frameworks such
as GMF) heavily rely on IResources which are probably impossible to
simulate for CDOResources. For example it's hard or impossible to
present problem markers for validation problems in CDOResources
because IMarkers are associated with IResources. This is not a CDO
problem but a platform/IMarker problem that other
non-"platform:resource" Resources share in common.<br>
<br>
<blockquote cite="mid:k5hqjk$f3l$1@xxxxxxxxe.org" type="cite">2
On the CDO Store, you can choose from the DBStore, which supports
various DB's, I have worked with MySQL and Postgres. With
Hibernate store, there is an additional ORM layer, which works
with tons of other DB's supported by Hibernate. </blockquote>
And there's support for some other backend types, such as DB4O,
MongoDB or Objectivity/DB. I've recently developed a
RandomAccessFile based journaling store, named LissomeStore. It
still uses an RDB for a small and fixed number of indexes into the
random access file(s). For commits it uses a journal file and
adjusts the index tables asynchronously. The performance of large
commits can typically be increased by factor 600 in my tests.<br>
<br>
IMHO the great value of the IStore design is that it becomes a snap
to *change* the backend choice at any time without much impact on
the application (except you're making heavy use of backend-specifc
IQueryHandlers such as SQL or HQL).<br>
<br>
<blockquote cite="mid:k5hqjk$f3l$1@xxxxxxxxe.org" type="cite">3
As CDO == EMF, you can easily adapt a generated RCP Client EMF
editor for CDO, but in practice you are likely better of to start
UI design from scratch, but you can re-use the concept of an
Editing domain and EMF.edit generated code, which is what I do.
(ItemProviders and Commands). </blockquote>
It's a major goal of CDO to better separate the functional from the
the technical design aspects/tasks. The only intrusive technical
aspect I can imagine of is large flat lists that should generally be
avoided in favour of a deeper object structure. IMHO this is a
useful rule even when only considering the usability of a graphical
application.<br>
<br>
<blockquote cite="mid:k5hqjk$f3l$1@xxxxxxxxe.org" type="cite">4
JFace databinding supports EMF, so JFace Databinding + CDO is a
great combination, you might want to watch loading large chunks of
data into your UI widgets (tables + trees), but there are ways to
limit the volumes. </blockquote>
I fully agree that EMF databinding is a totally cool thing. One
thing that tends to be problematic are remote deletions because the
databinding layer caches some strong references to objects that
might, all of a sudden, start to throw InvalidObjectExceptions or
ObjectNotFoundExceptions. You may appreciate that in CDO 4.2 we now
changed to:<br>
<br>
public static final CDOStaleReferencePolicy DEFAULT = PROXY;<br>
<br>
public static final CDOInvalidationPolicy DEFAULT = RELAXED;<br>
<br>
<br>
<blockquote cite="mid:k5hqjk$f3l$1@xxxxxxxxe.org" type="cite">5 I
you need to do something with DSL's (Develop a textual syntax,
which can interact with EMF/CDO models), this is also great with
xtext.
<br>
</blockquote>
Yes, because "CDO == EMF". But please keep in mind that editing DSL
instances stored *in* CDO with an Xtexteditor is problematic because
a text editor generally doesn't preserve the identities (e.g.
CDOIDs) of objects. That makes it hard to reconcile changes made in
a text editor back to CDO.<br>
<br>
<blockquote cite="mid:k5hqjk$f3l$1@xxxxxxxxe.org" type="cite">6
CDO performs well, you can tweak it, to fetch more or less chunks
of data for EReferences. If you don't like the behaviour you can
fire CDO Queries to get exactly what you want. Also unused objects
are garbage collected, so you can safely read a lot of data (As
long as you don't keep a reference). </blockquote>
Funnily this scalability originally came as a by-product of the
auditing functionality ;-)<br>
<br>
<blockquote cite="mid:k5hqjk$f3l$1@xxxxxxxxe.org" type="cite">7 I
am really fond that objects have a lifecycle, and all my object
have a unique CDO ID. I actually present the CDOID, in the status
line of the app. It's a great way to check what's going on. </blockquote>
And now you can even plug in your own CDOIDGenerator at the
client-side:<br>
<br>
public interface CDOIDGenerator<br>
{<br>
public static final CDOIDGenerator UUID = new CDOIDGenerator()<br>
{<br>
public CDOID generateCDOID(EObject object)<br>
{<br>
byte[] bytes = new byte[16];<br>
UUIDGenerator.DEFAULT.generate(bytes);<br>
return CDOIDUtil.createUUID(bytes);<br>
}<br>
<br>
public void reset()<br>
{<br>
// Do nothing<br>
}<br>
};<br>
<br>
/**<br>
* Generates a {@link CDOID}.<br>
* <br>
* @param object<br>
* the object to generate a new CDOID for if available,
<code>null</code> otherwise.<br>
*/<br>
public CDOID generateCDOID(EObject object);<br>
<br>
/**<br>
* Called at the end of a commit operation to give this ID
generator a chance to reset its sequence of IDs.<br>
*/<br>
public void reset();<br>
}<br>
<br>
<blockquote cite="mid:k5hqjk$f3l$1@xxxxxxxxe.org" type="cite">
8 Invalidations are great, basically when an object goes, remotely
dirty, other views are notified and can get the latest status of
an object. <br>
<br>
What I could do without in CDO
<br>
<br>
9. Revisions & referential integrity, I loved it at first, but
right now for the app. I have. it's a burden. The concept of
revisions adds a lot of requirements in CDO, I think CDO should
also have a simpler flat mode, without the revisions and checks on
integrity. It adds to the complexity of the CDO middleware and the
generated DB get's schema's. Some apps, don't need it or need it
partially. In my case, I would need revisions for some classes
only. </blockquote>
I suspect you don't refer to CDORevisions but to the auditing mode
in general? You know that it can be switched off. Granted, for the
DBStore in particular
<a class="moz-txt-link-freetext" href="https://bugs.eclipse.org/bugs/show_bug.cgi?id=351068">https://bugs.eclipse.org/bugs/show_bug.cgi?id=351068</a> is pending. I
really want to work on this soon.<br>
<br>
Partial auditing has been requested in the past. Conceptually I
don't like the idea because the framework couldn't guarantee the
logical consistency of the graph anymore. But I'm willing to
reconsider this when the DBStore gets its next design overhaul (not
scheduled, yet).<br>
<br>
What exact integrity checks are you referring to? Referential
integrity checks in the repository can be switched off (and they are
by default).<br>
<br>
<blockquote cite="mid:k5hqjk$f3l$1@xxxxxxxxe.org" type="cite">It
sometimes feels CDO is trying to mimic a Concurrent Version System
like SVN or CVS, but for many apps you really don't need that. <br>
</blockquote>
Yes, CDO tries to offer support in both worlds, the database
driven-like runtime applications and the more tool-like use cases
where design-time models need to be stored/managed in a repository.
You can imagine that this is sometimes hard but I think we've done a
pretty good job. Are there particular parts in CDO that are
problematic for you in this regard (i.e., not just unneeded)?<br>
<br>
BTW. an example of a cool new SCM-like feature is our new History
view support for repositories, branches or single objects:<br>
<br>
<img src="http://www.eclipse.org/forums/index.php?t=getfile&id=11919" alt=""><br>
<br>
<blockquote cite="mid:k5hqjk$f3l$1@xxxxxxxxe.org" type="cite">10.
In CDO there are CDOFolders and CDOResources. </blockquote>
Yes, and CDOTextResources and CDOBinaryResources, which are now
(almost) first class citizens of a CDO repository:<br>
<br>
<img src="http://www.eclipse.org/forums/index.php?t=getfile&id=11920" alt=""><br>
<br>
<blockquote cite="mid:k5hqjk$f3l$1@xxxxxxxxe.org" type="cite">Both
are also CDO objects, and stored in the DB. I went through great
length to find the best way to use them, like the the names to
give them, which is meta information you need to deal with in the
application. (Remember which name you used for which resource to
keep which data objects, in my case each eclass has its own
cdoresource). </blockquote>
Yes, that's the main value of Resources in general: They provide
well-known entry points into the (persistent) graph of objects.<br>
<br>
Apart from that they're an essential part of "CDO == EMF" (see point
1).<br>
<br>
<blockquote cite="mid:k5hqjk$f3l$1@xxxxxxxxe.org" type="cite">Right
now, I am not sure what the added value is of these, besides some
additional grouping of objects, I think, without them it could
keep CDO simpler and avoid additional DB data. </blockquote>
Please note that you absolutely don't need to use CDOResourceFolders
and CDOResources (except for a single one to contain all other
objects). The characteristics of a CDO model is the same when you
store all objects in a single resource.<br>
<br>
<blockquote cite="mid:k5hqjk$f3l$1@xxxxxxxxe.org" type="cite">(Note
that in point 3, I mentioned the EMF Editing domain, which has a
ResourceSet which can hold CDOResource objects. I use this, so
without CDO Resources, I wouldn't be able to use an editing
domain, so something else would be needed). <br>
</blockquote>
I think the generated editors also make heavy use of the assumption
that objects are contained by resources.<br>
<br>
<blockquote cite="mid:k5hqjk$f3l$1@xxxxxxxxe.org" type="cite">What
I wish for in CDO.
<br>
<br>
11. Model migrations. There are initiatives like COPE, which could
be applied with CDO, that would be great. So add a class in your
model, and let the new feature deal with the migration and transit
your data. </blockquote>
Fully agreed. If only someone would need it enough to open the
wallet and fund the development of this feature :P<br>
<br>
<blockquote cite="mid:k5hqjk$f3l$1@xxxxxxxxe.org" type="cite">12.
It's a hard learning curve, because most of the docs are outdated
or not written, so mea-culpa, we could do better. I wish for a
thriving community around a general purpose
smart-object-persistence system like CDO. <br>
</blockquote>
Yes! Technical writers in the world, here's a project that needs you
;-)<br>
<br>
<blockquote cite="mid:k5hqjk$f3l$1@xxxxxxxxe.org" type="cite">Finally.
Eike Stepper and others, have been great in supporting me on this
forum. Generally very quick and helpful!<br>
</blockquote>
Good docs would certainly be nicer but, while they're absent, good
online support is our attempt to compensate ;-)<br>
<br>
Cheers<br>
/Eike<br>
<br>
----<br>
<a class="moz-txt-link-freetext" href="http://www.esc-net.de">http://www.esc-net.de</a><br>
<a class="moz-txt-link-freetext" href="http://thegordian.blogspot.com">http://thegordian.blogspot.com</a><br>
<a class="moz-txt-link-freetext" href="http://twitter.com/eikestepper">http://twitter.com/eikestepper</a><br>
<br>
<br>
<br>
</body>
</html>
-
Attachment: bgchgghb.png
(Size: 83.23KB, Downloaded 118 times) -
Attachment: edjjaeef.png
(Size: 16.76KB, Downloaded 136 times)
Cheers
/Eike
----
http://www.esc-net.de
http://thegordian.blogspot.com
http://twitter.com/eikestepper
|
|
|
| Re: Understanding CDO [message #946507 is a reply to message #945941] |
Tue, 16 October 2012 06:30 |
|
<html>
<head>
<meta content="text/html; charset=UTF-8" http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
Hi Christophe,<br>
<br>
Thank you very much for your detailed experience report. I like it
lot ;-)<br>
<br>
More comments below...<br>
<br>
<br>
<div class="moz-cite-prefix">Am 15.10.2012 22:10, schrieb Christophe
Bouhier:<br>
</div>
<blockquote cite="mid:k5hqjk$f3l$1@xxxxxxxxe.org" type="cite">Hello
Mauro, <br>
for the last 2 years, I have been working on a client/server
application using CDO. Depending on your needs, CDO could be the
right fit. <br>
What I like (a lot). <br>
1 CDO == EMF, so you can model data first in .xsd or directly in
.ecore, and you can tell CDO to use your generated packages, which
will build the DB schema. </blockquote>
EMF compliance is very important to us and we're proud to support
most of EMF's features. Among the few exceptions are:<br>
<br>
a) Feature maps are hard to deal with in RDBs<br>
<br>
b) Because CDOResources are EObjects (see point 10) a small number
of other frameworks may run into trouble when trying to find out the
concrete type of a Notifier because the result depends on a
particular order of instanceof checks (check Resources first).<br>
<br>
c) With remote change notifications enabled, i.e.,
view.options().addChangeSubscriptionPolicy(...), your own Adapters
often need to distinguish between local or remote changes. An
instanceof CDODeltaNotification does the trick.<br>
<br>
d) Some IDE applications (and some poorly designed frameworks such
as GMF) heavily rely on IResources which are probably impossible to
simulate for CDOResources. For example it's hard or impossible to
present problem markers for validation problems in CDOResources
because IMarkers are associated with IResources. This is not a CDO
problem but a platform/IMarker problem that other
non-"platform:resource" Resources share in common.<br>
<br>
<blockquote cite="mid:k5hqjk$f3l$1@xxxxxxxxe.org" type="cite">2
On the CDO Store, you can choose from the DBStore, which supports
various DB's, I have worked with MySQL and Postgres. With
Hibernate store, there is an additional ORM layer, which works
with tons of other DB's supported by Hibernate. </blockquote>
And there's support for some other backend types, such as DB4O,
MongoDB or Objectivity/DB. I've recently developed a
RandomAccessFile based journaling store, named LissomeStore. It
still uses an RDB for a small and fixed number of indexes into the
random access file(s). For commits it uses a journal file and
adjusts the index tables asynchronously. The performance of large
commits can typically be increased by factor 600 in my tests.<br>
<br>
IMHO the great value of the IStore design is that it becomes a snap
to *change* the backend choice at any time without much impact on
the application (except you're making heavy use of backend-specifc
IQueryHandlers such as SQL or HQL).<br>
<br>
<blockquote cite="mid:k5hqjk$f3l$1@xxxxxxxxe.org" type="cite">3
As CDO == EMF, you can easily adapt a generated RCP Client EMF
editor for CDO, but in practice you are likely better of to start
UI design from scratch, but you can re-use the concept of an
Editing domain and EMF.edit generated code, which is what I do.
(ItemProviders and Commands). </blockquote>
It's a major goal of CDO to better separate the functional from the
the technical design aspects/tasks. The only intrusive technical
aspect I can imagine of is large flat lists that should generally be
avoided in favour of a deeper object structure. IMHO this is a
useful rule even when only considering the usability of a graphical
application.<br>
<br>
<blockquote cite="mid:k5hqjk$f3l$1@xxxxxxxxe.org" type="cite">4
JFace databinding supports EMF, so JFace Databinding + CDO is a
great combination, you might want to watch loading large chunks of
data into your UI widgets (tables + trees), but there are ways to
limit the volumes. </blockquote>
I fully agree that EMF databinding is a totally cool thing. One
thing that tends to be problematic are remote deletions because the
databinding layer caches some strong references to objects that
might, all of a sudden, start to throw InvalidObjectExceptions or
ObjectNotFoundExceptions. You may appreciate that in CDO 4.2 we now
changed to:<br>
<br>
public static final CDOStaleReferencePolicy DEFAULT = PROXY;<br>
<br>
public static final CDOInvalidationPolicy DEFAULT = RELAXED;<br>
<br>
<br>
<blockquote cite="mid:k5hqjk$f3l$1@xxxxxxxxe.org" type="cite">5 I
you need to do something with DSL's (Develop a textual syntax,
which can interact with EMF/CDO models), this is also great with
xtext.
<br>
</blockquote>
Yes, because "CDO == EMF". But please keep in mind that editing DSL
instances stored *in* CDO with an Xtexteditor is problematic because
a text editor generally doesn't preserve the identities (e.g.
CDOIDs) of objects. That makes it hard to reconcile changes made in
a text editor back to CDO.<br>
<br>
<blockquote cite="mid:k5hqjk$f3l$1@xxxxxxxxe.org" type="cite">6
CDO performs well, you can tweak it, to fetch more or less chunks
of data for EReferences. If you don't like the behaviour you can
fire CDO Queries to get exactly what you want. Also unused objects
are garbage collected, so you can safely read a lot of data (As
long as you don't keep a reference). </blockquote>
Funnily this scalability originally came as a by-product of the
auditing functionality ;-)<br>
<br>
<blockquote cite="mid:k5hqjk$f3l$1@xxxxxxxxe.org" type="cite">7 I
am really fond that objects have a lifecycle, and all my object
have a unique CDO ID. I actually present the CDOID, in the status
line of the app. It's a great way to check what's going on. </blockquote>
And now you can even plug in your own CDOIDGenerator at the
client-side:<br>
<br>
public interface CDOIDGenerator<br>
{<br>
public static final CDOIDGenerator UUID = new CDOIDGenerator()<br>
{<br>
public CDOID generateCDOID(EObject object)<br>
{<br>
byte[] bytes = new byte[16];<br>
UUIDGenerator.DEFAULT.generate(bytes);<br>
return CDOIDUtil.createUUID(bytes);<br>
}<br>
<br>
public void reset()<br>
{<br>
// Do nothing<br>
}<br>
};<br>
<br>
/**<br>
* Generates a {@link CDOID}.<br>
* <br>
* @param object<br>
* the object to generate a new CDOID for if available,
<code>null</code> otherwise.<br>
*/<br>
public CDOID generateCDOID(EObject object);<br>
<br>
/**<br>
* Called at the end of a commit operation to give this ID
generator a chance to reset its sequence of IDs.<br>
*/<br>
public void reset();<br>
}<br>
<br>
<blockquote cite="mid:k5hqjk$f3l$1@xxxxxxxxe.org" type="cite">
8 Invalidations are great, basically when an object goes, remotely
dirty, other views are notified and can get the latest status of
an object. <br>
<br>
What I could do without in CDO
<br>
<br>
9. Revisions & referential integrity, I loved it at first, but
right now for the app. I have. it's a burden. The concept of
revisions adds a lot of requirements in CDO, I think CDO should
also have a simpler flat mode, without the revisions and checks on
integrity. It adds to the complexity of the CDO middleware and the
generated DB get's schema's. Some apps, don't need it or need it
partially. In my case, I would need revisions for some classes
only. </blockquote>
I suspect you don't refer to CDORevisions but to the auditing mode
in general? You know that it can be switched off. Granted, for the
DBStore in particular
<a class="moz-txt-link-freetext" href="https://bugs.eclipse.org/bugs/show_bug.cgi?id=351068">https://bugs.eclipse.org/bugs/show_bug.cgi?id=351068</a> is pending. I
really want to work on this soon.<br>
<br>
Partial auditing has been requested in the past. Conceptually I
don't like the idea because the framework couldn't guarantee the
logical consistency of the graph anymore. But I'm willing to
reconsider this when the DBStore gets its next design overhaul (not
scheduled, yet).<br>
<br>
What exact integrity checks are you referring to? Referential
integrity checks in the repository can be switched off (and they are
by default).<br>
<br>
<blockquote cite="mid:k5hqjk$f3l$1@xxxxxxxxe.org" type="cite">It
sometimes feels CDO is trying to mimic a Concurrent Version System
like SVN or CVS, but for many apps you really don't need that. <br>
</blockquote>
Yes, CDO tries to offer support in both worlds, the database
driven-like runtime applications and the more tool-like use cases
where design-time models need to be stored/managed in a repository.
You can imagine that this is sometimes hard but I think we've done a
pretty good job. Are there particular parts in CDO that are
problematic for you in this regard (i.e., not just unneeded)?<br>
<br>
BTW. an example of a cool new SCM-like feature is our new History
view support for repositories, branches or single objects:<br>
<br>
<img src="http://www.eclipse.org/forums/index.php?t=getfile&id=11921" alt=""><br>
<br>
<blockquote cite="mid:k5hqjk$f3l$1@xxxxxxxxe.org" type="cite">10.
In CDO there are CDOFolders and CDOResources. </blockquote>
Yes, and CDOTextResources and CDOBinaryResources, which are now
(almost) first class citizens of a CDO repository:<br>
<br>
<img src="http://www.eclipse.org/forums/index.php?t=getfile&id=11922" alt=""><br>
<br>
<blockquote cite="mid:k5hqjk$f3l$1@xxxxxxxxe.org" type="cite">Both
are also CDO objects, and stored in the DB. I went through great
length to find the best way to use them, like the the names to
give them, which is meta information you need to deal with in the
application. (Remember which name you used for which resource to
keep which data objects, in my case each eclass has its own
cdoresource). </blockquote>
Yes, that's the main value of Resources in general: They provide
well-known entry points into the (persistent) graph of objects.<br>
<br>
Apart from that they're an essential part of "CDO == EMF" (see point
1).<br>
<br>
<blockquote cite="mid:k5hqjk$f3l$1@xxxxxxxxe.org" type="cite">Right
now, I am not sure what the added value is of these, besides some
additional grouping of objects, I think, without them it could
keep CDO simpler and avoid additional DB data. </blockquote>
Please note that you absolutely don't need to use CDOResourceFolders
and CDOResources (except for a single one to contain all other
objects). The characteristics of a CDO model is the same when you
store all objects in a single resource.<br>
<br>
<blockquote cite="mid:k5hqjk$f3l$1@xxxxxxxxe.org" type="cite">(Note
that in point 3, I mentioned the EMF Editing domain, which has a
ResourceSet which can hold CDOResource objects. I use this, so
without CDO Resources, I wouldn't be able to use an editing
domain, so something else would be needed). <br>
</blockquote>
I think the generated editors also make heavy use of the assumption
that objects are contained by resources.<br>
<br>
<blockquote cite="mid:k5hqjk$f3l$1@xxxxxxxxe.org" type="cite">What
I wish for in CDO.
<br>
<br>
11. Model migrations. There are initiatives like COPE, which could
be applied with CDO, that would be great. So add a class in your
model, and let the new feature deal with the migration and transit
your data. </blockquote>
Fully agreed. If only someone would need it enough to open the
wallet and fund the development of this feature :P<br>
<br>
<blockquote cite="mid:k5hqjk$f3l$1@xxxxxxxxe.org" type="cite">12.
It's a hard learning curve, because most of the docs are outdated
or not written, so mea-culpa, we could do better. I wish for a
thriving community around a general purpose
smart-object-persistence system like CDO. <br>
</blockquote>
Yes! Technical writers in the world, here's a project that needs you
;-)<br>
<br>
<blockquote cite="mid:k5hqjk$f3l$1@xxxxxxxxe.org" type="cite">Finally.
Eike Stepper and others, have been great in supporting me on this
forum. Generally very quick and helpful!<br>
</blockquote>
Good docs would certainly be nicer but, while they're absent, good
online support is our attempt to compensate ;-)<br>
<br>
Cheers<br>
/Eike<br>
<br>
----<br>
<a class="moz-txt-link-freetext" href="http://www.esc-net.de">http://www.esc-net.de</a><br>
<a class="moz-txt-link-freetext" href="http://thegordian.blogspot.com">http://thegordian.blogspot.com</a><br>
<a class="moz-txt-link-freetext" href="http://twitter.com/eikestepper">http://twitter.com/eikestepper</a><br>
<br>
<br>
<br>
</body>
</html>
-
Attachment: bgchgghb.png
(Size: 83.23KB, Downloaded 129 times) -
Attachment: edjjaeef.png
(Size: 16.76KB, Downloaded 129 times)
Cheers
/Eike
----
http://www.esc-net.de
http://thegordian.blogspot.com
http://twitter.com/eikestepper
|
|
|
| Re: Understanding CDO [message #946513 is a reply to message #945941] |
Tue, 16 October 2012 06:30 |
|
<html>
<head>
<meta content="text/html; charset=UTF-8" http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
Hi Christophe,<br>
<br>
Thank you very much for your detailed experience report. I like it
lot ;-)<br>
<br>
More comments below...<br>
<br>
<br>
<div class="moz-cite-prefix">Am 15.10.2012 22:10, schrieb Christophe
Bouhier:<br>
</div>
<blockquote cite="mid:k5hqjk$f3l$1@xxxxxxxxe.org" type="cite">Hello
Mauro, <br>
for the last 2 years, I have been working on a client/server
application using CDO. Depending on your needs, CDO could be the
right fit. <br>
What I like (a lot). <br>
1 CDO == EMF, so you can model data first in .xsd or directly in
.ecore, and you can tell CDO to use your generated packages, which
will build the DB schema. </blockquote>
EMF compliance is very important to us and we're proud to support
most of EMF's features. Among the few exceptions are:<br>
<br>
a) Feature maps are hard to deal with in RDBs<br>
<br>
b) Because CDOResources are EObjects (see point 10) a small number
of other frameworks may run into trouble when trying to find out the
concrete type of a Notifier because the result depends on a
particular order of instanceof checks (check Resources first).<br>
<br>
c) With remote change notifications enabled, i.e.,
view.options().addChangeSubscriptionPolicy(...), your own Adapters
often need to distinguish between local or remote changes. An
instanceof CDODeltaNotification does the trick.<br>
<br>
d) Some IDE applications (and some poorly designed frameworks such
as GMF) heavily rely on IResources which are probably impossible to
simulate for CDOResources. For example it's hard or impossible to
present problem markers for validation problems in CDOResources
because IMarkers are associated with IResources. This is not a CDO
problem but a platform/IMarker problem that other
non-"platform:resource" Resources share in common.<br>
<br>
<blockquote cite="mid:k5hqjk$f3l$1@xxxxxxxxe.org" type="cite">2
On the CDO Store, you can choose from the DBStore, which supports
various DB's, I have worked with MySQL and Postgres. With
Hibernate store, there is an additional ORM layer, which works
with tons of other DB's supported by Hibernate. </blockquote>
And there's support for some other backend types, such as DB4O,
MongoDB or Objectivity/DB. I've recently developed a
RandomAccessFile based journaling store, named LissomeStore. It
still uses an RDB for a small and fixed number of indexes into the
random access file(s). For commits it uses a journal file and
adjusts the index tables asynchronously. The performance of large
commits can typically be increased by factor 600 in my tests.<br>
<br>
IMHO the great value of the IStore design is that it becomes a snap
to *change* the backend choice at any time without much impact on
the application (except you're making heavy use of backend-specifc
IQueryHandlers such as SQL or HQL).<br>
<br>
<blockquote cite="mid:k5hqjk$f3l$1@xxxxxxxxe.org" type="cite">3
As CDO == EMF, you can easily adapt a generated RCP Client EMF
editor for CDO, but in practice you are likely better of to start
UI design from scratch, but you can re-use the concept of an
Editing domain and EMF.edit generated code, which is what I do.
(ItemProviders and Commands). </blockquote>
It's a major goal of CDO to better separate the functional from the
the technical design aspects/tasks. The only intrusive technical
aspect I can imagine of is large flat lists that should generally be
avoided in favour of a deeper object structure. IMHO this is a
useful rule even when only considering the usability of a graphical
application.<br>
<br>
<blockquote cite="mid:k5hqjk$f3l$1@xxxxxxxxe.org" type="cite">4
JFace databinding supports EMF, so JFace Databinding + CDO is a
great combination, you might want to watch loading large chunks of
data into your UI widgets (tables + trees), but there are ways to
limit the volumes. </blockquote>
I fully agree that EMF databinding is a totally cool thing. One
thing that tends to be problematic are remote deletions because the
databinding layer caches some strong references to objects that
might, all of a sudden, start to throw InvalidObjectExceptions or
ObjectNotFoundExceptions. You may appreciate that in CDO 4.2 we now
changed to:<br>
<br>
public static final CDOStaleReferencePolicy DEFAULT = PROXY;<br>
<br>
public static final CDOInvalidationPolicy DEFAULT = RELAXED;<br>
<br>
<br>
<blockquote cite="mid:k5hqjk$f3l$1@xxxxxxxxe.org" type="cite">5 I
you need to do something with DSL's (Develop a textual syntax,
which can interact with EMF/CDO models), this is also great with
xtext.
<br>
</blockquote>
Yes, because "CDO == EMF". But please keep in mind that editing DSL
instances stored *in* CDO with an Xtexteditor is problematic because
a text editor generally doesn't preserve the identities (e.g.
CDOIDs) of objects. That makes it hard to reconcile changes made in
a text editor back to CDO.<br>
<br>
<blockquote cite="mid:k5hqjk$f3l$1@xxxxxxxxe.org" type="cite">6
CDO performs well, you can tweak it, to fetch more or less chunks
of data for EReferences. If you don't like the behaviour you can
fire CDO Queries to get exactly what you want. Also unused objects
are garbage collected, so you can safely read a lot of data (As
long as you don't keep a reference). </blockquote>
Funnily this scalability originally came as a by-product of the
auditing functionality ;-)<br>
<br>
<blockquote cite="mid:k5hqjk$f3l$1@xxxxxxxxe.org" type="cite">7 I
am really fond that objects have a lifecycle, and all my object
have a unique CDO ID. I actually present the CDOID, in the status
line of the app. It's a great way to check what's going on. </blockquote>
And now you can even plug in your own CDOIDGenerator at the
client-side:<br>
<br>
public interface CDOIDGenerator<br>
{<br>
public static final CDOIDGenerator UUID = new CDOIDGenerator()<br>
{<br>
public CDOID generateCDOID(EObject object)<br>
{<br>
byte[] bytes = new byte[16];<br>
UUIDGenerator.DEFAULT.generate(bytes);<br>
return CDOIDUtil.createUUID(bytes);<br>
}<br>
<br>
public void reset()<br>
{<br>
// Do nothing<br>
}<br>
};<br>
<br>
/**<br>
* Generates a {@link CDOID}.<br>
* <br>
* @param object<br>
* the object to generate a new CDOID for if available,
<code>null</code> otherwise.<br>
*/<br>
public CDOID generateCDOID(EObject object);<br>
<br>
/**<br>
* Called at the end of a commit operation to give this ID
generator a chance to reset its sequence of IDs.<br>
*/<br>
public void reset();<br>
}<br>
<br>
<blockquote cite="mid:k5hqjk$f3l$1@xxxxxxxxe.org" type="cite">
8 Invalidations are great, basically when an object goes, remotely
dirty, other views are notified and can get the latest status of
an object. <br>
<br>
What I could do without in CDO
<br>
<br>
9. Revisions & referential integrity, I loved it at first, but
right now for the app. I have. it's a burden. The concept of
revisions adds a lot of requirements in CDO, I think CDO should
also have a simpler flat mode, without the revisions and checks on
integrity. It adds to the complexity of the CDO middleware and the
generated DB get's schema's. Some apps, don't need it or need it
partially. In my case, I would need revisions for some classes
only. </blockquote>
I suspect you don't refer to CDORevisions but to the auditing mode
in general? You know that it can be switched off. Granted, for the
DBStore in particular
<a class="moz-txt-link-freetext" href="https://bugs.eclipse.org/bugs/show_bug.cgi?id=351068">https://bugs.eclipse.org/bugs/show_bug.cgi?id=351068</a> is pending. I
really want to work on this soon.<br>
<br>
Partial auditing has been requested in the past. Conceptually I
don't like the idea because the framework couldn't guarantee the
logical consistency of the graph anymore. But I'm willing to
reconsider this when the DBStore gets its next design overhaul (not
scheduled, yet).<br>
<br>
What exact integrity checks are you referring to? Referential
integrity checks in the repository can be switched off (and they are
by default).<br>
<br>
<blockquote cite="mid:k5hqjk$f3l$1@xxxxxxxxe.org" type="cite">It
sometimes feels CDO is trying to mimic a Concurrent Version System
like SVN or CVS, but for many apps you really don't need that. <br>
</blockquote>
Yes, CDO tries to offer support in both worlds, the database
driven-like runtime applications and the more tool-like use cases
where design-time models need to be stored/managed in a repository.
You can imagine that this is sometimes hard but I think we've done a
pretty good job. Are there particular parts in CDO that are
problematic for you in this regard (i.e., not just unneeded)?<br>
<br>
BTW. an example of a cool new SCM-like feature is our new History
view support for repositories, branches or single objects:<br>
<br>
<img src="http://www.eclipse.org/forums/index.php?t=getfile&id=11924" alt=""><br>
<br>
<blockquote cite="mid:k5hqjk$f3l$1@xxxxxxxxe.org" type="cite">10.
In CDO there are CDOFolders and CDOResources. </blockquote>
Yes, and CDOTextResources and CDOBinaryResources, which are now
(almost) first class citizens of a CDO repository:<br>
<br>
<img src="http://www.eclipse.org/forums/index.php?t=getfile&id=11925" alt=""><br>
<br>
<blockquote cite="mid:k5hqjk$f3l$1@xxxxxxxxe.org" type="cite">Both
are also CDO objects, and stored in the DB. I went through great
length to find the best way to use them, like the the names to
give them, which is meta information you need to deal with in the
application. (Remember which name you used for which resource to
keep which data objects, in my case each eclass has its own
cdoresource). </blockquote>
Yes, that's the main value of Resources in general: They provide
well-known entry points into the (persistent) graph of objects.<br>
<br>
Apart from that they're an essential part of "CDO == EMF" (see point
1).<br>
<br>
<blockquote cite="mid:k5hqjk$f3l$1@xxxxxxxxe.org" type="cite">Right
now, I am not sure what the added value is of these, besides some
additional grouping of objects, I think, without them it could
keep CDO simpler and avoid additional DB data. </blockquote>
Please note that you absolutely don't need to use CDOResourceFolders
and CDOResources (except for a single one to contain all other
objects). The characteristics of a CDO model is the same when you
store all objects in a single resource.<br>
<br>
<blockquote cite="mid:k5hqjk$f3l$1@xxxxxxxxe.org" type="cite">(Note
that in point 3, I mentioned the EMF Editing domain, which has a
ResourceSet which can hold CDOResource objects. I use this, so
without CDO Resources, I wouldn't be able to use an editing
domain, so something else would be needed). <br>
</blockquote>
I think the generated editors also make heavy use of the assumption
that objects are contained by resources.<br>
<br>
<blockquote cite="mid:k5hqjk$f3l$1@xxxxxxxxe.org" type="cite">What
I wish for in CDO.
<br>
<br>
11. Model migrations. There are initiatives like COPE, which could
be applied with CDO, that would be great. So add a class in your
model, and let the new feature deal with the migration and transit
your data. </blockquote>
Fully agreed. If only someone would need it enough to open the
wallet and fund the development of this feature :P<br>
<br>
<blockquote cite="mid:k5hqjk$f3l$1@xxxxxxxxe.org" type="cite">12.
It's a hard learning curve, because most of the docs are outdated
or not written, so mea-culpa, we could do better. I wish for a
thriving community around a general purpose
smart-object-persistence system like CDO. <br>
</blockquote>
Yes! Technical writers in the world, here's a project that needs you
;-)<br>
<br>
<blockquote cite="mid:k5hqjk$f3l$1@xxxxxxxxe.org" type="cite">Finally.
Eike Stepper and others, have been great in supporting me on this
forum. Generally very quick and helpful!<br>
</blockquote>
Good docs would certainly be nicer but, while they're absent, good
online support is our attempt to compensate ;-)<br>
<br>
Cheers<br>
/Eike<br>
<br>
----<br>
<a class="moz-txt-link-freetext" href="http://www.esc-net.de">http://www.esc-net.de</a><br>
<a class="moz-txt-link-freetext" href="http://thegordian.blogspot.com">http://thegordian.blogspot.com</a><br>
<a class="moz-txt-link-freetext" href="http://twitter.com/eikestepper">http://twitter.com/eikestepper</a><br>
<br>
<br>
<br>
</body>
</html>
-
Attachment: bgchgghb.png
(Size: 83.23KB, Downloaded 111 times) -
Attachment: edjjaeef.png
(Size: 16.76KB, Downloaded 112 times)
Cheers
/Eike
----
http://www.esc-net.de
http://thegordian.blogspot.com
http://twitter.com/eikestepper
|
|
|
| Re: Understanding CDO [message #946519 is a reply to message #945941] |
Tue, 16 October 2012 06:30 |
|
<html>
<head>
<meta content="text/html; charset=UTF-8" http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
Hi Christophe,<br>
<br>
Thank you very much for your detailed experience report. I like it
lot ;-)<br>
<br>
More comments below...<br>
<br>
<br>
<div class="moz-cite-prefix">Am 15.10.2012 22:10, schrieb Christophe
Bouhier:<br>
</div>
<blockquote cite="mid:k5hqjk$f3l$1@xxxxxxxxe.org" type="cite">Hello
Mauro, <br>
for the last 2 years, I have been working on a client/server
application using CDO. Depending on your needs, CDO could be the
right fit. <br>
What I like (a lot). <br>
1 CDO == EMF, so you can model data first in .xsd or directly in
.ecore, and you can tell CDO to use your generated packages, which
will build the DB schema. </blockquote>
EMF compliance is very important to us and we're proud to support
most of EMF's features. Among the few exceptions are:<br>
<br>
a) Feature maps are hard to deal with in RDBs<br>
<br>
b) Because CDOResources are EObjects (see point 10) a small number
of other frameworks may run into trouble when trying to find out the
concrete type of a Notifier because the result depends on a
particular order of instanceof checks (check Resources first).<br>
<br>
c) With remote change notifications enabled, i.e.,
view.options().addChangeSubscriptionPolicy(...), your own Adapters
often need to distinguish between local or remote changes. An
instanceof CDODeltaNotification does the trick.<br>
<br>
d) Some IDE applications (and some poorly designed frameworks such
as GMF) heavily rely on IResources which are probably impossible to
simulate for CDOResources. For example it's hard or impossible to
present problem markers for validation problems in CDOResources
because IMarkers are associated with IResources. This is not a CDO
problem but a platform/IMarker problem that other
non-"platform:resource" Resources share in common.<br>
<br>
<blockquote cite="mid:k5hqjk$f3l$1@xxxxxxxxe.org" type="cite">2
On the CDO Store, you can choose from the DBStore, which supports
various DB's, I have worked with MySQL and Postgres. With
Hibernate store, there is an additional ORM layer, which works
with tons of other DB's supported by Hibernate. </blockquote>
And there's support for some other backend types, such as DB4O,
MongoDB or Objectivity/DB. I've recently developed a
RandomAccessFile based journaling store, named LissomeStore. It
still uses an RDB for a small and fixed number of indexes into the
random access file(s). For commits it uses a journal file and
adjusts the index tables asynchronously. The performance of large
commits can typically be increased by factor 600 in my tests.<br>
<br>
IMHO the great value of the IStore design is that it becomes a snap
to *change* the backend choice at any time without much impact on
the application (except you're making heavy use of backend-specifc
IQueryHandlers such as SQL or HQL).<br>
<br>
<blockquote cite="mid:k5hqjk$f3l$1@xxxxxxxxe.org" type="cite">3
As CDO == EMF, you can easily adapt a generated RCP Client EMF
editor for CDO, but in practice you are likely better of to start
UI design from scratch, but you can re-use the concept of an
Editing domain and EMF.edit generated code, which is what I do.
(ItemProviders and Commands). </blockquote>
It's a major goal of CDO to better separate the functional from the
the technical design aspects/tasks. The only intrusive technical
aspect I can imagine of is large flat lists that should generally be
avoided in favour of a deeper object structure. IMHO this is a
useful rule even when only considering the usability of a graphical
application.<br>
<br>
<blockquote cite="mid:k5hqjk$f3l$1@xxxxxxxxe.org" type="cite">4
JFace databinding supports EMF, so JFace Databinding + CDO is a
great combination, you might want to watch loading large chunks of
data into your UI widgets (tables + trees), but there are ways to
limit the volumes. </blockquote>
I fully agree that EMF databinding is a totally cool thing. One
thing that tends to be problematic are remote deletions because the
databinding layer caches some strong references to objects that
might, all of a sudden, start to throw InvalidObjectExceptions or
ObjectNotFoundExceptions. You may appreciate that in CDO 4.2 we now
changed to:<br>
<br>
public static final CDOStaleReferencePolicy DEFAULT = PROXY;<br>
<br>
public static final CDOInvalidationPolicy DEFAULT = RELAXED;<br>
<br>
<br>
<blockquote cite="mid:k5hqjk$f3l$1@xxxxxxxxe.org" type="cite">5 I
you need to do something with DSL's (Develop a textual syntax,
which can interact with EMF/CDO models), this is also great with
xtext.
<br>
</blockquote>
Yes, because "CDO == EMF". But please keep in mind that editing DSL
instances stored *in* CDO with an Xtexteditor is problematic because
a text editor generally doesn't preserve the identities (e.g.
CDOIDs) of objects. That makes it hard to reconcile changes made in
a text editor back to CDO.<br>
<br>
<blockquote cite="mid:k5hqjk$f3l$1@xxxxxxxxe.org" type="cite">6
CDO performs well, you can tweak it, to fetch more or less chunks
of data for EReferences. If you don't like the behaviour you can
fire CDO Queries to get exactly what you want. Also unused objects
are garbage collected, so you can safely read a lot of data (As
long as you don't keep a reference). </blockquote>
Funnily this scalability originally came as a by-product of the
auditing functionality ;-)<br>
<br>
<blockquote cite="mid:k5hqjk$f3l$1@xxxxxxxxe.org" type="cite">7 I
am really fond that objects have a lifecycle, and all my object
have a unique CDO ID. I actually present the CDOID, in the status
line of the app. It's a great way to check what's going on. </blockquote>
And now you can even plug in your own CDOIDGenerator at the
client-side:<br>
<br>
public interface CDOIDGenerator<br>
{<br>
public static final CDOIDGenerator UUID = new CDOIDGenerator()<br>
{<br>
public CDOID generateCDOID(EObject object)<br>
{<br>
byte[] bytes = new byte[16];<br>
UUIDGenerator.DEFAULT.generate(bytes);<br>
return CDOIDUtil.createUUID(bytes);<br>
}<br>
<br>
public void reset()<br>
{<br>
// Do nothing<br>
}<br>
};<br>
<br>
/**<br>
* Generates a {@link CDOID}.<br>
* <br>
* @param object<br>
* the object to generate a new CDOID for if available,
<code>null</code> otherwise.<br>
*/<br>
public CDOID generateCDOID(EObject object);<br>
<br>
/**<br>
* Called at the end of a commit operation to give this ID
generator a chance to reset its sequence of IDs.<br>
*/<br>
public void reset();<br>
}<br>
<br>
<blockquote cite="mid:k5hqjk$f3l$1@xxxxxxxxe.org" type="cite">
8 Invalidations are great, basically when an object goes, remotely
dirty, other views are notified and can get the latest status of
an object. <br>
<br>
What I could do without in CDO
<br>
<br>
9. Revisions & referential integrity, I loved it at first, but
right now for the app. I have. it's a burden. The concept of
revisions adds a lot of requirements in CDO, I think CDO should
also have a simpler flat mode, without the revisions and checks on
integrity. It adds to the complexity of the CDO middleware and the
generated DB get's schema's. Some apps, don't need it or need it
partially. In my case, I would need revisions for some classes
only. </blockquote>
I suspect you don't refer to CDORevisions but to the auditing mode
in general? You know that it can be switched off. Granted, for the
DBStore in particular
<a class="moz-txt-link-freetext" href="https://bugs.eclipse.org/bugs/show_bug.cgi?id=351068">https://bugs.eclipse.org/bugs/show_bug.cgi?id=351068</a> is pending. I
really want to work on this soon.<br>
<br>
Partial auditing has been requested in the past. Conceptually I
don't like the idea because the framework couldn't guarantee the
logical consistency of the graph anymore. But I'm willing to
reconsider this when the DBStore gets its next design overhaul (not
scheduled, yet).<br>
<br>
What exact integrity checks are you referring to? Referential
integrity checks in the repository can be switched off (and they are
by default).<br>
<br>
<blockquote cite="mid:k5hqjk$f3l$1@xxxxxxxxe.org" type="cite">It
sometimes feels CDO is trying to mimic a Concurrent Version System
like SVN or CVS, but for many apps you really don't need that. <br>
</blockquote>
Yes, CDO tries to offer support in both worlds, the database
driven-like runtime applications and the more tool-like use cases
where design-time models need to be stored/managed in a repository.
You can imagine that this is sometimes hard but I think we've done a
pretty good job. Are there particular parts in CDO that are
problematic for you in this regard (i.e., not just unneeded)?<br>
<br>
BTW. an example of a cool new SCM-like feature is our new History
view support for repositories, branches or single objects:<br>
<br>
<img src="http://www.eclipse.org/forums/index.php?t=getfile&id=11926" alt=""><br>
<br>
<blockquote cite="mid:k5hqjk$f3l$1@xxxxxxxxe.org" type="cite">10.
In CDO there are CDOFolders and CDOResources. </blockquote>
Yes, and CDOTextResources and CDOBinaryResources, which are now
(almost) first class citizens of a CDO repository:<br>
<br>
<img src="http://www.eclipse.org/forums/index.php?t=getfile&id=11927" alt=""><br>
<br>
<blockquote cite="mid:k5hqjk$f3l$1@xxxxxxxxe.org" type="cite">Both
are also CDO objects, and stored in the DB. I went through great
length to find the best way to use them, like the the names to
give them, which is meta information you need to deal with in the
application. (Remember which name you used for which resource to
keep which data objects, in my case each eclass has its own
cdoresource). </blockquote>
Yes, that's the main value of Resources in general: They provide
well-known entry points into the (persistent) graph of objects.<br>
<br>
Apart from that they're an essential part of "CDO == EMF" (see point
1).<br>
<br>
<blockquote cite="mid:k5hqjk$f3l$1@xxxxxxxxe.org" type="cite">Right
now, I am not sure what the added value is of these, besides some
additional grouping of objects, I think, without them it could
keep CDO simpler and avoid additional DB data. </blockquote>
Please note that you absolutely don't need to use CDOResourceFolders
and CDOResources (except for a single one to contain all other
objects). The characteristics of a CDO model is the same when you
store all objects in a single resource.<br>
<br>
<blockquote cite="mid:k5hqjk$f3l$1@xxxxxxxxe.org" type="cite">(Note
that in point 3, I mentioned the EMF Editing domain, which has a
ResourceSet which can hold CDOResource objects. I use this, so
without CDO Resources, I wouldn't be able to use an editing
domain, so something else would be needed). <br>
</blockquote>
I think the generated editors also make heavy use of the assumption
that objects are contained by resources.<br>
<br>
<blockquote cite="mid:k5hqjk$f3l$1@xxxxxxxxe.org" type="cite">What
I wish for in CDO.
<br>
<br>
11. Model migrations. There are initiatives like COPE, which could
be applied with CDO, that would be great. So add a class in your
model, and let the new feature deal with the migration and transit
your data. </blockquote>
Fully agreed. If only someone would need it enough to open the
wallet and fund the development of this feature :P<br>
<br>
<blockquote cite="mid:k5hqjk$f3l$1@xxxxxxxxe.org" type="cite">12.
It's a hard learning curve, because most of the docs are outdated
or not written, so mea-culpa, we could do better. I wish for a
thriving community around a general purpose
smart-object-persistence system like CDO. <br>
</blockquote>
Yes! Technical writers in the world, here's a project that needs you
;-)<br>
<br>
<blockquote cite="mid:k5hqjk$f3l$1@xxxxxxxxe.org" type="cite">Finally.
Eike Stepper and others, have been great in supporting me on this
forum. Generally very quick and helpful!<br>
</blockquote>
Good docs would certainly be nicer but, while they're absent, good
online support is our attempt to compensate ;-)<br>
<br>
Cheers<br>
/Eike<br>
<br>
----<br>
<a class="moz-txt-link-freetext" href="http://www.esc-net.de">http://www.esc-net.de</a><br>
<a class="moz-txt-link-freetext" href="http://thegordian.blogspot.com">http://thegordian.blogspot.com</a><br>
<a class="moz-txt-link-freetext" href="http://twitter.com/eikestepper">http://twitter.com/eikestepper</a><br>
<br>
<br>
<br>
</body>
</html>
-
Attachment: bgchgghb.png
(Size: 83.23KB, Downloaded 111 times) -
Attachment: edjjaeef.png
(Size: 16.76KB, Downloaded 114 times)
Cheers
/Eike
----
http://www.esc-net.de
http://thegordian.blogspot.com
http://twitter.com/eikestepper
|
|
|
| Re: Understanding CDO [message #946524 is a reply to message #945941] |
Tue, 16 October 2012 06:30 |
|
<html>
<head>
<meta content="text/html; charset=UTF-8" http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
Hi Christophe,<br>
<br>
Thank you very much for your detailed experience report. I like it
lot ;-)<br>
<br>
More comments below...<br>
<br>
<br>
<div class="moz-cite-prefix">Am 15.10.2012 22:10, schrieb Christophe
Bouhier:<br>
</div>
<blockquote cite="mid:k5hqjk$f3l$1@xxxxxxxxe.org" type="cite">Hello
Mauro, <br>
for the last 2 years, I have been working on a client/server
application using CDO. Depending on your needs, CDO could be the
right fit. <br>
What I like (a lot). <br>
1 CDO == EMF, so you can model data first in .xsd or directly in
.ecore, and you can tell CDO to use your generated packages, which
will build the DB schema. </blockquote>
EMF compliance is very important to us and we're proud to support
most of EMF's features. Among the few exceptions are:<br>
<br>
a) Feature maps are hard to deal with in RDBs<br>
<br>
b) Because CDOResources are EObjects (see point 10) a small number
of other frameworks may run into trouble when trying to find out the
concrete type of a Notifier because the result depends on a
particular order of instanceof checks (check Resources first).<br>
<br>
c) With remote change notifications enabled, i.e.,
view.options().addChangeSubscriptionPolicy(...), your own Adapters
often need to distinguish between local or remote changes. An
instanceof CDODeltaNotification does the trick.<br>
<br>
d) Some IDE applications (and some poorly designed frameworks such
as GMF) heavily rely on IResources which are probably impossible to
simulate for CDOResources. For example it's hard or impossible to
present problem markers for validation problems in CDOResources
because IMarkers are associated with IResources. This is not a CDO
problem but a platform/IMarker problem that other
non-"platform:resource" Resources share in common.<br>
<br>
<blockquote cite="mid:k5hqjk$f3l$1@xxxxxxxxe.org" type="cite">2
On the CDO Store, you can choose from the DBStore, which supports
various DB's, I have worked with MySQL and Postgres. With
Hibernate store, there is an additional ORM layer, which works
with tons of other DB's supported by Hibernate. </blockquote>
And there's support for some other backend types, such as DB4O,
MongoDB or Objectivity/DB. I've recently developed a
RandomAccessFile based journaling store, named LissomeStore. It
still uses an RDB for a small and fixed number of indexes into the
random access file(s). For commits it uses a journal file and
adjusts the index tables asynchronously. The performance of large
commits can typically be increased by factor 600 in my tests.<br>
<br>
IMHO the great value of the IStore design is that it becomes a snap
to *change* the backend choice at any time without much impact on
the application (except you're making heavy use of backend-specifc
IQueryHandlers such as SQL or HQL).<br>
<br>
<blockquote cite="mid:k5hqjk$f3l$1@xxxxxxxxe.org" type="cite">3
As CDO == EMF, you can easily adapt a generated RCP Client EMF
editor for CDO, but in practice you are likely better of to start
UI design from scratch, but you can re-use the concept of an
Editing domain and EMF.edit generated code, which is what I do.
(ItemProviders and Commands). </blockquote>
It's a major goal of CDO to better separate the functional from the
the technical design aspects/tasks. The only intrusive technical
aspect I can imagine of is large flat lists that should generally be
avoided in favour of a deeper object structure. IMHO this is a
useful rule even when only considering the usability of a graphical
application.<br>
<br>
<blockquote cite="mid:k5hqjk$f3l$1@xxxxxxxxe.org" type="cite">4
JFace databinding supports EMF, so JFace Databinding + CDO is a
great combination, you might want to watch loading large chunks of
data into your UI widgets (tables + trees), but there are ways to
limit the volumes. </blockquote>
I fully agree that EMF databinding is a totally cool thing. One
thing that tends to be problematic are remote deletions because the
databinding layer caches some strong references to objects that
might, all of a sudden, start to throw InvalidObjectExceptions or
ObjectNotFoundExceptions. You may appreciate that in CDO 4.2 we now
changed to:<br>
<br>
public static final CDOStaleReferencePolicy DEFAULT = PROXY;<br>
<br>
public static final CDOInvalidationPolicy DEFAULT = RELAXED;<br>
<br>
<br>
<blockquote cite="mid:k5hqjk$f3l$1@xxxxxxxxe.org" type="cite">5 I
you need to do something with DSL's (Develop a textual syntax,
which can interact with EMF/CDO models), this is also great with
xtext.
<br>
</blockquote>
Yes, because "CDO == EMF". But please keep in mind that editing DSL
instances stored *in* CDO with an Xtexteditor is problematic because
a text editor generally doesn't preserve the identities (e.g.
CDOIDs) of objects. That makes it hard to reconcile changes made in
a text editor back to CDO.<br>
<br>
<blockquote cite="mid:k5hqjk$f3l$1@xxxxxxxxe.org" type="cite">6
CDO performs well, you can tweak it, to fetch more or less chunks
of data for EReferences. If you don't like the behaviour you can
fire CDO Queries to get exactly what you want. Also unused objects
are garbage collected, so you can safely read a lot of data (As
long as you don't keep a reference). </blockquote>
Funnily this scalability originally came as a by-product of the
auditing functionality ;-)<br>
<br>
<blockquote cite="mid:k5hqjk$f3l$1@xxxxxxxxe.org" type="cite">7 I
am really fond that objects have a lifecycle, and all my object
have a unique CDO ID. I actually present the CDOID, in the status
line of the app. It's a great way to check what's going on. </blockquote>
And now you can even plug in your own CDOIDGenerator at the
client-side:<br>
<br>
public interface CDOIDGenerator<br>
{<br>
public static final CDOIDGenerator UUID = new CDOIDGenerator()<br>
{<br>
public CDOID generateCDOID(EObject object)<br>
{<br>
byte[] bytes = new byte[16];<br>
UUIDGenerator.DEFAULT.generate(bytes);<br>
return CDOIDUtil.createUUID(bytes);<br>
}<br>
<br>
public void reset()<br>
{<br>
// Do nothing<br>
}<br>
};<br>
<br>
/**<br>
* Generates a {@link CDOID}.<br>
* <br>
* @param object<br>
* the object to generate a new CDOID for if available,
<code>null</code> otherwise.<br>
*/<br>
public CDOID generateCDOID(EObject object);<br>
<br>
/**<br>
* Called at the end of a commit operation to give this ID
generator a chance to reset its sequence of IDs.<br>
*/<br>
public void reset();<br>
}<br>
<br>
<blockquote cite="mid:k5hqjk$f3l$1@xxxxxxxxe.org" type="cite">
8 Invalidations are great, basically when an object goes, remotely
dirty, other views are notified and can get the latest status of
an object. <br>
<br>
What I could do without in CDO
<br>
<br>
9. Revisions & referential integrity, I loved it at first, but
right now for the app. I have. it's a burden. The concept of
revisions adds a lot of requirements in CDO, I think CDO should
also have a simpler flat mode, without the revisions and checks on
integrity. It adds to the complexity of the CDO middleware and the
generated DB get's schema's. Some apps, don't need it or need it
partially. In my case, I would need revisions for some classes
only. </blockquote>
I suspect you don't refer to CDORevisions but to the auditing mode
in general? You know that it can be switched off. Granted, for the
DBStore in particular
<a class="moz-txt-link-freetext" href="https://bugs.eclipse.org/bugs/show_bug.cgi?id=351068">https://bugs.eclipse.org/bugs/show_bug.cgi?id=351068</a> is pending. I
really want to work on this soon.<br>
<br>
Partial auditing has been requested in the past. Conceptually I
don't like the idea because the framework couldn't guarantee the
logical consistency of the graph anymore. But I'm willing to
reconsider this when the DBStore gets its next design overhaul (not
scheduled, yet).<br>
<br>
What exact integrity checks are you referring to? Referential
integrity checks in the repository can be switched off (and they are
by default).<br>
<br>
<blockquote cite="mid:k5hqjk$f3l$1@xxxxxxxxe.org" type="cite">It
sometimes feels CDO is trying to mimic a Concurrent Version System
like SVN or CVS, but for many apps you really don't need that. <br>
</blockquote>
Yes, CDO tries to offer support in both worlds, the database
driven-like runtime applications and the more tool-like use cases
where design-time models need to be stored/managed in a repository.
You can imagine that this is sometimes hard but I think we've done a
pretty good job. Are there particular parts in CDO that are
problematic for you in this regard (i.e., not just unneeded)?<br>
<br>
BTW. an example of a cool new SCM-like feature is our new History
view support for repositories, branches or single objects:<br>
<br>
<img src="http://www.eclipse.org/forums/index.php?t=getfile&id=11928" alt=""><br>
<br>
<blockquote cite="mid:k5hqjk$f3l$1@xxxxxxxxe.org" type="cite">10.
In CDO there are CDOFolders and CDOResources. </blockquote>
Yes, and CDOTextResources and CDOBinaryResources, which are now
(almost) first class citizens of a CDO repository:<br>
<br>
<img src="http://www.eclipse.org/forums/index.php?t=getfile&id=11929" alt=""><br>
<br>
<blockquote cite="mid:k5hqjk$f3l$1@xxxxxxxxe.org" type="cite">Both
are also CDO objects, and stored in the DB. I went through great
length to find the best way to use them, like the the names to
give them, which is meta information you need to deal with in the
application. (Remember which name you used for which resource to
keep which data objects, in my case each eclass has its own
cdoresource). </blockquote>
Yes, that's the main value of Resources in general: They provide
well-known entry points into the (persistent) graph of objects.<br>
<br>
Apart from that they're an essential part of "CDO == EMF" (see point
1).<br>
<br>
<blockquote cite="mid:k5hqjk$f3l$1@xxxxxxxxe.org" type="cite">Right
now, I am not sure what the added value is of these, besides some
additional grouping of objects, I think, without them it could
keep CDO simpler and avoid additional DB data. </blockquote>
Please note that you absolutely don't need to use CDOResourceFolders
and CDOResources (except for a single one to contain all other
objects). The characteristics of a CDO model is the same when you
store all objects in a single resource.<br>
<br>
<blockquote cite="mid:k5hqjk$f3l$1@xxxxxxxxe.org" type="cite">(Note
that in point 3, I mentioned the EMF Editing domain, which has a
ResourceSet which can hold CDOResource objects. I use this, so
without CDO Resources, I wouldn't be able to use an editing
domain, so something else would be needed). <br>
</blockquote>
I think the generated editors also make heavy use of the assumption
that objects are contained by resources.<br>
<br>
<blockquote cite="mid:k5hqjk$f3l$1@xxxxxxxxe.org" type="cite">What
I wish for in CDO.
<br>
<br>
11. Model migrations. There are initiatives like COPE, which could
be applied with CDO, that would be great. So add a class in your
model, and let the new feature deal with the migration and transit
your data. </blockquote>
Fully agreed. If only someone would need it enough to open the
wallet and fund the development of this feature :P<br>
<br>
<blockquote cite="mid:k5hqjk$f3l$1@xxxxxxxxe.org" type="cite">12.
It's a hard learning curve, because most of the docs are outdated
or not written, so mea-culpa, we could do better. I wish for a
thriving community around a general purpose
smart-object-persistence system like CDO. <br>
</blockquote>
Yes! Technical writers in the world, here's a project that needs you
;-)<br>
<br>
<blockquote cite="mid:k5hqjk$f3l$1@xxxxxxxxe.org" type="cite">Finally.
Eike Stepper and others, have been great in supporting me on this
forum. Generally very quick and helpful!<br>
</blockquote>
Good docs would certainly be nicer but, while they're absent, good
online support is our attempt to compensate ;-)<br>
<br>
Cheers<br>
/Eike<br>
<br>
----<br>
<a class="moz-txt-link-freetext" href="http://www.esc-net.de">http://www.esc-net.de</a><br>
<a class="moz-txt-link-freetext" href="http://thegordian.blogspot.com">http://thegordian.blogspot.com</a><br>
<a class="moz-txt-link-freetext" href="http://twitter.com/eikestepper">http://twitter.com/eikestepper</a><br>
<br>
<br>
<br>
</body>
</html>
-
Attachment: bgchgghb.png
(Size: 83.23KB, Downloaded 115 times) -
Attachment: edjjaeef.png
(Size: 16.76KB, Downloaded 142 times)
Cheers
/Eike
----
http://www.esc-net.de
http://thegordian.blogspot.com
http://twitter.com/eikestepper
|
|
|
| Re: Understanding CDO [message #946530 is a reply to message #945941] |
Tue, 16 October 2012 06:30 |
|
<html>
<head>
<meta content="text/html; charset=UTF-8" http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
Hi Christophe,<br>
<br>
Thank you very much for your detailed experience report. I like it
lot ;-)<br>
<br>
More comments below...<br>
<br>
<br>
<div class="moz-cite-prefix">Am 15.10.2012 22:10, schrieb Christophe
Bouhier:<br>
</div>
<blockquote cite="mid:k5hqjk$f3l$1@xxxxxxxxe.org" type="cite">Hello
Mauro, <br>
for the last 2 years, I have been working on a client/server
application using CDO. Depending on your needs, CDO could be the
right fit. <br>
What I like (a lot). <br>
1 CDO == EMF, so you can model data first in .xsd or directly in
.ecore, and you can tell CDO to use your generated packages, which
will build the DB schema. </blockquote>
EMF compliance is very important to us and we're proud to support
most of EMF's features. Among the few exceptions are:<br>
<br>
a) Feature maps are hard to deal with in RDBs<br>
<br>
b) Because CDOResources are EObjects (see point 10) a small number
of other frameworks may run into trouble when trying to find out the
concrete type of a Notifier because the result depends on a
particular order of instanceof checks (check Resources first).<br>
<br>
c) With remote change notifications enabled, i.e.,
view.options().addChangeSubscriptionPolicy(...), your own Adapters
often need to distinguish between local or remote changes. An
instanceof CDODeltaNotification does the trick.<br>
<br>
d) Some IDE applications (and some poorly designed frameworks such
as GMF) heavily rely on IResources which are probably impossible to
simulate for CDOResources. For example it's hard or impossible to
present problem markers for validation problems in CDOResources
because IMarkers are associated with IResources. This is not a CDO
problem but a platform/IMarker problem that other
non-"platform:resource" Resources share in common.<br>
<br>
<blockquote cite="mid:k5hqjk$f3l$1@xxxxxxxxe.org" type="cite">2
On the CDO Store, you can choose from the DBStore, which supports
various DB's, I have worked with MySQL and Postgres. With
Hibernate store, there is an additional ORM layer, which works
with tons of other DB's supported by Hibernate. </blockquote>
And there's support for some other backend types, such as DB4O,
MongoDB or Objectivity/DB. I've recently developed a
RandomAccessFile based journaling store, named LissomeStore. It
still uses an RDB for a small and fixed number of indexes into the
random access file(s). For commits it uses a journal file and
adjusts the index tables asynchronously. The performance of large
commits can typically be increased by factor 600 in my tests.<br>
<br>
IMHO the great value of the IStore design is that it becomes a snap
to *change* the backend choice at any time without much impact on
the application (except you're making heavy use of backend-specifc
IQueryHandlers such as SQL or HQL).<br>
<br>
<blockquote cite="mid:k5hqjk$f3l$1@xxxxxxxxe.org" type="cite">3
As CDO == EMF, you can easily adapt a generated RCP Client EMF
editor for CDO, but in practice you are likely better of to start
UI design from scratch, but you can re-use the concept of an
Editing domain and EMF.edit generated code, which is what I do.
(ItemProviders and Commands). </blockquote>
It's a major goal of CDO to better separate the functional from the
the technical design aspects/tasks. The only intrusive technical
aspect I can imagine of is large flat lists that should generally be
avoided in favour of a deeper object structure. IMHO this is a
useful rule even when only considering the usability of a graphical
application.<br>
<br>
<blockquote cite="mid:k5hqjk$f3l$1@xxxxxxxxe.org" type="cite">4
JFace databinding supports EMF, so JFace Databinding + CDO is a
great combination, you might want to watch loading large chunks of
data into your UI widgets (tables + trees), but there are ways to
limit the volumes. </blockquote>
I fully agree that EMF databinding is a totally cool thing. One
thing that tends to be problematic are remote deletions because the
databinding layer caches some strong references to objects that
might, all of a sudden, start to throw InvalidObjectExceptions or
ObjectNotFoundExceptions. You may appreciate that in CDO 4.2 we now
changed to:<br>
<br>
public static final CDOStaleReferencePolicy DEFAULT = PROXY;<br>
<br>
public static final CDOInvalidationPolicy DEFAULT = RELAXED;<br>
<br>
<br>
<blockquote cite="mid:k5hqjk$f3l$1@xxxxxxxxe.org" type="cite">5 I
you need to do something with DSL's (Develop a textual syntax,
which can interact with EMF/CDO models), this is also great with
xtext.
<br>
</blockquote>
Yes, because "CDO == EMF". But please keep in mind that editing DSL
instances stored *in* CDO with an Xtexteditor is problematic because
a text editor generally doesn't preserve the identities (e.g.
CDOIDs) of objects. That makes it hard to reconcile changes made in
a text editor back to CDO.<br>
<br>
<blockquote cite="mid:k5hqjk$f3l$1@xxxxxxxxe.org" type="cite">6
CDO performs well, you can tweak it, to fetch more or less chunks
of data for EReferences. If you don't like the behaviour you can
fire CDO Queries to get exactly what you want. Also unused objects
are garbage collected, so you can safely read a lot of data (As
long as you don't keep a reference). </blockquote>
Funnily this scalability originally came as a by-product of the
auditing functionality ;-)<br>
<br>
<blockquote cite="mid:k5hqjk$f3l$1@xxxxxxxxe.org" type="cite">7 I
am really fond that objects have a lifecycle, and all my object
have a unique CDO ID. I actually present the CDOID, in the status
line of the app. It's a great way to check what's going on. </blockquote>
And now you can even plug in your own CDOIDGenerator at the
client-side:<br>
<br>
public interface CDOIDGenerator<br>
{<br>
public static final CDOIDGenerator UUID = new CDOIDGenerator()<br>
{<br>
public CDOID generateCDOID(EObject object)<br>
{<br>
byte[] bytes = new byte[16];<br>
UUIDGenerator.DEFAULT.generate(bytes);<br>
return CDOIDUtil.createUUID(bytes);<br>
}<br>
<br>
public void reset()<br>
{<br>
// Do nothing<br>
}<br>
};<br>
<br>
/**<br>
* Generates a {@link CDOID}.<br>
* <br>
* @param object<br>
* the object to generate a new CDOID for if available,
<code>null</code> otherwise.<br>
*/<br>
public CDOID generateCDOID(EObject object);<br>
<br>
/**<br>
* Called at the end of a commit operation to give this ID
generator a chance to reset its sequence of IDs.<br>
*/<br>
public void reset();<br>
}<br>
<br>
<blockquote cite="mid:k5hqjk$f3l$1@xxxxxxxxe.org" type="cite">
8 Invalidations are great, basically when an object goes, remotely
dirty, other views are notified and can get the latest status of
an object. <br>
<br>
What I could do without in CDO
<br>
<br>
9. Revisions & referential integrity, I loved it at first, but
right now for the app. I have. it's a burden. The concept of
revisions adds a lot of requirements in CDO, I think CDO should
also have a simpler flat mode, without the revisions and checks on
integrity. It adds to the complexity of the CDO middleware and the
generated DB get's schema's. Some apps, don't need it or need it
partially. In my case, I would need revisions for some classes
only. </blockquote>
I suspect you don't refer to CDORevisions but to the auditing mode
in general? You know that it can be switched off. Granted, for the
DBStore in particular
<a class="moz-txt-link-freetext" href="https://bugs.eclipse.org/bugs/show_bug.cgi?id=351068">https://bugs.eclipse.org/bugs/show_bug.cgi?id=351068</a> is pending. I
really want to work on this soon.<br>
<br>
Partial auditing has been requested in the past. Conceptually I
don't like the idea because the framework couldn't guarantee the
logical consistency of the graph anymore. But I'm willing to
reconsider this when the DBStore gets its next design overhaul (not
scheduled, yet).<br>
<br>
What exact integrity checks are you referring to? Referential
integrity checks in the repository can be switched off (and they are
by default).<br>
<br>
<blockquote cite="mid:k5hqjk$f3l$1@xxxxxxxxe.org" type="cite">It
sometimes feels CDO is trying to mimic a Concurrent Version System
like SVN or CVS, but for many apps you really don't need that. <br>
</blockquote>
Yes, CDO tries to offer support in both worlds, the database
driven-like runtime applications and the more tool-like use cases
where design-time models need to be stored/managed in a repository.
You can imagine that this is sometimes hard but I think we've done a
pretty good job. Are there particular parts in CDO that are
problematic for you in this regard (i.e., not just unneeded)?<br>
<br>
BTW. an example of a cool new SCM-like feature is our new History
view support for repositories, branches or single objects:<br>
<br>
<img src="http://www.eclipse.org/forums/index.php?t=getfile&id=11931" alt=""><br>
<br>
<blockquote cite="mid:k5hqjk$f3l$1@xxxxxxxxe.org" type="cite">10.
In CDO there are CDOFolders and CDOResources. </blockquote>
Yes, and CDOTextResources and CDOBinaryResources, which are now
(almost) first class citizens of a CDO repository:<br>
<br>
<img src="http://www.eclipse.org/forums/index.php?t=getfile&id=11932" alt=""><br>
<br>
<blockquote cite="mid:k5hqjk$f3l$1@xxxxxxxxe.org" type="cite">Both
are also CDO objects, and stored in the DB. I went through great
length to find the best way to use them, like the the names to
give them, which is meta information you need to deal with in the
application. (Remember which name you used for which resource to
keep which data objects, in my case each eclass has its own
cdoresource). </blockquote>
Yes, that's the main value of Resources in general: They provide
well-known entry points into the (persistent) graph of objects.<br>
<br>
Apart from that they're an essential part of "CDO == EMF" (see point
1).<br>
<br>
<blockquote cite="mid:k5hqjk$f3l$1@xxxxxxxxe.org" type="cite">Right
now, I am not sure what the added value is of these, besides some
additional grouping of objects, I think, without them it could
keep CDO simpler and avoid additional DB data. </blockquote>
Please note that you absolutely don't need to use CDOResourceFolders
and CDOResources (except for a single one to contain all other
objects). The characteristics of a CDO model is the same when you
store all objects in a single resource.<br>
<br>
<blockquote cite="mid:k5hqjk$f3l$1@xxxxxxxxe.org" type="cite">(Note
that in point 3, I mentioned the EMF Editing domain, which has a
ResourceSet which can hold CDOResource objects. I use this, so
without CDO Resources, I wouldn't be able to use an editing
domain, so something else would be needed). <br>
</blockquote>
I think the generated editors also make heavy use of the assumption
that objects are contained by resources.<br>
<br>
<blockquote cite="mid:k5hqjk$f3l$1@xxxxxxxxe.org" type="cite">What
I wish for in CDO.
<br>
<br>
11. Model migrations. There are initiatives like COPE, which could
be applied with CDO, that would be great. So add a class in your
model, and let the new feature deal with the migration and transit
your data. </blockquote>
Fully agreed. If only someone would need it enough to open the
wallet and fund the development of this feature :P<br>
<br>
<blockquote cite="mid:k5hqjk$f3l$1@xxxxxxxxe.org" type="cite">12.
It's a hard learning curve, because most of the docs are outdated
or not written, so mea-culpa, we could do better. I wish for a
thriving community around a general purpose
smart-object-persistence system like CDO. <br>
</blockquote>
Yes! Technical writers in the world, here's a project that needs you
;-)<br>
<br>
<blockquote cite="mid:k5hqjk$f3l$1@xxxxxxxxe.org" type="cite">Finally.
Eike Stepper and others, have been great in supporting me on this
forum. Generally very quick and helpful!<br>
</blockquote>
Good docs would certainly be nicer but, while they're absent, good
online support is our attempt to compensate ;-)<br>
<br>
Cheers<br>
/Eike<br>
<br>
----<br>
<a class="moz-txt-link-freetext" href="http://www.esc-net.de">http://www.esc-net.de</a><br>
<a class="moz-txt-link-freetext" href="http://thegordian.blogspot.com">http://thegordian.blogspot.com</a><br>
<a class="moz-txt-link-freetext" href="http://twitter.com/eikestepper">http://twitter.com/eikestepper</a><br>
<br>
<br>
<br>
</body>
</html>
-
Attachment: bgchgghb.png
(Size: 83.23KB, Downloaded 130 times) -
Attachment: edjjaeef.png
(Size: 16.76KB, Downloaded 125 times)
Cheers
/Eike
----
http://www.esc-net.de
http://thegordian.blogspot.com
http://twitter.com/eikestepper
|
|
|
| Re: Understanding CDO [message #946534 is a reply to message #945941] |
Tue, 16 October 2012 06:30 |
|
<html>
<head>
<meta content="text/html; charset=UTF-8" http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
Hi Christophe,<br>
<br>
Thank you very much for your detailed experience report. I like it
lot ;-)<br>
<br>
More comments below...<br>
<br>
<br>
<div class="moz-cite-prefix">Am 15.10.2012 22:10, schrieb Christophe
Bouhier:<br>
</div>
<blockquote cite="mid:k5hqjk$f3l$1@xxxxxxxxe.org" type="cite">Hello
Mauro, <br>
for the last 2 years, I have been working on a client/server
application using CDO. Depending on your needs, CDO could be the
right fit. <br>
What I like (a lot). <br>
1 CDO == EMF, so you can model data first in .xsd or directly in
.ecore, and you can tell CDO to use your generated packages, which
will build the DB schema. </blockquote>
EMF compliance is very important to us and we're proud to support
most of EMF's features. Among the few exceptions are:<br>
<br>
a) Feature maps are hard to deal with in RDBs<br>
<br>
b) Because CDOResources are EObjects (see point 10) a small number
of other frameworks may run into trouble when trying to find out the
concrete type of a Notifier because the result depends on a
particular order of instanceof checks (check Resources first).<br>
<br>
c) With remote change notifications enabled, i.e.,
view.options().addChangeSubscriptionPolicy(...), your own Adapters
often need to distinguish between local or remote changes. An
instanceof CDODeltaNotification does the trick.<br>
<br>
d) Some IDE applications (and some poorly designed frameworks such
as GMF) heavily rely on IResources which are probably impossible to
simulate for CDOResources. For example it's hard or impossible to
present problem markers for validation problems in CDOResources
because IMarkers are associated with IResources. This is not a CDO
problem but a platform/IMarker problem that other
non-"platform:resource" Resources share in common.<br>
<br>
<blockquote cite="mid:k5hqjk$f3l$1@xxxxxxxxe.org" type="cite">2
On the CDO Store, you can choose from the DBStore, which supports
various DB's, I have worked with MySQL and Postgres. With
Hibernate store, there is an additional ORM layer, which works
with tons of other DB's supported by Hibernate. </blockquote>
And there's support for some other backend types, such as DB4O,
MongoDB or Objectivity/DB. I've recently developed a
RandomAccessFile based journaling store, named LissomeStore. It
still uses an RDB for a small and fixed number of indexes into the
random access file(s). For commits it uses a journal file and
adjusts the index tables asynchronously. The performance of large
commits can typically be increased by factor 600 in my tests.<br>
<br>
IMHO the great value of the IStore design is that it becomes a snap
to *change* the backend choice at any time without much impact on
the application (except you're making heavy use of backend-specifc
IQueryHandlers such as SQL or HQL).<br>
<br>
<blockquote cite="mid:k5hqjk$f3l$1@xxxxxxxxe.org" type="cite">3
As CDO == EMF, you can easily adapt a generated RCP Client EMF
editor for CDO, but in practice you are likely better of to start
UI design from scratch, but you can re-use the concept of an
Editing domain and EMF.edit generated code, which is what I do.
(ItemProviders and Commands). </blockquote>
It's a major goal of CDO to better separate the functional from the
the technical design aspects/tasks. The only intrusive technical
aspect I can imagine of is large flat lists that should generally be
avoided in favour of a deeper object structure. IMHO this is a
useful rule even when only considering the usability of a graphical
application.<br>
<br>
<blockquote cite="mid:k5hqjk$f3l$1@xxxxxxxxe.org" type="cite">4
JFace databinding supports EMF, so JFace Databinding + CDO is a
great combination, you might want to watch loading large chunks of
data into your UI widgets (tables + trees), but there are ways to
limit the volumes. </blockquote>
I fully agree that EMF databinding is a totally cool thing. One
thing that tends to be problematic are remote deletions because the
databinding layer caches some strong references to objects that
might, all of a sudden, start to throw InvalidObjectExceptions or
ObjectNotFoundExceptions. You may appreciate that in CDO 4.2 we now
changed to:<br>
<br>
public static final CDOStaleReferencePolicy DEFAULT = PROXY;<br>
<br>
public static final CDOInvalidationPolicy DEFAULT = RELAXED;<br>
<br>
<br>
<blockquote cite="mid:k5hqjk$f3l$1@xxxxxxxxe.org" type="cite">5 I
you need to do something with DSL's (Develop a textual syntax,
which can interact with EMF/CDO models), this is also great with
xtext.
<br>
</blockquote>
Yes, because "CDO == EMF". But please keep in mind that editing DSL
instances stored *in* CDO with an Xtexteditor is problematic because
a text editor generally doesn't preserve the identities (e.g.
CDOIDs) of objects. That makes it hard to reconcile changes made in
a text editor back to CDO.<br>
<br>
<blockquote cite="mid:k5hqjk$f3l$1@xxxxxxxxe.org" type="cite">6
CDO performs well, you can tweak it, to fetch more or less chunks
of data for EReferences. If you don't like the behaviour you can
fire CDO Queries to get exactly what you want. Also unused objects
are garbage collected, so you can safely read a lot of data (As
long as you don't keep a reference). </blockquote>
Funnily this scalability originally came as a by-product of the
auditing functionality ;-)<br>
<br>
<blockquote cite="mid:k5hqjk$f3l$1@xxxxxxxxe.org" type="cite">7 I
am really fond that objects have a lifecycle, and all my object
have a unique CDO ID. I actually present the CDOID, in the status
line of the app. It's a great way to check what's going on. </blockquote>
And now you can even plug in your own CDOIDGenerator at the
client-side:<br>
<br>
public interface CDOIDGenerator<br>
{<br>
public static final CDOIDGenerator UUID = new CDOIDGenerator()<br>
{<br>
public CDOID generateCDOID(EObject object)<br>
{<br>
byte[] bytes = new byte[16];<br>
UUIDGenerator.DEFAULT.generate(bytes);<br>
return CDOIDUtil.createUUID(bytes);<br>
}<br>
<br>
public void reset()<br>
{<br>
// Do nothing<br>
}<br>
};<br>
<br>
/**<br>
* Generates a {@link CDOID}.<br>
* <br>
* @param object<br>
* the object to generate a new CDOID for if available,
<code>null</code> otherwise.<br>
*/<br>
public CDOID generateCDOID(EObject object);<br>
<br>
/**<br>
* Called at the end of a commit operation to give this ID
generator a chance to reset its sequence of IDs.<br>
*/<br>
public void reset();<br>
}<br>
<br>
<blockquote cite="mid:k5hqjk$f3l$1@xxxxxxxxe.org" type="cite">
8 Invalidations are great, basically when an object goes, remotely
dirty, other views are notified and can get the latest status of
an object. <br>
<br>
What I could do without in CDO
<br>
<br>
9. Revisions & referential integrity, I loved it at first, but
right now for the app. I have. it's a burden. The concept of
revisions adds a lot of requirements in CDO, I think CDO should
also have a simpler flat mode, without the revisions and checks on
integrity. It adds to the complexity of the CDO middleware and the
generated DB get's schema's. Some apps, don't need it or need it
partially. In my case, I would need revisions for some classes
only. </blockquote>
I suspect you don't refer to CDORevisions but to the auditing mode
in general? You know that it can be switched off. Granted, for the
DBStore in particular
<a class="moz-txt-link-freetext" href="https://bugs.eclipse.org/bugs/show_bug.cgi?id=351068">https://bugs.eclipse.org/bugs/show_bug.cgi?id=351068</a> is pending. I
really want to work on this soon.<br>
<br>
Partial auditing has been requested in the past. Conceptually I
don't like the idea because the framework couldn't guarantee the
logical consistency of the graph anymore. But I'm willing to
reconsider this when the DBStore gets its next design overhaul (not
scheduled, yet).<br>
<br>
What exact integrity checks are you referring to? Referential
integrity checks in the repository can be switched off (and they are
by default).<br>
<br>
<blockquote cite="mid:k5hqjk$f3l$1@xxxxxxxxe.org" type="cite">It
sometimes feels CDO is trying to mimic a Concurrent Version System
like SVN or CVS, but for many apps you really don't need that. <br>
</blockquote>
Yes, CDO tries to offer support in both worlds, the database
driven-like runtime applications and the more tool-like use cases
where design-time models need to be stored/managed in a repository.
You can imagine that this is sometimes hard but I think we've done a
pretty good job. Are there particular parts in CDO that are
problematic for you in this regard (i.e., not just unneeded)?<br>
<br>
BTW. an example of a cool new SCM-like feature is our new History
view support for repositories, branches or single objects:<br>
<br>
<img src="http://www.eclipse.org/forums/index.php?t=getfile&id=11933" alt=""><br>
<br>
<blockquote cite="mid:k5hqjk$f3l$1@xxxxxxxxe.org" type="cite">10.
In CDO there are CDOFolders and CDOResources. </blockquote>
Yes, and CDOTextResources and CDOBinaryResources, which are now
(almost) first class citizens of a CDO repository:<br>
<br>
<img src="http://www.eclipse.org/forums/index.php?t=getfile&id=11934" alt=""><br>
<br>
<blockquote cite="mid:k5hqjk$f3l$1@xxxxxxxxe.org" type="cite">Both
are also CDO objects, and stored in the DB. I went through great
length to find the best way to use them, like the the names to
give them, which is meta information you need to deal with in the
application. (Remember which name you used for which resource to
keep which data objects, in my case each eclass has its own
cdoresource). </blockquote>
Yes, that's the main value of Resources in general: They provide
well-known entry points into the (persistent) graph of objects.<br>
<br>
Apart from that they're an essential part of "CDO == EMF" (see point
1).<br>
<br>
<blockquote cite="mid:k5hqjk$f3l$1@xxxxxxxxe.org" type="cite">Right
now, I am not sure what the added value is of these, besides some
additional grouping of objects, I think, without them it could
keep CDO simpler and avoid additional DB data. </blockquote>
Please note that you absolutely don't need to use CDOResourceFolders
and CDOResources (except for a single one to contain all other
objects). The characteristics of a CDO model is the same when you
store all objects in a single resource.<br>
<br>
<blockquote cite="mid:k5hqjk$f3l$1@xxxxxxxxe.org" type="cite">(Note
that in point 3, I mentioned the EMF Editing domain, which has a
ResourceSet which can hold CDOResource objects. I use this, so
without CDO Resources, I wouldn't be able to use an editing
domain, so something else would be needed). <br>
</blockquote>
I think the generated editors also make heavy use of the assumption
that objects are contained by resources.<br>
<br>
<blockquote cite="mid:k5hqjk$f3l$1@xxxxxxxxe.org" type="cite">What
I wish for in CDO.
<br>
<br>
11. Model migrations. There are initiatives like COPE, which could
be applied with CDO, that would be great. So add a class in your
model, and let the new feature deal with the migration and transit
your data. </blockquote>
Fully agreed. If only someone would need it enough to open the
wallet and fund the development of this feature :P<br>
<br>
<blockquote cite="mid:k5hqjk$f3l$1@xxxxxxxxe.org" type="cite">12.
It's a hard learning curve, because most of the docs are outdated
or not written, so mea-culpa, we could do better. I wish for a
thriving community around a general purpose
smart-object-persistence system like CDO. <br>
</blockquote>
Yes! Technical writers in the world, here's a project that needs you
;-)<br>
<br>
<blockquote cite="mid:k5hqjk$f3l$1@xxxxxxxxe.org" type="cite">Finally.
Eike Stepper and others, have been great in supporting me on this
forum. Generally very quick and helpful!<br>
</blockquote>
Good docs would certainly be nicer but, while they're absent, good
online support is our attempt to compensate ;-)<br>
<br>
Cheers<br>
/Eike<br>
<br>
----<br>
<a class="moz-txt-link-freetext" href="http://www.esc-net.de">http://www.esc-net.de</a><br>
<a class="moz-txt-link-freetext" href="http://thegordian.blogspot.com">http://thegordian.blogspot.com</a><br>
<a class="moz-txt-link-freetext" href="http://twitter.com/eikestepper">http://twitter.com/eikestepper</a><br>
<br>
<br>
<br>
</body>
</html>
-
Attachment: bgchgghb.png
(Size: 83.23KB, Downloaded 103 times) -
Attachment: edjjaeef.png
(Size: 16.76KB, Downloaded 125 times)
Cheers
/Eike
----
http://www.esc-net.de
http://thegordian.blogspot.com
http://twitter.com/eikestepper
|
|
| |
| Re: Understanding CDO [message #961444 is a reply to message #946359] |
Sun, 28 October 2012 09:20 |
Guido Scalise
Messages: 16
Registered: April 2012 |
Junior Member |
|
|
El 16/10/2012 8:30, Eike Stepper escribió:
>> 5 I you need to do something with DSL's (Develop a textual syntax,
>> which can interact with EMF/CDO models), this is also great with xtext.
> Yes, because "CDO == EMF". But please keep in mind that editing DSL
> instances stored *in* CDO with an Xtexteditor is problematic because a
> text editor generally doesn't preserve the identities (e.g. CDOIDs) of
> objects. That makes it hard to reconcile changes made in a text editor
> back to CDO.
We've had exactly this same situation... but, in our experience, even
for a very simple expression language like ours (3 operators, 5 types of
operands, no modules, no functions), the amount of model changes fired
due to a simple modification of a DSL source was too large for the
benefit of having the parsed expression in the DB. Also there are
potential pitfalls due to the fact that Xtext won't generate/manage
CDOObjects but plain EObjects.
So, we opted for keeping the source code in a text attribute in the
model and then parsing the source only when needed. This way we could
also evolve the DSL syntax without fear of breaking the already parsed
elements.
I'd recommend you to stay away from storing your DSL in other form than
plain source code, unless you _must_ have your DSL parsed object model
persistent in CDO.
OTOH, finding some way for Xtext editors to be CDO-aware would open the
path for very interesting collaborative coding tools concepts, don't you
think?.
Regards,
Guido Scalise
|
|
|
| Re: Understanding CDO [message #961457 is a reply to message #961444] |
Sun, 28 October 2012 09:36 |
|
Am 28.10.2012 10:20, schrieb Guido Scalise:
> El 16/10/2012 8:30, Eike Stepper escribió:
>>> 5 I you need to do something with DSL's (Develop a textual syntax,
>>> which can interact with EMF/CDO models), this is also great with xtext.
>> Yes, because "CDO == EMF". But please keep in mind that editing DSL
>> instances stored *in* CDO with an Xtexteditor is problematic because a
>> text editor generally doesn't preserve the identities (e.g. CDOIDs) of
>> objects. That makes it hard to reconcile changes made in a text editor
>> back to CDO.
>
> We've had exactly this same situation... but, in our experience, even for a very simple expression language like ours
> (3 operators, 5 types of operands, no modules, no functions), the amount of model changes fired due to a simple
> modification of a DSL source was too large for the benefit of having the parsed expression in the DB.
What exactly do you mean by "amount"? The "number of" or the "size of" or...? Do you still have concrete measures at hand?
> Also there are potential pitfalls due to the fact that Xtext won't generate/manage CDOObjects but plain EObjects.
>
> So, we opted for keeping the source code in a text attribute in the model and then parsing the source only when
> needed. This way we could also evolve the DSL syntax without fear of breaking the already parsed elements.
Also a very reasobale approach, IMHO. You could keep larger texts in a CDOClob attribute and add a derived reference
feature that omputes the AST from the stream that can be obtained from the clob.
> I'd recommend you to stay away from storing your DSL in other form than plain source code, unless you _must_ have your
> DSL parsed object model persistent in CDO.
>
> OTOH, finding some way for Xtext editors to be CDO-aware would open the path for very interesting collaborative coding
> tools concepts, don't you think?.
I do. And Sven Efftinge does so, too. We're very open to any kind of concrete suggestion or contribution.
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
|
|
| |
| [CDO] Xtext Integration [message #961529 is a reply to message #961506] |
Sun, 28 October 2012 10:56 |
|
Hi Christophe,
That sounds and looks very interesting! I'm not an Xtext Xpert ( :P ), yet, to be fully able to judge your approach. But
I've heard the question for Xtext/CDO integration many times already. Funny, just the other day a friend from the UBS
told me about an approach that sounded similar to me. I've CC'ed Robert because he may be interested in adding a
cooment, too.
Am I right that you're remaining questions mostly address the Xtext team? I've renamed this thread and CC'ed Sven as well.
If you think the Xtext-related issues have been clarified sufficiently I'd be happy to review a reusable solution from a
CDO perspective ;-)
Cheers
/Eike
----
http://www.esc-net.de
http://thegordian.blogspot.com
http://twitter.com/eikestepper
Am 28.10.2012 11:31, schrieb Christophe Bouhier:
> Hi Guido,
> Actually this is also the way I work with xtext and CDO, simply serialize it as a String in a CDOObject In my case, I
> have opted to store each DSL line in a list of strings. When I edit the DSL, notifications are used to write the DSL
> in strings out to CDO.
>
> The real interesting challenge, I found is to reference (CDO) model objects from the DSL. For this I needed to create
> a custom implementation of an xtext ScopeProvider. I managed to get it work, even updating IResourceDescriptions when
> CDO invalidations occur. In user experience this means, that I can be editing a DSL, and mean while in an other editor
> add objects which are persisted to CDO. While this happens the xtext ScopeProvider is updated and the user can pick
> added objects from Content assist... It's really sweet. I made an ill-attempt to blog about it here:
>
> http://modelmoo.blogspot.nl/
>
>
> Perhaps it would be useful to others. Cheers Christophe Bouhier
>
>
>
Cheers
/Eike
----
http://www.esc-net.de
http://thegordian.blogspot.com
http://twitter.com/eikestepper
|
|
|
Goto Forum:
Current Time: Fri Apr 19 20:47:01 GMT 2024
Powered by FUDForum. Page generated in 0.07352 seconds |
] 
Search
Help
Register
Login
Home
