Skip to main content


Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Modeling » EMF » Custom Store Developing
Custom Store Developing [message #508922] Wed, 20 January 2010 12:38 Go to next message
Oliver is currently offline OliverFriend
Messages: 20
Registered: July 2009
Junior Member
Hi,

I want to implement a custom store because there is an existing
store in form of a database table. So there is no way to save some
meta informations like versions or class names. I think, it is
impossible to use DBStore without managing versions, packages, folders
and store all EClasses in the same table.
In addition: the emf model is static and consisting of three simple
EClasses: node, attribute and relation. These classes have only EString
attributes (so there are no EReferences, containments etc.) The database
consists of thousands of nodes etc. so scalability of CDO is needed for
model transformations on this big models.

Some questions to Store and StoreAccessor:

- How to call the super constructor?
super(TYPE, set(ChangeFormat.REVISION), set(RevisionTemporality.NONE),
set(RevisionParallelism.NONE)); I don't want to support delats (only
revisions) and no versions.
Have in this case the methods readRevisionByTime, readRevisionByVersion,
writeRevisionDeltas of StoreAccessor to throw a new
UnsupportedOperationException?

- Should Store return true or false for isFirstTime?
Data is already existing in the database but the Store is running first
time. I've note only that commit and writePackageUnit are invoked when
isFirstTime() = false. Have isFirstTime impact on the client side?

- When is createChunkReader is needed?
I think a ChunkReader is needed for lazy loading lists. My model haven't
lists but CDO with CDOResourceNode? It is legal to return a simple
null? What does listChunk mean in readRevision method?

- What have to add to context for queryResources method?
If I right, than context.getFolderID() is the CDOID for the
CDOResourceFolder in that the StoreAccessor have to search. By query the
root ressource, FolderID is null?
/aaa/bbb/ccc/MyInstance
What is in this example ResourceFolder, what is ResourceNode, what is
context? I think, CDO is using lazy loading. So only CDOIDs have to
return but where?

- How to support own CDOIDObjects?
In my case it is really important to use the IDs generated by the
database (auto increment column as primary key). So I have to extend
CDOIDObject and implement CDOIDObjectFactory. No problem, but a problem
is to understand LibraryHandler. getFactoryName, getlibraryNames, write
- no idea what this should do or for what this interface exists.
In case of a own CDOIDObjectFactory, how can I register this factory to
the CDO Session View (I mean the Eclipse view with the plus button to
add sessions etc.). My CDOIDObject implementation returns Type.OBJECT
for getType(). Is this the right type in my case (there are
EXTERNAL_OBJECT, TEMP_OBJECT etc. but no idea what this means)?

- Are there experience with model transformations on big models?
Has any one do model transformations with CDO regards scalability? I
want to use Xtend for it.

Many questions and bad english :)

Ciao Oliver
Re: [CDO] Custom Store Developing [message #508936 is a reply to message #508922] Wed, 20 January 2010 18:42 Go to previous messageGo to next message
Eike Stepper is currently offline Eike StepperFriend
Messages: 6682
Registered: July 2009
Senior Member
This is a multi-part message in MIME format.
--------------000005000706050500060206
Content-Type: text/plain; charset=ISO-8859-15
Content-Transfer-Encoding: 7bit

Hi Oliver,

Please prefix CDO questions with [CDO].

More comments below...


Oliver schrieb:
> Hi,
>
> I want to implement a custom store because there is an existing
> store in form of a database table. So there is no way to save some
> meta informations like versions or class names. I think, it is
> impossible to use DBStore without managing versions, packages, folders
> and store all EClasses in the same table.
> In addition: the emf model is static and consisting of three simple
> EClasses: node, attribute and relation. These classes have only
> EString attributes (so there are no EReferences, containments etc.)
> The database consists of thousands of nodes etc. so scalability of CDO
> is needed for model transformations on this big models.
>
> Some questions to Store and StoreAccessor:
>
> - How to call the super constructor?
> super(TYPE, set(ChangeFormat.REVISION), set(RevisionTemporality.NONE),
> set(RevisionParallelism.NONE)); I don't want to support delats (only
> revisions) and no versions.
Looks reasonable. Note that we're currently discussing to drop the
explicit specification of store capabilities. It's still unclear whether
we'll be relying on marker interfaces or just encourage checks in
doBeforeActivate() to validate that the store can support the repository
configuration.

> Have in this case the methods readRevisionByTime
Yes, but you can ignore the timeStamp parameter then as it will always
be UNSPECIFIED_DATE. Note that in a few days this method will be renamed
to getRevision() because we're introducing CDOBranches. The timeStamp
parameter will become a CDOBranchPoint, carrying a CDOBranch and the
timeStamp.

> , readRevisionByVersion
I think so. Without auditing/versioning you may just validate version==1
and delegate to getRevisionByTime(UNSPECIFIED_DATE).

> , writeRevisionDeltas of StoreAccessor to throw a new
> UnsupportedOperationException?
Yes.

>
> - Should Store return true or false for isFirstTime?
> Data is already existing in the database but the Store is running
> first time. I've note only that commit and writePackageUnit are
> invoked when isFirstTime() = false. Have isFirstTime impact on the
> client side?
I think you can return false. This leads to readPackageUnits being
called on repo startup:
| *if *(store.isFirstTime())
{
initSystemPackages();
}
*else*
{
readPackageUnits();
}|


This leads to a call of
org.eclipse.emf.cdo.server.IStoreAccessor.readPackageUnits() . There you
can construct the CDOPackageUnit and CDOPackageInfo objects that
describe the EPackage that you have statically available.

>
> - When is createChunkReader is needed?
> I think a ChunkReader is needed for lazy loading lists. My model
> haven't lists but CDO with CDOResourceNode? It is legal to return a
> simple null? What does listChunk mean in readRevision method?
You may return null if you don't plan to support partial collection loading.

>
> - What have to add to context for queryResources method?
> If I right, than context.getFolderID() is the CDOID for the
> CDOResourceFolder in that the StoreAccessor have to search. By query
> the root ressource, FolderID is null?
> /aaa/bbb/ccc/MyInstance
> What is in this example ResourceFolder, what is ResourceNode, what is
> context? I think, CDO is using lazy loading. So only CDOIDs have to
> return but where?
Since you don't want to persist data that is not modeled, I assume that
you want to simulate a single resource under the root resource that
contains your model objects. Just verify that the query parameters are
valid:

IStoreAccessor.QueryResourcesContext.getFolderID() == null
IStoreAccessor.QueryResourcesContext.getName() == <name of your resource>

Then call IStoreAccessor.QueryResourcesContext.addResource(CDOID) once
with the static CDOID of your resource. You must further ensure two things:

1) Do not assign the static CDOID of your resource to any other objects
in IStoreAccessor.write(CommitContext, OMMonitor) or
IStoreAccessor.commit(OMMonitor).

2) Be prepared to deliver an appropriate CDORevision from the
readRevisionXYZ() methods if the static CDOID of your resource is
passed. Look at org.eclipse.emf.cdo.eresource.EresourcePackage to get an
impression of the values to provide.

>
> - How to support own CDOIDObjects?
> In my case it is really important to use the IDs generated by the
> database (auto increment column as primary key). So I have to extend
> CDOIDObject and implement CDOIDObjectFactory.
Oh, are you using CDO 2.0? The ID handling has been reworked for CDO
3.0. There is no longer a CDOIDObjectFactory as it turned out to be
fragile because it relied on Java class serialization and ClassLoader
hacking.

What *type* do your PKs have? There's currently build-in support for
long integers (CDOIDObjectLongImpl) and Strings (CDOIDObjectStringImpl).

> No problem, but a problem is to understand LibraryHandler.
> getFactoryName, getlibraryNames, write - no idea what this should do
> or for what this interface exists.
> In case of a own CDOIDObjectFactory, how can I register this factory
> to the CDO Session View (I mean the Eclipse view with the plus button
> to add sessions etc.). My CDOIDObject implementation returns
> Type.OBJECT for getType(). Is this the right type in my case (there
> are EXTERNAL_OBJECT, TEMP_OBJECT etc. but no idea what this means)?
All the other ID types are somewhat system-reserved. You only need to
choose an implementation for CDOIDObject. Note that CDO requires the
value of a CDOID never to change once it's assigned to an object!

>
> - Are there experience with model transformations on big models?
> Has any one do model transformations with CDO regards scalability?
I know of a company on Teneriffe that uses CDO to transform huge models
(ASTs, IIRC.). Vik?

> I want to use Xtend for it.
I don't see problems ;-)

Please report your experiences with usage and extension of CDO back!

Cheers
/Eike

----
http://thegordian.blogspot.com
http://twitter.com/eikestepper



--------------000005000706050500060206
Content-Type: text/html; charset=ISO-8859-15
Content-Transfer-Encoding: 8bit

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=ISO-8859-15"
http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
Hi Oliver,<br>
<br>
Please prefix CDO questions with [CDO].<br>
<br>
More comments below...<br>
<br>
<br>
Oliver schrieb:
<blockquote cite="mid:hj7ebj$2qv$1@build.eclipse.org" type="cite">Hi,
<br>
<br>
I want to implement a custom store because there is an existing
<br>
store in form of a database table. So there is no way to save some
<br>
meta informations like versions or class names. I think, it is
impossible to use DBStore without managing versions, packages, folders
and store all EClasses in the same table.
<br>
In addition: the emf model is static and consisting of three simple
EClasses: node, attribute and relation. These classes have only EString
attributes (so there are no EReferences, containments etc.) The
database consists of thousands of nodes etc. so scalability of CDO is
needed for model transformations on this big models.
<br>
<br>
Some questions to Store and StoreAccessor:
<br>
<br>
- How to call the super constructor?
<br>
super(TYPE, set(ChangeFormat.REVISION), set(RevisionTemporality.NONE),
set(RevisionParallelism.NONE)); I don't want to support delats (only
revisions) and no versions.
<br>
</blockquote>
Looks reasonable. Note that we're currently discussing to drop the
explicit specification of store capabilities. It's still unclear
whether we'll be relying on marker interfaces or just encourage checks
in doBeforeActivate() to validate that the store can support the
repository configuration.<br>
<br>
<blockquote cite="mid:hj7ebj$2qv$1@build.eclipse.org" type="cite">Have
in this case the methods readRevisionByTime</blockquote>
Yes, but you can ignore the timeStamp parameter then as it will always
be UNSPECIFIED_DATE. Note that in a few days this method will be
renamed to getRevision() because we're introducing CDOBranches. The
timeStamp parameter will become a CDOBranchPoint, carrying a CDOBranch
and the timeStamp.<br>
<br>
<blockquote cite="mid:hj7ebj$2qv$1@build.eclipse.org" type="cite">,
readRevisionByVersion</blockquote>
I think so. Without auditing/versioning you may just validate
version==1 and delegate to getRevisionByTime(UNSPECIFIED_DATE).<br>
<br>
<blockquote cite="mid:hj7ebj$2qv$1@build.eclipse.org" type="cite">,
writeRevisionDeltas of StoreAccessor to throw a new
UnsupportedOperationException?
<br>
</blockquote>
Yes.<br>
<br>
<blockquote cite="mid:hj7ebj$2qv$1@build.eclipse.org" type="cite"><br>
- Should Store return true or false for isFirstTime?
<br>
Data is already existing in the database but the Store is running first
time. I've note only that commit and writePackageUnit are invoked when
isFirstTime() = false. Have isFirstTime impact on the client side?
<br>
</blockquote>
I think you can return false. This leads to readPackageUnits being
called on repo startup:<br>
<title></title>
<style type="text/css">
<!--code { font-family: Courier New, Courier; font-size: 10pt; margin: 0px; }-->
</style>
<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1">
<!-- ======================================================== -->
<!-- = Java Sourcecode to HTML automatically converted code = --><!-- = Java2Html Converter 5.0 [2006-02-26] by Markus Gebhard markus@jave.de = -->
<!-- = Further information: http://www.java2html.de = -->
<div class="java" align="left">
<table bgcolor="#ffffff" border="0" cellpadding="3" cellspacing="0">
<tbody>
<tr>
<!-- start source code --> <td align="left" nowrap="nowrap"
valign="top"> <code><font color="#ffffff">


Re: [CDO] Custom Store Developing [message #509190 is a reply to message #508936] Thu, 21 January 2010 15:53 Go to previous messageGo to next message
Victor Roldan Betancort is currently offline Victor Roldan BetancortFriend
Messages: 524
Registered: July 2009
Senior Member
Hi guys,

>> - Are there experience with model transformations on big models?
>> Has any one do model transformations with CDO regards scalability?
> I know of a company on Teneriffe that uses CDO to transform huge models
> (ASTs, IIRC.). Vik?

Yes, we execute model transformations to inventory Cobol/CICS ASTs into
a KDM model. The KDM keeps information from lot of different Cobol
sources from big legacy systems, and its stored in a CDO DBStore
backend. The results are acceptable, but there is a lot of room for
improvement. My opinion (and I guess the same as many folks) is that
there is an important "impedance mismatch" between the object world and
the relational world which causes poor performance. Guys from Hibernate
won't agree with me :P Simon McDuff has deployed CDO using an
Object-Oriented backed that has provided great performance. I've been
developing a DB4O as backend as experiment, and the results are very
positive as well, close to in-memory databases like HSQLDB.

I'm also particularly interested in the NoSQL movement. Some of the
biggest contenders in the Internet are using such technologies (see
google, facebook...). However, the "is it ready for enterprise" question
always raises...

Some interesting links:

Neo4J, graph-based database: http://neo4j.org/
Hypertable, inspired in Google's BigTable: http://www.hypertable.org/
Apache Cassandra, key-value database: http://incubator.apache.org/cassandra/
MongoDB, document database: http://www.mongodb.org/
HBase, also inspired in BigTable: http://hadoop.apache.org/hbase/
.... and many more

Site with lot of resources: http://nosql-databases.org

Would like to see people out there experimenting with these stores :D

Cheers,
Víctor.
Re: [CDO] Custom Store Developing: triple store? [message #509315 is a reply to message #509190] Thu, 21 January 2010 22:48 Go to previous messageGo to next message
Andre Dietisheim is currently offline Andre DietisheimFriend
Messages: 131
Registered: July 2009
Senior Member
Hi guys

Just in case someone else thinks this might be an insteresting store, too:

I got in touch with semantic guys, googled and discovered that a french
university developed a mapper that bridges the OO and the semantic world:

http://code.google.com/p/emftriple/

EMFtriple currently offers a Resource that uses a jena backend. Jena,
for the ones who never heard of it, is a semantic store (backed up by a
database) that handles triples. These guys developed a framework that
transforms triples to ecore objects on behalf of ATL model
transformations and ecore objects to triples by using annotations.

In a birds view, an IStore implementation that uses emftriple
transformation could offer (CDO based) OO access to the ontological
world. Sounded pretty interesting to me.

Cheers
André

Víctor Roldán Betancort wrote:
> I'm also particularly interested in the NoSQL movement. Some of the
> biggest contenders in the Internet are using such technologies (see
> google, facebook...). However, the "is it ready for enterprise" question
> always raises...
>
> Some interesting links:
>
> Neo4J, graph-based database: http://neo4j.org/
> Hypertable, inspired in Google's BigTable: http://www.hypertable.org/
> Apache Cassandra, key-value database:
> http://incubator.apache.org/cassandra/
> MongoDB, document database: http://www.mongodb.org/
> HBase, also inspired in BigTable: http://hadoop.apache.org/hbase/
> .... and many more
>
> Site with lot of resources: http://nosql-databases.org
>
> Would like to see people out there experimenting with these stores :D
>
> Cheers,
> Víctor.
Re: [CDO] Custom Store Developing [message #509550 is a reply to message #508936] Fri, 22 January 2010 20:30 Go to previous messageGo to next message
Oliver is currently offline OliverFriend
Messages: 20
Registered: July 2009
Junior Member
Hi Eike, Victor and Ande,

Thank you verry, verry much!

With your help, Eike, the store is running. I've tested on MySQL and I
can create, delete, update and read nodes, attributes and relations. A
simple modeltransformation working too, wuhu :)

transformation.ext:
import repository;

void addX (Node n):
n.setName(n.name + 'X');

Java:
CDOTransaction transaction = session.openTransaction();
CDOResource resource = transaction.getOrCreateResource("rtr");

XtendFacade facade = XtendFacade.create("C:/transformation");
EmfMetaModel metaModel = new EmfMetaModel(RepositoryPackage.eINSTANCE);
facade.registerMetaModel(metaModel);

Node node = (Node) resource.getContents().get(0);
System.out.println("name before: " + node.getName());
facade.call("addX", new Object[] { node });
System.out.println("name after: " + node.getName());

transaction.commit();
transaction.close();

On monday I will test it with the Oracle consisting of ca. 40'000 nodes,
attributes and relations.

more comments below...

Eike Stepper schrieb:
> Hi Oliver,
>
> Please prefix CDO questions with [CDO].
Sorry, I will do so in the next post.
>
> More comments below...
>
>
> Oliver schrieb:
>> Hi,
>>
>> I want to implement a custom store because there is an existing
>> store in form of a database table. So there is no way to save some
>> meta informations like versions or class names. I think, it is
>> impossible to use DBStore without managing versions, packages, folders
>> and store all EClasses in the same table.
>> In addition: the emf model is static and consisting of three simple
>> EClasses: node, attribute and relation. These classes have only
>> EString attributes (so there are no EReferences, containments etc.)
>> The database consists of thousands of nodes etc. so scalability of CDO
>> is needed for model transformations on this big models.
>>
>> Some questions to Store and StoreAccessor:
>>
>> - How to call the super constructor?
>> super(TYPE, set(ChangeFormat.REVISION), set(RevisionTemporality.NONE),
>> set(RevisionParallelism.NONE)); I don't want to support delats (only
>> revisions) and no versions.
> Looks reasonable. Note that we're currently discussing to drop the
> explicit specification of store capabilities. It's still unclear whether
> we'll be relying on marker interfaces or just encourage checks in
> doBeforeActivate() to validate that the store can support the repository
> configuration.
>
>> Have in this case the methods readRevisionByTime
> Yes, but you can ignore the timeStamp parameter then as it will always
> be UNSPECIFIED_DATE. Note that in a few days this method will be renamed
> to getRevision() because we're introducing CDOBranches. The timeStamp
> parameter will become a CDOBranchPoint, carrying a CDOBranch and the
> timeStamp.
>
>> , readRevisionByVersion
> I think so. Without auditing/versioning you may just validate version==1
> and delegate to getRevisionByTime(UNSPECIFIED_DATE).
>
>> , writeRevisionDeltas of StoreAccessor to throw a new
>> UnsupportedOperationException?
> Yes.
>
>>
>> - Should Store return true or false for isFirstTime?
>> Data is already existing in the database but the Store is running
>> first time. I've note only that commit and writePackageUnit are
>> invoked when isFirstTime() = false. Have isFirstTime impact on the
>> client side?
> I think you can return false. This leads to readPackageUnits being
> called on repo startup:
> | *if *(store.isFirstTime())
> {
> initSystemPackages();
> }
> *else*
> {
> readPackageUnits();
> }|
>
>
> This leads to a call of
> org.eclipse.emf.cdo.server.IStoreAccessor.readPackageUnits() . There you
> can construct the CDOPackageUnit and CDOPackageInfo objects that
> describe the EPackage that you have statically available.
>
In the CDO View it get nerved to register on every session the same
workspace EPackage. Can I avoid this by implementing readPackageUnits()?
So readPackageUnits can send my RepositoryPackage trough CDO and the
client don't have to register manually this EPackage.

>>
>> - When is createChunkReader is needed?
>> I think a ChunkReader is needed for lazy loading lists. My model
>> haven't lists but CDO with CDOResourceNode? It is legal to return a
>> simple null? What does listChunk mean in readRevision method?
> You may return null if you don't plan to support partial collection loading.
Means this, that the CDOResource, wich contains all CDOIDs of the nodes,
attributes
and relations also cannot loaded partially?

>>
>> - What have to add to context for queryResources method?
>> If I right, than context.getFolderID() is the CDOID for the
>> CDOResourceFolder in that the StoreAccessor have to search. By query
>> the root ressource, FolderID is null?
>> /aaa/bbb/ccc/MyInstance
>> What is in this example ResourceFolder, what is ResourceNode, what is
>> context? I think, CDO is using lazy loading. So only CDOIDs have to
>> return but where?
> Since you don't want to persist data that is not modeled, I assume that
> you want to simulate a single resource under the root resource that
> contains your model objects. Just verify that the query parameters are
> valid:
>
> IStoreAccessor.QueryResourcesContext.getFolderID() == null
> IStoreAccessor.QueryResourcesContext.getName() == <name of your resource>
>
> Then call IStoreAccessor.QueryResourcesContext.addResource(CDOID) once
> with the static CDOID of your resource. You must further ensure two things:
>
> 1) Do not assign the static CDOID of your resource to any other objects
> in IStoreAccessor.write(CommitContext, OMMonitor) or
> IStoreAccessor.commit(OMMonitor).
>
> 2) Be prepared to deliver an appropriate CDORevision from the
> readRevisionXYZ() methods if the static CDOID of your resource is
> passed. Look at org.eclipse.emf.cdo.eresource.EresourcePackage to get an
> impression of the values to provide.
>
This was the interesting part :)
CDOIDLongImpl cdoid = (CDOIDLongImpl) id;
for resourceCDOID.equals(cdoid):
CDOList list = revision.getList(EresourcePackage.eINSTANCE
.getCDOResource_Contents());
list.addAll(adapter.getAllCDOIDs());
revision.setListSize(EresourcePackage.eINSTANCE.getCDOResour ce_Contents(),
list.size());

for rootCDOID.equals(cdoid):
CDOList list = revision.getList(EresourcePackage.eINSTANCE
.getCDOResource_Contents());
list.addAll(resourceCDOID);
revision.setListSize(EresourcePackage.eINSTANCE.getCDOResour ce_Contents(),
1);

Where resourceCDOID is the CDOID for the static resource with name "rtr"
and rootCDOID is the CDOID for the static resource with name null.

Please look at list.addAll(adapter.getAllCDOIDs()); The adapter returns
in this case 40'000 new CDOIDLongImpls. Here ends the scalability I
think. For billions of CDOIDs this can't be handled so. But a ResultSet
can handle this partially I think. ChunkReader/listChunk?
>>
>> - How to support own CDOIDObjects?
>> In my case it is really important to use the IDs generated by the
>> database (auto increment column as primary key). So I have to extend
>> CDOIDObject and implement CDOIDObjectFactory.
> Oh, are you using CDO 2.0? The ID handling has been reworked for CDO
> 3.0. There is no longer a CDOIDObjectFactory as it turned out to be
> fragile because it relied on Java class serialization and ClassLoader
> hacking.
>
> What *type* do your PKs have? There's currently build-in support for
> long integers (CDOIDObjectLongImpl) and Strings (CDOIDObjectStringImpl).
>
>> No problem, but a problem is to understand LibraryHandler.
>> getFactoryName, getlibraryNames, write - no idea what this should do
>> or for what this interface exists.
>> In case of a own CDOIDObjectFactory, how can I register this factory
>> to the CDO Session View (I mean the Eclipse view with the plus button
>> to add sessions etc.). My CDOIDObject implementation returns
>> Type.OBJECT for getType(). Is this the right type in my case (there
>> are EXTERNAL_OBJECT, TEMP_OBJECT etc. but no idea what this means)?
> All the other ID types are somewhat system-reserved. You only need to
> choose an implementation for CDOIDObject. Note that CDO requires the
> value of a CDOID never to change once it's assigned to an object!
>
Oh, yes, CDOIDLongImpl was the right. I was confused by addIDMappings in
LongStoreImpl but this can easily override.

>>
>> - Are there experience with model transformations on big models?
>> Has any one do model transformations with CDO regards scalability?
> I know of a company on Teneriffe that uses CDO to transform huge models
> (ASTs, IIRC.). Vik?
>
>> I want to use Xtend for it.
> I don't see problems ;-)
Is CDOResource.getContents() scaleable? Xtend needs all EObject passed
through XtendFacade.call method. Returns getContents() all EObjects or
are there partially returned?
For example:
for (EObject obj : resource.getContents()) {
// do something
}
In my case getContents() would return 40'000 EObjects. But handle CDO
this loop by getting the first e.g. 10000 EObjects, than getting the
next 1000 EObjects and so on?
>
> Please report your experiences with usage and extension of CDO back!
Yes, I want to compare a Xtend transformation and a native PL/SQL
transformation and you getting a report :)
>
> Cheers
> /Eike
>
> ----
> http://thegordian.blogspot.com
> http://twitter.com/eikestepper
>
>

A question to addIDMappings:
The actually addIDMappings method looks like
for (CDORevision revision : context.getNewObjects()) {
EClass eClass = revision.getEClass();
CDOIDTemp oldID = (CDOIDTemp) revision.getID();
CDOID newID = null;
if ("Node".equals(eClass.getName())) {
newID = adapter.getNextCDOID(ObjectType.NODE);
} else if ("Attribute".equals(eClass.getName())) {
newID = adapter.getNextCDOID(ObjectType.ATTRIBUTE);
} else if ("Relation".equals(eClass.getName())) {
newID = adapter.getNextCDOID(ObjectType.RELATION);
// ...
context.addIDMapping(oldID, newID);
}
"Node".equals(eClass.getName()) works but
RepositoryPackage.eINSTANCE.getNode().equals(eClass) not. Both returns
for getName() "Node" but there are two different instances of EClass.
Is revision.getEClass() a dynamic EMF generated EClass?

------------------------------------------------------------ -----------------

Víctor Roldán Betancort schrieb:
> Hi guys,
>
>>> - Are there experience with model transformations on big models?
>>> Has any one do model transformations with CDO regards scalability?
>> I know of a company on Teneriffe that uses CDO to transform huge
>> models (ASTs, IIRC.). Vik?
>
> Yes, we execute model transformations to inventory Cobol/CICS ASTs into
> a KDM model. The KDM keeps information from lot of different Cobol
> sources from big legacy systems, and its stored in a CDO DBStore
> backend.
What do you mean with Cobol/CICS ASTs and KDM? :)
A EMF model represents a AST - Abstract Syntax Tree of a Cobol program
and you do model transformations of this AST into another language "KDM"?
How many EObjects consists a typically model for your transformation?

The results are acceptable, but there is a lot of room for
> improvement. My opinion (and I guess the same as many folks) is that
> there is an important "impedance mismatch" between the object world and
> the relational world which causes poor performance. Guys from Hibernate
> won't agree with me :P Simon McDuff has deployed CDO using an
> Object-Oriented backed that has provided great performance. I've been
> developing a DB4O as backend as experiment, and the results are very
> positive as well, close to in-memory databases like HSQLDB.
>
> I'm also particularly interested in the NoSQL movement. Some of the
> biggest contenders in the Internet are using such technologies (see
> google, facebook...). However, the "is it ready for enterprise" question
> always raises...
>
> Some interesting links:
>
> Neo4J, graph-based database: http://neo4j.org/
> Hypertable, inspired in Google's BigTable: http://www.hypertable.org/
> Apache Cassandra, key-value database:
> http://incubator.apache.org/cassandra/
> MongoDB, document database: http://www.mongodb.org/
> HBase, also inspired in BigTable: http://hadoop.apache.org/hbase/
> ... and many more
>
> Site with lot of resources: http://nosql-databases.org
>
> Would like to see people out there experimenting with these stores :D
>
> Cheers,
> Víctor.
Wow, I've don't heard about NoSQL databases before your post. In
particular Neo4J is a very interesting graph based DB.

And whats with a XML-Storage-Backends? exist-DB
http://exist.sourceforge.net/ e.g. uses PDOM (Persitence DOM, b-tree
based paging mechanism), indexing (incl. lucene fulltext indexing),
transactions, XPath, XQuery, XUpdate as DML.
But I'am not a DB expert :)

------------------------------------------------------------ -----------------


Ande Dietisheim schrieb:
> Hi guys
>
> Just in case someone else thinks this might be an insteresting store,
too:
>
> I got in touch with semantic guys, googled and discovered that a french
> university developed a mapper that bridges the OO and the semantic world:
>
> http://code.google.com/p/emftriple/
>
> EMFtriple currently offers a Resource that uses a jena backend. Jena,
> for the ones who never heard of it, is a semantic store (backed up by a
> database) that handles triples. These guys developed a framework that
> transforms triples to ecore objects on behalf of ATL model
> transformations and ecore objects to triples by using annotations.
>
> In a birds view, an IStore implementation that uses emftriple
> transformation could offer (CDO based) OO access to the ontological
> world. Sounded pretty interesting to me.
>
> Cheers
> André
>
Looking intersting too, but OWL and RDF ? Whats this? :)
("Jena" means that the german university?)

Ciao Oliver
Re: [CDO] Custom Store Developing [message #509562 is a reply to message #509550] Fri, 22 January 2010 22:32 Go to previous messageGo to next message
Eike Stepper is currently offline Eike StepperFriend
Messages: 6682
Registered: July 2009
Senior Member
Oliver schrieb:
> Hi Eike, Victor and Ande,
>
> Thank you verry, verry much!
You're welcome ;-)

>
> With your help, Eike, the store is running. I've tested on MySQL and I
> can create, delete, update and read nodes, attributes and relations. A
> simple modeltransformation working too, wuhu :)
Awesome! How long approximately did it take you to get it working?

>
> transformation.ext:
> import repository;
>
> void addX (Node n):
> n.setName(n.name + 'X');
>
> Java:
> CDOTransaction transaction = session.openTransaction();
> CDOResource resource = transaction.getOrCreateResource("rtr");
Isn't your resource implicitely always existent? If so, getResource()
should do it.

>
> XtendFacade facade = XtendFacade.create("C:/transformation");
> EmfMetaModel metaModel = new EmfMetaModel(RepositoryPackage.eINSTANCE);
> facade.registerMetaModel(metaModel);
>
> Node node = (Node) resource.getContents().get(0);
> System.out.println("name before: " + node.getName());
> facade.call("addX", new Object[] { node });
A shame that XtendFacade does not support variable arguments :P

> System.out.println("name after: " + node.getName());
>
> transaction.commit();
> transaction.close();
Don't forget to close the session! That implicitely closes all open
views and transactions.

>
> On monday I will test it with the Oracle consisting of ca. 40'000
> nodes, attributes and relations.
I'm looking forward to hear about your experiences...

>
> more comments below...
>
> Eike Stepper schrieb:
>> Hi Oliver,
>>
>> Please prefix CDO questions with [CDO].
> Sorry, I will do so in the next post.
Np.

>>
>> More comments below...
>>
>>
>> Oliver schrieb:
>>> Hi,
>>>
>>> I want to implement a custom store because there is an existing
>>> store in form of a database table. So there is no way to save some
>>> meta informations like versions or class names. I think, it is
>>> impossible to use DBStore without managing versions, packages,
>>> folders and store all EClasses in the same table.
>>> In addition: the emf model is static and consisting of three simple
>>> EClasses: node, attribute and relation. These classes have only
>>> EString attributes (so there are no EReferences, containments etc.)
>>> The database consists of thousands of nodes etc. so scalability of
>>> CDO is needed for model transformations on this big models.
>>>
>>> Some questions to Store and StoreAccessor:
>>>
>>> - How to call the super constructor?
>>> super(TYPE, set(ChangeFormat.REVISION),
>>> set(RevisionTemporality.NONE), set(RevisionParallelism.NONE)); I
>>> don't want to support delats (only revisions) and no versions.
>> Looks reasonable. Note that we're currently discussing to drop the
>> explicit specification of store capabilities. It's still unclear
>> whether we'll be relying on marker interfaces or just encourage
>> checks in doBeforeActivate() to validate that the store can support
>> the repository configuration.
>>
>>> Have in this case the methods readRevisionByTime
>> Yes, but you can ignore the timeStamp parameter then as it will
>> always be UNSPECIFIED_DATE. Note that in a few days this method will
>> be renamed to getRevision() because we're introducing CDOBranches.
>> The timeStamp parameter will become a CDOBranchPoint, carrying a
>> CDOBranch and the timeStamp.
>>
>>> , readRevisionByVersion
>> I think so. Without auditing/versioning you may just validate
>> version==1 and delegate to getRevisionByTime(UNSPECIFIED_DATE).
>>
>>> , writeRevisionDeltas of StoreAccessor to throw a new
>>> UnsupportedOperationException?
>> Yes.
>>
>>>
>>> - Should Store return true or false for isFirstTime?
>>> Data is already existing in the database but the Store is running
>>> first time. I've note only that commit and writePackageUnit are
>>> invoked when isFirstTime() = false. Have isFirstTime impact on the
>>> client side?
>> I think you can return false. This leads to readPackageUnits being
>> called on repo startup:
>> | *if *(store.isFirstTime())
>> {
>> initSystemPackages();
>> }
>> *else*
>> {
>> readPackageUnits();
>> }|
>>
>>
>> This leads to a call of
>> org.eclipse.emf.cdo.server.IStoreAccessor.readPackageUnits() . There
>> you can construct the CDOPackageUnit and CDOPackageInfo objects that
>> describe the EPackage that you have statically available.
>>
> In the CDO View it get nerved to register on every session the same
> workspace EPackage. Can I avoid this by implementing readPackageUnits()?
Yes.

> So readPackageUnits can send my RepositoryPackage trough CDO and the
> client don't have to register manually this EPackage.
>
>>>
>>> - When is createChunkReader is needed?
>>> I think a ChunkReader is needed for lazy loading lists. My model
>>> haven't lists but CDO with CDOResourceNode? It is legal to return
>>> a simple null? What does listChunk mean in readRevision method?
>> You may return null if you don't plan to support partial collection
>> loading.
> Means this, that the CDOResource, wich contains all CDOIDs of the
> nodes, attributes
> and relations also cannot loaded partially?
It applies to all lists anywhere in the repository, i.e. also to the
"contents" lists resource(s). Better ensure that these lists don't get
too long. Use nested containers.

>
>>>
>>> - What have to add to context for queryResources method?
>>> If I right, than context.getFolderID() is the CDOID for the
>>> CDOResourceFolder in that the StoreAccessor have to search. By query
>>> the root ressource, FolderID is null?
>>> /aaa/bbb/ccc/MyInstance
>>> What is in this example ResourceFolder, what is ResourceNode, what
>>> is context? I think, CDO is using lazy loading. So only CDOIDs have
>>> to return but where?
>> Since you don't want to persist data that is not modeled, I assume
>> that you want to simulate a single resource under the root resource
>> that contains your model objects. Just verify that the query
>> parameters are valid:
>>
>> IStoreAccessor.QueryResourcesContext.getFolderID() == null
>> IStoreAccessor.QueryResourcesContext.getName() == <name of your
>> resource>
>>
>> Then call IStoreAccessor.QueryResourcesContext.addResource(CDOID)
>> once with the static CDOID of your resource. You must further ensure
>> two things:
>>
>> 1) Do not assign the static CDOID of your resource to any other
>> objects in IStoreAccessor.write(CommitContext, OMMonitor) or
>> IStoreAccessor.commit(OMMonitor).
>>
>> 2) Be prepared to deliver an appropriate CDORevision from the
>> readRevisionXYZ() methods if the static CDOID of your resource is
>> passed. Look at org.eclipse.emf.cdo.eresource.EresourcePackage to get
>> an impression of the values to provide.
>>
> This was the interesting part :)
> CDOIDLongImpl cdoid = (CDOIDLongImpl) id;
Better do not use the ID implementation classes. See CDOIDUtil.

> for resourceCDOID.equals(cdoid):
> CDOList list = revision.getList(EresourcePackage.eINSTANCE
> .getCDOResource_Contents());
Ok. Better: EresourcePackage.Literals.CDO_RESOURCE__CONTENTS
> list.addAll(adapter.getAllCDOIDs());
> revision.setListSize(EresourcePackage.eINSTANCE.getCDOResour ce_Contents(),
>
> list.size());
>
> for rootCDOID.equals(cdoid):
> CDOList list = revision.getList(EresourcePackage.eINSTANCE
> .getCDOResource_Contents());
> list.addAll(resourceCDOID);
> revision.setListSize(EresourcePackage.eINSTANCE.getCDOResour ce_Contents(),
> 1);
>
> Where resourceCDOID is the CDOID for the static resource with name
> "rtr" and rootCDOID is the CDOID for the static resource with name null.
>
> Please look at list.addAll(adapter.getAllCDOIDs()); The adapter
> returns in this case 40'000 new CDOIDLongImpls. Here ends the
> scalability I think. For billions of CDOIDs this can't be handled so.
> But a ResultSet can handle this partially I think. ChunkReader/listChunk?
Yes, IChunkReader is supposed to swap in chunks of list elements as
specified by CDOSession.Options.setCollectionLoadingPolicy(). See also
CDOUtil.createCollectionLoadingPolicy().

>>>
>>> - How to support own CDOIDObjects?
>>> In my case it is really important to use the IDs generated by the
>>> database (auto increment column as primary key). So I have to extend
>>> CDOIDObject and implement CDOIDObjectFactory.
>> Oh, are you using CDO 2.0? The ID handling has been reworked for CDO
>> 3.0. There is no longer a CDOIDObjectFactory as it turned out to be
>> fragile because it relied on Java class serialization and ClassLoader
>> hacking.
>>
>> What *type* do your PKs have? There's currently build-in support for
>> long integers (CDOIDObjectLongImpl) and Strings (CDOIDObjectStringImpl).
>>
>>> No problem, but a problem is to understand LibraryHandler.
>>> getFactoryName, getlibraryNames, write - no idea what this should do
>>> or for what this interface exists.
>>> In case of a own CDOIDObjectFactory, how can I register this factory
>>> to the CDO Session View (I mean the Eclipse view with the plus
>>> button to add sessions etc.). My CDOIDObject implementation returns
>>> Type.OBJECT for getType(). Is this the right type in my case (there
>>> are EXTERNAL_OBJECT, TEMP_OBJECT etc. but no idea what this means)?
>> All the other ID types are somewhat system-reserved. You only need to
>> choose an implementation for CDOIDObject. Note that CDO requires the
>> value of a CDOID never to change once it's assigned to an object!
>>
> Oh, yes, CDOIDLongImpl was the right. I was confused by addIDMappings
> in LongStoreImpl but this can easily override.
What's LongStoreImpl?

You must call IStoreAccessor.CommitContext.addIDMapping(CDOIDTemp,
CDOID) to tell CDO about the *persistent* IDs that you assign to NEW
objects in IStoreAccessor.write(CommitContext, OMMonitor). The
CDOTransaction at the client side assigned *temporary* IDs at attach
time. Since some stores do get persistent IDs from the backend
(generated keys, etc...), it's necessary to first add *all* ID mappings
of a commit and later call applyIDMappings(). The LongIDStore automates
all of this for you.

>
>>>
>>> - Are there experience with model transformations on big models?
>>> Has any one do model transformations with CDO regards scalability?
>> I know of a company on Teneriffe that uses CDO to transform huge
>> models (ASTs, IIRC.). Vik?
>>
>>> I want to use Xtend for it.
>> I don't see problems ;-)
> Is CDOResource.getContents() scaleable? Xtend needs all EObject passed
> through XtendFacade.call method. Returns getContents() all EObjects or
> are there partially returned?
That depends on two things:
1) Your store accessor must return a chunk reader instance from
createChunkReader()
2) The client session must set a non-default CDOCollectionLoadingPolicy

Then you can control the initialChunkSize and a resolveChunkSize
independently. The first one determines how many list elements are
loaded with the initial LoadRevisionRequest. The second one determines
how many elements are loaded later if a list index K is accessed but not
yet loaded. CDO tries to load a optimal chunk of elements around K,
possibly loading multiple smaller chunks if the list is fragmented.
Compare
http://wiki.eclipse.org/Tweaking_CDO_Performance#Loading_Par tial_Collections_.E2.80.93_CDOCollectionLoadingPolicy

If you can, ensure that lists never grow too large by using containment
features to nest your objects.

> For example:
> for (EObject obj : resource.getContents()) {
> // do something
> }
> In my case getContents() would return 40'000 EObjects. But handle CDO
> this loop by getting the first e.g. 10000 EObjects, than getting the
> next 1000 EObjects and so on?
See above.

>>
>> Please report your experiences with usage and extension of CDO back!
> Yes, I want to compare a Xtend transformation and a native PL/SQL
> transformation and you getting a report :)
Cool. Thx ;-)

Cheers
/Eike

----
http://thegordian.blogspot.com
http://twitter.com/eikestepper


>>
>> Cheers
>> /Eike
>>
>> ----
>> http://thegordian.blogspot.com
>> http://twitter.com/eikestepper
>>
>>
>
> A question to addIDMappings:
> The actually addIDMappings method looks like
> for (CDORevision revision : context.getNewObjects()) {
> EClass eClass = revision.getEClass();
> CDOIDTemp oldID = (CDOIDTemp) revision.getID();
> CDOID newID = null;
> if ("Node".equals(eClass.getName())) {
> newID = adapter.getNextCDOID(ObjectType.NODE);
> } else if ("Attribute".equals(eClass.getName())) {
> newID = adapter.getNextCDOID(ObjectType.ATTRIBUTE);
> } else if ("Relation".equals(eClass.getName())) {
> newID = adapter.getNextCDOID(ObjectType.RELATION);
> // ...
> context.addIDMapping(oldID, newID);
> }
> "Node".equals(eClass.getName()) works but
> RepositoryPackage.eINSTANCE.getNode().equals(eClass) not. Both returns
> for getName() "Node" but there are two different instances of EClass.
> Is revision.getEClass() a dynamic EMF generated EClass?
>
> ------------------------------------------------------------ -----------------
>
>
> Víctor Roldán Betancort schrieb:
> > Hi guys,
> >
> >>> - Are there experience with model transformations on big models?
> >>> Has any one do model transformations with CDO regards scalability?
> >> I know of a company on Teneriffe that uses CDO to transform huge
> >> models (ASTs, IIRC.). Vik?
> >
> > Yes, we execute model transformations to inventory Cobol/CICS ASTs into
> > a KDM model. The KDM keeps information from lot of different Cobol
> > sources from big legacy systems, and its stored in a CDO DBStore
> > backend.
> What do you mean with Cobol/CICS ASTs and KDM? :)
> A EMF model represents a AST - Abstract Syntax Tree of a Cobol program
> and you do model transformations of this AST into another language "KDM"?
> How many EObjects consists a typically model for your transformation?
>
> The results are acceptable, but there is a lot of room for
> > improvement. My opinion (and I guess the same as many folks) is that
> > there is an important "impedance mismatch" between the object world and
> > the relational world which causes poor performance. Guys from Hibernate
> > won't agree with me :P Simon McDuff has deployed CDO using an
> > Object-Oriented backed that has provided great performance. I've been
> > developing a DB4O as backend as experiment, and the results are very
> > positive as well, close to in-memory databases like HSQLDB.
> >
> > I'm also particularly interested in the NoSQL movement. Some of the
> > biggest contenders in the Internet are using such technologies (see
> > google, facebook...). However, the "is it ready for enterprise"
> question
> > always raises...
> >
> > Some interesting links:
> >
> > Neo4J, graph-based database: http://neo4j.org/
> > Hypertable, inspired in Google's BigTable: http://www.hypertable.org/
> > Apache Cassandra, key-value database:
> > http://incubator.apache.org/cassandra/
> > MongoDB, document database: http://www.mongodb.org/
> > HBase, also inspired in BigTable: http://hadoop.apache.org/hbase/
> > ... and many more
> >
> > Site with lot of resources: http://nosql-databases.org
> >
> > Would like to see people out there experimenting with these stores :D
> >
> > Cheers,
> > Víctor.
> Wow, I've don't heard about NoSQL databases before your post. In
> particular Neo4J is a very interesting graph based DB.
>
> And whats with a XML-Storage-Backends? exist-DB
> http://exist.sourceforge.net/ e.g. uses PDOM (Persitence DOM, b-tree
> based paging mechanism), indexing (incl. lucene fulltext indexing),
> transactions, XPath, XQuery, XUpdate as DML.
> But I'am not a DB expert :)
>
> ------------------------------------------------------------ -----------------
>
>
>
> Ande Dietisheim schrieb:
> > Hi guys
> >
> > Just in case someone else thinks this might be an insteresting
> store, too:
> >
> > I got in touch with semantic guys, googled and discovered that a french
> > university developed a mapper that bridges the OO and the semantic
> world:
> >
> > http://code.google.com/p/emftriple/
> >
> > EMFtriple currently offers a Resource that uses a jena backend. Jena,
> > for the ones who never heard of it, is a semantic store (backed up by a
> > database) that handles triples. These guys developed a framework that
> > transforms triples to ecore objects on behalf of ATL model
> > transformations and ecore objects to triples by using annotations.
> >
> > In a birds view, an IStore implementation that uses emftriple
> > transformation could offer (CDO based) OO access to the ontological
> > world. Sounded pretty interesting to me.
> >
> > Cheers
> > André
> >
> Looking intersting too, but OWL and RDF ? Whats this? :)
> ("Jena" means that the german university?)
>
> Ciao Oliver


Re: [CDO] Custom Store Developing [message #509588 is a reply to message #509562] Sat, 23 January 2010 11:58 Go to previous messageGo to next message
Andre Dietisheim is currently offline Andre DietisheimFriend
Messages: 131
Registered: July 2009
Senior Member
Hi Oliver, Hi Eike

>
>> With your help, Eike, the store is running. I've tested on MySQL and I>> can create, delete, update and read nodes, attributes and relations. A
>> simple modeltransformation working too, wuhu :)
> Awesome! How long approximately did it take you to get it working?
>
>> transformation.ext:
>> import repository;
>>
>> void addX (Node n):
>> n.setName(n.name + 'X');
>>
>> Java:
>> CDOTransaction transaction = session.openTransaction();
>> CDOResource resource = transaction.getOrCreateResource("rtr");
> Isn't your resource implicitely always existent? If so, getResource()
> should do it.
>
>> XtendFacade facade = XtendFacade.create("C:/transformation");
>> EmfMetaModel metaModel = new EmfMetaModel(RepositoryPackage.eINSTANCE);
>> facade.registerMetaModel(metaModel);
>>
>> Node node = (Node) resource.getContents().get(0);
>> System.out.println("name before: " + node.getName());
>> facade.call("addX", new Object[] { node });
> A shame that XtendFacade does not support variable arguments :P
>
>> System.out.println("name after: " + node.getName());
>>
>> transaction.commit();
>> transaction.close();

Awesome! I'd be more than glad to hear about your experiences, too!

I lately had a chat with an interested party and we spotted that model
evolution (aka schema evolution in the RDBMS world) currently is a
shortcoming in EMF/CDO.
I had a few tweets with Ekke (redview), too. Open ERP Ware (ekkes main
project) uses CDO to store UI metamodels. On the other hand he uses
POJOs instead of ecore objects (and possibly CDO) for the data. He
argues that EclipseLink/Hibernate are more flexible when it comes to
schema evolution. I therefore think that it would be a good choice to
invest more in model evolution. Great to see that you Oliver already
made first steps in this direction.
Ekke offered to chat with us on this matter at EclipseCon (I
unfortunately wont be able to get there, but some of us certain will be
there).

What are your thoughts on this?

Cheers
André
Re: [CDO] Custom Store Developing [message #509589 is a reply to message #509588] Sat, 23 January 2010 12:06 Go to previous messageGo to next message
Eike Stepper is currently offline Eike StepperFriend
Messages: 6682
Registered: July 2009
Senior Member
Ande Dietisheim schrieb:
> [...] I had a few tweets with Ekke (redview), too. Open ERP Ware (ekkes main
> project) uses CDO to store UI metamodels. On the other hand he uses
> POJOs instead of ecore objects (and possibly CDO) for the data. He
> argues that EclipseLink/Hibernate are more flexible when it comes to
> schema evolution.
What does "more flexible" mean exactly?


> I therefore think that it would be a good choice to
> invest more in model evolution.
For whom?

Cheers
/Eike

----
http://thegordian.blogspot.com
http://twitter.com/eikestepper


Re: [CDO] Custom Store Developing [message #509610 is a reply to message #509589] Sat, 23 January 2010 10:56 Go to previous messageGo to next message
Andre Dietisheim is currently offline Andre DietisheimFriend
Messages: 131
Registered: July 2009
Senior Member
Eike Stepper wrote:
> Ande Dietisheim schrieb:
>> [...] I had a few tweets with Ekke (redview), too. Open ERP Ware (ekkes main
>> project) uses CDO to store UI metamodels. On the other hand he uses
>> POJOs instead of ecore objects (and possibly CDO) for the data. He
>> argues that EclipseLink/Hibernate are more flexible when it comes to
>> schema evolution.
> What does "more flexible" mean exactly?

What Ekke exactly meant with "more flexible" might only be explained by
Ekke himself.
I'm no Hibernate nor EclipseLink expert so my impression's probably not
as accurate as it could be, but I'd love to discuss my impression. I
wondered what benefits CDO can bring to classic JEE developers compared
to a classic JEE approach that uses POJOs, OR-Mappers etc.
The use case I discussed with my contacts needs to evolve the model
schema at runtime (WYSIWYG editor that allows to edit data models and
forms). In both scenarios you have to evolve the database schema,
migrate the data and adapt the object-mapping.
My rough impression's that the JEE world already has widely used and
mature tools whereas the emf world's (COPE, edapt, etc.) only getting
there lately. I therefore guess that investing in this area could grow
our community. Corret me if you think I'm wrong here...
I'd love to take Ekke into this discussion to enlight what led him to
use classic JEE frameworks for his data and ecore/CDO for his UI metamodels.

>
>
>> I therefore think that it would be a good choice to
>> invest more in model evolution.
> For whom?

for scenarios where a classic JEE approach competes with an approach
that involves ecore/cdo.

>
> Cheers
> /Eike
>
> ----
> http://thegordian.blogspot.com
> http://twitter.com/eikestepper
>
Re: [CDO] Custom Store Developing [message #509614 is a reply to message #509550] Sat, 23 January 2010 16:21 Go to previous messageGo to next message
Andre Dietisheim is currently offline Andre DietisheimFriend
Messages: 131
Registered: July 2009
Senior Member
Hi Oliver

> Looking intersting too, but OWL and RDF ? Whats this? :)

http://en.wikipedia.org/wiki/Resource_Description_Framework:
"The RDF data model is similar to classic conceptual modeling approaches
such as Entity-Relationship or Class diagrams, as it is based upon the
idea of making statements about resources (in particular Web resources)
in the form of subject-predicate-object expressions. These expressions
are known as triples in RDF terminology"

The main problem here's that RDF based types do not behave the way we
are used to in the OO world. RDF based entities have multiple
inheritance, RDF properties exist even without an enclosing class, etc.
There's a very interesting paper on this topic that was submitted to
EclipseCon 2008:
http://www.abdn.ac.uk/~r01srt7/swese2008/pdf/swese2008_submi ssion_14.pdf

In consequence you need to bridge both worlds and that's what's
implemented for classic EMF resources in emftriple
(http://code.google.com/p/emftriple/)

> ("Jena" means that the german university?)

could be, but related to semantic frameworks, jena's a mature and well
known web framework that also offers a so called triple store (persistency):

http://jena.sourceforge.net/

Cheers
André
JPA annotation and the use of stereotypes [message #509655 is a reply to message #508922] Sun, 24 January 2010 11:21 Go to previous messageGo to next message
Vlad Varnica is currently offline Vlad VarnicaFriend
Messages: 546
Registered: July 2009
Location: Milton Keynes - UK
Senior Member
The use of JPA annotations and UML stereotypes allows to model with Ecore and mapping tools such as Hibernate or Oracle.
I have written a short documentation on Use Oracle® Enterprise Pack Eclipse 11g with EclipseUML 2008 at: http://www.forum-omondo.com/documentation_eclipseuml_2008/Ec lipse_Database/Activate_JPA_Perspective/oracle_integration.h tml

This modleing stage could be created without java code because JPA / EJB 3 annotations will once the modeling stage is finished be written at code generation and based on the stereotype value.

btw, it is not fair to compare Hibernate/Oracle + UML which has been developped by many developers around the world and CDO+EMF.

Let's give CDO more time and see in 3 years. Mapping tools are for me currently getting more and more proprietary on a very strategic market so an alternative is still important for the community.
Good luck for your project.

Vlad

[Updated on: Sun, 24 January 2010 11:27]

Report message to a moderator

Re: [CDO] Custom Store Developing [message #509694 is a reply to message #509610] Sun, 24 January 2010 21:45 Go to previous messageGo to next message
Thomas Schindl is currently offline Thomas SchindlFriend
Messages: 6651
Registered: July 2009
Senior Member
From my POV CDO + Teneo-JPA-(Hibernate) backend store is as flexible as
the any other POJO + JPA solution.

What I'm trying to say is that if you managed (which not always trivial)
to do model evolution with Hibernate/EclipseLink it should be applicable
to CDO as well because Teneo translates it into Hibernate-Configurations.

A thing I like in CDO is that it solves my serialization and concurrency
problems without any additional coding from me.

Tom


Am 23.01.10 16:53, schrieb Ande Dietisheim:
> Eike Stepper wrote:
>> Ande Dietisheim schrieb:
>>> [...] I had a few tweets with Ekke (redview), too. Open ERP Ware (ekkes main
>>> project) uses CDO to store UI metamodels. On the other hand he uses
>>> POJOs instead of ecore objects (and possibly CDO) for the data. He
>>> argues that EclipseLink/Hibernate are more flexible when it comes to
>>> schema evolution.
>> What does "more flexible" mean exactly?
>
> What Ekke exactly meant with "more flexible" might only be explained by
> Ekke himself.
> I'm no Hibernate nor EclipseLink expert so my impression's probably not
> as accurate as it could be, but I'd love to discuss my impression. I
> wondered what benefits CDO can bring to classic JEE developers compared
> to a classic JEE approach that uses POJOs, OR-Mappers etc.
> The use case I discussed with my contacts needs to evolve the model
> schema at runtime (WYSIWYG editor that allows to edit data models and
> forms). In both scenarios you have to evolve the database schema,
> migrate the data and adapt the object-mapping.
> My rough impression's that the JEE world already has widely used and
> mature tools whereas the emf world's (COPE, edapt, etc.) only getting
> there lately. I therefore guess that investing in this area could grow
> our community. Corret me if you think I'm wrong here...
> I'd love to take Ekke into this discussion to enlight what led him to
> use classic JEE frameworks for his data and ecore/CDO for his UI metamodels.
>
>>
>>
>>> I therefore think that it would be a good choice to
>>> invest more in model evolution.
>> For whom?
>
> for scenarios where a classic JEE approach competes with an approach
> that involves ecore/cdo.
>
>>
>> Cheers
>> /Eike
>>
>> ----
>> http://thegordian.blogspot.com
>> http://twitter.com/eikestepper
>>
Re: [CDO] Custom Store Developing [message #509698 is a reply to message #509694] Sun, 24 January 2010 18:38 Go to previous messageGo to next message
Martin Taal is currently offline Martin TaalFriend
Messages: 5468
Registered: July 2009
Senior Member
Hi Andre and others,
I can only talk about schema evolution for Hibernate. It works fine in that tables and columns and foreign keys are
created for you. Indexes are however not added automatically to an existing table. Hibernate does not remove
columns/tables and I am not sure if it allows updates of column metadata (type, length, nullability). So the schema
evolution of Hibernate is okay and workable but it does not seem very advanced. My feel is also that this part of
hibernate has not had a lot of development the past years (but I can be wrong here).

As Tom remarks, CDO with Teneo gives you the same schema update behavior as pojo-hibernate. And j2ee developers can use
EMF server side with Teneo standard also (so without CDO). So afaics EMF (with CDO/Teneo) can be used in a j2ee environment.

So, for me schema evolution is not the main difference between CDO and j2ee technology stacks.
From my point of view, what I see as a main difference is that in a jee environment you can work with the actual
pojos/business objects on the server. Although this is a planned feature for CDO it is not there yet. Other things which
I can do with hibernate is the possibility to get to the lower layers (the sql connection...) in the same db transaction
and have important hooks (onflush, onchange, pre-commit, post-commit..) which can be used to attach server side logic to.
Another difference between CDO and Hibernate/Eclipselink is that the latter support a standard (JPA), this makes them
easier to understand and accept and it gives some credibility (as we all hope that these standards have been designed by
people smarter than ourselves...:-).

As a last point, there are EMF concepts which are less common in the non EMF world (nl. resources, specific
list-implementations, notifications, bi-directional associations and the explicit container relationship). I can imagine
that for non-EMF developers these things give a bit of a learning curve and make it harder to accept CDO in non-EMF
environments.

Just my 2 cents :-)

gr. Martin

Tom Schindl wrote:
> From my POV CDO + Teneo-JPA-(Hibernate) backend store is as flexible as
> the any other POJO + JPA solution.
>
> What I'm trying to say is that if you managed (which not always trivial)
> to do model evolution with Hibernate/EclipseLink it should be applicable
> to CDO as well because Teneo translates it into Hibernate-Configurations.
>
> A thing I like in CDO is that it solves my serialization and concurrency
> problems without any additional coding from me.
>
> Tom
>
>
> Am 23.01.10 16:53, schrieb Ande Dietisheim:
>> Eike Stepper wrote:
>>> Ande Dietisheim schrieb:
>>>> [...] I had a few tweets with Ekke (redview), too. Open ERP Ware (ekkes main
>>>> project) uses CDO to store UI metamodels. On the other hand he uses
>>>> POJOs instead of ecore objects (and possibly CDO) for the data. He
>>>> argues that EclipseLink/Hibernate are more flexible when it comes to
>>>> schema evolution.
>>> What does "more flexible" mean exactly?
>> What Ekke exactly meant with "more flexible" might only be explained by
>> Ekke himself.
>> I'm no Hibernate nor EclipseLink expert so my impression's probably not
>> as accurate as it could be, but I'd love to discuss my impression. I
>> wondered what benefits CDO can bring to classic JEE developers compared
>> to a classic JEE approach that uses POJOs, OR-Mappers etc.
>> The use case I discussed with my contacts needs to evolve the model
>> schema at runtime (WYSIWYG editor that allows to edit data models and
>> forms). In both scenarios you have to evolve the database schema,
>> migrate the data and adapt the object-mapping.
>> My rough impression's that the JEE world already has widely used and
>> mature tools whereas the emf world's (COPE, edapt, etc.) only getting
>> there lately. I therefore guess that investing in this area could grow
>> our community. Corret me if you think I'm wrong here...
>> I'd love to take Ekke into this discussion to enlight what led him to
>> use classic JEE frameworks for his data and ecore/CDO for his UI metamodels.
>>
>>>
>>>> I therefore think that it would be a good choice to
>>>> invest more in model evolution.
>>> For whom?
>> for scenarios where a classic JEE approach competes with an approach
>> that involves ecore/cdo.
>>
>>> Cheers
>>> /Eike
>>>
>>> ----
>>> http://thegordian.blogspot.com
>>> http://twitter.com/eikestepper
>>>
>


--

With Regards, Martin Taal

Springsite/Elver.org
Office: Hardwareweg 4, 3821 BV Amersfoort
Postal: Nassaulaan 7, 3941 EC Doorn
The Netherlands
Cell: +31 (0)6 288 48 943
Tel: +31 (0)84 420 2397
Fax: +31 (0)84 225 9307
Mail: mtaal@springsite.com - mtaal@elver.org
Web: www.springsite.com - www.elver.org
Re: [CDO] Custom Store Developing [message #509708 is a reply to message #509694] Mon, 25 January 2010 01:06 Go to previous messageGo to next message
ekkehard gentz is currently offline ekkehard gentzFriend
Messages: 118
Registered: July 2009
Location: rosenheim, Germany, bavar...
Senior Member

This is a multi-part message in MIME format.
--------------030106050000010405000408
Content-Type: text/plain; charset=ISO-8859-15; format=flowed
Content-Transfer-Encoding: 7bit

at first I must say, that the decision to use JPA (Hibernate or
EclipseLink) in my enterprise applications to store the data was done
some time ago ;-)

as some of you know, we decided to use EMF to store our UI View Models
(project http://redview.org). this works great and we're just in the
process to publish the code.

after some discussions with Eike we tried CDO for our View models to be
able to store the Models at a server and also to push design changes
live into running RCP applications. Flo (my co-worker on redview) did
the work to implement CDO and it works really great - we demonstrated
running RCP apps on windows, OSX and Ubuntu with live-pushing design
changes made inside the IDE.

thanks to Eike and CDO team some performance-problems we had at first
with our small but deep models to prefetch them at once from server are
all solved.

where we have problems was model-evolution. while developing our tool
we made many changes in our models and in most cases where the normal
EMF editor was able to open old model files, CDO doesn't. There was also
no easy way with CDO Session Viewer to copy from CDO server into
workspace to do changes there and then copy back to the CDO repository
or so.
So from my POV its a Tooling problem, too to support easy
model-evolution. There will be much work for us to make this
end-user-friendly. Thats the reason why our first publish of redView
will include CDO, because it works technically - but only marked as
experimental at this time, because there's still much to do for us.

these are current problems with our small View models, but I'm sure
we'll find ways to solve model-evolution.

but to use EMF / CDO as my data model for a very complex ERP Enterprise
application, with 800 Entity and the application will grow and change
the model - I cannot imagine how to do this with EMF / CDO. Yes - I can
use Teneo/JPA as backend store, but there's still the problem of EMF
Model evolution.

I like EMF, EMF Databinding, undo-redo.... I like CDO to store large EMF
models.... all well done from a pure-technical point. But the default
Tooling and problems with model-evolution from my POV isn't ready today
to be used in classical Enterprise Apps as-is. I imagine that this will
be better in 1 or 2 years, because so many projects are now using EMF
and also CDO - so I hope there will be much development.

Yes, Tom is right - model evolution still isn't easy using Hibernate,
but there are proved ways to update a schema - and if I'm having
problems I can use one of many tools to do changes in my database. Doing
this with Teneo isn't the same if Teneo is used as backend behind CDO,
because the problem that CDO has to understand my EMF model evolution
still exists.

Perhaps I'm wrong and I didn't found the right way to do this or didn't
found documentation. If someone demonstrates a complex business
application running on EMF / CDO / Teneo where its easy to add some
classes to the model and to add some properties to existing Classes and
CDO was able to handle the already stored data I would be happy.

dont understand me wrong - I like CDO, also Flo was very impressed about
the code quality and its always an eye-catcher if we demonstrate CDO
live-pushing.

hope we can also discuss these points at eclipsecon.

ekke
BTW: hope, this message appears only once - sent it yesterday from
eclipse forums, but miss it here
Am 24.01.10 22:45, schrieb Tom Schindl:
> From my POV CDO + Teneo-JPA-(Hibernate) backend store is as flexible as
> the any other POJO + JPA solution.
>
> What I'm trying to say is that if you managed (which not always trivial)
> to do model evolution with Hibernate/EclipseLink it should be applicable
> to CDO as well because Teneo translates it into Hibernate-Configurations.
>
> A thing I like in CDO is that it solves my serialization and concurrency
> problems without any additional coding from me.
>
> Tom
>
>
> Am 23.01.10 16:53, schrieb Ande Dietisheim:
>
>> Eike Stepper wrote:
>>
>>> Ande Dietisheim schrieb:
>>>
>>>> [...] I had a few tweets with Ekke (redview), too. Open ERP Ware (ekkes main
>>>> project) uses CDO to store UI metamodels. On the other hand he uses
>>>> POJOs instead of ecore objects (and possibly CDO) for the data. He
>>>> argues that EclipseLink/Hibernate are more flexible when it comes to
>>>> schema evolution.
>>>>
>>> What does "more flexible" mean exactly?
>>>
>> What Ekke exactly meant with "more flexible" might only be explained by
>> Ekke himself.
>> I'm no Hibernate nor EclipseLink expert so my impression's probably not
>> as accurate as it could be, but I'd love to discuss my impression. I
>> wondered what benefits CDO can bring to classic JEE developers compared
>> to a classic JEE approach that uses POJOs, OR-Mappers etc.
>> The use case I discussed with my contacts needs to evolve the model
>> schema at runtime (WYSIWYG editor that allows to edit data models and
>> forms). In both scenarios you have to evolve the database schema,
>> migrate the data and adapt the object-mapping.
>> My rough impression's that the JEE world already has widely used and
>> mature tools whereas the emf world's (COPE, edapt, etc.) only getting
>> there lately. I therefore guess that investing in this area could grow
>> our community. Corret me if you think I'm wrong here...
>> I'd love to take Ekke into this discussion to enlight what led him to
>> use classic JEE frameworks for his data and ecore/CDO for his UI metamodels.
>>
>>
>>>
>>>
>>>> I therefore think that it would be a good choice to
>>>> invest more in model evolution.
>>>>
>>> For whom?
>>>
>> for scenarios where a classic JEE approach competes with an approach
>> that involves ecore/cdo.
>>
>>
>>> Cheers
>>> /Eike
>>>
>>> ----
>>> http://thegordian.blogspot.com
>>> http://twitter.com/eikestepper
>>>
>>>
>


--

ekke (ekkehard gentz)
independent software-architect
senior erp-consultant
eclipse | osgi | equinox | mdsd | oaw | emf | uml
max-josefs-platz 30, D-83022 rosenheim, germany
mailto:ekke@ekkes-corner.org
homepage (de): http://gentz-software.de
blog (en): http://ekkes-corner.org
twitter: @ekkescorner
skype: ekkes-corner
Steuer-Nr: 156/220/30931 FA Rosenheim, UST-ID: DE189929490


--------------030106050000010405000408
Content-Type: text/html; charset=ISO-8859-15
Content-Transfer-Encoding: 8bit

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html; charset=ISO-8859-15"
http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
at first I must say, that the decision to use JPA (Hibernate or
EclipseLink) in my enterprise applications to store the data was done
some time ago ;-)<br>
<br>
as some of you know, we decided to use EMF to store our UI View Models
(project <a class="moz-txt-link-freetext" href="http://redview.org">http://redview.org</a>). this works great and we're just in the
process to publish the code.<br>
<br>
after some discussions with Eike we tried CDO for our View models to be
able to store the Models at a server and also to push design changes
live into running RCP applications. Flo (my co-worker on redview) did
the work to implement CDO and it works really great - we demonstrated
running RCP apps on windows, OSX and Ubuntu with live-pushing design
changes made inside the IDE.<br>
<br>
thanks to Eike and CDO team some performance-problems we had at first
with our small but deep models to prefetch them at once from server are
all solved.<br>
<br>
where we have problems was model-evolution.


ekke
independent software architect

blog: http://ekkes-corner.org
twitter: @ekkescorner
Re: [CDO] Custom Store Developing [message #509709 is a reply to message #509698] Mon, 25 January 2010 01:06 Go to previous messageGo to next message
ekkehard gentz is currently offline ekkehard gentzFriend
Messages: 118
Registered: July 2009
Location: rosenheim, Germany, bavar...
Senior Member

This is a multi-part message in MIME format.
--------------000200050302050204060103
Content-Type: text/plain; charset=ISO-8859-15; format=flowed
Content-Transfer-Encoding: 7bit

hi martin,

thanks for all your informations about CDO/Teneo - just read the wiki

at the moment all my experiences are using CDO defaults with
derby-embedded. this was fast enough for our stored View Models.

if I have some time, I'll try Teneo, too.

Do you have examples how it works using CDO/Teneo Hibernate if the model
changes ?

thx

ekke
Am 25.01.10 00:36, schrieb Martin Taal:
> Hi Andre and others,
> I can only talk about schema evolution for Hibernate. It works fine in
> that tables and columns and foreign keys are created for you. Indexes
> are however not added automatically to an existing table. Hibernate
> does not remove columns/tables and I am not sure if it allows updates
> of column metadata (type, length, nullability). So the schema
> evolution of Hibernate is okay and workable but it does not seem very
> advanced. My feel is also that this part of hibernate has not had a
> lot of development the past years (but I can be wrong here).
>
> As Tom remarks, CDO with Teneo gives you the same schema update
> behavior as pojo-hibernate. And j2ee developers can use EMF server
> side with Teneo standard also (so without CDO). So afaics EMF (with
> CDO/Teneo) can be used in a j2ee environment.
>
> So, for me schema evolution is not the main difference between CDO and
> j2ee technology stacks.
> From my point of view, what I see as a main difference is that in a
> jee environment you can work with the actual pojos/business objects on
> the server. Although this is a planned feature for CDO it is not there
> yet. Other things which I can do with hibernate is the possibility to
> get to the lower layers (the sql connection...) in the same db
> transaction and have important hooks (onflush, onchange, pre-commit,
> post-commit..) which can be used to attach server side logic to.
> Another difference between CDO and Hibernate/Eclipselink is that the
> latter support a standard (JPA), this makes them easier to understand
> and accept and it gives some credibility (as we all hope that these
> standards have been designed by people smarter than ourselves...:-).
>
> As a last point, there are EMF concepts which are less common in the
> non EMF world (nl. resources, specific list-implementations,
> notifications, bi-directional associations and the explicit container
> relationship). I can imagine that for non-EMF developers these things
> give a bit of a learning curve and make it harder to accept CDO in
> non-EMF environments.
>
> Just my 2 cents :-)
>
> gr. Martin
>
> Tom Schindl wrote:
>> From my POV CDO + Teneo-JPA-(Hibernate) backend store is as flexible as
>> the any other POJO + JPA solution.
>>
>> What I'm trying to say is that if you managed (which not always trivial)
>> to do model evolution with Hibernate/EclipseLink it should be applicable
>> to CDO as well because Teneo translates it into
>> Hibernate-Configurations.
>>
>> A thing I like in CDO is that it solves my serialization and concurrency
>> problems without any additional coding from me.
>>
>> Tom
>>
>>
>> Am 23.01.10 16:53, schrieb Ande Dietisheim:
>>> Eike Stepper wrote:
>>>> Ande Dietisheim schrieb:
>>>>> [...] I had a few tweets with Ekke (redview), too. Open ERP Ware
>>>>> (ekkes main
>>>>> project) uses CDO to store UI metamodels. On the other hand he uses
>>>>> POJOs instead of ecore objects (and possibly CDO) for the data. He
>>>>> argues that EclipseLink/Hibernate are more flexible when it comes to
>>>>> schema evolution.
>>>> What does "more flexible" mean exactly?
>>> What Ekke exactly meant with "more flexible" might only be explained by
>>> Ekke himself.
>>> I'm no Hibernate nor EclipseLink expert so my impression's probably not
>>> as accurate as it could be, but I'd love to discuss my impression. I
>>> wondered what benefits CDO can bring to classic JEE developers compared
>>> to a classic JEE approach that uses POJOs, OR-Mappers etc.
>>> The use case I discussed with my contacts needs to evolve the model
>>> schema at runtime (WYSIWYG editor that allows to edit data models and
>>> forms). In both scenarios you have to evolve the database schema,
>>> migrate the data and adapt the object-mapping.
>>> My rough impression's that the JEE world already has widely used and
>>> mature tools whereas the emf world's (COPE, edapt, etc.) only getting
>>> there lately. I therefore guess that investing in this area could grow
>>> our community. Corret me if you think I'm wrong here...
>>> I'd love to take Ekke into this discussion to enlight what led him to
>>> use classic JEE frameworks for his data and ecore/CDO for his UI
>>> metamodels.
>>>
>>>>
>>>>> I therefore think that it would be a good choice to
>>>>> invest more in model evolution.
>>>> For whom?
>>> for scenarios where a classic JEE approach competes with an approach
>>> that involves ecore/cdo.
>>>
>>>> Cheers
>>>> /Eike
>>>>
>>>> ----
>>>> http://thegordian.blogspot.com
>>>> http://twitter.com/eikestepper
>>>>
>>
>
>


--

ekke (ekkehard gentz)
independent software-architect
senior erp-consultant
eclipse | osgi | equinox | mdsd | oaw | emf | uml
max-josefs-platz 30, D-83022 rosenheim, germany
mailto:ekke@ekkes-corner.org
homepage (de): http://gentz-software.de
blog (en): http://ekkes-corner.org
twitter: @ekkescorner
skype: ekkes-corner
Steuer-Nr: 156/220/30931 FA Rosenheim, UST-ID: DE189929490


--------------000200050302050204060103
Content-Type: text/html; charset=ISO-8859-15
Content-Transfer-Encoding: 7bit

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html; charset=ISO-8859-15"
http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
hi martin,<br>
<br>
thanks for all your informations about CDO/Teneo - just read the wiki<br>
<br>
at the moment all my experiences are using CDO defaults with
derby-embedded. this was fast enough for our stored View Models.<br>
<br>
if I have some time, I'll try Teneo, too.<br>
<br>
Do you have examples how it works using CDO/Teneo Hibernate if the
model changes ?<br>
<br>
thx<br>
<br>
ekke<br>
Am 25.01.10 00:36, schrieb Martin Taal:
<blockquote cite="mid:hjilir$dfd$1@build.eclipse.org" type="cite">Hi
Andre and others,
<br>
I can only talk about schema evolution for Hibernate. It works fine in
that tables and columns and foreign keys are created for you. Indexes
are however not added automatically to an existing table. Hibernate
does not remove columns/tables and I am not sure if it allows updates
of column metadata (type, length, nullability). So the schema evolution
of Hibernate is okay and workable but it does not seem very advanced.
My feel is also that this part of hibernate has not had a lot of
development the past years (but I can be wrong here).
<br>
<br>
As Tom remarks, CDO with Teneo gives you the same schema update
behavior as pojo-hibernate. And j2ee developers can use EMF server side
with Teneo standard also (so without CDO). So afaics EMF (with
CDO/Teneo) can be used in a j2ee environment.
<br>
<br>
So, for me schema evolution is not the main difference between CDO and
j2ee technology stacks.
<br>
From my point of view, what I see as a main difference is that in a jee
environment you can work with the actual pojos/business objects on the
server. Although this is a planned feature for CDO it is not there yet.
Other things which I can do with hibernate is the possibility to get to
the lower layers (the sql connection...) in the same db transaction and
have important hooks (onflush, onchange, pre-commit, post-commit..)
which can be used to attach server side logic to.
<br>
Another difference between CDO and Hibernate/Eclipselink is that the
latter support a standard (JPA), this makes them easier to understand
and accept and it gives some credibility (as we all hope that these
standards have been designed by people smarter than ourselves...:-).
<br>
<br>
As a last point, there are EMF concepts which are less common in the
non EMF world (nl. resources, specific list-implementations,
notifications, bi-directional associations and the explicit container
relationship). I can imagine that for non-EMF developers these things
give a bit of a learning curve and make it harder to accept CDO in
non-EMF environments.
<br>
<br>
Just my 2 cents :-)
<br>
<br>
gr. Martin
<br>
<br>
Tom Schindl wrote:
<br>
<blockquote type="cite">From my POV CDO + Teneo-JPA-(Hibernate)
backend store is as flexible as
<br>
the any other POJO + JPA solution.
<br>
<br>
What I'm trying to say is that if you managed (which not always
trivial)
<br>
to do model evolution with Hibernate/EclipseLink it should be
applicable
<br>
to CDO as well because Teneo translates it into
Hibernate-Configurations.
<br>
<br>
A thing I like in CDO is that it solves my serialization and
concurrency
<br>
problems without any additional coding from me.
<br>
<br>
Tom
<br>
<br>
<br>
Am 23.01.10 16:53, schrieb Ande Dietisheim:
<br>
<blockquote type="cite">Eike Stepper wrote:
<br>
<blockquote type="cite">Ande Dietisheim schrieb:
<br>
<blockquote type="cite">[...] I had a few tweets with Ekke
(redview), too. Open ERP Ware (ekkes main
<br>
project) uses CDO to store UI metamodels. On the other hand he uses
<br>
POJOs instead of ecore objects (and possibly CDO) for the data. He
<br>
argues that EclipseLink/Hibernate are more flexible when it comes to
<br>
schema evolution. </blockquote>
What does "more flexible" mean exactly?
<br>
</blockquote>
What Ekke exactly meant with "more flexible" might only be explained by
<br>
Ekke himself.
<br>
I'm no Hibernate nor EclipseLink expert so my impression's probably not
<br>
as accurate as it could be, but I'd love to discuss my impression. I
<br>
wondered what benefits CDO can bring to classic JEE developers compared
<br>
to a classic JEE approach that uses POJOs, OR-Mappers etc.
<br>
The use case I discussed with my contacts needs to evolve the model
<br>
schema at runtime (WYSIWYG editor that allows to edit data models and
<br>
forms). In both scenarios you have to evolve the database schema,
<br>
migrate the data and adapt the object-mapping.
<br>
My rough impression's that the JEE world already has widely used and
<br>
mature tools whereas the emf world's (COPE, edapt, etc.) only getting
<br>
there lately. I therefore guess that investing in this area could grow
<br>
our community. Corret me if you think I'm wrong here...
<br>
I'd love to take Ekke into this discussion to enlight what led him to
<br>
use classic JEE frameworks for his data and ecore/CDO for his UI
metamodels.
<br>
<br>
<blockquote type="cite"><br>
<blockquote type="cite">I therefore think that it would be a
good choice to
<br>
invest more in model evolution. </blockquote>
For whom?
<br>
</blockquote>
for scenarios where a classic JEE approach competes with an approach
<br>
that involves ecore/cdo.
<br>
<br>
<blockquote type="cite">Cheers
<br>
/Eike
<br>
<br>
----
<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>
</blockquote>
</blockquote>
<br>
</blockquote>
<br>
<br>
</blockquote>
<br>
<br>
<div class="moz-signature">-- <br>
<p style="margin-bottom: 0cm;"> <font ,="" color="#808080"
face="Verdana, sans-serif"> <font size="4">ekke (ekkehard gentz)<br>
</font> <font size="3"> independent software-architect<br>
senior erp-consultant<br>
</font> <font size="2">eclipse | osgi | equinox | mdsd | oaw | emf |
uml<br>
max-josefs-platz 30, D-83022 rosenheim, germany<br>
<a class="moz-txt-link-freetext" href="mailto:ekke@ekkes-corner.org">mailto:ekke@ekkes-corner.org</a><br>
homepage (de): <a class="moz-txt-link-freetext" href="http://gentz-software.de">http://gentz-software.de</a><br>
blog (en): <a class="moz-txt-link-freetext" href="http://ekkes-corner.org">http://ekkes-corner.org</a><br>
twitter: @ekkescorner<br>
skype: ekkes-corner<br>
</font> <font size="1"> Steuer-Nr: 156/220/30931 FA Rosenheim, UST-ID:
DE189929490<br>
</font> </font> </p>
</div>
</body>
</html>

--------------000200050302050204060103--


ekke
independent software architect

blog: http://ekkes-corner.org
twitter: @ekkescorner
Re: [CDO] Custom Store Developing [message #509731 is a reply to message #509708] Mon, 25 January 2010 08:43 Go to previous messageGo to next message
Thomas Schindl is currently offline Thomas SchindlFriend
Messages: 6651
Registered: July 2009
Senior Member
[...]

> but to use EMF / CDO as my data model for a very complex ERP Enterprise
> application, with 800 Entity and the application will grow and change
> the model - I cannot imagine how to do this with EMF / CDO. Yes - I can
> use Teneo/JPA as backend store, but there's still the problem of EMF
> Model evolution.

.... and in case of POJO the POJO evolution - so where is the difference?

The only real difference I can think of is that you get "IDE Refactoring
Support" but then how often does one rename stuff?

Tom
Re: [CDO] Custom Store Developing [message #509736 is a reply to message #509709] Mon, 25 January 2010 04:32 Go to previous messageGo to next message
Martin Taal is currently offline Martin TaalFriend
Messages: 5468
Registered: July 2009
Senior Member
Hi Ekke,
To give some background, the CDO/Teneo datastore supports the registration of new epackages for Teneo/Hibernate at
runtime (*). A new epackage automatically results in re-creation of the complete hibernate mapping. Hibernate updates
the underlying db schema with this new mapping. If in this process an epackage would have changed then this change would
also be reflected in the new mapping.

So afaics, for the CDO/Teneo store there is not that much difference between registering new epackage or updating an
existing epackage (as the complete mapping gets recreated).

Btw, I think what Hibernate implements is not extremely advanced but it is workable. So I guess that just a workable
solution for CDO would be nice. Maybe model evolution is easier in CDO if not supported together with auditing or other
advanced features (which are less needed in some environments).

But I think Eike and others have more knowledge here to comment on the possible obstacles in supporting model changes in
CDO core.

(*) Btw, although registering/handling new epackages on-the-fly at runtime is a core CDO feature it is not adviced to do
this in a production system for the Teneo store as you get all kinds of db locking issues. So new epackages/model
evolution for the CDO Hibernate store should be done in a controlled upgrade environment.

gr. Martin

ekke wrote:
> hi martin,
>
> thanks for all your informations about CDO/Teneo - just read the wiki
>
> at the moment all my experiences are using CDO defaults with
> derby-embedded. this was fast enough for our stored View Models.
>
> if I have some time, I'll try Teneo, too.
>
> Do you have examples how it works using CDO/Teneo Hibernate if the model
> changes ?
>
> thx
>
> ekke
> Am 25.01.10 00:36, schrieb Martin Taal:
>> Hi Andre and others,
>> I can only talk about schema evolution for Hibernate. It works fine in
>> that tables and columns and foreign keys are created for you. Indexes
>> are however not added automatically to an existing table. Hibernate
>> does not remove columns/tables and I am not sure if it allows updates
>> of column metadata (type, length, nullability). So the schema
>> evolution of Hibernate is okay and workable but it does not seem very
>> advanced. My feel is also that this part of hibernate has not had a
>> lot of development the past years (but I can be wrong here).
>>
>> As Tom remarks, CDO with Teneo gives you the same schema update
>> behavior as pojo-hibernate. And j2ee developers can use EMF server
>> side with Teneo standard also (so without CDO). So afaics EMF (with
>> CDO/Teneo) can be used in a j2ee environment.
>>
>> So, for me schema evolution is not the main difference between CDO and
>> j2ee technology stacks.
>> From my point of view, what I see as a main difference is that in a
>> jee environment you can work with the actual pojos/business objects on
>> the server. Although this is a planned feature for CDO it is not there
>> yet. Other things which I can do with hibernate is the possibility to
>> get to the lower layers (the sql connection...) in the same db
>> transaction and have important hooks (onflush, onchange, pre-commit,
>> post-commit..) which can be used to attach server side logic to.
>> Another difference between CDO and Hibernate/Eclipselink is that the
>> latter support a standard (JPA), this makes them easier to understand
>> and accept and it gives some credibility (as we all hope that these
>> standards have been designed by people smarter than ourselves...:-).
>>
>> As a last point, there are EMF concepts which are less common in the
>> non EMF world (nl. resources, specific list-implementations,
>> notifications, bi-directional associations and the explicit container
>> relationship). I can imagine that for non-EMF developers these things
>> give a bit of a learning curve and make it harder to accept CDO in
>> non-EMF environments.
>>
>> Just my 2 cents :-)
>>
>> gr. Martin
>>
>> Tom Schindl wrote:
>>> From my POV CDO + Teneo-JPA-(Hibernate) backend store is as flexible as
>>> the any other POJO + JPA solution.
>>>
>>> What I'm trying to say is that if you managed (which not always trivial)
>>> to do model evolution with Hibernate/EclipseLink it should be applicable
>>> to CDO as well because Teneo translates it into
>>> Hibernate-Configurations.
>>>
>>> A thing I like in CDO is that it solves my serialization and concurrency
>>> problems without any additional coding from me.
>>>
>>> Tom
>>>
>>>
>>> Am 23.01.10 16:53, schrieb Ande Dietisheim:
>>>> Eike Stepper wrote:
>>>>> Ande Dietisheim schrieb:
>>>>>> [...] I had a few tweets with Ekke (redview), too. Open ERP Ware
>>>>>> (ekkes main
>>>>>> project) uses CDO to store UI metamodels. On the other hand he uses
>>>>>> POJOs instead of ecore objects (and possibly CDO) for the data. He
>>>>>> argues that EclipseLink/Hibernate are more flexible when it comes to
>>>>>> schema evolution.
>>>>> What does "more flexible" mean exactly?
>>>> What Ekke exactly meant with "more flexible" might only be explained by
>>>> Ekke himself.
>>>> I'm no Hibernate nor EclipseLink expert so my impression's probably not
>>>> as accurate as it could be, but I'd love to discuss my impression. I
>>>> wondered what benefits CDO can bring to classic JEE developers compared
>>>> to a classic JEE approach that uses POJOs, OR-Mappers etc.
>>>> The use case I discussed with my contacts needs to evolve the model
>>>> schema at runtime (WYSIWYG editor that allows to edit data models and
>>>> forms). In both scenarios you have to evolve the database schema,
>>>> migrate the data and adapt the object-mapping.
>>>> My rough impression's that the JEE world already has widely used and
>>>> mature tools whereas the emf world's (COPE, edapt, etc.) only getting
>>>> there lately. I therefore guess that investing in this area could grow
>>>> our community. Corret me if you think I'm wrong here...
>>>> I'd love to take Ekke into this discussion to enlight what led him to
>>>> use classic JEE frameworks for his data and ecore/CDO for his UI
>>>> metamodels.
>>>>
>>>>>
>>>>>> I therefore think that it would be a good choice to
>>>>>> invest more in model evolution.
>>>>> For whom?
>>>> for scenarios where a classic JEE approach competes with an approach
>>>> that involves ecore/cdo.
>>>>
>>>>> Cheers
>>>>> /Eike
>>>>>
>>>>> ----
>>>>> http://thegordian.blogspot.com
>>>>> http://twitter.com/eikestepper
>>>>>
>>>
>>
>>
>
>
> --
>
> ekke (ekkehard gentz)
> independent software-architect
> senior erp-consultant
> eclipse | osgi | equinox | mdsd | oaw | emf | uml
> max-josefs-platz 30, D-83022 rosenheim, germany
> mailto:ekke@ekkes-corner.org
> homepage (de): http://gentz-software.de
> blog (en): http://ekkes-corner.org
> twitter: @ekkescorner
> skype: ekkes-corner
> Steuer-Nr: 156/220/30931 FA Rosenheim, UST-ID: DE189929490
>


--

With Regards, Martin Taal

Springsite/Elver.org
Office: Hardwareweg 4, 3821 BV Amersfoort
Postal: Nassaulaan 7, 3941 EC Doorn
The Netherlands
Cell: +31 (0)6 288 48 943
Tel: +31 (0)84 420 2397
Fax: +31 (0)84 225 9307
Mail: mtaal@springsite.com - mtaal@elver.org
Web: www.springsite.com - www.elver.org
Re: [CDO] Custom Store Developing [message #509745 is a reply to message #509694] Mon, 25 January 2010 09:51 Go to previous messageGo to next message
Eike Stepper is currently offline Eike StepperFriend
Messages: 6682
Registered: July 2009
Senior Member
Hi Guys,

This thread finally made it to "model evolution" ;-)

I think the main problem here is more in the model part of the stack,
not so much in the persistent part (relational DB or whatever). With EMF
it's not possible to deploy two different, versions of a model as
generated plugins (they're marked singleton). The EPackage.Registry does
not permit registration of two different EPackage instances with the
same nsURI. Consequently a model can *NOT* be evolved with the same
nsURI or the same plugin name. It results that objects change their
EClass if a new version of a model is deployed, even if that particular
EClass was not structurally changed over time. That breaks a lot of the
current assumptions about immutability of certain object properties.

Cheers
/Eike

----
http://thegordian.blogspot.com
http://twitter.com/eikestepper



Tom Schindl schrieb:
> From my POV CDO + Teneo-JPA-(Hibernate) backend store is as flexible as
> the any other POJO + JPA solution.
>
> What I'm trying to say is that if you managed (which not always trivial)
> to do model evolution with Hibernate/EclipseLink it should be applicable
> to CDO as well because Teneo translates it into Hibernate-Configurations.
>
> A thing I like in CDO is that it solves my serialization and concurrency
> problems without any additional coding from me.
>
> Tom
>
>
> Am 23.01.10 16:53, schrieb Ande Dietisheim:
>
>> Eike Stepper wrote:
>>
>>> Ande Dietisheim schrieb:
>>>
>>>> [...] I had a few tweets with Ekke (redview), too. Open ERP Ware (ekkes main
>>>> project) uses CDO to store UI metamodels. On the other hand he uses
>>>> POJOs instead of ecore objects (and possibly CDO) for the data. He
>>>> argues that EclipseLink/Hibernate are more flexible when it comes to
>>>> schema evolution.
>>>>
>>> What does "more flexible" mean exactly?
>>>
>> What Ekke exactly meant with "more flexible" might only be explained by
>> Ekke himself.
>> I'm no Hibernate nor EclipseLink expert so my impression's probably not
>> as accurate as it could be, but I'd love to discuss my impression. I
>> wondered what benefits CDO can bring to classic JEE developers compared
>> to a classic JEE approach that uses POJOs, OR-Mappers etc.
>> The use case I discussed with my contacts needs to evolve the model
>> schema at runtime (WYSIWYG editor that allows to edit data models and
>> forms). In both scenarios you have to evolve the database schema,
>> migrate the data and adapt the object-mapping.
>> My rough impression's that the JEE world already has widely used and
>> mature tools whereas the emf world's (COPE, edapt, etc.) only getting
>> there lately. I therefore guess that investing in this area could grow
>> our community. Corret me if you think I'm wrong here...
>> I'd love to take Ekke into this discussion to enlight what led him to
>> use classic JEE frameworks for his data and ecore/CDO for his UI metamodels.
>>
>>
>>>
>>>> I therefore think that it would be a good choice to
>>>> invest more in model evolution.
>>>>
>>> For whom?
>>>
>> for scenarios where a classic JEE approach competes with an approach
>> that involves ecore/cdo.
>>
>>
>>> Cheers
>>> /Eike
>>>
>>> ----
>>> http://thegordian.blogspot.com
>>> http://twitter.com/eikestepper
>>>
>>>
>
>


Re: [CDO] Custom Store Developing [message #509746 is a reply to message #509731] Mon, 25 January 2010 05:00 Go to previous messageGo to next message
ekkehard gentz is currently offline ekkehard gentzFriend
Messages: 118
Registered: July 2009
Location: rosenheim, Germany, bavar...
Senior Member

This is a multi-part message in MIME format.
--------------000302010208090001020809
Content-Type: text/plain; charset=ISO-8859-15; format=flowed
Content-Transfer-Encoding: 7bit

Am 25.01.10 09:43, schrieb Tom Schindl:
> [...]
>
>
>> but to use EMF / CDO as my data model for a very complex ERP Enterprise
>> application, with 800 Entity and the application will grow and change
>> the model - I cannot imagine how to do this with EMF / CDO. Yes - I can
>> use Teneo/JPA as backend store, but there's still the problem of EMF
>> Model evolution.
>>
> ... and in case of POJO the POJO evolution - so where is the difference?
>
> The only real difference I can think of is that you get "IDE Refactoring
> Support" but then how often does one rename stuff?
>
> Tom
>
renaming stuff is not a normal use-case for me, too. most times things
are added.

from our experiences (using cdo default with derby-embedded) following
happened:
we imported some View models into CDO, then we used redView designer to
edit these
models. works well. after saving model-changes are pushed to running rcp
apps.
works also well. then we did changes in our ecore model.
using the XMI EMF Editor the existing models could be read without a
problem.

trying to read existing models from CDO doesnt work. I could see the
models from
CDO session viewer, but I couldn't read them. there also was no way to
say export
models as XMI into workspace, then we could get the models, delete the
repository and
import into CDO again, which would be a solution in our case of storing
View models.

because of missing default tooling the CDO store is something like a
black box -
compared with storing data the 'old' way using hibernate in RDBMS where
I have
much tooling to inspect, manipulate, export / import / query the data

as I wrote in another reply - we didn't test the solution using
Teneo/Hibernate/CDO -
perhaps it works better.

ekke


--

ekke (ekkehard gentz)
independent software-architect
senior erp-consultant
eclipse | osgi | equinox | mdsd | oaw | emf | uml
max-josefs-platz 30, D-83022 rosenheim, germany
mailto:ekke@ekkes-corner.org
homepage (de): http://gentz-software.de
blog (en): http://ekkes-corner.org
twitter: @ekkescorner
skype: ekkes-corner
Steuer-Nr: 156/220/30931 FA Rosenheim, UST-ID: DE189929490


--------------000302010208090001020809
Content-Type: text/html; charset=ISO-8859-15
Content-Transfer-Encoding: 7bit

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html; charset=ISO-8859-15"
http-equiv="Content-Type">
<title></title>
</head>
<body bgcolor="#ffffff" text="#000000">
Am 25.01.10 09:43, schrieb Tom Schindl:
<blockquote cite="mid:hjjljc$4q4$1@build.eclipse.org" type="cite">
<pre wrap="">[...]

</pre>
<blockquote type="cite">
<pre wrap="">but to use EMF / CDO as my data model for a very complex ERP Enterprise
application, with 800 Entity and the application will grow and change
the model - I cannot imagine how to do this with EMF / CDO. Yes - I can
use Teneo/JPA as backend store, but there's still the problem of EMF
Model evolution.
</pre>
</blockquote>
<pre wrap="">
.... and in case of POJO the POJO evolution - so where is the difference?

The only real difference I can think of is that you get "IDE Refactoring
Support" but then how often does one rename stuff?

Tom
</pre>
</blockquote>
renaming stuff is not a normal use-case for me, too. most times things
are added.<br>
<br>
from our experiences (using cdo default with derby-embedded) following
happened:<br>
we imported some View models into CDO, then we used redView designer to
edit these<br>
models. works well. after saving model-changes are pushed to running
rcp apps.<br>
works also well. then we did changes in our ecore model.<br>
using the XMI EMF Editor the existing models could be read without a
problem.<br>
<br>
trying to read existing models from CDO doesnt work. I could see the
models from<br>
CDO session viewer, but I couldn't read them. there also was no way to
say export<br>
models as XMI into workspace, then we could get the models, delete the
repository and<br>
import into CDO again, which would be a solution in our case of storing
View models.<br>
<br>
because of missing default tooling the CDO store is something like a
black box -<br>
compared with storing data the 'old' way using hibernate in RDBMS where
I have<br>
much tooling to inspect, manipulate, export / import / query the data<br>
<br>
as I wrote in another reply - we didn't test the solution using
Teneo/Hibernate/CDO -<br>
perhaps it works better.<br>
<br>
ekke<br>
<br>
<br>
<div class="moz-signature">-- <br>
<p style="margin-bottom: 0cm;"> <font ,="" color="#808080"
face="Verdana, sans-serif"> <font size="4">ekke (ekkehard gentz)<br>
</font> <font size="3"> independent software-architect<br>
senior erp-consultant<br>
</font> <font size="2">eclipse | osgi | equinox | mdsd | oaw | emf |
uml<br>
max-josefs-platz 30, D-83022 rosenheim, germany<br>
<a class="moz-txt-link-freetext" href="mailto:ekke@ekkes-corner.org">mailto:ekke@ekkes-corner.org</a><br>
homepage (de): <a class="moz-txt-link-freetext" href="http://gentz-software.de">http://gentz-software.de</a><br>
blog (en): <a class="moz-txt-link-freetext" href="http://ekkes-corner.org">http://ekkes-corner.org</a><br>
twitter: @ekkescorner<br>
skype: ekkes-corner<br>
</font> <font size="1"> Steuer-Nr: 156/220/30931 FA Rosenheim, UST-ID:
DE189929490<br>
</font> </font> </p>
</div>
</body>
</html>

--------------000302010208090001020809--


ekke
independent software architect

blog: http://ekkes-corner.org
twitter: @ekkescorner
Re: [CDO] Custom Store Developing [message #509754 is a reply to message #509745] Mon, 25 January 2010 10:10 Go to previous messageGo to next message
ekkehard gentz is currently offline ekkehard gentzFriend
Messages: 118
Registered: July 2009
Location: rosenheim, Germany, bavar...
Senior Member

This is a multi-part message in MIME format.
--------------070900010007070606070600
Content-Type: text/plain; charset=ISO-8859-15; format=flowed
Content-Transfer-Encoding: 7bit

Hi Eike,

Am 25.01.10 10:51, schrieb Eike Stepper:
> Hi Guys,
>
> This thread finally made it to "model evolution" ;-)
>
....will we continue our discussion from last EclipseCon in march ? ;-)
> I think the main problem here is more in the model part of the stack,
> not so much in the persistent part (relational DB or whatever). With EMF
> it's not possible to deploy two different, versions of a model as
> generated plugins (they're marked singleton). The EPackage.Registry does
> not permit registration of two different EPackage instances with the
> same nsURI. Consequently a model can *NOT* be evolved with the same
> nsURI or the same plugin name. It results that objects change their
> EClass if a new version of a model is deployed, even if that particular
> EClass was not structurally changed over time. That breaks a lot of the
> current assumptions about immutability of certain object properties.
>
> Cheers
> /Eike
>
>
thanks for clarifying this. ... was also my understanding from our
skype-discussions,
....and as I understand - there's - as today - no default
update-mechanism to "move" existing
models from one version of a model to another one ...

ekke
> ----
> http://thegordian.blogspot.com
> http://twitter.com/eikestepper
>
>
>
> Tom Schindl schrieb:
>
>> From my POV CDO + Teneo-JPA-(Hibernate) backend store is as flexible as
>> the any other POJO + JPA solution.
>>
>> What I'm trying to say is that if you managed (which not always trivial)
>> to do model evolution with Hibernate/EclipseLink it should be applicable
>> to CDO as well because Teneo translates it into Hibernate-Configurations.
>>
>> A thing I like in CDO is that it solves my serialization and concurrency
>> problems without any additional coding from me.
>>
>> Tom
>>
>>
>> Am 23.01.10 16:53, schrieb Ande Dietisheim:
>>
>>
>>> Eike Stepper wrote:
>>>
>>>
>>>> Ande Dietisheim schrieb:
>>>>
>>>>
>>>>> [...] I had a few tweets with Ekke (redview), too. Open ERP Ware (ekkes main
>>>>> project) uses CDO to store UI metamodels. On the other hand he uses
>>>>> POJOs instead of ecore objects (and possibly CDO) for the data. He
>>>>> argues that EclipseLink/Hibernate are more flexible when it comes to
>>>>> schema evolution.
>>>>>
>>>>>
>>>> What does "more flexible" mean exactly?
>>>>
>>>>
>>> What Ekke exactly meant with "more flexible" might only be explained by
>>> Ekke himself.
>>> I'm no Hibernate nor EclipseLink expert so my impression's probably not
>>> as accurate as it could be, but I'd love to discuss my impression. I
>>> wondered what benefits CDO can bring to classic JEE developers compared
>>> to a classic JEE approach that uses POJOs, OR-Mappers etc.
>>> The use case I discussed with my contacts needs to evolve the model
>>> schema at runtime (WYSIWYG editor that allows to edit data models and
>>> forms). In both scenarios you have to evolve the database schema,
>>> migrate the data and adapt the object-mapping.
>>> My rough impression's that the JEE world already has widely used and
>>> mature tools whereas the emf world's (COPE, edapt, etc.) only getting
>>> there lately. I therefore guess that investing in this area could grow
>>> our community. Corret me if you think I'm wrong here...
>>> I'd love to take Ekke into this discussion to enlight what led him to
>>> use classic JEE frameworks for his data and ecore/CDO for his UI metamodels.
>>>
>>>
>>>
>>>>
>>>>
>>>>> I therefore think that it would be a good choice to
>>>>> invest more in model evolution.
>>>>>
>>>>>
>>>> For whom?
>>>>
>>>>
>>> for scenarios where a classic JEE approach competes with an approach
>>> that involves ecore/cdo.
>>>
>>>
>>>
>>>> Cheers
>>>> /Eike
>>>>
>>>> ----
>>>> http://thegordian.blogspot.com
>>>> http://twitter.com/eikestepper
>>>>
>>>>
>>>>
>>
>>


--

ekke (ekkehard gentz)
independent software-architect
senior erp-consultant
eclipse | osgi | equinox | mdsd | oaw | emf | uml
max-josefs-platz 30, D-83022 rosenheim, germany
mailto:ekke@ekkes-corner.org
homepage (de): http://gentz-software.de
blog (en): http://ekkes-corner.org
twitter: @ekkescorner
skype: ekkes-corner
Steuer-Nr: 156/220/30931 FA Rosenheim, UST-ID: DE189929490


--------------070900010007070606070600
Content-Type: text/html; charset=ISO-8859-15
Content-Transfer-Encoding: 7bit

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html; charset=ISO-8859-15"
http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
Hi Eike,<br>
<br>
Am 25.01.10 10:51, schrieb Eike Stepper:
<blockquote cite="mid:hjjpir$1ll$2@build.eclipse.org" type="cite">
<pre wrap="">Hi Guys,

This thread finally made it to "model evolution" ;-)
</pre>
</blockquote>
....will we continue our discussion from last EclipseCon in march ? ;-)<br>
<blockquote cite="mid:hjjpir$1ll$2@build.eclipse.org" type="cite">
<pre wrap="">
I think the main problem here is more in the model part of the stack,
not so much in the persistent part (relational DB or whatever). With EMF
it's not possible to deploy two different, versions of a model as
generated plugins (they're marked singleton). The EPackage.Registry does
not permit registration of two different EPackage instances with the
same nsURI. Consequently a model can *NOT* be evolved with the same
nsURI or the same plugin name. It results that objects change their
EClass if a new version of a model is deployed, even if that particular
EClass was not structurally changed over time. That breaks a lot of the
current assumptions about immutability of certain object properties.

Cheers
/Eike

</pre>
</blockquote>
thanks for clarifying this. ... was also my understanding from our
skype-discussions,<br>
....and as I understand - there's - as today - no default
update-mechanism to "move" existing<br>
models from one version of a model to another one ...<br>
<br>
ekke<br>
<blockquote cite="mid:hjjpir$1ll$2@build.eclipse.org" type="cite">
<pre wrap="">----
<a class="moz-txt-link-freetext" href="http://thegordian.blogspot.com">http://thegordian.blogspot.com</a>
<a class="moz-txt-link-freetext" href="http://twitter.com/eikestepper">http://twitter.com/eikestepper</a>



Tom Schindl schrieb:
</pre>
<blockquote type="cite">
<pre wrap="">From my POV CDO + Teneo-JPA-(Hibernate) backend store is as flexible as
the any other POJO + JPA solution.

What I'm trying to say is that if you managed (which not always trivial)
to do model evolution with Hibernate/EclipseLink it should be applicable
to CDO as well because Teneo translates it into Hibernate-Configurations.

A thing I like in CDO is that it solves my serialization and concurrency
problems without any additional coding from me.

Tom


Am 23.01.10 16:53, schrieb Ande Dietisheim:

</pre>
<blockquote type="cite">
<pre wrap="">Eike Stepper wrote:

</pre>
<blockquote type="cite">
<pre wrap="">Ande Dietisheim schrieb:

</pre>
<blockquote type="cite">
<pre wrap="">[...] I had a few tweets with Ekke (redview), too. Open ERP Ware (ekkes main
project) uses CDO to store UI metamodels. On the other hand he uses
POJOs instead of ecore objects (and possibly CDO) for the data. He
argues that EclipseLink/Hibernate are more flexible when it comes to
schema evolution.

</pre>
</blockquote>
<pre wrap="">What does "more flexible" mean exactly?

</pre>
</blockquote>
<pre wrap="">What Ekke exactly meant with "more flexible" might only be explained by
Ekke himself.
I'm no Hibernate nor EclipseLink expert so my impression's probably not
as accurate as it could be, but I'd love to discuss my impression. I
wondered what benefits CDO can bring to classic JEE developers compared
to a classic JEE approach that uses POJOs, OR-Mappers etc.
The use case I discussed with my contacts needs to evolve the model
schema at runtime (WYSIWYG editor that allows to edit data models and
forms). In both scenarios you have to evolve the database schema,
migrate the data and adapt the object-mapping.
My rough impression's that the JEE world already has widely used and
mature tools whereas the emf world's (COPE, edapt, etc.) only getting
there lately. I therefore guess that investing in this area could grow
our community. Corret me if you think I'm wrong here...
I'd love to take Ekke into this discussion to enlight what led him to
use classic JEE frameworks for his data and ecore/CDO for his UI metamodels.


</pre>
<blockquote type="cite">
<pre wrap="">
</pre>
<blockquote type="cite">
<pre wrap="">I therefore think that it would be a good choice to
invest more in model evolution.

</pre>
</blockquote>
<pre wrap="">For whom?

</pre>
</blockquote>
<pre wrap="">for scenarios where a classic JEE approach competes with an approach
that involves ecore/cdo.


</pre>
<blockquote type="cite">
<pre wrap="">Cheers
/Eike

----
<a class="moz-txt-link-freetext" href="http://thegordian.blogspot.com">http://thegordian.blogspot.com</a>
<a class="moz-txt-link-freetext" href="http://twitter.com/eikestepper">http://twitter.com/eikestepper</a>


</pre>
</blockquote>
</blockquote>
<pre wrap="">

</pre>
</blockquote>
</blockquote>
<br>
<br>
<div class="moz-signature">-- <br>
<p style="margin-bottom: 0cm;"> <font ,="" color="#808080"
face="Verdana, sans-serif"> <font size="4">ekke (ekkehard gentz)<br>
</font> <font size="3"> independent software-architect<br>
senior erp-consultant<br>
</font> <font size="2">eclipse | osgi | equinox | mdsd | oaw | emf |
uml<br>
max-josefs-platz 30, D-83022 rosenheim, germany<br>
<a class="moz-txt-link-freetext" href="mailto:ekke@ekkes-corner.org">mailto:ekke@ekkes-corner.org</a><br>
homepage (de): <a class="moz-txt-link-freetext" href="http://gentz-software.de">http://gentz-software.de</a><br>
blog (en): <a class="moz-txt-link-freetext" href="http://ekkes-corner.org">http://ekkes-corner.org</a><br>
twitter: @ekkescorner<br>
skype: ekkes-corner<br>
</font> <font size="1"> Steuer-Nr: 156/220/30931 FA Rosenheim, UST-ID:
DE189929490<br>
</font> </font> </p>
</div>
</body>
</html>

--------------070900010007070606070600--


ekke
independent software architect

blog: http://ekkes-corner.org
twitter: @ekkescorner
Re: [CDO] Custom Store Developing [message #509773 is a reply to message #509745] Mon, 25 January 2010 11:02 Go to previous messageGo to next message
Thomas Schindl is currently offline Thomas SchindlFriend
Messages: 6651
Registered: July 2009
Senior Member
Hm,

I think there are multiple different levels of model evolution and the
most common model evolution is probably the simplest one:
* adding attributes
* adding entities

and to make this work with CDO/EMF in a none-audit-mode scenario is as
"easy" as it is with POJO. Evolving a POJO(-Model) is as hard if you
take into account renamings, auditing ... as it is with EMF-Models.

Let's look at what one would do for POJO-Models (I don't go into details
but only highlight the difference for ease of description I assume one
uses .xml to define the mapping):

* Attribute Addition
--------------------
POJO:
* Open the MyPOJO.java and add the attribute
* update the hibernate-mapping
* use hibernate tools to evolve your DB-Schema

EMF:
* Open the .ecore and add the attribute
* Regenerate EMF-Model-Classes
* Use Teneo to update the hibernate mapping
* use hibernate tools to evolve your DB-Schema


* Entity Addition:
------------------
POJO:
* Create a new MyPOJO.java
* update the hibernate-mapping
* use hibernate tools to evolve your DB-Schema

EMF:
* Open the .ecore and create new class
* Regenerate EMF-Model-Classes
* Use Teneo to update the hibernate mapping
* use hibernate tools to evolve your DB-Schema


Though you are technically perfectly correct for the above metionned
model evolution one doesn't really need to load two EMF-Models and I
guess the adding-use-case also plays nice with CDO-Audit-Mode because
features would simply hold the default-value for ancient version of a
model object.

I think Ekke's main problem is going to be solved by the Hibernate-Store
and then he also has all his hibernate, DB-Tooling, ... he is used to.

I guess writing an "poor mans model adding attributes-entity
evolution"-tool for the CDO-DbStore would be not too hard though I have
not looked at the store implementation very closely - and before you ask
I don't have time to write such a thing because I think the Teneo-Store
solves all my model evolution problems :-).

Tom

Am 25.01.10 10:51, schrieb Eike Stepper:
> Hi Guys,
>
> This thread finally made it to "model evolution" ;-)
>
> I think the main problem here is more in the model part of the stack,
> not so much in the persistent part (relational DB or whatever). With EMF
> it's not possible to deploy two different, versions of a model as
> generated plugins (they're marked singleton). The EPackage.Registry does
> not permit registration of two different EPackage instances with the
> same nsURI. Consequently a model can *NOT* be evolved with the same
> nsURI or the same plugin name. It results that objects change their
> EClass if a new version of a model is deployed, even if that particular
> EClass was not structurally changed over time. That breaks a lot of the
> current assumptions about immutability of certain object properties.
>
> Cheers
> /Eike
>
> ----
> http://thegordian.blogspot.com
> http://twitter.com/eikestepper
>
>
>
> Tom Schindl schrieb:
>> From my POV CDO + Teneo-JPA-(Hibernate) backend store is as flexible as
>> the any other POJO + JPA solution.
>>
>> What I'm trying to say is that if you managed (which not always trivial)
>> to do model evolution with Hibernate/EclipseLink it should be applicable
>> to CDO as well because Teneo translates it into Hibernate-Configurations.
>>
>> A thing I like in CDO is that it solves my serialization and concurrency
>> problems without any additional coding from me.
>>
>> Tom
>>
>>
>> Am 23.01.10 16:53, schrieb Ande Dietisheim:
>>
>>> Eike Stepper wrote:
>>>
>>>> Ande Dietisheim schrieb:
>>>>
>>>>> [...] I had a few tweets with Ekke (redview), too. Open ERP Ware (ekkes main
>>>>> project) uses CDO to store UI metamodels. On the other hand he uses
>>>>> POJOs instead of ecore objects (and possibly CDO) for the data. He
>>>>> argues that EclipseLink/Hibernate are more flexible when it comes to
>>>>> schema evolution.
>>>>>
>>>> What does "more flexible" mean exactly?
>>>>
>>> What Ekke exactly meant with "more flexible" might only be explained by
>>> Ekke himself.
>>> I'm no Hibernate nor EclipseLink expert so my impression's probably not
>>> as accurate as it could be, but I'd love to discuss my impression. I
>>> wondered what benefits CDO can bring to classic JEE developers compared
>>> to a classic JEE approach that uses POJOs, OR-Mappers etc.
>>> The use case I discussed with my contacts needs to evolve the model
>>> schema at runtime (WYSIWYG editor that allows to edit data models and
>>> forms). In both scenarios you have to evolve the database schema,
>>> migrate the data and adapt the object-mapping.
>>> My rough impression's that the JEE world already has widely used and
>>> mature tools whereas the emf world's (COPE, edapt, etc.) only getting
>>> there lately. I therefore guess that investing in this area could grow
>>> our community. Corret me if you think I'm wrong here...
>>> I'd love to take Ekke into this discussion to enlight what led him to
>>> use classic JEE frameworks for his data and ecore/CDO for his UI metamodels.
>>>
>>>
>>>>
>>>>> I therefore think that it would be a good choice to
>>>>> invest more in model evolution.
>>>>>
>>>> For whom?
>>>>
>>> for scenarios where a classic JEE approach competes with an approach
>>> that involves ecore/cdo.
>>>
>>>
>>>> Cheers
>>>> /Eike
>>>>
>>>> ----
>>>> http://thegordian.blogspot.com
>>>> http://twitter.com/eikestepper
>>>>
>>>>
>>
>>
Re: [CDO] Custom Store Developing [message #509782 is a reply to message #509745] Mon, 25 January 2010 11:35 Go to previous messageGo to next message
Martin Taal is currently offline Martin TaalFriend
Messages: 5468
Registered: July 2009
Senior Member
Hi Eike and others,
Maybe I miss something but afaics many model changes (also the one's outlined by Tom) require a restart anyway (as the
business logic changes and new java classes are added etc.). Also for many model changes they require deployment in a
very controlled way (together with other database data changes for example).

So to me it seems that the app (client at least) needs to be restarted anyway.
In this case, if my model changes, I regenerate the model code (for the client) and then have an updated ecore. Then
after a restart there will be only one epackage instance in the registry which represents the new epackage.

If the new epackage would have a version number (eannotation?) somewhere the CDO server could detect a change and update
the model in the database and the database schema. Very similar to that also detects new epackages and persists them
(with a db schema update).

or do I miss something obvious somewhere?

gr. Martin

Eike Stepper wrote:
> Hi Guys,
>
> This thread finally made it to "model evolution" ;-)
>
> I think the main problem here is more in the model part of the stack,
> not so much in the persistent part (relational DB or whatever). With EMF
> it's not possible to deploy two different, versions of a model as
> generated plugins (they're marked singleton). The EPackage.Registry does
> not permit registration of two different EPackage instances with the
> same nsURI. Consequently a model can *NOT* be evolved with the same
> nsURI or the same plugin name. It results that objects change their
> EClass if a new version of a model is deployed, even if that particular
> EClass was not structurally changed over time. That breaks a lot of the
> current assumptions about immutability of certain object properties.
>
> Cheers
> /Eike
>
> ----
> http://thegordian.blogspot.com
> http://twitter.com/eikestepper
>
>
>
> Tom Schindl schrieb:
>> From my POV CDO + Teneo-JPA-(Hibernate) backend store is as flexible as
>> the any other POJO + JPA solution.
>>
>> What I'm trying to say is that if you managed (which not always trivial)
>> to do model evolution with Hibernate/EclipseLink it should be applicable
>> to CDO as well because Teneo translates it into Hibernate-Configurations.
>>
>> A thing I like in CDO is that it solves my serialization and concurrency
>> problems without any additional coding from me.
>>
>> Tom
>>
>>
>> Am 23.01.10 16:53, schrieb Ande Dietisheim:
>>
>>> Eike Stepper wrote:
>>>
>>>> Ande Dietisheim schrieb:
>>>>
>>>>> [...] I had a few tweets with Ekke (redview), too. Open ERP Ware (ekkes main
>>>>> project) uses CDO to store UI metamodels. On the other hand he uses
>>>>> POJOs instead of ecore objects (and possibly CDO) for the data. He
>>>>> argues that EclipseLink/Hibernate are more flexible when it comes to
>>>>> schema evolution.
>>>>>
>>>> What does "more flexible" mean exactly?
>>>>
>>> What Ekke exactly meant with "more flexible" might only be explained by
>>> Ekke himself.
>>> I'm no Hibernate nor EclipseLink expert so my impression's probably not
>>> as accurate as it could be, but I'd love to discuss my impression. I
>>> wondered what benefits CDO can bring to classic JEE developers compared
>>> to a classic JEE approach that uses POJOs, OR-Mappers etc.
>>> The use case I discussed with my contacts needs to evolve the model
>>> schema at runtime (WYSIWYG editor that allows to edit data models and
>>> forms). In both scenarios you have to evolve the database schema,
>>> migrate the data and adapt the object-mapping.
>>> My rough impression's that the JEE world already has widely used and
>>> mature tools whereas the emf world's (COPE, edapt, etc.) only getting
>>> there lately. I therefore guess that investing in this area could grow
>>> our community. Corret me if you think I'm wrong here...
>>> I'd love to take Ekke into this discussion to enlight what led him to
>>> use classic JEE frameworks for his data and ecore/CDO for his UI metamodels.
>>>
>>>
>>>>
>>>>> I therefore think that it would be a good choice to
>>>>> invest more in model evolution.
>>>>>
>>>> For whom?
>>>>
>>> for scenarios where a classic JEE approach competes with an approach
>>> that involves ecore/cdo.
>>>
>>>
>>>> Cheers
>>>> /Eike
>>>>
>>>> ----
>>>> http://thegordian.blogspot.com
>>>> http://twitter.com/eikestepper
>>>>
>>>>
>>


--

With Regards, Martin Taal

Springsite/Elver.org
Office: Hardwareweg 4, 3821 BV Amersfoort
Postal: Nassaulaan 7, 3941 EC Doorn
The Netherlands
Cell: +31 (0)6 288 48 943
Tel: +31 (0)84 420 2397
Fax: +31 (0)84 225 9307
Mail: mtaal@springsite.com - mtaal@elver.org
Web: www.springsite.com - www.elver.org
Re: [CDO] Custom Store Developing [message #509949 is a reply to message #509562] Mon, 25 January 2010 20:54 Go to previous messageGo to next message
Oliver is currently offline OliverFriend
Messages: 20
Registered: July 2009
Junior Member
Thank you guys for the answers!

Eike, I can test the storage backend with Orcale connector earliest next
week. So I have some time to get scalability into the backend.

The origin "flat" meta model looks like:

- Node (Name, Ident, Type : EString)
- Attribute (Ident, Node, Type, Value : EString)
- Relation (Ident, From, To, Type : EString)

In this case, all nodes, attributes and relations are root objects -> no
EReferences -> no scalability.

To get the scalability into the meta model, the meta model have to
become a new root EClass that holds in a EReference-List all nodes,
attributes and relations:

- Repository (entries : EReference to IEntry with 0..* multiplicity,
setted containment flag and resolve proxies = false)
- Interface IEntry
- Node implements IEntry (Name, Ident, Type : EString)
- Attribute implements IEntry (Ident, Node, Type, Value : EString)
- Relation implements IEntry (Ident, From, To, Type : EString)

So I hope, CDO now can load the entries list partially. To get an idea
of when a StoreChunkReader is created by StoreAccessor.createChunkReader
I've added some println statements into the MEMStore. But I've got
surprised about, that createChunkReader is never invoked. The session is
setuped with:

CDOCollectionLoadingPolicy policy = CDOUtil
.createCollectionLoadingPolicy(0, 10);
session.options().setCollectionLoadingPolicy(policy);

I've assumed, that when I get the root object "Repository" that contains
the EStructualFeature "entries" and do something like:

Repository repository = (Repository) resource.get(0);
for (IEntry : repository.getEntries()) {
// do something
}

, a ChunkReader for the current revision and the "entries" feature would
created. And every 10 iterations of the loop, the
StoreChunkReader.executeRead method will invoked. But createChunkReader
is never called. I thought, that a StoreChunkReader is created to send a
part of CDOIDs of a EReference-List.

When it runs, I hope it is possible to call Xtend with only one CDO
Object (in this case a Repository-Object). Remind, the first version of
the meta model have only root objects, so Xtends needed all thousands of
objects in an array to get worked.

Can you help me?

Ciao Oliver
Re: [CDO] Custom Store Developing [message #510005 is a reply to message #509949] Tue, 26 January 2010 02:06 Go to previous message
Eike Stepper is currently offline Eike StepperFriend
Messages: 6682
Registered: July 2009
Senior Member
Hi Oliver,

I fear I can not help much without debugging through your code and I
currently don't have time for that. I suggest that you compare your
behaviour with the one tested in org.eclipse.emf.cdo.tests.ChunkingTest.
Does that give you new insights?

Cheers
/Eike

----
http://thegordian.blogspot.com
http://twitter.com/eikestepper



Oliver schrieb:
> Thank you guys for the answers!
>
> Eike, I can test the storage backend with Orcale connector earliest
> next week. So I have some time to get scalability into the backend.
>
> The origin "flat" meta model looks like:
>
> - Node (Name, Ident, Type : EString)
> - Attribute (Ident, Node, Type, Value : EString)
> - Relation (Ident, From, To, Type : EString)
>
> In this case, all nodes, attributes and relations are root objects ->
> no EReferences -> no scalability.
>
> To get the scalability into the meta model, the meta model have to
> become a new root EClass that holds in a EReference-List all nodes,
> attributes and relations:
>
> - Repository (entries : EReference to IEntry with 0..* multiplicity,
> setted containment flag and resolve proxies = false)
> - Interface IEntry
> - Node implements IEntry (Name, Ident, Type : EString)
> - Attribute implements IEntry (Ident, Node, Type, Value : EString)
> - Relation implements IEntry (Ident, From, To, Type : EString)
>
> So I hope, CDO now can load the entries list partially. To get an idea
> of when a StoreChunkReader is created by
> StoreAccessor.createChunkReader I've added some println statements
> into the MEMStore. But I've got surprised about, that
> createChunkReader is never invoked. The session is setuped with:
>
> CDOCollectionLoadingPolicy policy = CDOUtil
> .createCollectionLoadingPolicy(0, 10);
> session.options().setCollectionLoadingPolicy(policy);
>
> I've assumed, that when I get the root object "Repository" that
> contains the EStructualFeature "entries" and do something like:
>
> Repository repository = (Repository) resource.get(0);
> for (IEntry : repository.getEntries()) {
> // do something
> }
>
> , a ChunkReader for the current revision and the "entries" feature
> would created. And every 10 iterations of the loop, the
> StoreChunkReader.executeRead method will invoked. But
> createChunkReader is never called. I thought, that a StoreChunkReader
> is created to send a part of CDOIDs of a EReference-List.
>
> When it runs, I hope it is possible to call Xtend with only one CDO
> Object (in this case a Repository-Object). Remind, the first version
> of the meta model have only root objects, so Xtends needed all
> thousands of objects in an array to get worked.
>
> Can you help me?
>
> Ciao Oliver


Previous Topic:EMF's OSGI Configuration
Next Topic:[CDO] Adding to CDO server properties programmatically
Goto Forum:
  


Current Time: Thu Mar 28 23:39:43 GMT 2024

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

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

Back to the top