Skip to main content


Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Modeling » EMF "Technology" (Ecore Tools, EMFatic, etc)  » [CDO] is it what I want ?
[CDO] is it what I want ? [message #108921] Tue, 29 January 2008 12:28 Go to next message
Eclipse UserFriend
Originally posted by: tom.eiswind.de

HI I learned about teneo and cdo only the last couple of days. I like
soemthink about cdo, but I wonder if its hwat I actually want. I have a
typical three tiered architecture. currently i have JPA entities
persited with hibernate in my domain model. what I like is that CDO
promises to handle the lazy loading of the model to the client (which I
currently cant with hibernate) for a single business object i always
have to load the whole object graph and transfer it to the client. But I
come from relational database background. so I wonder if i have an emf
model for everything, how can i query it (for e.g. give me all persons
with name like '%Thomas%' ? how is the cdo persistence layer ? I want to
be db independant (at least postgres, sql server, oracle). I have tons
of data, what about performance issues ? with hibernate i can tune many
things on the db. would be glad if you can teach me something about cdo :)

Regards Thomas
Re: [CDO] is it what I want ? [message #108996 is a reply to message #108921] Tue, 29 January 2008 14:01 Go to previous messageGo to next message
Eclipse UserFriend
Originally posted by: stepper.sympedia.de

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

Hi Thomas,

With CDO you need a CDOView to access model objects. CDOView in the
current 0.8 stream doesn't have API to query the repository. The former
stream had it, but since 0.8 is a complete rewrite this is one of the
few outstanding features to be rewritten. If you open an enhancement
request I can add a method like the following:
| /**
* Sends a query to the repository and returns a list of the matching objects or an empty list if no object matched
* the query. The query must be in a language that is supported by the store of the repository. For example, if the
* repository of this view's session has a DBStore configured, the query must be a valid SQL select statement.
*/
*public *EList<CDOObject> query(String query);|


CDO is basically DB independent. In fact it is even not bound to work
with JDBC databases. An IRepository works with an IStore which I have
implemented as DBStore (JDBC connection plus O/R mapping). There's also
a MEMStore and another user has developed an OODBStore (non-public so
far). The DBStore itself is independent of different DB vendors (driver
and dialect). CDO ships with DB adapters for Derby, Hsqldb and Mysql. It
is very easy to develop other DB adapters. An example is the DerbyAdapter:
|/********************************************************** *****************
* Copyright (c) 2004 - 2008 Eike Stepper, Germany.
* All rights reserved. This program and the accompanying materials
* are made available under the terms of the Eclipse Public License v1.0
* which accompanies this distribution, and is available at
* http://www.eclipse.org/legal/epl-v10.html
*
* Contributors:
* Eike Stepper - initial API and implementation
************************************************************ **************/
*package *org.eclipse.net4j.db.internal.derby;

*import *org.eclipse.net4j.db.DBType;
*import *org.eclipse.net4j.db.ddl.IDBField;
*import *org.eclipse.net4j.internal.db.DBAdapter;
*import *org.eclipse.net4j.internal.db.ddl.DBField;

*import *org.apache.derby.jdbc.EmbeddedDriver;

*import *java.sql.Driver;
*import *java.util.Arrays;

/**
* @author Eike Stepper
*/
*public class *DerbyAdapter *extends *DBAdapter
{
*private static final *String[] RESERVED_WORDS = { "ADD", "ALL", "ALLOCATE", "ALTER", "AND", "ANY", "ARE", "AS", "ASC",
"ASSERTION", "AT", "AUTHORIZATION", "AVG", "BEGIN", "BETWEEN", "BIGINT", "BIT", "BOOLEAN", "BOTH", "BY", "CALL",
"CASCADE", "CASCADED", "CASE", "CAST", "CHAR", "CHARACTER", "CHECK", "CLOSE", "COALESCE", "COLLATE", "COLLATION",
"COLUMN", "COMMIT", "CONNECT", "CONNECTION", "CONSTRAINT", "CONSTRAINTS", "CONTINUE", "CONVERT", "CORRESPONDING",
"CREATE", "CURRENT", "CURRENT_DATE", "CURRENT_TIME", "CURRENT_TIMESTAMP", "CURRENT_USER", "CURSOR", "DEALLOCATE",
"DEC", "DECIMAL", "DECLARE", "DEFAULT", "DEFERRABLE", "DEFERRED", "DELETE", "DESC", "DESCRIBE", "DIAGNOSTICS",
"DISCONNECT", "DISTINCT", "DOUBLE", "DROP", "ELSE", "END", "END-EXEC", "ESCAPE", "EXCEPT", "EXCEPTION", "EXEC",
"EXECUTE", "EXISTS", "EXPLAIN", "EXTERNAL", "FALSE", "FETCH", "FIRST", "FLOAT", "FOR", "FOREIGN", "FOUND",
"FROM", "FULL", "FUNCTION", "GET", "GETCURRENTCONNECTION", "GLOBAL", "GO", "GOTO", "GRANT", "GROUP", "HAVING",
"HOUR", "IDENTITY", "IMMEDIATE", "IN", "INDICATOR", "INITIALLY", "INNER", "INOUT", "INPUT", "INSENSITIVE",
"INSERT", "INT", "INTEGER", "INTERSECT", "INTO", "IS", "ISOLATION", "JOIN", "KEY", "LAST", "LEFT", "LIKE",
"LOWER", "LTRIM", "MATCH", "MAX", "MIN", "MINUTE", "NATIONAL", "NATURAL", "NCHAR", "NVARCHAR", "NEXT", "NO",
"NOT", "NULL", "NULLIF", "NUMERIC", "OF", "ON", "ONLY", "OPEN", "OPTION", "OR", "ORDER", "OUTER", "OUTPUT",
"OVERLAPS", "PAD", "PARTIAL", "PREPARE", "PRESERVE", "PRIMARY", "PRIOR", "PRIVILEGES", "PROCEDURE", "PUBLIC",
"READ", "REAL", "REFERENCES", "RELATIVE", "RESTRICT", "REVOKE", "RIGHT", "ROLLBACK", "ROWS", "RTRIM", "SCHEMA",
"SCROLL", "SECOND", "SELECT", "SESSION_USER", "SET", "SMALLINT", "SOME", "SPACE", "SQL", "SQLCODE", "SQLERROR",
"SQLSTATE", "SUBSTR", "SUBSTRING", "SUM", "SYSTEM_USER", "TABLE", "TEMPORARY", "TIMEZONE_HOUR",
"TIMEZONE_MINUTE", "TO", "TRANSACTION", "TRANSLATE", "TRANSLATION", "TRIM", "TRUE", "UNION", "UNIQUE", "UNKNOWN",
"UPDATE", "UPPER", "USER", "USING", "VALUES", "VARCHAR", "VARYING", "VIEW", "WHENEVER", "WHERE", "WITH", "WORK",
"WRITE", "XML", "XMLEXISTS", "XMLPARSE", "XMLQUERY", "XMLSERIALIZE", "YEAR" };

*public *DerbyAdapter()
{
*super*("derby", "10.2.2.0");
}

*public *Driver getJDBCDriver()
{
*return new *EmbeddedDriver();
}

@Override
*protected *String getTypeName(DBField field)
{
DBType type = field.getType();
*switch *(type)
{
*case *BOOLEAN:
*case *BIT:
*return *"SMALLINT";
}

*return super*.getTypeName(field);
}

@Override
*public **void *appendValue(StringBuilder builder, IDBField field, Object value)
{
*if *(value *instanceof *Boolean)
{
value = (Boolean)value ? 1 : 0;
}

*super*.appendValue(builder, field, value);
}

@Override
*protected **boolean *isReservedWord(String word)
{
*return *Arrays.binarySearch(RESERVED_WORDS, word.toUpperCase()) >= 0;
}
}|


The performance of CDO is highly optimized especially between the client
and the repository (above the store implementation). The DBStore (the
facility that is responsible for server side O/R mapping) seems fast to
me, but I have no evidence for it since we haven't started to implement
a comparable IStore on the base of server side Hibernate. I suggest that
you try the DBStore and report your experiences here ;-)

If you have more questions, please don't hesitate to ask them here.

Regards,
Eike Stepper
----
http://wiki.eclipse.org/CDO
http://wiki.eclipse.org/Net4j



Thomas schrieb:
> HI I learned about teneo and cdo only the last couple of days. I like
> soemthink about cdo, but I wonder if its hwat I actually want. I have
> a typical three tiered architecture. currently i have JPA entities
> persited with hibernate in my domain model. what I like is that CDO
> promises to handle the lazy loading of the model to the client (which
> I currently cant with hibernate) for a single business object i always
> have to load the whole object graph and transfer it to the client. But
> I come from relational database background. so I wonder if i have an
> emf model for everything, how can i query it (for e.g. give me all
> persons with name like '%Thomas%' ? how is the cdo persistence layer ?
> I want to be db independant (at least postgres, sql server, oracle). I
> have tons of data, what about performance issues ? with hibernate i
> can tune many things on the db. would be glad if you can teach me
> something about cdo :)
>
> Regards Thomas

--------------030606020309080208060407
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 Thomas,<br>
<br>
With CDO you need a CDOView to access model objects. CDOView in the
current 0.8 stream doesn't have API to query the repository. The former
stream had it, but since 0.8 is a complete rewrite this is one of the
few outstanding features to be rewritten. If you open an enhancement
request I can add a method like the following:<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] is it what I want ? [message #109034 is a reply to message #108996] Tue, 29 January 2008 14:16 Go to previous messageGo to next message
Eclipse UserFriend
Originally posted by: tom.eiswind.de

Hello Eike,

thanks for your reply. Im just evaluating. So Ill open a request as soon
as I decide to dive deeper into it. If I understand you right the query
will be executed on the server and has to be pure sql. For that I would
have to learn about the mapping strategy (am used to hibernate though).
How would such an sql query have to look like ? I understand that I
would have to implement the queries on the client side then, but that
should be no problem. Another question I have is about mapping. Suggest
I have an EMF model (playing around with it right now) how is it mapped
qo the db ? are there annotations for eg varchar length, nullability etc
? I have to look into emf validation as for now I have hibernate
validators bound into the databinding framework that do client side
validation. many questions :)

Regards Thomas

Eike Stepper schrieb:
> Hi Thomas,
>
> With CDO you need a CDOView to access model objects. CDOView in the
> current 0.8 stream doesn't have API to query the repository. The former
> stream had it, but since 0.8 is a complete rewrite this is one of the
> few outstanding features to be rewritten. If you open an enhancement
> request I can add a method like the following:
> | /**
> * Sends a query to the repository and returns a list of the matching objects or an empty list if no object matched
> * the query. The query must be in a language that is supported by the store of the repository. For example, if the
> * repository of this view's session has a DBStore configured, the query must be a valid SQL select statement.
> */
> *public *EList<CDOObject> query(String query);|
>
>
> CDO is basically DB independent. In fact it is even not bound to work
> with JDBC databases. An IRepository works with an IStore which I have
> implemented as DBStore (JDBC connection plus O/R mapping). There's also
> a MEMStore and another user has developed an OODBStore (non-public so
> far). The DBStore itself is independent of different DB vendors (driver
> and dialect). CDO ships with DB adapters for Derby, Hsqldb and Mysql. It
> is very easy to develop other DB adapters. An example is the DerbyAdapter:
> |/********************************************************** *****************
> * Copyright (c) 2004 - 2008 Eike Stepper, Germany.
> * All rights reserved. This program and the accompanying materials
> * are made available under the terms of the Eclipse Public License v1.0
> * which accompanies this distribution, and is available at
> * http://www.eclipse.org/legal/epl-v10.html
> *
> * Contributors:
> * Eike Stepper - initial API and implementation
> ************************************************************ **************/
> *package *org.eclipse.net4j.db.internal.derby;
>
> *import *org.eclipse.net4j.db.DBType;
> *import *org.eclipse.net4j.db.ddl.IDBField;
> *import *org.eclipse.net4j.internal.db.DBAdapter;
> *import *org.eclipse.net4j.internal.db.ddl.DBField;
>
> *import *org.apache.derby.jdbc.EmbeddedDriver;
>
> *import *java.sql.Driver;
> *import *java.util.Arrays;
>
> /**
> * @author Eike Stepper
> */
> *public class *DerbyAdapter *extends *DBAdapter
> {
> *private static final *String[] RESERVED_WORDS = { "ADD", "ALL", "ALLOCATE", "ALTER", "AND", "ANY", "ARE", "AS", "ASC",
> "ASSERTION", "AT", "AUTHORIZATION", "AVG", "BEGIN", "BETWEEN", "BIGINT", "BIT", "BOOLEAN", "BOTH", "BY", "CALL",
> "CASCADE", "CASCADED", "CASE", "CAST", "CHAR", "CHARACTER", "CHECK", "CLOSE", "COALESCE", "COLLATE", "COLLATION",
> "COLUMN", "COMMIT", "CONNECT", "CONNECTION", "CONSTRAINT", "CONSTRAINTS", "CONTINUE", "CONVERT", "CORRESPONDING",
> "CREATE", "CURRENT", "CURRENT_DATE", "CURRENT_TIME", "CURRENT_TIMESTAMP", "CURRENT_USER", "CURSOR", "DEALLOCATE",
> "DEC", "DECIMAL", "DECLARE", "DEFAULT", "DEFERRABLE", "DEFERRED", "DELETE", "DESC", "DESCRIBE", "DIAGNOSTICS",
> "DISCONNECT", "DISTINCT", "DOUBLE", "DROP", "ELSE", "END", "END-EXEC", "ESCAPE", "EXCEPT", "EXCEPTION", "EXEC",
> "EXECUTE", "EXISTS", "EXPLAIN", "EXTERNAL", "FALSE", "FETCH", "FIRST", "FLOAT", "FOR", "FOREIGN", "FOUND",
> "FROM", "FULL", "FUNCTION", "GET", "GETCURRENTCONNECTION", "GLOBAL", "GO", "GOTO", "GRANT", "GROUP", "HAVING",
> "HOUR", "IDENTITY", "IMMEDIATE", "IN", "INDICATOR", "INITIALLY", "INNER", "INOUT", "INPUT", "INSENSITIVE",
> "INSERT", "INT", "INTEGER", "INTERSECT", "INTO", "IS", "ISOLATION", "JOIN", "KEY", "LAST", "LEFT", "LIKE",
> "LOWER", "LTRIM", "MATCH", "MAX", "MIN", "MINUTE", "NATIONAL", "NATURAL", "NCHAR", "NVARCHAR", "NEXT", "NO",
> "NOT", "NULL", "NULLIF", "NUMERIC", "OF", "ON", "ONLY", "OPEN", "OPTION", "OR", "ORDER", "OUTER", "OUTPUT",
> "OVERLAPS", "PAD", "PARTIAL", "PREPARE", "PRESERVE", "PRIMARY", "PRIOR", "PRIVILEGES", "PROCEDURE", "PUBLIC",
> "READ", "REAL", "REFERENCES", "RELATIVE", "RESTRICT", "REVOKE", "RIGHT", "ROLLBACK", "ROWS", "RTRIM", "SCHEMA",
> "SCROLL", "SECOND", "SELECT", "SESSION_USER", "SET", "SMALLINT", "SOME", "SPACE", "SQL", "SQLCODE", "SQLERROR",
> "SQLSTATE", "SUBSTR", "SUBSTRING", "SUM", "SYSTEM_USER", "TABLE", "TEMPORARY", "TIMEZONE_HOUR",
> "TIMEZONE_MINUTE", "TO", "TRANSACTION", "TRANSLATE", "TRANSLATION", "TRIM", "TRUE", "UNION", "UNIQUE", "UNKNOWN",
> "UPDATE", "UPPER", "USER", "USING", "VALUES", "VARCHAR", "VARYING", "VIEW", "WHENEVER", "WHERE", "WITH", "WORK",
> "WRITE", "XML", "XMLEXISTS", "XMLPARSE", "XMLQUERY", "XMLSERIALIZE", "YEAR" };
>
> *public *DerbyAdapter()
> {
> *super*("derby", "10.2.2.0");
> }
>
> *public *Driver getJDBCDriver()
> {
> *return new *EmbeddedDriver();
> }
>
> @Override
> *protected *String getTypeName(DBField field)
> {
> DBType type = field.getType();
> *switch *(type)
> {
> *case *BOOLEAN:
> *case *BIT:
> *return *"SMALLINT";
> }
>
> *return super*.getTypeName(field);
> }
>
> @Override
> *public **void *appendValue(StringBuilder builder, IDBField field, Object value)
> {
> *if *(value *instanceof *Boolean)
> {
> value = (Boolean)value ? 1 : 0;
> }
>
> *super*.appendValue(builder, field, value);
> }
>
> @Override
> *protected **boolean *isReservedWord(String word)
> {
> *return *Arrays.binarySearch(RESERVED_WORDS, word.toUpperCase()) >= 0;
> }
> }|
>
>
> The performance of CDO is highly optimized especially between the client
> and the repository (above the store implementation). The DBStore (the
> facility that is responsible for server side O/R mapping) seems fast to
> me, but I have no evidence for it since we haven't started to implement
> a comparable IStore on the base of server side Hibernate. I suggest that
> you try the DBStore and report your experiences here ;-)
>
> If you have more questions, please don't hesitate to ask them here.
>
> Regards,
> Eike Stepper
> ----
> http://wiki.eclipse.org/CDO
> http://wiki.eclipse.org/Net4j
>
>
>
> Thomas schrieb:
>> HI I learned about teneo and cdo only the last couple of days. I like
>> soemthink about cdo, but I wonder if its hwat I actually want. I have
>> a typical three tiered architecture. currently i have JPA entities
>> persited with hibernate in my domain model. what I like is that CDO
>> promises to handle the lazy loading of the model to the client (which
>> I currently cant with hibernate) for a single business object i always
>> have to load the whole object graph and transfer it to the client. But
>> I come from relational database background. so I wonder if i have an
>> emf model for everything, how can i query it (for e.g. give me all
>> persons with name like '%Thomas%' ? how is the cdo persistence layer ?
>> I want to be db independant (at least postgres, sql server, oracle). I
>> have tons of data, what about performance issues ? with hibernate i
>> can tune many things on the db. would be glad if you can teach me
>> something about cdo :)
>>
>> Regards Thomas
Re: [CDO] is it what I want ? [message #109047 is a reply to message #108996] Tue, 29 January 2008 14:22 Go to previous messageGo to next message
Eclipse UserFriend
Originally posted by: tom.eiswind.de

Once again..
Another thing coming to my mind is about the object graph. Suggest I
have a Object Person with a Collection of Adresses. when I query for the
person did I get it right that the Adresse are only loaded when I try to
access them ? That would be the main decision factor for me. I have
expensive objects and the more the could be lazy loaded the better my ui
handling would be.

Regards Thomas
Re: [CDO] is it what I want ? [message #109073 is a reply to message #109034] Tue, 29 January 2008 14:31 Go to previous messageGo to next message
Simon Mc Duff is currently offline Simon Mc DuffFriend
Messages: 596
Registered: July 2009
Senior Member
Hi Thomas,

I would like to share our experience with CDO and Query.

To use a more standard API, we develop a basic (not complete yet) JPA
implementation using CDO.
For the query, (this is the part I want to mention you) we use OCL as our
language.

From EntityManager we use createNativeQuery() method to pass the string from
the client to the server.

On the server we delegate the call to the IStoreQuery

Now, to be able to execute it the database provider could have 2 choices :

- Convert the OCL language to an SQL
- Use extension point in OCL to interact with your database.

It returns a list of ID.. so you no dot load all tha data.

So far we used solutions number 2.

I hope this can help you.


"Thomas" <tom@eiswind.de> wrote in message
news:fnncgj$ktv$1@build.eclipse.org...
> Hello Eike,
>
> thanks for your reply. Im just evaluating. So Ill open a request as soon
> as I decide to dive deeper into it. If I understand you right the query
> will be executed on the server and has to be pure sql. For that I would
> have to learn about the mapping strategy (am used to hibernate though).
> How would such an sql query have to look like ? I understand that I would
> have to implement the queries on the client side then, but that should be
> no problem. Another question I have is about mapping. Suggest I have an
> EMF model (playing around with it right now) how is it mapped qo the db ?
> are there annotations for eg varchar length, nullability etc ? I have to
> look into emf validation as for now I have hibernate validators bound into
> the databinding framework that do client side validation. many questions
> :)
>
> Regards Thomas
>
> Eike Stepper schrieb:
>> Hi Thomas,
>>
>> With CDO you need a CDOView to access model objects. CDOView in the
>> current 0.8 stream doesn't have API to query the repository. The former
>> stream had it, but since 0.8 is a complete rewrite this is one of the few
>> outstanding features to be rewritten. If you open an enhancement request
>> I can add a method like the following:
>> | /**
>> * Sends a query to the repository and returns a list of the matching
>> objects or an empty list if no object matched
>> * the query. The query must be in a language that is supported by the
>> store of the repository. For example, if the
>> * repository of this view's session has a DBStore configured, the
>> query must be a valid SQL select statement.
>> */
>> *public *EList<CDOObject> query(String query);|
>>
>>
>> CDO is basically DB independent. In fact it is even not bound to work
>> with JDBC databases. An IRepository works with an IStore which I have
>> implemented as DBStore (JDBC connection plus O/R mapping). There's also a
>> MEMStore and another user has developed an OODBStore (non-public so far).
>> The DBStore itself is independent of different DB vendors (driver and
>> dialect). CDO ships with DB adapters for Derby, Hsqldb and Mysql. It is
>> very easy to develop other DB adapters. An example is the DerbyAdapter:
>> |/********************************************************** *****************
>> * Copyright (c) 2004 - 2008 Eike Stepper, Germany.
>> * All rights reserved. This program and the accompanying materials
>> * are made available under the terms of the Eclipse Public License v1.0
>> * which accompanies this distribution, and is available at
>> * http://www.eclipse.org/legal/epl-v10.html
>> * * Contributors:
>> * Eike Stepper - initial API and implementation
>>
>> ************************************************************ **************/
>> *package *org.eclipse.net4j.db.internal.derby;
>>
>> *import *org.eclipse.net4j.db.DBType;
>> *import *org.eclipse.net4j.db.ddl.IDBField;
>> *import *org.eclipse.net4j.internal.db.DBAdapter;
>> *import *org.eclipse.net4j.internal.db.ddl.DBField;
>>
>> *import *org.apache.derby.jdbc.EmbeddedDriver;
>>
>> *import *java.sql.Driver;
>> *import *java.util.Arrays;
>>
>> /**
>> * @author Eike Stepper
>> */
>> *public class *DerbyAdapter *extends *DBAdapter
>> {
>> *private static final *String[] RESERVED_WORDS = { "ADD", "ALL",
>> "ALLOCATE", "ALTER", "AND", "ANY", "ARE", "AS", "ASC",
>> "ASSERTION", "AT", "AUTHORIZATION", "AVG", "BEGIN", "BETWEEN",
>> "BIGINT", "BIT", "BOOLEAN", "BOTH", "BY", "CALL",
>> "CASCADE", "CASCADED", "CASE", "CAST", "CHAR", "CHARACTER",
>> "CHECK", "CLOSE", "COALESCE", "COLLATE", "COLLATION",
>> "COLUMN", "COMMIT", "CONNECT", "CONNECTION", "CONSTRAINT",
>> "CONSTRAINTS", "CONTINUE", "CONVERT", "CORRESPONDING",
>> "CREATE", "CURRENT", "CURRENT_DATE", "CURRENT_TIME",
>> "CURRENT_TIMESTAMP", "CURRENT_USER", "CURSOR", "DEALLOCATE",
>> "DEC", "DECIMAL", "DECLARE", "DEFAULT", "DEFERRABLE", "DEFERRED",
>> "DELETE", "DESC", "DESCRIBE", "DIAGNOSTICS",
>> "DISCONNECT", "DISTINCT", "DOUBLE", "DROP", "ELSE", "END",
>> "END-EXEC", "ESCAPE", "EXCEPT", "EXCEPTION", "EXEC",
>> "EXECUTE", "EXISTS", "EXPLAIN", "EXTERNAL", "FALSE", "FETCH",
>> "FIRST", "FLOAT", "FOR", "FOREIGN", "FOUND",
>> "FROM", "FULL", "FUNCTION", "GET", "GETCURRENTCONNECTION",
>> "GLOBAL", "GO", "GOTO", "GRANT", "GROUP", "HAVING",
>> "HOUR", "IDENTITY", "IMMEDIATE", "IN", "INDICATOR", "INITIALLY",
>> "INNER", "INOUT", "INPUT", "INSENSITIVE",
>> "INSERT", "INT", "INTEGER", "INTERSECT", "INTO", "IS", "ISOLATION",
>> "JOIN", "KEY", "LAST", "LEFT", "LIKE",
>> "LOWER", "LTRIM", "MATCH", "MAX", "MIN", "MINUTE", "NATIONAL",
>> "NATURAL", "NCHAR", "NVARCHAR", "NEXT", "NO",
>> "NOT", "NULL", "NULLIF", "NUMERIC", "OF", "ON", "ONLY", "OPEN",
>> "OPTION", "OR", "ORDER", "OUTER", "OUTPUT",
>> "OVERLAPS", "PAD", "PARTIAL", "PREPARE", "PRESERVE", "PRIMARY",
>> "PRIOR", "PRIVILEGES", "PROCEDURE", "PUBLIC",
>> "READ", "REAL", "REFERENCES", "RELATIVE", "RESTRICT", "REVOKE",
>> "RIGHT", "ROLLBACK", "ROWS", "RTRIM", "SCHEMA",
>> "SCROLL", "SECOND", "SELECT", "SESSION_USER", "SET", "SMALLINT",
>> "SOME", "SPACE", "SQL", "SQLCODE", "SQLERROR",
>> "SQLSTATE", "SUBSTR", "SUBSTRING", "SUM", "SYSTEM_USER", "TABLE",
>> "TEMPORARY", "TIMEZONE_HOUR",
>> "TIMEZONE_MINUTE", "TO", "TRANSACTION", "TRANSLATE", "TRANSLATION",
>> "TRIM", "TRUE", "UNION", "UNIQUE", "UNKNOWN",
>> "UPDATE", "UPPER", "USER", "USING", "VALUES", "VARCHAR", "VARYING",
>> "VIEW", "WHENEVER", "WHERE", "WITH", "WORK",
>> "WRITE", "XML", "XMLEXISTS", "XMLPARSE", "XMLQUERY",
>> "XMLSERIALIZE", "YEAR" };
>>
>> *public *DerbyAdapter()
>> {
>> *super*("derby", "10.2.2.0");
>> }
>>
>> *public *Driver getJDBCDriver()
>> {
>> *return new *EmbeddedDriver();
>> }
>>
>> @Override
>> *protected *String getTypeName(DBField field)
>> {
>> DBType type = field.getType();
>> *switch *(type)
>> {
>> *case *BOOLEAN:
>> *case *BIT:
>> *return *"SMALLINT";
>> }
>>
>> *return super*.getTypeName(field);
>> }
>>
>> @Override
>> *public **void *appendValue(StringBuilder builder, IDBField field,
>> Object value)
>> {
>> *if *(value *instanceof *Boolean)
>> {
>> value = (Boolean)value ? 1 : 0;
>> }
>>
>> *super*.appendValue(builder, field, value);
>> }
>>
>> @Override
>> *protected **boolean *isReservedWord(String word)
>> {
>> *return *Arrays.binarySearch(RESERVED_WORDS, word.toUpperCase()) >=
>> 0;
>> }
>> }|
>>
>>
>> The performance of CDO is highly optimized especially between the client
>> and the repository (above the store implementation). The DBStore (the
>> facility that is responsible for server side O/R mapping) seems fast to
>> me, but I have no evidence for it since we haven't started to implement a
>> comparable IStore on the base of server side Hibernate. I suggest that
>> you try the DBStore and report your experiences here ;-)
>>
>> If you have more questions, please don't hesitate to ask them here.
>>
>> Regards,
>> Eike Stepper
>> ----
>> http://wiki.eclipse.org/CDO
>> http://wiki.eclipse.org/Net4j
>>
>>
>>
>> Thomas schrieb:
>>> HI I learned about teneo and cdo only the last couple of days. I like
>>> soemthink about cdo, but I wonder if its hwat I actually want. I have a
>>> typical three tiered architecture. currently i have JPA entities
>>> persited with hibernate in my domain model. what I like is that CDO
>>> promises to handle the lazy loading of the model to the client (which I
>>> currently cant with hibernate) for a single business object i always
>>> have to load the whole object graph and transfer it to the client. But I
>>> come from relational database background. so I wonder if i have an emf
>>> model for everything, how can i query it (for e.g. give me all persons
>>> with name like '%Thomas%' ? how is the cdo persistence layer ? I want to
>>> be db independant (at least postgres, sql server, oracle). I have tons
>>> of data, what about performance issues ? with hibernate i can tune many
>>> things on the db. would be glad if you can teach me something about cdo
>>> :)
>>>
>>> Regards Thomas
Re: [CDO] is it what I want ? [message #109099 is a reply to message #109073] Tue, 29 January 2008 14:40 Go to previous messageGo to next message
Eclipse UserFriend
Originally posted by: tom.eiswind.de

HI Simon,

will you share your JPA implementation or is it closed source ?
Would be great if I could have a look into it.

Regards Thomas

Simon McDuff schrieb:
> Hi Thomas,
>
> I would like to share our experience with CDO and Query.
>
> To use a more standard API, we develop a basic (not complete yet) JPA
> implementation using CDO.
> For the query, (this is the part I want to mention you) we use OCL as our
> language.
>
> From EntityManager we use createNativeQuery() method to pass the string from
> the client to the server.
>
> On the server we delegate the call to the IStoreQuery
>
> Now, to be able to execute it the database provider could have 2 choices :
>
> - Convert the OCL language to an SQL
> - Use extension point in OCL to interact with your database.
>
> It returns a list of ID.. so you no dot load all tha data.
>
> So far we used solutions number 2.
>
> I hope this can help you.
>
Re: [CDO] is it what I want ? [message #109138 is a reply to message #109047] Tue, 29 January 2008 15:23 Go to previous messageGo to next message
Eclipse UserFriend
Originally posted by: stepper.sympedia.de

Hi Thomas,

A CDOSession has a setReferenceChunkSize() method which you can call to
limit the number of objects (ids) to load on collection read accesses.
Since read access (loading) is handled by the CDOSession all CDOViews on
that session share this setting. We are currently discussing to provide
an additional session property: InitialReferenceChunkSize. Then you
could even configure to load nothing on the first access (of the source
object) and max n targets on subsequent reference accesses. At the
moment I'd suggest to set a value of 10-100 so that you're shielded
against huge collections.

Regards,
Eike Stepper
----
http://wiki.eclipse.org/CDO
http://wiki.eclipse.org/Net4j



Thomas schrieb:
> Once again..
> Another thing coming to my mind is about the object graph. Suggest I
> have a Object Person with a Collection of Adresses. when I query for
> the person did I get it right that the Adresse are only loaded when I
> try to access them ? That would be the main decision factor for me. I
> have expensive objects and the more the could be lazy loaded the
> better my ui handling would be.
>
> Regards Thomas
Re: [CDO] is it what I want ? [message #109167 is a reply to message #109034] Tue, 29 January 2008 15:54 Go to previous messageGo to next message
Eclipse UserFriend
Originally posted by: stepper.sympedia.de

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

Thomas schrieb:
> Hello Eike,
>
> thanks for your reply. Im just evaluating. So Ill open a request as
> soon as I decide to dive deeper into it. If I understand you right the
> query will be executed on the server and has to be pure sql. For that
> I would have to learn about the mapping strategy (am used to hibernate
> though). How would such an sql query have to look like ?
As you suspected this depends on the mapping strategy and its
configuration. Here some explanation about the default horizontal
mapping strategy of CDO:
1) Each concrete class of the model is mapped to one non-shared table.
There is potentially some name mangling applied which is DB adapter
specific. If you pay a bit attention when modeling class names and table
names should be identical.
2) Each table of 1) contains the following "system" columns:
| /**
* Field names of attribute tables
*/
*public static final *String ATTRIBUTES_ID = "cdo_id";

*public static final *String ATTRIBUTES_VERSION = "cdo_version";

*public static final *String ATTRIBUTES_CLASS = "cdo_class";

*public static final *String ATTRIBUTES_CREATED = "cdo_created";

*public static final *String ATTRIBUTES_REVISED = "cdo_revised";

*public static final *String ATTRIBUTES_RESOURCE = "cdo_resource";

*public static final *String ATTRIBUTES_CONTAINER = "cdo_container";

*public static final *String ATTRIBUTES_FEATURE = "cdo_feature";|


3) Each row in such tables is identified by cdo_id and cdo_version
columns (PK).
cdo_class is a foreign key into the table cdo_classes (mapped meta
model),
cdo_created and cdo_revised are timestamps,
cdo_resource is the CDOID of the containing Resource object
(cdo_resource table),
cdo_container is the CDOID of the containing EObject (same or
another model table),
cdo_feature is a foreign key into the table cdo_features (mapped
meta model).

4) The attributes and single references of the mapped class form the
additional columns.
5) Each *many* reference of a class is mapped to a separate table (per
default) with name := cdoClass.getName() + "_" + cdoFeature.getName() +
"_refs". These "collection tables" can also be shared on class, package
or repository level, names will change then, see
org.eclipse.emf.cdo.server.internal.db.ReferenceMapping.mapR eference(CDOClass,
CDOFeature).
6) A reference table has the following format:
| /**
* Field names of reference tables
*/
*public static final *String REFERENCES_FEATURE = "cdo_feature";

*public static final *String REFERENCES_SOURCE = "cdo_source";

*public static final *String REFERENCES_VERSION = "cdo_version";

*public static final *String REFERENCES_IDX = "cdo_idx";

*public static final *String REFERENCES_TARGET = "cdo_target";|

cdo_feature is only present if the table is shared by several
references.
cdo_source is the CDOID of the source object.
cdo_source is the version of the source object.
cdo_target is the CDOID of the target object.
cdo_idx is the ordinal position of the target object with the
reference list.

I know this is only rough information but I hope it helps to gain a picture.

> I understand that I would have to implement the queries on the client
> side then, but that should be no problem.
If by "implementing" you mean writing a java string literal, yes.

> Another question I have is about mapping. Suggest I have an EMF model
> (playing around with it right now) how is it mapped qo the db ? are
> there annotations for eg varchar length, nullability etc ?
Not so far. If you have a clear picture of what you'd like to configure
and how you'd like to do that (annotations?) I'm open for enhancement
requests.

Regards,
Eike Stepper
----
http://wiki.eclipse.org/CDO
http://wiki.eclipse.org/Net4j


> I have to look into emf validation as for now I have hibernate
> validators bound into the databinding framework that do client side
> validation. many questions :)
>
> Regards Thomas
>
> Eike Stepper schrieb:
>> Hi Thomas,
>>
>> With CDO you need a CDOView to access model objects. CDOView in the
>> current 0.8 stream doesn't have API to query the repository. The
>> former stream had it, but since 0.8 is a complete rewrite this is one
>> of the few outstanding features to be rewritten. If you open an
>> enhancement request I can add a method like the following:
>> | /**
>> * Sends a query to the repository and returns a list of the
>> matching objects or an empty list if no object matched
>> * the query. The query must be in a language that is supported by
>> the store of the repository. For example, if the
>> * repository of this view's session has a DBStore configured, the
>> query must be a valid SQL select statement.
>> */
>> *public *EList<CDOObject> query(String query);|
>>
>>
>> CDO is basically DB independent. In fact it is even not bound to work
>> with JDBC databases. An IRepository works with an IStore which I have
>> implemented as DBStore (JDBC connection plus O/R mapping). There's
>> also a MEMStore and another user has developed an OODBStore
>> (non-public so far). The DBStore itself is independent of different
>> DB vendors (driver and dialect). CDO ships with DB adapters for
>> Derby, Hsqldb and Mysql. It is very easy to develop other DB
>> adapters. An example is the DerbyAdapter:
>> |/********************************************************** *****************
>>
>> * Copyright (c) 2004 - 2008 Eike Stepper, Germany.
>> * All rights reserved. This program and the accompanying materials
>> * are made available under the terms of the Eclipse Public License v1.0
>> * which accompanies this distribution, and is available at
>> * http://www.eclipse.org/legal/epl-v10.html
>> * * Contributors:
>> * Eike Stepper - initial API and implementation
>> ************************************************************ **************/
>>
>> *package *org.eclipse.net4j.db.internal.derby;
>>
>> *import *org.eclipse.net4j.db.DBType;
>> *import *org.eclipse.net4j.db.ddl.IDBField;
>> *import *org.eclipse.net4j.internal.db.DBAdapter;
>> *import *org.eclipse.net4j.internal.db.ddl.DBField;
>>
>> *import *org.apache.derby.jdbc.EmbeddedDriver;
>>
>> *import *java.sql.Driver;
>> *import *java.util.Arrays;
>>
>> /**
>> * @author Eike Stepper
>> */
>> *public class *DerbyAdapter *extends *DBAdapter
>> {
>> *private static final *String[] RESERVED_WORDS = { "ADD", "ALL",
>> "ALLOCATE", "ALTER", "AND", "ANY", "ARE", "AS", "ASC",
>> "ASSERTION", "AT", "AUTHORIZATION", "AVG", "BEGIN", "BETWEEN",
>> "BIGINT", "BIT", "BOOLEAN", "BOTH", "BY", "CALL",
>> "CASCADE", "CASCADED", "CASE", "CAST", "CHAR", "CHARACTER",
>> "CHECK", "CLOSE", "COALESCE", "COLLATE", "COLLATION",
>> "COLUMN", "COMMIT", "CONNECT", "CONNECTION", "CONSTRAINT",
>> "CONSTRAINTS", "CONTINUE", "CONVERT", "CORRESPONDING",
>> "CREATE", "CURRENT", "CURRENT_DATE", "CURRENT_TIME",
>> "CURRENT_TIMESTAMP", "CURRENT_USER", "CURSOR", "DEALLOCATE",
>> "DEC", "DECIMAL", "DECLARE", "DEFAULT", "DEFERRABLE",
>> "DEFERRED", "DELETE", "DESC", "DESCRIBE", "DIAGNOSTICS",
>> "DISCONNECT", "DISTINCT", "DOUBLE", "DROP", "ELSE", "END",
>> "END-EXEC", "ESCAPE", "EXCEPT", "EXCEPTION", "EXEC",
>> "EXECUTE", "EXISTS", "EXPLAIN", "EXTERNAL", "FALSE", "FETCH",
>> "FIRST", "FLOAT", "FOR", "FOREIGN", "FOUND",
>> "FROM", "FULL", "FUNCTION", "GET", "GETCURRENTCONNECTION",
>> "GLOBAL", "GO", "GOTO", "GRANT", "GROUP", "HAVING",
>> "HOUR", "IDENTITY", "IMMEDIATE", "IN", "INDICATOR",
>> "INITIALLY", "INNER", "INOUT", "INPUT", "INSENSITIVE",
>> "INSERT", "INT", "INTEGER", "INTERSECT", "INTO", "IS",
>> "ISOLATION", "JOIN", "KEY", "LAST", "LEFT", "LIKE",
>> "LOWER", "LTRIM", "MATCH", "MAX", "MIN", "MINUTE", "NATIONAL",
>> "NATURAL", "NCHAR", "NVARCHAR", "NEXT", "NO",
>> "NOT", "NULL", "NULLIF", "NUMERIC", "OF", "ON", "ONLY", "OPEN",
>> "OPTION", "OR", "ORDER", "OUTER", "OUTPUT",
>> "OVERLAPS", "PAD", "PARTIAL", "PREPARE", "PRESERVE", "PRIMARY",
>> "PRIOR", "PRIVILEGES", "PROCEDURE", "PUBLIC",
>> "READ", "REAL", "REFERENCES", "RELATIVE", "RESTRICT", "REVOKE",
>> "RIGHT", "ROLLBACK", "ROWS", "RTRIM", "SCHEMA",
>> "SCROLL", "SECOND", "SELECT", "SESSION_USER", "SET",
>> "SMALLINT", "SOME", "SPACE", "SQL", "SQLCODE", "SQLERROR",
>> "SQLSTATE", "SUBSTR", "SUBSTRING", "SUM", "SYSTEM_USER",
>> "TABLE", "TEMPORARY", "TIMEZONE_HOUR",
>> "TIMEZONE_MINUTE", "TO", "TRANSACTION", "TRANSLATE",
>> "TRANSLATION", "TRIM", "TRUE", "UNION", "UNIQUE", "UNKNOWN",
>> "UPDATE", "UPPER", "USER", "USING", "VALUES", "VARCHAR",
>> "VARYING", "VIEW", "WHENEVER", "WHERE", "WITH", "WORK",
>> "WRITE", "XML", "XMLEXISTS", "XMLPARSE", "XMLQUERY",
>> "XMLSERIALIZE", "YEAR" };
>>
>> *public *DerbyAdapter()
>> {
>> *super*("derby", "10.2.2.0");
>> }
>>
>> *public *Driver getJDBCDriver()
>> {
>> *return new *EmbeddedDriver();
>> }
>>
>> @Override
>> *protected *String getTypeName(DBField field)
>> {
>> DBType type = field.getType();
>> *switch *(type)
>> {
>> *case *BOOLEAN:
>> *case *BIT:
>> *return *"SMALLINT";
>> }
>>
>> *return super*.getTypeName(field);
>> }
>>
>> @Override
>> *public **void *appendValue(StringBuilder builder, IDBField field,
>> Object value)
>> {
>> *if *(value *instanceof *Boolean)
>> {
>> value = (Boolean)value ? 1 : 0;
>> }
>>
>> *super*.appendValue(builder, field, value);
>> }
>>
>> @Override
>> *protected **boolean *isReservedWord(String word)
>> {
>> *return *Arrays.binarySearch(RESERVED_WORDS, word.toUpperCase())
>> >= 0;
>> }
>> }|
>>
>>
>> The performance of CDO is highly optimized especially between the
>> client and the repository (above the store implementation). The
>> DBStore (the facility that is responsible for server side O/R
>> mapping) seems fast to me, but I have no evidence for it since we
>> haven't started to implement a comparable IStore on the base of
>> server side Hibernate. I suggest that you try the DBStore and report
>> your experiences here ;-)
>>
>> If you have more questions, please don't hesitate to ask them here.
>>
>> Regards,
>> Eike Stepper
>> ----
>> http://wiki.eclipse.org/CDO
>> http://wiki.eclipse.org/Net4j
>>
>>
>>
>> Thomas schrieb:
>>> HI I learned about teneo and cdo only the last couple of days. I
>>> like soemthink about cdo, but I wonder if its hwat I actually want.
>>> I have a typical three tiered architecture. currently i have JPA
>>> entities persited with hibernate in my domain model. what I like is
>>> that CDO promises to handle the lazy loading of the model to the
>>> client (which I currently cant with hibernate) for a single business
>>> object i always have to load the whole object graph and transfer it
>>> to the client. But I come from relational database background. so I
>>> wonder if i have an emf model for everything, how can i query it
>>> (for e.g. give me all persons with name like '%Thomas%' ? how is the
>>> cdo persistence layer ? I want to be db independant (at least
>>> postgres, sql server, oracle). I have tons of data, what about
>>> performance issues ? with hibernate i can tune many things on the
>>> db. would be glad if you can teach me something about cdo :)
>>>
>>> Regards Thomas

--------------020908040203020601060508
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">
Thomas schrieb:
<blockquote cite="mid:fnncgj$ktv$1@build.eclipse.org" type="cite">Hello
Eike,
<br>
<br>
thanks for your reply. Im just evaluating. So Ill open a request as
soon as I decide to dive deeper into it. If I understand you right the
query will be executed on the server and has to be pure sql. For that I
would have to learn about the mapping strategy (am used to hibernate
though). How would such an sql query have to look like ? </blockquote>
As you suspected this depends on the mapping strategy and its
configuration. Here some explanation about the default horizontal
mapping strategy of CDO:<br>
1) Each concrete class of the model is mapped to one non-shared table.
There is potentially some name mangling applied which is DB adapter
specific. If you pay a bit attention when modeling class names and
table names should be identical.<br>
2) Each table of 1) contains the following "system" columns:<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] is it what I want ? [message #109181 is a reply to message #109099] Tue, 29 January 2008 15:55 Go to previous messageGo to next message
Simon Mc Duff is currently offline Simon Mc DuffFriend
Messages: 596
Registered: July 2009
Senior Member
It is not a closed source !! :-)

You will not be able to query ... since your Store need to provide how you
will handle the ocl expression (or something else). We did it only for our
OODB database

This is the only feature we've been implemented yet :

refresh (You can refresh your resource, an object or a list of objects)
begin
commit
getReference
rollback

XATransaction isn't supported yet :-(

Let me know if this still interest you.

If this is the case, I will maybe work on an implemtation to query other
Store...So the query mechanism will work for you as well.

Simon




"Thomas" <tom@eiswind.de> wrote in message
news:fnndtr$tpr$1@build.eclipse.org...
> HI Simon,
>
> will you share your JPA implementation or is it closed source ?
> Would be great if I could have a look into it.
>
> Regards Thomas
>
> Simon McDuff schrieb:
>> Hi Thomas,
>>
>> I would like to share our experience with CDO and Query.
>>
>> To use a more standard API, we develop a basic (not complete yet) JPA
>> implementation using CDO.
>> For the query, (this is the part I want to mention you) we use OCL as our
>> language.
>>
>> From EntityManager we use createNativeQuery() method to pass the string
>> from the client to the server.
>>
>> On the server we delegate the call to the IStoreQuery
>>
>> Now, to be able to execute it the database provider could have 2 choices
>> :
>>
>> - Convert the OCL language to an SQL
>> - Use extension point in OCL to interact with your database.
>>
>> It returns a list of ID.. so you no dot load all tha data.
>>
>> So far we used solutions number 2.
>>
>> I hope this can help you.
>>
>
Re: [CDO] is it what I want ? [message #109193 is a reply to message #109181] Tue, 29 January 2008 16:02 Go to previous messageGo to next message
Eclipse UserFriend
Originally posted by: stepper.sympedia.de

Simon,

After all the work with CDO it is a real pleasure to see you
contributing and together we've also managed to apply a lot of
enhancements. Thanks a lot!!!

Cheers
/Eike



Simon McDuff schrieb:
> It is not a closed source !! :-)
>
> You will not be able to query ... since your Store need to provide how you
> will handle the ocl expression (or something else). We did it only for our
> OODB database
>
> This is the only feature we've been implemented yet :
>
> refresh (You can refresh your resource, an object or a list of objects)
> begin
> commit
> getReference
> rollback
>
> XATransaction isn't supported yet :-(
>
> Let me know if this still interest you.
>
> If this is the case, I will maybe work on an implemtation to query other
> Store...So the query mechanism will work for you as well.
>
> Simon
>
>
>
>
> "Thomas" <tom@eiswind.de> wrote in message
> news:fnndtr$tpr$1@build.eclipse.org...
>
>> HI Simon,
>>
>> will you share your JPA implementation or is it closed source ?
>> Would be great if I could have a look into it.
>>
>> Regards Thomas
>>
>> Simon McDuff schrieb:
>>
>>> Hi Thomas,
>>>
>>> I would like to share our experience with CDO and Query.
>>>
>>> To use a more standard API, we develop a basic (not complete yet) JPA
>>> implementation using CDO.
>>> For the query, (this is the part I want to mention you) we use OCL as our
>>> language.
>>>
>>> From EntityManager we use createNativeQuery() method to pass the string
>>> from the client to the server.
>>>
>>> On the server we delegate the call to the IStoreQuery
>>>
>>> Now, to be able to execute it the database provider could have 2 choices
>>> :
>>>
>>> - Convert the OCL language to an SQL
>>> - Use extension point in OCL to interact with your database.
>>>
>>> It returns a list of ID.. so you no dot load all tha data.
>>>
>>> So far we used solutions number 2.
>>>
>>> I hope this can help you.
>>>
>>>
>
>
>
Re: [CDO] is it what I want ? [message #109206 is a reply to message #109181] Tue, 29 January 2008 16:51 Go to previous messageGo to next message
Eclipse UserFriend
Originally posted by: tom.eiswind.de

Hi Simon,

Im just getting started, but I will love to have a look at it.

Can I get access anywhere ?

Thomas

Simon McDuff schrieb:
> It is not a closed source !! :-)
>
> You will not be able to query ... since your Store need to provide how you
> will handle the ocl expression (or something else). We did it only for our
> OODB database
>
> This is the only feature we've been implemented yet :
>
> refresh (You can refresh your resource, an object or a list of objects)
> begin
> commit
> getReference
> rollback
>
> XATransaction isn't supported yet :-(
>
> Let me know if this still interest you.
>
> If this is the case, I will maybe work on an implemtation to query other
> Store...So the query mechanism will work for you as well.
>
> Simon
Re: [CDO] is it what I want ? [message #109216 is a reply to message #109138] Tue, 29 January 2008 17:09 Go to previous messageGo to next message
Eclipse UserFriend
Originally posted by: tom.eiswind.de

HI Eike, this seems to be what I would need.
I overlooked your mapping hints (will have to see this in an example
maybe tommorrow.) what I dislike is the relation tables. as i do
reporting with birt i will have to query the database with sql and th
relation tables make manual joining a pain. I know some dtabase gurus
recommend join tables but I still prefer a single foreign key in the
target table. ok you need a single column then for each relation (give
it a speaking name and everthing is clear) why is the version part of
the primary key ? that doesnt make sense to me. maybe you have reasons
but i would expect that the db has only a single version stored. and
again here pain in joining. what kinds of relations are supported ?

What about Lobs ? is there support for large objects ?

We would at least need to supply not null constraints on fields and
ManyToOne relations, field lengthes for character strings, plus I have
to dive into the validation problem. plus i need something for unique
key constraints and indexes.

Thomas

Eike Stepper schrieb:
> Hi Thomas,
>
> A CDOSession has a setReferenceChunkSize() method which you can call to
> limit the number of objects (ids) to load on collection read accesses.
> Since read access (loading) is handled by the CDOSession all CDOViews on
> that session share this setting. We are currently discussing to provide
> an additional session property: InitialReferenceChunkSize. Then you
> could even configure to load nothing on the first access (of the source
> object) and max n targets on subsequent reference accesses. At the
> moment I'd suggest to set a value of 10-100 so that you're shielded
> against huge collections.
>
> Regards,
> Eike Stepper
> ----
> http://wiki.eclipse.org/CDO
> http://wiki.eclipse.org/Net4j
>
>
>
> Thomas schrieb:
>> Once again..
>> Another thing coming to my mind is about the object graph. Suggest I
>> have a Object Person with a Collection of Adresses. when I query for
>> the person did I get it right that the Adresse are only loaded when I
>> try to access them ? That would be the main decision factor for me. I
>> have expensive objects and the more the could be lazy loaded the
>> better my ui handling would be.
>>
>> Regards Thomas
Re: [CDO] is it what I want ? [message #109524 is a reply to message #109216] Wed, 30 January 2008 10:19 Go to previous messageGo to next message
Eclipse UserFriend
Originally posted by: stepper.sympedia.de

Thomas schrieb:
> HI Eike, this seems to be what I would need.
> I overlooked your mapping hints (will have to see this in an example
> maybe tommorrow.) what I dislike is the relation tables. as i do
> reporting with birt i will have to query the database with sql and th
> relation tables make manual joining a pain. I know some dtabase gurus
> recommend join tables but I still prefer a single foreign key in the
> target table. ok you need a single column then for each relation (give
> it a speaking name and everthing is clear)
What I don't like with the foreign key joins you mention is the following:
Assume you are a big IT company and you have many application with one
development team being responsible for one application. The applications
have non-circular dependencies on each other and this is clearly
reflected within the models that form the applications. As long as
you're modeling there's at no time the need to modify foreign code (the
models you depend on). Consider the following example:
Team1, January 2008, develops a model Employees. There is an EClass
Employee.
Team2, March 2008, develops the model Supervisors. There is an EClass
Supervisor with a many-reference supervisedEmployees:List<Emplyoee>.

In the OO world there's no need for Team2 to touch code of Team1.
If the many-reference supervisedEmployees is mapped to a dedicated join
table there's also no responsibility conflict in the DB team of your
company.
But when it comes to O/R mapping of supervisedEmployees with foreign
keys in the table of Employee there is no longer a clear responsibility
for that class!
The same is true for m:n references across model boundaries.

> why is the version part of the primary key ? that doesnt make sense to
> me. maybe you have reasons but i would expect that the db has only a
> single version stored. and again here pain in joining.
CDO is basically capable of auditing (retrieving historical states of
the overall model). I guess it's a similar effect like the one the new
Temporality project announces. An Istore decides if it supports auditing
mode and if it supports non-auditing mode. The DBStore currently does
only support auditing mode! I'm currently a bit unsure what to
prioritize: Make DBStore support non-auditing mode or help Martin
develop a HibernateStore for CDO. I guess you'll vote for the latter ;-)
I'd agree.

> what kinds of relations are supported ?
Single-valued references are mapped to CDOID columns in the table of the
referencing EClass.
Multi-valued references are mapped to the join tables I mentioned before.
Was this what you asked for?

>
> What about Lobs ? is there support for large objects ?
In which context? For mapping multi-valued references? This is planned
via org.eclipse.emf.cdo.server.internal.db.ToMany.LIKE_ATTRIBUTE S. I'd
make querying even harder.

>
> We would at least need to supply not null constraints
That could make a good Bugzilla (A) ;-)

> on fields and ManyToOne relations,
See my above concerns. A separate Bugzilla (B) could be good to discuss
these concerns.

> field lengthes for character strings,
Fits well into the Bugzilla (A).

> plus I have to dive into the validation problem. plus i need something
> for unique key constraints and indexes.
What is the validation problem? The one Simon solved via OCL?
Unique key constraints and indexes could go into (A) as well.

One general comment to all this mapping stuff: As you correctly analyzed
in another thread, CDO is not mainly about providing a new O/R mapping
solution. Hibernate will probably always be better here and I didn't
plan to compete with it. CDO is more focused on providing a stable and
efficient 3-tier solution (client / repository / store) with distributed
shared model semantics (remote update notifications) and an auditing
mode. The store even doesn't need to be a relational database.

I think it's time for me to dig into the Hibernate code and work with
Martin to develop a HibernateStore for the CDO storage framework.

Regards,
Eike Stepper
----
http://wiki.eclipse.org/CDO
http://wiki.eclipse.org/Net4j


>
> Thomas
>
> Eike Stepper schrieb:
>> Hi Thomas,
>>
>> A CDOSession has a setReferenceChunkSize() method which you can call
>> to limit the number of objects (ids) to load on collection read
>> accesses. Since read access (loading) is handled by the CDOSession
>> all CDOViews on that session share this setting. We are currently
>> discussing to provide an additional session property:
>> InitialReferenceChunkSize. Then you could even configure to load
>> nothing on the first access (of the source object) and max n targets
>> on subsequent reference accesses. At the moment I'd suggest to set a
>> value of 10-100 so that you're shielded against huge collections.
>>
>> Regards,
>> Eike Stepper
>> ----
>> http://wiki.eclipse.org/CDO
>> http://wiki.eclipse.org/Net4j
>>
>>
>>
>> Thomas schrieb:
>>> Once again..
>>> Another thing coming to my mind is about the object graph. Suggest I
>>> have a Object Person with a Collection of Adresses. when I query for
>>> the person did I get it right that the Adresse are only loaded when
>>> I try to access them ? That would be the main decision factor for
>>> me. I have expensive objects and the more the could be lazy loaded
>>> the better my ui handling would be.
>>>
>>> Regards Thomas
Re: [CDO] is it what I want ? [message #109576 is a reply to message #109524] Wed, 30 January 2008 10:59 Go to previous messageGo to next message
Eclipse UserFriend
Originally posted by: tom.eiswind.de

Consider the following example:
> Team1, January 2008, develops a model Employees. There is an EClass
> Employee.
> Team2, March 2008, develops the model Supervisors. There is an EClass
> Supervisor with a many-reference supervisedEmployees:List<Emplyoee>.
>
> In the OO world there's no need for Team2 to touch code of Team1.
> If the many-reference supervisedEmployees is mapped to a dedicated join
> table there's also no responsibility conflict in the DB team of your
> company.
> But when it comes to O/R mapping of supervisedEmployees with foreign
> keys in the table of Employee there is no longer a clear responsibility
> for that class!
> The same is true for m:n references across model boundaries.

OK I see your argument. I just want to be pragmatic all the time when it
comes to use native sql queries. :)

>
>> why is the version part of the primary key ? that doesnt make sense to
>> me. maybe you have reasons but i would expect that the db has only a
>> single version stored. and again here pain in joining.
> CDO is basically capable of auditing (retrieving historical states of
> the overall model). I guess it's a similar effect like the one the new
> Temporality project announces.

Ok then you have mutliple versions. But I would (personal taste ?)
prefer a single column surrogate primary key in any case. There are some
techniques on versioning (take three add columns columns, a group id
that groups the versions a counter/timestamp and a boolean, set the
boolean true for the current version, put a unique constraint on
group_id and version) timestamp makes problems on oracle as it not
finegrained enough for have load, so i prefer a counter or a mix of both
of it. its just the idea of having a clean surrogate key that i always
prefer.



>> what kinds of relations are supported ?
> Single-valued references are mapped to CDOID columns in the table of the
> referencing EClass.
> Multi-valued references are mapped to the join tables I mentioned before.
> Was this what you asked for?

yes

>
>>
>> What about Lobs ? is there support for large objects ?
> In which context? For mapping multi-valued references? This is planned
> via org.eclipse.emf.cdo.server.internal.db.ToMany.LIKE_ATTRIBUTE S. I'd
> make querying even harder.

I mean very long Strings or ByteArrays. Hibernate does that with @Lob

>> We would at least need to supply not null constraints
> That could make a good Bugzilla (A) ;-)
>
>> on fields and ManyToOne relations,
> See my above concerns. A separate Bugzilla (B) could be good to discuss
> these concerns.
>
>> field lengthes for character strings,
> Fits well into the Bugzilla (A).
>
>> plus I have to dive into the validation problem. plus i need something
>> for unique key constraints and indexes.
> What is the validation problem? The one Simon solved via OCL?
> Unique key constraints and indexes could go into (A) as well.
>
> One general comment to all this mapping stuff: As you correctly analyzed
> in another thread, CDO is not mainly about providing a new O/R mapping
> solution. Hibernate will probably always be better here and I didn't
> plan to compete with it. CDO is more focused on providing a stable and
> efficient 3-tier solution (client / repository / store) with distributed
> shared model semantics (remote update notifications) and an auditing
> mode. The store even doesn't need to be a relational database.
>
> I think it's time for me to dig into the Hibernate code and work with
> Martin to develop a HibernateStore for the CDO storage framework.
>


Hmm Eike, dont know if I should open bugs on this if we dig into teneo.
Why put so much effort in there when we already have (nearly)everything
we need at hand ?

Regarding the task force I think I can try to support you. I just dont
know how much time I can put in there, can be that I have a new project
next week, can be that I have lots of time to spent in february.

What Im not happy with (other thread..) is not your implementation at
all. Things are as they are :) I have to learn about your fetching
strategy and proxiing will try to look into that tonight. It is that
hibernate puts its own proxies in there and we have to find a way to
make it play together.

another point i see is that you put additional columns and tables in the
db, and teneo seems to have its own way to to that. dont know up to now
how much the dbstore api depends on that.

its another point that teneo builds on the hbm mapping files (that goes
to the teneo audience:). if we had pure jpa entities we could have
integration with eclipseLink, openJpa or whatever.


Regards Thomas
Re: [CDO] is it what I want ? [message #109588 is a reply to message #109524] Wed, 30 January 2008 11:01 Go to previous messageGo to next message
Martin Taal is currently offline Martin TaalFriend
Messages: 5468
Registered: July 2009
Senior Member
Hi Eike, Thomas,
I will start looking at the integration between CDO and Teneo today. I first need to get familiar
with cdo and then I can see how Teneo can be integrated. I'll keep you posted.

See my other additions below.

gr. Martin

Eike Stepper wrote:
> Thomas schrieb:
>> HI Eike, this seems to be what I would need.
>> I overlooked your mapping hints (will have to see this in an example
>> maybe tommorrow.) what I dislike is the relation tables. as i do
>> reporting with birt i will have to query the database with sql and th
>> relation tables make manual joining a pain. I know some dtabase gurus
>> recommend join tables but I still prefer a single foreign key in the
>> target table. ok you need a single column then for each relation (give
>> it a speaking name and everthing is clear)
> What I don't like with the foreign key joins you mention is the following:
> Assume you are a big IT company and you have many application with one
> development team being responsible for one application. The applications
> have non-circular dependencies on each other and this is clearly
> reflected within the models that form the applications. As long as
> you're modeling there's at no time the need to modify foreign code (the
> models you depend on). Consider the following example:
> Team1, January 2008, develops a model Employees. There is an EClass
> Employee.
> Team2, March 2008, develops the model Supervisors. There is an EClass
> Supervisor with a many-reference supervisedEmployees:List<Emplyoee>.
>
> In the OO world there's no need for Team2 to touch code of Team1.
> If the many-reference supervisedEmployees is mapped to a dedicated join
> table there's also no responsibility conflict in the DB team of your
> company.
> But when it comes to O/R mapping of supervisedEmployees with foreign
> keys in the table of Employee there is no longer a clear responsibility
> for that class!
> The same is true for m:n references across model boundaries.
MT>> I have a background in developing ERP systems and there it was also common to use a foreign key
field instead of join tables. A number of thoughts from my side regarding this topic:
- as Eike mentions foreign keys are more intruisive than join table as the target table gets changed
(has an extra foreign key field(s))
- Foreign keys are more efficient as there is one less join to do
- Foreign keys do not support duplicate occurences in a list (join tables do, assuming a join table
has a separate id column).
- Specifically for containment relations my feel is that a foreign key field is appropriate as it
reflects the stronger relation between the child and the parent. The same can be said for
bidirectional relations.

Overall I have the same feel as Thomas, with my background I like foreign keys (as they are more
efficient) but I understand that there are many people with other ideas. Teneo has an option to
specify if all non-containment relations should be mapped with a join table (or not).

>
>> why is the version part of the primary key ? that doesnt make sense to
>> me. maybe you have reasons but i would expect that the db has only a
>> single version stored. and again here pain in joining.
> CDO is basically capable of auditing (retrieving historical states of
> the overall model). I guess it's a similar effect like the one the new
> Temporality project announces. An Istore decides if it supports auditing
> mode and if it supports non-auditing mode. The DBStore currently does
> only support auditing mode! I'm currently a bit unsure what to
> prioritize: Make DBStore support non-auditing mode or help Martin
> develop a HibernateStore for CDO. I guess you'll vote for the latter ;-)
> I'd agree.
MT>> I will start looking at CDO today and try out the tutorial, etc. Maybe I can get a long way
without asking to much of your time Eike (so then you can do both :-).
MT>> Btw, imo it is great that CDO also considers topics like auditing, these generic topics can
really be solved at this level.

>
>> what kinds of relations are supported ?
> Single-valued references are mapped to CDOID columns in the table of the
> referencing EClass.
> Multi-valued references are mapped to the join tables I mentioned before.
> Was this what you asked for?
>
>>
>> What about Lobs ? is there support for large objects ?
> In which context? For mapping multi-valued references? This is planned
> via org.eclipse.emf.cdo.server.internal.db.ToMany.LIKE_ATTRIBUTE S. I'd
> make querying even harder.
>
>>
>> We would at least need to supply not null constraints
> That could make a good Bugzilla (A) ;-)
>
>> on fields and ManyToOne relations,
> See my above concerns. A separate Bugzilla (B) could be good to discuss
> these concerns.
>
>> field lengthes for character strings,
> Fits well into the Bugzilla (A).
>
>> plus I have to dive into the validation problem. plus i need something
>> for unique key constraints and indexes.
> What is the validation problem? The one Simon solved via OCL?
> Unique key constraints and indexes could go into (A) as well.
>
> One general comment to all this mapping stuff: As you correctly analyzed
> in another thread, CDO is not mainly about providing a new O/R mapping
> solution. Hibernate will probably always be better here and I didn't
> plan to compete with it. CDO is more focused on providing a stable and
> efficient 3-tier solution (client / repository / store) with distributed
> shared model semantics (remote update notifications) and an auditing
> mode. The store even doesn't need to be a relational database.
>
> I think it's time for me to dig into the Hibernate code and work with
> Martin to develop a HibernateStore for the CDO storage framework.
>
> Regards,
> Eike Stepper
> ----
> http://wiki.eclipse.org/CDO
> http://wiki.eclipse.org/Net4j
>
>
>>
>> Thomas
>>
>> Eike Stepper schrieb:
>>> Hi Thomas,
>>>
>>> A CDOSession has a setReferenceChunkSize() method which you can call
>>> to limit the number of objects (ids) to load on collection read
>>> accesses. Since read access (loading) is handled by the CDOSession
>>> all CDOViews on that session share this setting. We are currently
>>> discussing to provide an additional session property:
>>> InitialReferenceChunkSize. Then you could even configure to load
>>> nothing on the first access (of the source object) and max n targets
>>> on subsequent reference accesses. At the moment I'd suggest to set a
>>> value of 10-100 so that you're shielded against huge collections.
>>>
>>> Regards,
>>> Eike Stepper
>>> ----
>>> http://wiki.eclipse.org/CDO
>>> http://wiki.eclipse.org/Net4j
>>>
>>>
>>>
>>> Thomas schrieb:
>>>> Once again..
>>>> Another thing coming to my mind is about the object graph. Suggest I
>>>> have a Object Person with a Collection of Adresses. when I query for
>>>> the person did I get it right that the Adresse are only loaded when
>>>> I try to access them ? That would be the main decision factor for
>>>> me. I have expensive objects and the more the could be lazy loaded
>>>> the better my ui handling would be.
>>>>
>>>> Regards Thomas


--

With Regards, Martin Taal

Springsite/Elver.org
Office: Hardwareweg 4, 3821 BV Amersfoort
Postal: Nassaulaan 7, 3941 EC Doorn
The Netherlands
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] is it what I want ? [message #109600 is a reply to message #109576] Wed, 30 January 2008 11:14 Go to previous messageGo to next message
Martin Taal is currently offline Martin TaalFriend
Messages: 5468
Registered: July 2009
Senior Member
Hi Thomas,
Just to react on your last point (to the Teneo audience :) about jpa entities. Hidden within Teneo
there is already a possibility to create jpa annotations which can be placed in the source code (see
the PAnnotation class it has a method getJavaAnnotation(...). I use it myself when generating jpa
entities. However, I am not sure yet how to integrate this with the current code generation of EMF.

I wanted to post a question about this in the emf newsgroup (maybe I'll do that today).

Other then that, EMF has specific list implementations (for supporting bi-directional and
containment and notifications), these do not work out of the box with hibernate (or TopLink)
therefore Teneo also has a runtime layer. But depending on the business case ofcourse these list
implementations are important or not.

gr. Martin

Thomas wrote:
> Consider the following example:
>> Team1, January 2008, develops a model Employees. There is an EClass
>> Employee.
>> Team2, March 2008, develops the model Supervisors. There is an EClass
>> Supervisor with a many-reference supervisedEmployees:List<Emplyoee>.
>>
>> In the OO world there's no need for Team2 to touch code of Team1.
>> If the many-reference supervisedEmployees is mapped to a dedicated
>> join table there's also no responsibility conflict in the DB team of
>> your company.
>> But when it comes to O/R mapping of supervisedEmployees with foreign
>> keys in the table of Employee there is no longer a clear
>> responsibility for that class!
>> The same is true for m:n references across model boundaries.
>
> OK I see your argument. I just want to be pragmatic all the time when it
> comes to use native sql queries. :)
>
>>
>>> why is the version part of the primary key ? that doesnt make sense
>>> to me. maybe you have reasons but i would expect that the db has only
>>> a single version stored. and again here pain in joining.
>> CDO is basically capable of auditing (retrieving historical states of
>> the overall model). I guess it's a similar effect like the one the new
>> Temporality project announces.
>
> Ok then you have mutliple versions. But I would (personal taste ?)
> prefer a single column surrogate primary key in any case. There are some
> techniques on versioning (take three add columns columns, a group id
> that groups the versions a counter/timestamp and a boolean, set the
> boolean true for the current version, put a unique constraint on
> group_id and version) timestamp makes problems on oracle as it not
> finegrained enough for have load, so i prefer a counter or a mix of both
> of it. its just the idea of having a clean surrogate key that i always
> prefer.
>
>
>
>>> what kinds of relations are supported ?
>> Single-valued references are mapped to CDOID columns in the table of
>> the referencing EClass.
>> Multi-valued references are mapped to the join tables I mentioned before.
>> Was this what you asked for?
>
> yes
>
>>
>>>
>>> What about Lobs ? is there support for large objects ?
>> In which context? For mapping multi-valued references? This is planned
>> via org.eclipse.emf.cdo.server.internal.db.ToMany.LIKE_ATTRIBUTE S. I'd
>> make querying even harder.
>
> I mean very long Strings or ByteArrays. Hibernate does that with @Lob
>
>>> We would at least need to supply not null constraints
>> That could make a good Bugzilla (A) ;-)
>>
>>> on fields and ManyToOne relations,
>> See my above concerns. A separate Bugzilla (B) could be good to
>> discuss these concerns.
>>
>>> field lengthes for character strings,
>> Fits well into the Bugzilla (A).
>>
>>> plus I have to dive into the validation problem. plus i need
>>> something for unique key constraints and indexes.
>> What is the validation problem? The one Simon solved via OCL?
>> Unique key constraints and indexes could go into (A) as well.
>>
>> One general comment to all this mapping stuff: As you correctly
>> analyzed in another thread, CDO is not mainly about providing a new
>> O/R mapping solution. Hibernate will probably always be better here
>> and I didn't plan to compete with it. CDO is more focused on providing
>> a stable and efficient 3-tier solution (client / repository / store)
>> with distributed shared model semantics (remote update notifications)
>> and an auditing mode. The store even doesn't need to be a relational
>> database.
>>
>> I think it's time for me to dig into the Hibernate code and work with
>> Martin to develop a HibernateStore for the CDO storage framework.
>>
>
>
> Hmm Eike, dont know if I should open bugs on this if we dig into teneo.
> Why put so much effort in there when we already have (nearly)everything
> we need at hand ?
>
> Regarding the task force I think I can try to support you. I just dont
> know how much time I can put in there, can be that I have a new project
> next week, can be that I have lots of time to spent in february.
>
> What Im not happy with (other thread..) is not your implementation at
> all. Things are as they are :) I have to learn about your fetching
> strategy and proxiing will try to look into that tonight. It is that
> hibernate puts its own proxies in there and we have to find a way to
> make it play together.
>
> another point i see is that you put additional columns and tables in the
> db, and teneo seems to have its own way to to that. dont know up to now
> how much the dbstore api depends on that.
>
> its another point that teneo builds on the hbm mapping files (that goes
> to the teneo audience:). if we had pure jpa entities we could have
> integration with eclipseLink, openJpa or whatever.
>
>
> Regards Thomas


--

With Regards, Martin Taal

Springsite/Elver.org
Office: Hardwareweg 4, 3821 BV Amersfoort
Postal: Nassaulaan 7, 3941 EC Doorn
The Netherlands
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] is it what I want ? [message #109613 is a reply to message #109600] Wed, 30 January 2008 11:30 Go to previous messageGo to next message
Eclipse UserFriend
Originally posted by: merks.ca.ibm.com

Martin,

This sounds related a bit to
https://bugs.eclipse.org/bugs/show_bug.cgi?id=176726. I.e., if we had
some kind of GenModel annotation that could be converted to Java 5.0
annotations in the generator so they show up in the generated code. Is
something like that what you'd need? I imagine you already have
annotations though, so some way to being able to influence how they are
converted to Java 5.0 annotations would be nicer...


Martin Taal wrote:
> Hi Thomas,
> Just to react on your last point (to the Teneo audience :) about jpa
> entities. Hidden within Teneo there is already a possibility to create
> jpa annotations which can be placed in the source code (see the
> PAnnotation class it has a method getJavaAnnotation(...). I use it
> myself when generating jpa entities. However, I am not sure yet how to
> integrate this with the current code generation of EMF.
>
> I wanted to post a question about this in the emf newsgroup (maybe
> I'll do that today).
>
> Other then that, EMF has specific list implementations (for supporting
> bi-directional and containment and notifications), these do not work
> out of the box with hibernate (or TopLink) therefore Teneo also has a
> runtime layer. But depending on the business case ofcourse these list
> implementations are important or not.
>
> gr. Martin
>
> Thomas wrote:
>> Consider the following example:
>>> Team1, January 2008, develops a model Employees. There is an EClass
>>> Employee.
>>> Team2, March 2008, develops the model Supervisors. There is an
>>> EClass Supervisor with a many-reference
>>> supervisedEmployees:List<Emplyoee>.
>>>
>>> In the OO world there's no need for Team2 to touch code of Team1.
>>> If the many-reference supervisedEmployees is mapped to a dedicated
>>> join table there's also no responsibility conflict in the DB team of
>>> your company.
>>> But when it comes to O/R mapping of supervisedEmployees with foreign
>>> keys in the table of Employee there is no longer a clear
>>> responsibility for that class!
>>> The same is true for m:n references across model boundaries.
>>
>> OK I see your argument. I just want to be pragmatic all the time when
>> it comes to use native sql queries. :)
>>
>>>
>>>> why is the version part of the primary key ? that doesnt make sense
>>>> to me. maybe you have reasons but i would expect that the db has
>>>> only a single version stored. and again here pain in joining.
>>> CDO is basically capable of auditing (retrieving historical states
>>> of the overall model). I guess it's a similar effect like the one
>>> the new Temporality project announces.
>>
>> Ok then you have mutliple versions. But I would (personal taste ?)
>> prefer a single column surrogate primary key in any case. There are
>> some techniques on versioning (take three add columns columns, a
>> group id that groups the versions a counter/timestamp and a boolean,
>> set the boolean true for the current version, put a unique constraint
>> on group_id and version) timestamp makes problems on oracle as it not
>> finegrained enough for have load, so i prefer a counter or a mix of
>> both of it. its just the idea of having a clean surrogate key that i
>> always prefer.
>>
>>
>>
>>>> what kinds of relations are supported ?
>>> Single-valued references are mapped to CDOID columns in the table of
>>> the referencing EClass.
>>> Multi-valued references are mapped to the join tables I mentioned
>>> before.
>>> Was this what you asked for?
>>
>> yes
>>
>>>
>>>>
>>>> What about Lobs ? is there support for large objects ?
>>> In which context? For mapping multi-valued references? This is
>>> planned via
>>> org.eclipse.emf.cdo.server.internal.db.ToMany.LIKE_ATTRIBUTE S. I'd
>>> make querying even harder.
>>
>> I mean very long Strings or ByteArrays. Hibernate does that with @Lob
>>
>>>> We would at least need to supply not null constraints
>>> That could make a good Bugzilla (A) ;-)
>>>
>>>> on fields and ManyToOne relations,
>>> See my above concerns. A separate Bugzilla (B) could be good to
>>> discuss these concerns.
>>>
>>>> field lengthes for character strings,
>>> Fits well into the Bugzilla (A).
>>>
>>>> plus I have to dive into the validation problem. plus i need
>>>> something for unique key constraints and indexes.
>>> What is the validation problem? The one Simon solved via OCL?
>>> Unique key constraints and indexes could go into (A) as well.
>>>
>>> One general comment to all this mapping stuff: As you correctly
>>> analyzed in another thread, CDO is not mainly about providing a new
>>> O/R mapping solution. Hibernate will probably always be better here
>>> and I didn't plan to compete with it. CDO is more focused on
>>> providing a stable and efficient 3-tier solution (client /
>>> repository / store) with distributed shared model semantics (remote
>>> update notifications) and an auditing mode. The store even doesn't
>>> need to be a relational database.
>>>
>>> I think it's time for me to dig into the Hibernate code and work
>>> with Martin to develop a HibernateStore for the CDO storage framework.
>>>
>>
>>
>> Hmm Eike, dont know if I should open bugs on this if we dig into
>> teneo. Why put so much effort in there when we already have
>> (nearly)everything we need at hand ?
>>
>> Regarding the task force I think I can try to support you. I just
>> dont know how much time I can put in there, can be that I have a new
>> project next week, can be that I have lots of time to spent in february.
>>
>> What Im not happy with (other thread..) is not your implementation at
>> all. Things are as they are :) I have to learn about your fetching
>> strategy and proxiing will try to look into that tonight. It is that
>> hibernate puts its own proxies in there and we have to find a way to
>> make it play together.
>>
>> another point i see is that you put additional columns and tables in
>> the db, and teneo seems to have its own way to to that. dont know up
>> to now how much the dbstore api depends on that.
>>
>> its another point that teneo builds on the hbm mapping files (that
>> goes to the teneo audience:). if we had pure jpa entities we could
>> have integration with eclipseLink, openJpa or whatever.
>>
>>
>> Regards Thomas
>
>
Re: [CDO] is it what I want ? [message #109626 is a reply to message #109600] Wed, 30 January 2008 11:41 Go to previous messageGo to next message
Eclipse UserFriend
Originally posted by: tom.eiswind.de

Hi Martin,

Martin Taal schrieb:
> Hi Thomas,
> Just to react on your last point (to the Teneo audience :) about jpa
> entities. Hidden within Teneo there is already a possibility to create
> jpa annotations which can be placed in the source code (see the
> PAnnotation class it has a method getJavaAnnotation(...). I use it
> myself when generating jpa entities. However, I am not sure yet how to
> integrate this with the current code generation of EMF.
I saw that before. Im just diving into it so forgive me :)
Its just that I believe theres is great power in bringing all this
together that makes me very interested.

I'm a little conscious about this annotation stuff as one doesnt have
any nice compiler checks on the syntax in the model.


>
> I wanted to post a question about this in the emf newsgroup (maybe I'll
> do that today).
>
> Other then that, EMF has specific list implementations (for supporting
> bi-directional and containment and notifications), these do not work out
> of the box with hibernate (or TopLink) therefore Teneo also has a
> runtime layer. But depending on the business case ofcourse these list
> implementations are important or not.

I was too dumb to do my first simple emf model yesterday, so I will
leave that up to you :)
>
> gr. Martin
>
Re: [CDO] is it what I want ? [message #109639 is a reply to message #109613] Wed, 30 January 2008 11:53 Go to previous messageGo to next message
Martin Taal is currently offline Martin TaalFriend
Messages: 5468
Registered: July 2009
Senior Member
Thanks Ed, I posted a question related to this in the EMF newsgroup.

gr. Martin

Ed Merks wrote:
> Martin,
>
> This sounds related a bit to
> https://bugs.eclipse.org/bugs/show_bug.cgi?id=176726. I.e., if we had
> some kind of GenModel annotation that could be converted to Java 5.0
> annotations in the generator so they show up in the generated code. Is
> something like that what you'd need? I imagine you already have
> annotations though, so some way to being able to influence how they are
> converted to Java 5.0 annotations would be nicer...
>
>
> Martin Taal wrote:
>> Hi Thomas,
>> Just to react on your last point (to the Teneo audience :) about jpa
>> entities. Hidden within Teneo there is already a possibility to create
>> jpa annotations which can be placed in the source code (see the
>> PAnnotation class it has a method getJavaAnnotation(...). I use it
>> myself when generating jpa entities. However, I am not sure yet how to
>> integrate this with the current code generation of EMF.
>>
>> I wanted to post a question about this in the emf newsgroup (maybe
>> I'll do that today).
>>
>> Other then that, EMF has specific list implementations (for supporting
>> bi-directional and containment and notifications), these do not work
>> out of the box with hibernate (or TopLink) therefore Teneo also has a
>> runtime layer. But depending on the business case ofcourse these list
>> implementations are important or not.
>>
>> gr. Martin
>>
>> Thomas wrote:
>>> Consider the following example:
>>>> Team1, January 2008, develops a model Employees. There is an EClass
>>>> Employee.
>>>> Team2, March 2008, develops the model Supervisors. There is an
>>>> EClass Supervisor with a many-reference
>>>> supervisedEmployees:List<Emplyoee>.
>>>>
>>>> In the OO world there's no need for Team2 to touch code of Team1.
>>>> If the many-reference supervisedEmployees is mapped to a dedicated
>>>> join table there's also no responsibility conflict in the DB team of
>>>> your company.
>>>> But when it comes to O/R mapping of supervisedEmployees with foreign
>>>> keys in the table of Employee there is no longer a clear
>>>> responsibility for that class!
>>>> The same is true for m:n references across model boundaries.
>>>
>>> OK I see your argument. I just want to be pragmatic all the time when
>>> it comes to use native sql queries. :)
>>>
>>>>
>>>>> why is the version part of the primary key ? that doesnt make sense
>>>>> to me. maybe you have reasons but i would expect that the db has
>>>>> only a single version stored. and again here pain in joining.
>>>> CDO is basically capable of auditing (retrieving historical states
>>>> of the overall model). I guess it's a similar effect like the one
>>>> the new Temporality project announces.
>>>
>>> Ok then you have mutliple versions. But I would (personal taste ?)
>>> prefer a single column surrogate primary key in any case. There are
>>> some techniques on versioning (take three add columns columns, a
>>> group id that groups the versions a counter/timestamp and a boolean,
>>> set the boolean true for the current version, put a unique constraint
>>> on group_id and version) timestamp makes problems on oracle as it not
>>> finegrained enough for have load, so i prefer a counter or a mix of
>>> both of it. its just the idea of having a clean surrogate key that i
>>> always prefer.
>>>
>>>
>>>
>>>>> what kinds of relations are supported ?
>>>> Single-valued references are mapped to CDOID columns in the table of
>>>> the referencing EClass.
>>>> Multi-valued references are mapped to the join tables I mentioned
>>>> before.
>>>> Was this what you asked for?
>>>
>>> yes
>>>
>>>>
>>>>>
>>>>> What about Lobs ? is there support for large objects ?
>>>> In which context? For mapping multi-valued references? This is
>>>> planned via
>>>> org.eclipse.emf.cdo.server.internal.db.ToMany.LIKE_ATTRIBUTE S. I'd
>>>> make querying even harder.
>>>
>>> I mean very long Strings or ByteArrays. Hibernate does that with @Lob
>>>
>>>>> We would at least need to supply not null constraints
>>>> That could make a good Bugzilla (A) ;-)
>>>>
>>>>> on fields and ManyToOne relations,
>>>> See my above concerns. A separate Bugzilla (B) could be good to
>>>> discuss these concerns.
>>>>
>>>>> field lengthes for character strings,
>>>> Fits well into the Bugzilla (A).
>>>>
>>>>> plus I have to dive into the validation problem. plus i need
>>>>> something for unique key constraints and indexes.
>>>> What is the validation problem? The one Simon solved via OCL?
>>>> Unique key constraints and indexes could go into (A) as well.
>>>>
>>>> One general comment to all this mapping stuff: As you correctly
>>>> analyzed in another thread, CDO is not mainly about providing a new
>>>> O/R mapping solution. Hibernate will probably always be better here
>>>> and I didn't plan to compete with it. CDO is more focused on
>>>> providing a stable and efficient 3-tier solution (client /
>>>> repository / store) with distributed shared model semantics (remote
>>>> update notifications) and an auditing mode. The store even doesn't
>>>> need to be a relational database.
>>>>
>>>> I think it's time for me to dig into the Hibernate code and work
>>>> with Martin to develop a HibernateStore for the CDO storage framework.
>>>>
>>>
>>>
>>> Hmm Eike, dont know if I should open bugs on this if we dig into
>>> teneo. Why put so much effort in there when we already have
>>> (nearly)everything we need at hand ?
>>>
>>> Regarding the task force I think I can try to support you. I just
>>> dont know how much time I can put in there, can be that I have a new
>>> project next week, can be that I have lots of time to spent in february.
>>>
>>> What Im not happy with (other thread..) is not your implementation at
>>> all. Things are as they are :) I have to learn about your fetching
>>> strategy and proxiing will try to look into that tonight. It is that
>>> hibernate puts its own proxies in there and we have to find a way to
>>> make it play together.
>>>
>>> another point i see is that you put additional columns and tables in
>>> the db, and teneo seems to have its own way to to that. dont know up
>>> to now how much the dbstore api depends on that.
>>>
>>> its another point that teneo builds on the hbm mapping files (that
>>> goes to the teneo audience:). if we had pure jpa entities we could
>>> have integration with eclipseLink, openJpa or whatever.
>>>
>>>
>>> Regards Thomas
>>
>>


--

With Regards, Martin Taal

Springsite/Elver.org
Office: Hardwareweg 4, 3821 BV Amersfoort
Postal: Nassaulaan 7, 3941 EC Doorn
The Netherlands
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] is it what I want ? [message #109653 is a reply to message #109626] Wed, 30 January 2008 11:56 Go to previous messageGo to next message
Martin Taal is currently offline Martin TaalFriend
Messages: 5468
Registered: July 2009
Senior Member
Hi Thomas,
Yes I also see the lack of compiler support when annotating models. The idea behind Teneo is really
that Teneo generates most annotations automatically and that the user only needs to manually specify
annotations for the parts which are not done correctly in automatic mode. So you only need to
annotate the exceptions.
But this approach ofcourse is mostly valid if there not so much to override (if the automatic
approach is mostly fine). So it all depends...
Also for me it always seemed nicer to annotate models and not the java source code. But I also see
that there is great value in having one location to edit this together with code completion and
syntax checking. Especially if the jpa annotations can first be generated automatically by Teneo and
then manually changed by the user.

gr. Martin

Thomas wrote:
> Hi Martin,
>
> Martin Taal schrieb:
>> Hi Thomas,
>> Just to react on your last point (to the Teneo audience :) about jpa
>> entities. Hidden within Teneo there is already a possibility to create
>> jpa annotations which can be placed in the source code (see the
>> PAnnotation class it has a method getJavaAnnotation(...). I use it
>> myself when generating jpa entities. However, I am not sure yet how to
>> integrate this with the current code generation of EMF.
> I saw that before. Im just diving into it so forgive me :)
> Its just that I believe theres is great power in bringing all this
> together that makes me very interested.
>
> I'm a little conscious about this annotation stuff as one doesnt have
> any nice compiler checks on the syntax in the model.
>
>
>>
>> I wanted to post a question about this in the emf newsgroup (maybe
>> I'll do that today).
>>
>> Other then that, EMF has specific list implementations (for supporting
>> bi-directional and containment and notifications), these do not work
>> out of the box with hibernate (or TopLink) therefore Teneo also has a
>> runtime layer. But depending on the business case ofcourse these list
>> implementations are important or not.
>
> I was too dumb to do my first simple emf model yesterday, so I will
> leave that up to you :)
>>
>> gr. Martin
>>
>


--

With Regards, Martin Taal

Springsite/Elver.org
Office: Hardwareweg 4, 3821 BV Amersfoort
Postal: Nassaulaan 7, 3941 EC Doorn
The Netherlands
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] is it what I want ? [message #109663 is a reply to message #109653] Wed, 30 January 2008 12:20 Go to previous messageGo to next message
Eclipse UserFriend
Originally posted by: tom.eiswind.de

HI Martin,

Yes doing as much by convention as possible is a good idea. But for
example in my current model (CDO may change this) I have always eager
fetching. I use HiberObjects at the moment. I have to put manual
annotations on the fetch strategy on every relation I have. So
convention is good, but even better if one can define what the
convention actually is.

Thomas

Martin Taal schrieb:
> Hi Thomas,
> Yes I also see the lack of compiler support when annotating models. The
> idea behind Teneo is really that Teneo generates most annotations
> automatically and that the user only needs to manually specify
> annotations for the parts which are not done correctly in automatic
> mode. So you only need to annotate the exceptions.
> But this approach ofcourse is mostly valid if there not so much to
> override (if the automatic approach is mostly fine). So it all depends...
> Also for me it always seemed nicer to annotate models and not the java
> source code. But I also see that there is great value in having one
> location to edit this together with code completion and syntax checking.
> Especially if the jpa annotations can first be generated automatically
> by Teneo and then manually changed by the user.
>
> gr. Martin
>
> Thomas wrote:
>> Hi Martin,
>>
>> Martin Taal schrieb:
>>> Hi Thomas,
>>> Just to react on your last point (to the Teneo audience :) about jpa
>>> entities. Hidden within Teneo there is already a possibility to
>>> create jpa annotations which can be placed in the source code (see
>>> the PAnnotation class it has a method getJavaAnnotation(...). I use
>>> it myself when generating jpa entities. However, I am not sure yet
>>> how to integrate this with the current code generation of EMF.
>> I saw that before. Im just diving into it so forgive me :)
>> Its just that I believe theres is great power in bringing all this
>> together that makes me very interested.
>>
>> I'm a little conscious about this annotation stuff as one doesnt have
>> any nice compiler checks on the syntax in the model.
>>
>>
>>>
>>> I wanted to post a question about this in the emf newsgroup (maybe
>>> I'll do that today).
>>>
>>> Other then that, EMF has specific list implementations (for
>>> supporting bi-directional and containment and notifications), these
>>> do not work out of the box with hibernate (or TopLink) therefore
>>> Teneo also has a runtime layer. But depending on the business case
>>> ofcourse these list implementations are important or not.
>>
>> I was too dumb to do my first simple emf model yesterday, so I will
>> leave that up to you :)
>>>
>>> gr. Martin
>>>
>>
>
>
Re: [CDO] is it what I want ? [message #109675 is a reply to message #109588] Wed, 30 January 2008 12:54 Go to previous messageGo to next message
Eclipse UserFriend
Originally posted by: stepper.sympedia.de

Guys,

I just downloaded Hibernate ;-)

Regards,
Eike Stepper
----
http://wiki.eclipse.org/CDO
http://wiki.eclipse.org/Net4j



Martin Taal schrieb:
> Hi Eike, Thomas,
> I will start looking at the integration between CDO and Teneo today. I
> first need to get familiar with cdo and then I can see how Teneo can
> be integrated. I'll keep you posted.
>
> See my other additions below.
>
> gr. Martin
>
> Eike Stepper wrote:
>> Thomas schrieb:
>>> HI Eike, this seems to be what I would need.
>>> I overlooked your mapping hints (will have to see this in an example
>>> maybe tommorrow.) what I dislike is the relation tables. as i do
>>> reporting with birt i will have to query the database with sql and
>>> th relation tables make manual joining a pain. I know some dtabase
>>> gurus recommend join tables but I still prefer a single foreign key
>>> in the target table. ok you need a single column then for each
>>> relation (give it a speaking name and everthing is clear)
>> What I don't like with the foreign key joins you mention is the
>> following:
>> Assume you are a big IT company and you have many application with
>> one development team being responsible for one application. The
>> applications have non-circular dependencies on each other and this is
>> clearly reflected within the models that form the applications. As
>> long as you're modeling there's at no time the need to modify foreign
>> code (the models you depend on). Consider the following example:
>> Team1, January 2008, develops a model Employees. There is an EClass
>> Employee.
>> Team2, March 2008, develops the model Supervisors. There is an EClass
>> Supervisor with a many-reference supervisedEmployees:List<Emplyoee>.
>>
>> In the OO world there's no need for Team2 to touch code of Team1.
>> If the many-reference supervisedEmployees is mapped to a dedicated
>> join table there's also no responsibility conflict in the DB team of
>> your company.
>> But when it comes to O/R mapping of supervisedEmployees with foreign
>> keys in the table of Employee there is no longer a clear
>> responsibility for that class!
>> The same is true for m:n references across model boundaries.
> MT>> I have a background in developing ERP systems and there it was
> also common to use a foreign key field instead of join tables. A
> number of thoughts from my side regarding this topic:
> - as Eike mentions foreign keys are more intruisive than join table as
> the target table gets changed (has an extra foreign key field(s))
> - Foreign keys are more efficient as there is one less join to do
> - Foreign keys do not support duplicate occurences in a list (join
> tables do, assuming a join table has a separate id column).
> - Specifically for containment relations my feel is that a foreign key
> field is appropriate as it reflects the stronger relation between the
> child and the parent. The same can be said for bidirectional relations.
>
> Overall I have the same feel as Thomas, with my background I like
> foreign keys (as they are more efficient) but I understand that there
> are many people with other ideas. Teneo has an option to specify if
> all non-containment relations should be mapped with a join table (or
> not).
>
>>
>>> why is the version part of the primary key ? that doesnt make sense
>>> to me. maybe you have reasons but i would expect that the db has
>>> only a single version stored. and again here pain in joining.
>> CDO is basically capable of auditing (retrieving historical states of
>> the overall model). I guess it's a similar effect like the one the
>> new Temporality project announces. An Istore decides if it supports
>> auditing mode and if it supports non-auditing mode. The DBStore
>> currently does only support auditing mode! I'm currently a bit unsure
>> what to prioritize: Make DBStore support non-auditing mode or help
>> Martin develop a HibernateStore for CDO. I guess you'll vote for the
>> latter ;-) I'd agree.
> MT>> I will start looking at CDO today and try out the tutorial, etc.
> Maybe I can get a long way without asking to much of your time Eike
> (so then you can do both :-).
> MT>> Btw, imo it is great that CDO also considers topics like
> auditing, these generic topics can really be solved at this level.
>
>>
>>> what kinds of relations are supported ?
>> Single-valued references are mapped to CDOID columns in the table of
>> the referencing EClass.
>> Multi-valued references are mapped to the join tables I mentioned
>> before.
>> Was this what you asked for?
>>
>>>
>>> What about Lobs ? is there support for large objects ?
>> In which context? For mapping multi-valued references? This is
>> planned via
>> org.eclipse.emf.cdo.server.internal.db.ToMany.LIKE_ATTRIBUTE S. I'd
>> make querying even harder.
>>
>>>
>>> We would at least need to supply not null constraints
>> That could make a good Bugzilla (A) ;-)
>>
>>> on fields and ManyToOne relations,
>> See my above concerns. A separate Bugzilla (B) could be good to
>> discuss these concerns.
>>
>>> field lengthes for character strings,
>> Fits well into the Bugzilla (A).
>>
>>> plus I have to dive into the validation problem. plus i need
>>> something for unique key constraints and indexes.
>> What is the validation problem? The one Simon solved via OCL?
>> Unique key constraints and indexes could go into (A) as well.
>>
>> One general comment to all this mapping stuff: As you correctly
>> analyzed in another thread, CDO is not mainly about providing a new
>> O/R mapping solution. Hibernate will probably always be better here
>> and I didn't plan to compete with it. CDO is more focused on
>> providing a stable and efficient 3-tier solution (client / repository
>> / store) with distributed shared model semantics (remote update
>> notifications) and an auditing mode. The store even doesn't need to
>> be a relational database.
>>
>> I think it's time for me to dig into the Hibernate code and work with
>> Martin to develop a HibernateStore for the CDO storage framework.
>>
>> Regards,
>> Eike Stepper
>> ----
>> http://wiki.eclipse.org/CDO
>> http://wiki.eclipse.org/Net4j
>>
>>
>>>
>>> Thomas
>>>
>>> Eike Stepper schrieb:
>>>> Hi Thomas,
>>>>
>>>> A CDOSession has a setReferenceChunkSize() method which you can
>>>> call to limit the number of objects (ids) to load on collection
>>>> read accesses. Since read access (loading) is handled by the
>>>> CDOSession all CDOViews on that session share this setting. We are
>>>> currently discussing to provide an additional session property:
>>>> InitialReferenceChunkSize. Then you could even configure to load
>>>> nothing on the first access (of the source object) and max n
>>>> targets on subsequent reference accesses. At the moment I'd suggest
>>>> to set a value of 10-100 so that you're shielded against huge
>>>> collections.
>>>>
>>>> Regards,
>>>> Eike Stepper
>>>> ----
>>>> http://wiki.eclipse.org/CDO
>>>> http://wiki.eclipse.org/Net4j
>>>>
>>>>
>>>>
>>>> Thomas schrieb:
>>>>> Once again..
>>>>> Another thing coming to my mind is about the object graph. Suggest
>>>>> I have a Object Person with a Collection of Adresses. when I query
>>>>> for the person did I get it right that the Adresse are only loaded
>>>>> when I try to access them ? That would be the main decision factor
>>>>> for me. I have expensive objects and the more the could be lazy
>>>>> loaded the better my ui handling would be.
>>>>>
>>>>> Regards Thomas
>
>
Re: [CDO] is it what I want ? [message #109683 is a reply to message #109675] Wed, 30 January 2008 13:04 Go to previous messageGo to next message
Eclipse UserFriend
Originally posted by: tom.eiswind.de

Hi Eike,

Be sure to have annotations and entitymanager too.

I tried to migrate my ecore from yesterday with new emf project, native
CDO. installed the latest integration build, as the build scripts are
unix only.

I get:
!MESSAGE
!STACK 0
java.lang.reflect.InvocationTargetException
at
org.eclipse.ui.actions.WorkspaceModifyOperation.run(Workspac eModifyOperation.java:119)
at
org.eclipse.jface.operation.ModalContext.runInCurrentThread( ModalContext.java:407)
at org.eclipse.jface.operation.ModalContext.run(ModalContext.ja va:347)
at org.eclipse.jface.wizard.WizardDialog.run(WizardDialog.java: 934)
at
org.eclipse.emf.converter.ui.contribution.base.ModelConverte rWizard.performFinish(ModelConverterWizard.java:246)
at
org.eclipse.emf.importer.ui.contribution.base.ModelImporterW izard.performFinish(ModelImporterWizard.java:157)
at
org.eclipse.jface.wizard.WizardDialog.finishPressed(WizardDi alog.java:742)
at
org.eclipse.jface.wizard.WizardDialog.buttonPressed(WizardDi alog.java:373)
at org.eclipse.jface.dialogs.Dialog$2.widgetSelected(Dialog.jav a:623)
at
org.eclipse.swt.widgets.TypedListener.handleEvent(TypedListe ner.java:227)
at org.eclipse.swt.widgets.EventTable.sendEvent(EventTable.java :66)
at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:952)
at org.eclipse.swt.widgets.Display.runDeferredEvents(Display.ja va:3750)
at org.eclipse.swt.widgets.Display.readAndDispatch(Display.java :3361)
at org.eclipse.jface.window.Window.runEventLoop(Window.java:825 )
at org.eclipse.jface.window.Window.open(Window.java:801)
at org.eclipse.ui.actions.NewProjectAction.run(NewProjectAction .java:116)
at org.eclipse.jface.action.Action.runWithEvent(Action.java:498 )
at
org.eclipse.jface.action.ActionContributionItem.handleWidget Selection(ActionContributionItem.java:582)
at
org.eclipse.jface.action.ActionContributionItem.access$2(Act ionContributionItem.java:499)
at
org.eclipse.jface.action.ActionContributionItem$5.handleEven t(ActionContributionItem.java:410)
at org.eclipse.swt.widgets.EventTable.sendEvent(EventTable.java :66)
at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:952)
at org.eclipse.swt.widgets.Display.runDeferredEvents(Display.ja va:3750)
at org.eclipse.swt.widgets.Display.readAndDispatch(Display.java :3361)
at org.eclipse.ui.internal.Workbench.runEventLoop(Workbench.jav a:2381)
at org.eclipse.ui.internal.Workbench.runUI(Workbench.java:2345)
at org.eclipse.ui.internal.Workbench.access$4(Workbench.java:22 11)
at org.eclipse.ui.internal.Workbench$4.run(Workbench.java:473)
at
org.eclipse.core.databinding.observable.Realm.runWithDefault (Realm.java:288)
at
org.eclipse.ui.internal.Workbench.createAndRunWorkbench(Work bench.java:468)
at org.eclipse.ui.PlatformUI.createAndRunWorkbench(PlatformUI.j ava:149)
at
org.eclipse.ui.internal.ide.application.IDEApplication.start (IDEApplication.java:106)
at
org.eclipse.equinox.internal.app.EclipseAppHandle.run(Eclips eAppHandle.java:193)
at
org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher .runApplication(EclipseAppLauncher.java:106)
at
org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher .start(EclipseAppLauncher.java:76)
at
org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseS tarter.java:362)
at
org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseS tarter.java:175)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
at java.lang.reflect.Method.invoke(Unknown Source)
at org.eclipse.equinox.launcher.Main.invokeFramework(Main.java: 561)
at org.eclipse.equinox.launcher.Main.basicRun(Main.java:501)
at org.eclipse.equinox.launcher.Main.run(Main.java:1239)
Caused by: org.eclipse.core.runtime.CoreException: An error occurred
while performing this operation.
at
org.eclipse.emf.common.util.DiagnosticException.toCoreExcept ion(DiagnosticException.java:47)
at
org.eclipse.emf.converter.ui.contribution.base.ModelConverte rWizard$1.execute(ModelConverterWizard.java:235)
at
org.eclipse.ui.actions.WorkspaceModifyOperation$1.run(Worksp aceModifyOperation.java:104)
at org.eclipse.core.internal.resources.Workspace.run(Workspace. java:1800)
at
org.eclipse.ui.actions.WorkspaceModifyOperation.run(Workspac eModifyOperation.java:116)
... 44 more
Root exception:
org.eclipse.core.runtime.CoreException: An error occurred while
performing this operation.
at
org.eclipse.emf.common.util.DiagnosticException.toCoreExcept ion(DiagnosticException.java:47)
at
org.eclipse.emf.converter.ui.contribution.base.ModelConverte rWizard$1.execute(ModelConverterWizard.java:235)
at
org.eclipse.ui.actions.WorkspaceModifyOperation$1.run(Worksp aceModifyOperation.java:104)
at org.eclipse.core.internal.resources.Workspace.run(Workspace. java:1800)
at
org.eclipse.ui.actions.WorkspaceModifyOperation.run(Workspac eModifyOperation.java:116)
at
org.eclipse.jface.operation.ModalContext.runInCurrentThread( ModalContext.java:407)
at org.eclipse.jface.operation.ModalContext.run(ModalContext.ja va:347)
at org.eclipse.jface.wizard.WizardDialog.run(WizardDialog.java: 934)
at
org.eclipse.emf.converter.ui.contribution.base.ModelConverte rWizard.performFinish(ModelConverterWizard.java:246)
at
org.eclipse.emf.importer.ui.contribution.base.ModelImporterW izard.performFinish(ModelImporterWizard.java:157)
at
org.eclipse.jface.wizard.WizardDialog.finishPressed(WizardDi alog.java:742)
at
org.eclipse.jface.wizard.WizardDialog.buttonPressed(WizardDi alog.java:373)
at org.eclipse.jface.dialogs.Dialog$2.widgetSelected(Dialog.jav a:623)
at
org.eclipse.swt.widgets.TypedListener.handleEvent(TypedListe ner.java:227)
at org.eclipse.swt.widgets.EventTable.sendEvent(EventTable.java :66)
at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:952)
at org.eclipse.swt.widgets.Display.runDeferredEvents(Display.ja va:3750)
at org.eclipse.swt.widgets.Display.readAndDispatch(Display.java :3361)
at org.eclipse.jface.window.Window.runEventLoop(Window.java:825 )
at org.eclipse.jface.window.Window.open(Window.java:801)
at org.eclipse.ui.actions.NewProjectAction.run(NewProjectAction .java:116)
at org.eclipse.jface.action.Action.runWithEvent(Action.java:498 )
at
org.eclipse.jface.action.ActionContributionItem.handleWidget Selection(ActionContributionItem.java:582)
at
org.eclipse.jface.action.ActionContributionItem.access$2(Act ionContributionItem.java:499)
at
org.eclipse.jface.action.ActionContributionItem$5.handleEven t(ActionContributionItem.java:410)
at org.eclipse.swt.widgets.EventTable.sendEvent(EventTable.java :66)
at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:952)
at org.eclipse.swt.widgets.Display.runDeferredEvents(Display.ja va:3750)
at org.eclipse.swt.widgets.Display.readAndDispatch(Display.java :3361)
at org.eclipse.ui.internal.Workbench.runEventLoop(Workbench.jav a:2381)
at org.eclipse.ui.internal.Workbench.runUI(Workbench.java:2345)
at org.eclipse.ui.internal.Workbench.access$4(Workbench.java:22 11)
at org.eclipse.ui.internal.Workbench$4.run(Workbench.java:473)
at
org.eclipse.core.databinding.observable.Realm.runWithDefault (Realm.java:288)
at
org.eclipse.ui.internal.Workbench.createAndRunWorkbench(Work bench.java:468)
at org.eclipse.ui.PlatformUI.createAndRunWorkbench(PlatformUI.j ava:149)
at
org.eclipse.ui.internal.ide.application.IDEApplication.start (IDEApplication.java:106)
at
org.eclipse.equinox.internal.app.EclipseAppHandle.run(Eclips eAppHandle.java:193)
at
org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher .runApplication(EclipseAppLauncher.java:106)
at
org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher .start(EclipseAppLauncher.java:76)
at
org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseS tarter.java:362)
at
org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseS tarter.java:175)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
at java.lang.reflect.Method.invoke(Unknown Source)
at org.eclipse.equinox.launcher.Main.invokeFramework(Main.java: 561)
at org.eclipse.equinox.launcher.Main.basicRun(Main.java:501)
at org.eclipse.equinox.launcher.Main.run(Main.java:1239)
org.eclipse.core.runtime.CoreException[2048]:
org.eclipse.emf.common.util.DiagnosticException: An error occurred while
performing this operation.
at
org.eclipse.emf.converter.ui.contribution.base.ModelConverte rWizard$1.execute(ModelConverterWizard.java:234)
at
org.eclipse.ui.actions.WorkspaceModifyOperation$1.run(Worksp aceModifyOperation.java:104)
at org.eclipse.core.internal.resources.Workspace.run(Workspace. java:1800)
at
org.eclipse.ui.actions.WorkspaceModifyOperation.run(Workspac eModifyOperation.java:116)
at
org.eclipse.jface.operation.ModalContext.runInCurrentThread( ModalContext.java:407)
at org.eclipse.jface.operation.ModalContext.run(ModalContext.ja va:347)
at org.eclipse.jface.wizard.WizardDialog.run(WizardDialog.java: 934)
at
org.eclipse.emf.converter.ui.contribution.base.ModelConverte rWizard.performFinish(ModelConverterWizard.java:246)
at
org.eclipse.emf.importer.ui.contribution.base.ModelImporterW izard.performFinish(ModelImporterWizard.java:157)
at
org.eclipse.jface.wizard.WizardDialog.finishPressed(WizardDi alog.java:742)
at
org.eclipse.jface.wizard.WizardDialog.buttonPressed(WizardDi alog.java:373)
at org.eclipse.jface.dialogs.Dialog$2.widgetSelected(Dialog.jav a:623)
at
org.eclipse.swt.widgets.TypedListener.handleEvent(TypedListe ner.java:227)
at org.eclipse.swt.widgets.EventTable.sendEvent(EventTable.java :66)
at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:952)
at org.eclipse.swt.widgets.Display.runDeferredEvents(Display.ja va:3750)
at org.eclipse.swt.widgets.Display.readAndDispatch(Display.java :3361)
at org.eclipse.jface.window.Window.runEventLoop(Window.java:825 )
at org.eclipse.jface.window.Window.open(Window.java:801)
at org.eclipse.ui.actions.NewProjectAction.run(NewProjectAction .java:116)
at org.eclipse.jface.action.Action.runWithEvent(Action.java:498 )
at
org.eclipse.jface.action.ActionContributionItem.handleWidget Selection(ActionContributionItem.java:582)
at
org.eclipse.jface.action.ActionContributionItem.access$2(Act ionContributionItem.java:499)
at
org.eclipse.jface.action.ActionContributionItem$5.handleEven t(ActionContributionItem.java:410)
at org.eclipse.swt.widgets.EventTable.sendEvent(EventTable.java :66)
at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:952)
at org.eclipse.swt.widgets.Display.runDeferredEvents(Display.ja va:3750)
at org.eclipse.swt.widgets.Display.readAndDispatch(Display.java :3361)
at org.eclipse.ui.internal.Workbench.runEventLoop(Workbench.jav a:2381)
at org.eclipse.ui.internal.Workbench.runUI(Workbench.java:2345)
at org.eclipse.ui.internal.Workbench.access$4(Workbench.java:22 11)
at org.eclipse.ui.internal.Workbench$4.run(Workbench.java:473)
at
org.eclipse.core.databinding.observable.Realm.runWithDefault (Realm.java:288)
at
org.eclipse.ui.internal.Workbench.createAndRunWorkbench(Work bench.java:468)
at org.eclipse.ui.PlatformUI.createAndRunWorkbench(PlatformUI.j ava:149)
at
org.eclipse.ui.internal.ide.application.IDEApplication.start (IDEApplication.java:106)
at
org.eclipse.equinox.internal.app.EclipseAppHandle.run(Eclips eAppHandle.java:193)
at
org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher .runApplication(EclipseAppLauncher.java:106)
at
org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher .start(EclipseAppLauncher.java:76)
at
org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseS tarter.java:362)
at
org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseS tarter.java:175)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
at java.lang.reflect.Method.invoke(Unknown Source)
at org.eclipse.equinox.launcher.Main.invokeFramework(Main.java: 561)
at org.eclipse.equinox.launcher.Main.basicRun(Main.java:501)
at org.eclipse.equinox.launcher.Main.run(Main.java:1239)
Caused by: org.eclipse.emf.common.util.WrappedException:
org.eclipse.core.internal.resources.ResourceException: Resource
'/test.cdo' does not exist.
at
org.eclipse.emf.cdo.migrator.CDOMigrator.adjustGenModel(CDOM igrator.java:91)
at
org.eclipse.emf.cdo.migrator.CDOImporter.adjustGenModel(CDOI mporter.java:125)
at
org.eclipse.emf.importer.ModelImporter.prepareGenModelAndEPa ckages(ModelImporter.java:718)
at
org.eclipse.emf.importer.ui.contribution.base.ModelImporterW izard.doPerformFinish(ModelImporterWizard.java:149)
at
org.eclipse.emf.converter.ui.contribution.base.ModelConverte rWizard$1.execute(ModelConverterWizard.java:228)
... 47 more
Caused by: org.eclipse.core.internal.resources.ResourceException:
Resource '/test.cdo' does not exist.
at
org.eclipse.core.internal.resources.Resource.checkExists(Res ource.java:309)
at
org.eclipse.core.internal.resources.Resource.checkAccessible (Resource.java:192)
at
org.eclipse.core.internal.resources.Project.checkAccessible( Project.java:113)
at
org.eclipse.core.internal.resources.Folder.assertCreateRequi rements(Folder.java:32)
at org.eclipse.core.internal.resources.Folder.create(Folder.jav a:88)
at org.eclipse.core.internal.resources.Folder.create(Folder.jav a:118)
at
org.eclipse.emf.cdo.migrator.CDOMigrator.adjustGenModel(CDOM igrator.java:86)
... 51 more

Eike Stepper schrieb:
> Guys,
>
> I just downloaded Hibernate ;-)
>
> Regards,
> Eike Stepper
> ----
> http://wiki.eclipse.org/CDO
> http://wiki.eclipse.org/Net4j
>
>
>
> Martin Taal schrieb:
>> Hi Eike, Thomas,
>> I will start looking at the integration between CDO and Teneo today. I
>> first need to get familiar with cdo and then I can see how Teneo can
>> be integrated. I'll keep you posted.
>>
>> See my other additions below.
>>
>> gr. Martin
>>
>> Eike Stepper wrote:
>>> Thomas schrieb:
>>>> HI Eike, this seems to be what I would need.
>>>> I overlooked your mapping hints (will have to see this in an example
>>>> maybe tommorrow.) what I dislike is the relation tables. as i do
>>>> reporting with birt i will have to query the database with sql and
>>>> th relation tables make manual joining a pain. I know some dtabase
>>>> gurus recommend join tables but I still prefer a single foreign key
>>>> in the target table. ok you need a single column then for each
>>>> relation (give it a speaking name and everthing is clear)
>>> What I don't like with the foreign key joins you mention is the
>>> following:
>>> Assume you are a big IT company and you have many application with
>>> one development team being responsible for one application. The
>>> applications have non-circular dependencies on each other and this is
>>> clearly reflected within the models that form the applications. As
>>> long as you're modeling there's at no time the need to modify foreign
>>> code (the models you depend on). Consider the following example:
>>> Team1, January 2008, develops a model Employees. There is an EClass
>>> Employee.
>>> Team2, March 2008, develops the model Supervisors. There is an EClass
>>> Supervisor with a many-reference supervisedEmployees:List<Emplyoee>.
>>>
>>> In the OO world there's no need for Team2 to touch code of Team1.
>>> If the many-reference supervisedEmployees is mapped to a dedicated
>>> join table there's also no responsibility conflict in the DB team of
>>> your company.
>>> But when it comes to O/R mapping of supervisedEmployees with foreign
>>> keys in the table of Employee there is no longer a clear
>>> responsibility for that class!
>>> The same is true for m:n references across model boundaries.
>> MT>> I have a background in developing ERP systems and there it was
>> also common to use a foreign key field instead of join tables. A
>> number of thoughts from my side regarding this topic:
>> - as Eike mentions foreign keys are more intruisive than join table as
>> the target table gets changed (has an extra foreign key field(s))
>> - Foreign keys are more efficient as there is one less join to do
>> - Foreign keys do not support duplicate occurences in a list (join
>> tables do, assuming a join table has a separate id column).
>> - Specifically for containment relations my feel is that a foreign key
>> field is appropriate as it reflects the stronger relation between the
>> child and the parent. The same can be said for bidirectional relations.
>>
>> Overall I have the same feel as Thomas, with my background I like
>> foreign keys (as they are more efficient) but I understand that there
>> are many people with other ideas. Teneo has an option to specify if
>> all non-containment relations should be mapped with a join table (or
>> not).
>>
>>>
>>>> why is the version part of the primary key ? that doesnt make sense
>>>> to me. maybe you have reasons but i would expect that the db has
>>>> only a single version stored. and again here pain in joining.
>>> CDO is basically capable of auditing (retrieving historical states of
>>> the overall model). I guess it's a similar effect like the one the
>>> new Temporality project announces. An Istore decides if it supports
>>> auditing mode and if it supports non-auditing mode. The DBStore
>>> currently does only support auditing mode! I'm currently a bit unsure
>>> what to prioritize: Make DBStore support non-auditing mode or help
>>> Martin develop a HibernateStore for CDO. I guess you'll vote for the
>>> latter ;-) I'd agree.
>> MT>> I will start looking at CDO today and try out the tutorial, etc.
>> Maybe I can get a long way without asking to much of your time Eike
>> (so then you can do both :-).
>> MT>> Btw, imo it is great that CDO also considers topics like
>> auditing, these generic topics can really be solved at this level.
>>
>>>
>>>> what kinds of relations are supported ?
>>> Single-valued references are mapped to CDOID columns in the table of
>>> the referencing EClass.
>>> Multi-valued references are mapped to the join tables I mentioned
>>> before.
>>> Was this what you asked for?
>>>
>>>>
>>>> What about Lobs ? is there support for large objects ?
>>> In which context? For mapping multi-valued references? This is
>>> planned via
>>> org.eclipse.emf.cdo.server.internal.db.ToMany.LIKE_ATTRIBUTE S. I'd
>>> make querying even harder.
>>>
>>>>
>>>> We would at least need to supply not null constraints
>>> That could make a good Bugzilla (A) ;-)
>>>
>>>> on fields and ManyToOne relations,
>>> See my above concerns. A separate Bugzilla (B) could be good to
>>> discuss these concerns.
>>>
>>>> field lengthes for character strings,
>>> Fits well into the Bugzilla (A).
>>>
>>>> plus I have to dive into the validation problem. plus i need
>>>> something for unique key constraints and indexes.
>>> What is the validation problem? The one Simon solved via OCL?
>>> Unique key constraints and indexes could go into (A) as well.
>>>
>>> One general comment to all this mapping stuff: As you correctly
>>> analyzed in another thread, CDO is not mainly about providing a new
>>> O/R mapping solution. Hibernate will probably always be better here
>>> and I didn't plan to compete with it. CDO is more focused on
>>> providing a stable and efficient 3-tier solution (client / repository
>>> / store) with distributed shared model semantics (remote update
>>> notifications) and an auditing mode. The store even doesn't need to
>>> be a relational database.
>>>
>>> I think it's time for me to dig into the Hibernate code and work with
>>> Martin to develop a HibernateStore for the CDO storage framework.
>>>
>>> Regards,
>>> Eike Stepper
>>> ----
>>> http://wiki.eclipse.org/CDO
>>> http://wiki.eclipse.org/Net4j
>>>
>>>
>>>>
>>>> Thomas
>>>>
>>>> Eike Stepper schrieb:
>>>>> Hi Thomas,
>>>>>
>>>>> A CDOSession has a setReferenceChunkSize() method which you can
>>>>> call to limit the number of objects (ids) to load on collection
>>>>> read accesses. Since read access (loading) is handled by the
>>>>> CDOSession all CDOViews on that session share this setting. We are
>>>>> currently discussing to provide an additional session property:
>>>>> InitialReferenceChunkSize. Then you could even configure to load
>>>>> nothing on the first access (of the source object) and max n
>>>>> targets on subsequent reference accesses. At the moment I'd suggest
>>>>> to set a value of 10-100 so that you're shielded against huge
>>>>> collections.
>>>>>
>>>>> Regards,
>>>>> Eike Stepper
>>>>> ----
>>>>> http://wiki.eclipse.org/CDO
>>>>> http://wiki.eclipse.org/Net4j
>>>>>
>>>>>
>>>>>
>>>>> Thomas schrieb:
>>>>>> Once again..
>>>>>> Another thing coming to my mind is about the object graph. Suggest
>>>>>> I have a Object Person with a Collection of Adresses. when I query
>>>>>> for the person did I get it right that the Adresse are only loaded
>>>>>> when I try to access them ? That would be the main decision factor
>>>>>> for me. I have expensive objects and the more the could be lazy
>>>>>> loaded the better my ui handling would be.
>>>>>>
>>>>>> Regards Thomas
>>
>>
Re: [CDO] is it what I want ? [message #109697 is a reply to message #109576] Wed, 30 January 2008 13:05 Go to previous messageGo to next message
Eclipse UserFriend
Originally posted by: stepper.sympedia.de

Thomas schrieb:
> [stuff deleted]
>
>> why is the version part of the primary key ? that doesnt make sense
>> to me. maybe you have reasons but i would expect that the db has only
>> a single version stored. and again here pain in joining. CDO is
>> basically capable of auditing (retrieving historical states of the
>> overall model). I guess it's a similar effect like the one the new
>> Temporality project announces.
>
> Ok then you have mutliple versions. But I would (personal taste ?)
> prefer a single column surrogate primary key in any case. There are
> some techniques on versioning (take three add columns columns, a group
> id that groups the versions a counter/timestamp and a boolean, set the
> boolean true for the current version, put a unique constraint on
> group_id and version) timestamp makes problems on oracle as it not
> finegrained enough for have load, so i prefer a counter or a mix of
> both of it. its just the idea of having a clean surrogate key that i
> always prefer.
I'm not sure if I completely understand what you're saying about
versioning technique, but I'm sure you've been a DB expert before you
started modeling ;-)

The current structure of the internal columns of CDO is carefully
chosen. There's no redundancy and all of the following operations are
possible efficiently:
a) loadLatestRevision (revised==null)
b) loadRevisionByVersion (version == v)
c) loadRevisionByTime (revised == UNSPECIFIED_DATE || revised >=
timeStamp) && timeStamp >= created
d) lockForWrite (set revised = now)

As I said these structures are optimized for the repository access
(defined by the IStore API) and not for manual querying (although this
was a secondary requirement).

> [stuff deleted]
>
> Hmm Eike, dont know if I should open bugs on this if we dig into
> teneo. Why put so much effort in there when we already have
> (nearly)everything we need at hand ?
Agreed ;-)

>
> Regarding the task force I think I can try to support you. I just dont
> know how much time I can put in there, can be that I have a new
> project next week, can be that I have lots of time to spent in february.
I'm also about to start into a new customer project until beginning of May.

Regards,
Eike Stepper
----
http://wiki.eclipse.org/CDO
http://wiki.eclipse.org/Net4j
Re: [CDO] is it what I want ? [message #109705 is a reply to message #109683] Wed, 30 January 2008 13:09 Go to previous messageGo to next message
Eclipse UserFriend
Originally posted by: stepper.sympedia.de

Thomas schrieb:
> Hi Eike,
>
> Be sure to have annotations and entitymanager too.
Got them ;-)

>
> I tried to migrate my ecore from yesterday with new emf project,
> native CDO. installed the latest integration build, as the build
> scripts are unix only.
You don't need build scripts. BTW. which scripts do you refer to?
Just check out everything with All.psf.
The migrator doesn't have any other CDO/Net4j dependencies. Just
right-click org.eclipse.emf.cdo.migrator and export it as deployable
plugin to your eclipse installation. restart and it should be there.

DTH?

WRT. the exception below, what is test.cdo?
--> "Resource '/test.cdo' does not exist. "


Regards,
Eike Stepper
----
http://wiki.eclipse.org/CDO
http://wiki.eclipse.org/Net4j


>
> I get:
> !MESSAGE
> !STACK 0
> java.lang.reflect.InvocationTargetException
> at
> org.eclipse.ui.actions.WorkspaceModifyOperation.run(Workspac eModifyOperation.java:119)
>
> at
> org.eclipse.jface.operation.ModalContext.runInCurrentThread( ModalContext.java:407)
>
> at
> org.eclipse.jface.operation.ModalContext.run(ModalContext.ja va:347)
> at org.eclipse.jface.wizard.WizardDialog.run(WizardDialog.java: 934)
> at
> org.eclipse.emf.converter.ui.contribution.base.ModelConverte rWizard.performFinish(ModelConverterWizard.java:246)
>
> at
> org.eclipse.emf.importer.ui.contribution.base.ModelImporterW izard.performFinish(ModelImporterWizard.java:157)
>
> at
> org.eclipse.jface.wizard.WizardDialog.finishPressed(WizardDi alog.java:742)
>
> at
> org.eclipse.jface.wizard.WizardDialog.buttonPressed(WizardDi alog.java:373)
>
> at org.eclipse.jface.dialogs.Dialog$2.widgetSelected(Dialog.jav a:623)
> at
> org.eclipse.swt.widgets.TypedListener.handleEvent(TypedListe ner.java:227)
> at org.eclipse.swt.widgets.EventTable.sendEvent(EventTable.java :66)
> at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:952)
> at
> org.eclipse.swt.widgets.Display.runDeferredEvents(Display.ja va:3750)
> at org.eclipse.swt.widgets.Display.readAndDispatch(Display.java :3361)
> at org.eclipse.jface.window.Window.runEventLoop(Window.java:825 )
> at org.eclipse.jface.window.Window.open(Window.java:801)
> at
> org.eclipse.ui.actions.NewProjectAction.run(NewProjectAction .java:116)
> at org.eclipse.jface.action.Action.runWithEvent(Action.java:498 )
> at
> org.eclipse.jface.action.ActionContributionItem.handleWidget Selection(ActionContributionItem.java:582)
>
> at
> org.eclipse.jface.action.ActionContributionItem.access$2(Act ionContributionItem.java:499)
>
> at
> org.eclipse.jface.action.ActionContributionItem$5.handleEven t(ActionContributionItem.java:410)
>
> at org.eclipse.swt.widgets.EventTable.sendEvent(EventTable.java :66)
> at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:952)
> at
> org.eclipse.swt.widgets.Display.runDeferredEvents(Display.ja va:3750)
> at org.eclipse.swt.widgets.Display.readAndDispatch(Display.java :3361)
> at
> org.eclipse.ui.internal.Workbench.runEventLoop(Workbench.jav a:2381)
> at org.eclipse.ui.internal.Workbench.runUI(Workbench.java:2345)
> at org.eclipse.ui.internal.Workbench.access$4(Workbench.java:22 11)
> at org.eclipse.ui.internal.Workbench$4.run(Workbench.java:473)
> at
> org.eclipse.core.databinding.observable.Realm.runWithDefault (Realm.java:288)
>
> at
> org.eclipse.ui.internal.Workbench.createAndRunWorkbench(Work bench.java:468)
>
> at
> org.eclipse.ui.PlatformUI.createAndRunWorkbench(PlatformUI.j ava:149)
> at
> org.eclipse.ui.internal.ide.application.IDEApplication.start (IDEApplication.java:106)
>
> at
> org.eclipse.equinox.internal.app.EclipseAppHandle.run(Eclips eAppHandle.java:193)
>
> at
> org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher .runApplication(EclipseAppLauncher.java:106)
>
> at
> org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher .start(EclipseAppLauncher.java:76)
>
> at
> org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseS tarter.java:362)
>
> at
> org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseS tarter.java:175)
>
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
> at java.lang.reflect.Method.invoke(Unknown Source)
> at org.eclipse.equinox.launcher.Main.invokeFramework(Main.java: 561)
> at org.eclipse.equinox.launcher.Main.basicRun(Main.java:501)
> at org.eclipse.equinox.launcher.Main.run(Main.java:1239)
> Caused by: org.eclipse.core.runtime.CoreException: An error occurred
> while performing this operation.
> at
> org.eclipse.emf.common.util.DiagnosticException.toCoreExcept ion(DiagnosticException.java:47)
>
> at
> org.eclipse.emf.converter.ui.contribution.base.ModelConverte rWizard$1.execute(ModelConverterWizard.java:235)
>
> at
> org.eclipse.ui.actions.WorkspaceModifyOperation$1.run(Worksp aceModifyOperation.java:104)
>
> at
> org.eclipse.core.internal.resources.Workspace.run(Workspace. java:1800)
> at
> org.eclipse.ui.actions.WorkspaceModifyOperation.run(Workspac eModifyOperation.java:116)
>
> ... 44 more
> Root exception:
> org.eclipse.core.runtime.CoreException: An error occurred while
> performing this operation.
> at
> org.eclipse.emf.common.util.DiagnosticException.toCoreExcept ion(DiagnosticException.java:47)
>
> at
> org.eclipse.emf.converter.ui.contribution.base.ModelConverte rWizard$1.execute(ModelConverterWizard.java:235)
>
> at
> org.eclipse.ui.actions.WorkspaceModifyOperation$1.run(Worksp aceModifyOperation.java:104)
>
> at
> org.eclipse.core.internal.resources.Workspace.run(Workspace. java:1800)
> at
> org.eclipse.ui.actions.WorkspaceModifyOperation.run(Workspac eModifyOperation.java:116)
>
> at
> org.eclipse.jface.operation.ModalContext.runInCurrentThread( ModalContext.java:407)
>
> at
> org.eclipse.jface.operation.ModalContext.run(ModalContext.ja va:347)
> at org.eclipse.jface.wizard.WizardDialog.run(WizardDialog.java: 934)
> at
> org.eclipse.emf.converter.ui.contribution.base.ModelConverte rWizard.performFinish(ModelConverterWizard.java:246)
>
> at
> org.eclipse.emf.importer.ui.contribution.base.ModelImporterW izard.performFinish(ModelImporterWizard.java:157)
>
> at
> org.eclipse.jface.wizard.WizardDialog.finishPressed(WizardDi alog.java:742)
>
> at
> org.eclipse.jface.wizard.WizardDialog.buttonPressed(WizardDi alog.java:373)
>
> at org.eclipse.jface.dialogs.Dialog$2.widgetSelected(Dialog.jav a:623)
> at
> org.eclipse.swt.widgets.TypedListener.handleEvent(TypedListe ner.java:227)
> at org.eclipse.swt.widgets.EventTable.sendEvent(EventTable.java :66)
> at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:952)
> at
> org.eclipse.swt.widgets.Display.runDeferredEvents(Display.ja va:3750)
> at org.eclipse.swt.widgets.Display.readAndDispatch(Display.java :3361)
> at org.eclipse.jface.window.Window.runEventLoop(Window.java:825 )
> at org.eclipse.jface.window.Window.open(Window.java:801)
> at
> org.eclipse.ui.actions.NewProjectAction.run(NewProjectAction .java:116)
> at org.eclipse.jface.action.Action.runWithEvent(Action.java:498 )
> at
> org.eclipse.jface.action.ActionContributionItem.handleWidget Selection(ActionContributionItem.java:582)
>
> at
> org.eclipse.jface.action.ActionContributionItem.access$2(Act ionContributionItem.java:499)
>
> at
> org.eclipse.jface.action.ActionContributionItem$5.handleEven t(ActionContributionItem.java:410)
>
> at org.eclipse.swt.widgets.EventTable.sendEvent(EventTable.java :66)
> at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:952)
> at
> org.eclipse.swt.widgets.Display.runDeferredEvents(Display.ja va:3750)
> at org.eclipse.swt.widgets.Display.readAndDispatch(Display.java :3361)
> at
> org.eclipse.ui.internal.Workbench.runEventLoop(Workbench.jav a:2381)
> at org.eclipse.ui.internal.Workbench.runUI(Workbench.java:2345)
> at org.eclipse.ui.internal.Workbench.access$4(Workbench.java:22 11)
> at org.eclipse.ui.internal.Workbench$4.run(Workbench.java:473)
> at
> org.eclipse.core.databinding.observable.Realm.runWithDefault (Realm.java:288)
>
> at
> org.eclipse.ui.internal.Workbench.createAndRunWorkbench(Work bench.java:468)
>
> at
> org.eclipse.ui.PlatformUI.createAndRunWorkbench(PlatformUI.j ava:149)
> at
> org.eclipse.ui.internal.ide.application.IDEApplication.start (IDEApplication.java:106)
>
> at
> org.eclipse.equinox.internal.app.EclipseAppHandle.run(Eclips eAppHandle.java:193)
>
> at
> org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher .runApplication(EclipseAppLauncher.java:106)
>
> at
> org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher .start(EclipseAppLauncher.java:76)
>
> at
> org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseS tarter.java:362)
>
> at
> org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseS tarter.java:175)
>
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
> at java.lang.reflect.Method.invoke(Unknown Source)
> at org.eclipse.equinox.launcher.Main.invokeFramework(Main.java: 561)
> at org.eclipse.equinox.launcher.Main.basicRun(Main.java:501)
> at org.eclipse.equinox.launcher.Main.run(Main.java:1239)
> org.eclipse.core.runtime.CoreException[2048]:
> org.eclipse.emf.common.util.DiagnosticException: An error occurred
> while performing this operation.
> at
> org.eclipse.emf.converter.ui.contribution.base.ModelConverte rWizard$1.execute(ModelConverterWizard.java:234)
>
> at
> org.eclipse.ui.actions.WorkspaceModifyOperation$1.run(Worksp aceModifyOperation.java:104)
>
> at
> org.eclipse.core.internal.resources.Workspace.run(Workspace. java:1800)
> at
> org.eclipse.ui.actions.WorkspaceModifyOperation.run(Workspac eModifyOperation.java:116)
>
> at
> org.eclipse.jface.operation.ModalContext.runInCurrentThread( ModalContext.java:407)
>
> at
> org.eclipse.jface.operation.ModalContext.run(ModalContext.ja va:347)
> at org.eclipse.jface.wizard.WizardDialog.run(WizardDialog.java: 934)
> at
> org.eclipse.emf.converter.ui.contribution.base.ModelConverte rWizard.performFinish(ModelConverterWizard.java:246)
>
> at
> org.eclipse.emf.importer.ui.contribution.base.ModelImporterW izard.performFinish(ModelImporterWizard.java:157)
>
> at
> org.eclipse.jface.wizard.WizardDialog.finishPressed(WizardDi alog.java:742)
>
> at
> org.eclipse.jface.wizard.WizardDialog.buttonPressed(WizardDi alog.java:373)
>
> at org.eclipse.jface.dialogs.Dialog$2.widgetSelected(Dialog.jav a:623)
> at
> org.eclipse.swt.widgets.TypedListener.handleEvent(TypedListe ner.java:227)
> at org.eclipse.swt.widgets.EventTable.sendEvent(EventTable.java :66)
> at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:952)
> at
> org.eclipse.swt.widgets.Display.runDeferredEvents(Display.ja va:3750)
> at org.eclipse.swt.widgets.Display.readAndDispatch(Display.java :3361)
> at org.eclipse.jface.window.Window.runEventLoop(Window.java:825 )
> at org.eclipse.jface.window.Window.open(Window.java:801)
> at
> org.eclipse.ui.actions.NewProjectAction.run(NewProjectAction .java:116)
> at org.eclipse.jface.action.Action.runWithEvent(Action.java:498 )
> at
> org.eclipse.jface.action.ActionContributionItem.handleWidget Selection(ActionContributionItem.java:582)
>
> at
> org.eclipse.jface.action.ActionContributionItem.access$2(Act ionContributionItem.java:499)
>
> at
> org.eclipse.jface.action.ActionContributionItem$5.handleEven t(ActionContributionItem.java:410)
>
> at org.eclipse.swt.widgets.EventTable.sendEvent(EventTable.java :66)
> at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:952)
> at
> org.eclipse.swt.widgets.Display.runDeferredEvents(Display.ja va:3750)
> at org.eclipse.swt.widgets.Display.readAndDispatch(Display.java :3361)
> at
> org.eclipse.ui.internal.Workbench.runEventLoop(Workbench.jav a:2381)
> at org.eclipse.ui.internal.Workbench.runUI(Workbench.java:2345)
> at org.eclipse.ui.internal.Workbench.access$4(Workbench.java:22 11)
> at org.eclipse.ui.internal.Workbench$4.run(Workbench.java:473)
> at
> org.eclipse.core.databinding.observable.Realm.runWithDefault (Realm.java:288)
>
> at
> org.eclipse.ui.internal.Workbench.createAndRunWorkbench(Work bench.java:468)
>
> at
> org.eclipse.ui.PlatformUI.createAndRunWorkbench(PlatformUI.j ava:149)
> at
> org.eclipse.ui.internal.ide.application.IDEApplication.start (IDEApplication.java:106)
>
> at
> org.eclipse.equinox.internal.app.EclipseAppHandle.run(Eclips eAppHandle.java:193)
>
> at
> org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher .runApplication(EclipseAppLauncher.java:106)
>
> at
> org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher .start(EclipseAppLauncher.java:76)
>
> at
> org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseS tarter.java:362)
>
> at
> org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseS tarter.java:175)
>
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
> at java.lang.reflect.Method.invoke(Unknown Source)
> at org.eclipse.equinox.launcher.Main.invokeFramework(Main.java: 561)
> at org.eclipse.equinox.launcher.Main.basicRun(Main.java:501)
> at org.eclipse.equinox.launcher.Main.run(Main.java:1239)
> Caused by: org.eclipse.emf.common.util.WrappedException:
> org.eclipse.core.internal.resources.ResourceException: Resource
> '/test.cdo' does not exist.
> at
> org.eclipse.emf.cdo.migrator.CDOMigrator.adjustGenModel(CDOM igrator.java:91)
>
> at
> org.eclipse.emf.cdo.migrator.CDOImporter.adjustGenModel(CDOI mporter.java:125)
>
> at
> org.eclipse.emf.importer.ModelImporter.prepareGenModelAndEPa ckages(ModelImporter.java:718)
>
> at
> org.eclipse.emf.importer.ui.contribution.base.ModelImporterW izard.doPerformFinish(ModelImporterWizard.java:149)
>
> at
> org.eclipse.emf.converter.ui.contribution.base.ModelConverte rWizard$1.execute(ModelConverterWizard.java:228)
>
> ... 47 more
> Caused by: org.eclipse.core.internal.resources.ResourceException:
> Resource '/test.cdo' does not exist.
> at
> org.eclipse.core.internal.resources.Resource.checkExists(Res ource.java:309)
>
> at
> org.eclipse.core.internal.resources.Resource.checkAccessible (Resource.java:192)
>
> at
> org.eclipse.core.internal.resources.Project.checkAccessible( Project.java:113)
>
> at
> org.eclipse.core.internal.resources.Folder.assertCreateRequi rements(Folder.java:32)
>
> at org.eclipse.core.internal.resources.Folder.create(Folder.jav a:88)
> at org.eclipse.core.internal.resources.Folder.create(Folder.jav a:118)
> at
> org.eclipse.emf.cdo.migrator.CDOMigrator.adjustGenModel(CDOM igrator.java:86)
>
> ... 51 more
>
> Eike Stepper schrieb:
>> Guys,
>>
>> I just downloaded Hibernate ;-)
>>
>> Regards,
>> Eike Stepper
>> ----
>> http://wiki.eclipse.org/CDO
>> http://wiki.eclipse.org/Net4j
>>
>>
>>
>> Martin Taal schrieb:
>>> Hi Eike, Thomas,
>>> I will start looking at the integration between CDO and Teneo today.
>>> I first need to get familiar with cdo and then I can see how Teneo
>>> can be integrated. I'll keep you posted.
>>>
>>> See my other additions below.
>>>
>>> gr. Martin
>>>
>>> Eike Stepper wrote:
>>>> Thomas schrieb:
>>>>> HI Eike, this seems to be what I would need.
>>>>> I overlooked your mapping hints (will have to see this in an
>>>>> example maybe tommorrow.) what I dislike is the relation tables.
>>>>> as i do reporting with birt i will have to query the database with
>>>>> sql and th relation tables make manual joining a pain. I know some
>>>>> dtabase gurus recommend join tables but I still prefer a single
>>>>> foreign key in the target table. ok you need a single column then
>>>>> for each relation (give it a speaking name and everthing is clear)
>>>> What I don't like with the foreign key joins you mention is the
>>>> following:
>>>> Assume you are a big IT company and you have many application with
>>>> one development team being responsible for one application. The
>>>> applications have non-circular dependencies on each other and this
>>>> is clearly reflected within the models that form the applications.
>>>> As long as you're modeling there's at no time the need to modify
>>>> foreign code (the models you depend on). Consider the following
>>>> example:
>>>> Team1, January 2008, develops a model Employees. There is an EClass
>>>> Employee.
>>>> Team2, March 2008, develops the model Supervisors. There is an
>>>> EClass Supervisor with a many-reference
>>>> supervisedEmployees:List<Emplyoee>.
>>>>
>>>> In the OO world there's no need for Team2 to touch code of Team1.
>>>> If the many-reference supervisedEmployees is mapped to a dedicated
>>>> join table there's also no responsibility conflict in the DB team
>>>> of your company.
>>>> But when it comes to O/R mapping of supervisedEmployees with
>>>> foreign keys in the table of Employee there is no longer a clear
>>>> responsibility for that class!
>>>> The same is true for m:n references across model boundaries.
>>> MT>> I have a background in developing ERP systems and there it was
>>> also common to use a foreign key field instead of join tables. A
>>> number of thoughts from my side regarding this topic:
>>> - as Eike mentions foreign keys are more intruisive than join table
>>> as the target table gets changed (has an extra foreign key field(s))
>>> - Foreign keys are more efficient as there is one less join to do
>>> - Foreign keys do not support duplicate occurences in a list (join
>>> tables do, assuming a join table has a separate id column).
>>> - Specifically for containment relations my feel is that a foreign
>>> key field is appropriate as it reflects the stronger relation
>>> between the child and the parent. The same can be said for
>>> bidirectional relations.
>>>
>>> Overall I have the same feel as Thomas, with my background I like
>>> foreign keys (as they are more efficient) but I understand that
>>> there are many people with other ideas. Teneo has an option to
>>> specify if all non-containment relations should be mapped with a
>>> join table (or not).
>>>
>>>>
>>>>> why is the version part of the primary key ? that doesnt make
>>>>> sense to me. maybe you have reasons but i would expect that the db
>>>>> has only a single version stored. and again here pain in joining.
>>>> CDO is basically capable of auditing (retrieving historical states
>>>> of the overall model). I guess it's a similar effect like the one
>>>> the new Temporality project announces. An Istore decides if it
>>>> supports auditing mode and if it supports non-auditing mode. The
>>>> DBStore currently does only support auditing mode! I'm currently a
>>>> bit unsure what to prioritize: Make DBStore support non-auditing
>>>> mode or help Martin develop a HibernateStore for CDO. I guess
>>>> you'll vote for the latter ;-) I'd agree.
>>> MT>> I will start looking at CDO today and try out the tutorial,
>>> etc. Maybe I can get a long way without asking to much of your time
>>> Eike (so then you can do both :-).
>>> MT>> Btw, imo it is great that CDO also considers topics like
>>> auditing, these generic topics can really be solved at this level.
>>>
>>>>
>>>>> what kinds of relations are supported ?
>>>> Single-valued references are mapped to CDOID columns in the table
>>>> of the referencing EClass.
>>>> Multi-valued references are mapped to the join tables I mentioned
>>>> before.
>>>> Was this what you asked for?
>>>>
>>>>>
>>>>> What about Lobs ? is there support for large objects ?
>>>> In which context? For mapping multi-valued references? This is
>>>> planned via
>>>> org.eclipse.emf.cdo.server.internal.db.ToMany.LIKE_ATTRIBUTE S. I'd
>>>> make querying even harder.
>>>>
>>>>>
>>>>> We would at least need to supply not null constraints
>>>> That could make a good Bugzilla (A) ;-)
>>>>
>>>>> on fields and ManyToOne relations,
>>>> See my above concerns. A separate Bugzilla (B) could be good to
>>>> discuss these concerns.
>>>>
>>>>> field lengthes for character strings,
>>>> Fits well into the Bugzilla (A).
>>>>
>>>>> plus I have to dive into the validation problem. plus i need
>>>>> something for unique key constraints and indexes.
>>>> What is the validation problem? The one Simon solved via OCL?
>>>> Unique key constraints and indexes could go into (A) as well.
>>>>
>>>> One general comment to all this mapping stuff: As you correctly
>>>> analyzed in another thread, CDO is not mainly about providing a new
>>>> O/R mapping solution. Hibernate will probably always be better here
>>>> and I didn't plan to compete with it. CDO is more focused on
>>>> providing a stable and efficient 3-tier solution (client /
>>>> repository / store) with distributed shared model semantics (remote
>>>> update notifications) and an auditing mode. The store even doesn't
>>>> need to be a relational database.
>>>>
>>>> I think it's time for me to dig into the Hibernate code and work
>>>> with Martin to develop a HibernateStore for the CDO storage framework.
>>>>
>>>> Regards,
>>>> Eike Stepper
>>>> ----
>>>> http://wiki.eclipse.org/CDO
>>>> http://wiki.eclipse.org/Net4j
>>>>
>>>>
>>>>>
>>>>> Thomas
>>>>>
>>>>> Eike Stepper schrieb:
>>>>>> Hi Thomas,
>>>>>>
>>>>>> A CDOSession has a setReferenceChunkSize() method which you can
>>>>>> call to limit the number of objects (ids) to load on collection
>>>>>> read accesses. Since read access (loading) is handled by the
>>>>>> CDOSession all CDOViews on that session share this setting. We
>>>>>> are currently discussing to provide an additional session
>>>>>> property: InitialReferenceChunkSize. Then you could even
>>>>>> configure to load nothing on the first access (of the source
>>>>>> object) and max n targets on subsequent reference accesses. At
>>>>>> the moment I'd suggest to set a value of 10-100 so that you're
>>>>>> shielded against huge collections.
>>>>>>
>>>>>> Regards,
>>>>>> Eike Stepper
>>>>>> ----
>>>>>> http://wiki.eclipse.org/CDO
>>>>>> http://wiki.eclipse.org/Net4j
>>>>>>
>>>>>>
>>>>>>
>>>>>> Thomas schrieb:
>>>>>>> Once again..
>>>>>>> Another thing coming to my mind is about the object graph.
>>>>>>> Suggest I have a Object Person with a Collection of Adresses.
>>>>>>> when I query for the person did I get it right that the Adresse
>>>>>>> are only loaded when I try to access them ? That would be the
>>>>>>> main decision factor for me. I have expensive objects and the
>>>>>>> more the could be lazy loaded the better my ui handling would be.
>>>>>>>
>>>>>>> Regards Thomas
>>>
>>>
Re: [CDO] is it what I want ? [message #110013 is a reply to message #109697] Wed, 30 January 2008 13:13 Go to previous messageGo to next message
Eclipse UserFriend
Originally posted by: tom.eiswind.de

HI Eike,

Im almost fine with that, but I would prefer to see the version not part
of the primary key. I know this makes an additional column, but then you
can join solely on the single column surrogate key, thats all what its
about. Makes joining very efficient.

Thomas

Eike Stepper schrieb:
> Thomas schrieb:
>> [stuff deleted]
>>
>>> why is the version part of the primary key ? that doesnt make sense
>>> to me. maybe you have reasons but i would expect that the db has only
>>> a single version stored. and again here pain in joining. CDO is
>>> basically capable of auditing (retrieving historical states of the
>>> overall model). I guess it's a similar effect like the one the new
>>> Temporality project announces.
>>
>> Ok then you have mutliple versions. But I would (personal taste ?)
>> prefer a single column surrogate primary key in any case. There are
>> some techniques on versioning (take three add columns columns, a group
>> id that groups the versions a counter/timestamp and a boolean, set the
>> boolean true for the current version, put a unique constraint on
>> group_id and version) timestamp makes problems on oracle as it not
>> finegrained enough for have load, so i prefer a counter or a mix of
>> both of it. its just the idea of having a clean surrogate key that i
>> always prefer.
> I'm not sure if I completely understand what you're saying about
> versioning technique, but I'm sure you've been a DB expert before you
> started modeling ;-)
>
> The current structure of the internal columns of CDO is carefully
> chosen. There's no redundancy and all of the following operations are
> possible efficiently:
> a) loadLatestRevision (revised==null)
> b) loadRevisionByVersion (version == v)
> c) loadRevisionByTime (revised == UNSPECIFIED_DATE || revised >=
> timeStamp) && timeStamp >= created
> d) lockForWrite (set revised = now)
>
> As I said these structures are optimized for the repository access
> (defined by the IStore API) and not for manual querying (although this
> was a secondary requirement).
>
>> [stuff deleted]
>>
>> Hmm Eike, dont know if I should open bugs on this if we dig into
>> teneo. Why put so much effort in there when we already have
>> (nearly)everything we need at hand ?
> Agreed ;-)
>
>>
>> Regarding the task force I think I can try to support you. I just dont
>> know how much time I can put in there, can be that I have a new
>> project next week, can be that I have lots of time to spent in february.
> I'm also about to start into a new customer project until beginning of May.
>
> Regards,
> Eike Stepper
> ----
> http://wiki.eclipse.org/CDO
> http://wiki.eclipse.org/Net4j
>
Re: [CDO] is it what I want ? [message #110051 is a reply to message #109705] Wed, 30 January 2008 13:15 Go to previous messageGo to next message
Eclipse UserFriend
Originally posted by: tom.eiswind.de

Eike Stepper schrieb:
> Thomas schrieb:
>> Hi Eike,
>>
>> Be sure to have annotations and entitymanager too.
> Got them ;-)
>
>>
>> I tried to migrate my ecore from yesterday with new emf project,
>> native CDO. installed the latest integration build, as the build
>> scripts are unix only.
I tried to build the sdk features.
There seem to be some shell scripts in there ?

> You don't need build scripts. BTW. which scripts do you refer to?
> Just check out everything with All.psf.
> The migrator doesn't have any other CDO/Net4j dependencies. Just
> right-click org.eclipse.emf.cdo.migrator and export it as deployable
> plugin to your eclipse installation. restart and it should be there.
OK Ill try to export the migrator

>
> DTH?
>
> WRT. the exception below, what is test.cdo?
> --> "Resource '/test.cdo' does not exist. "

test.cdo is the project name i gave in the wizard.
Re: [CDO] is it what I want ? [message #110063 is a reply to message #110013] Wed, 30 January 2008 13:19 Go to previous messageGo to next message
Eclipse UserFriend
Originally posted by: stepper.sympedia.de

Thomas schrieb:
> HI Eike,
>
> Im almost fine with that, but I would prefer to see the version not
> part of the primary key. I know this makes an additional column, but
> then you can join solely on the single column surrogate key, thats all
> what its about. Makes joining very efficient.
Do you mean an additional technical key, i.e. an automatically assigned
(long) integer number that has no association with the (also technical)
CDOID which is at least visible at the client side? Just to circumvent
joining via two columns?

Regards,
Eike Stepper
----
http://wiki.eclipse.org/CDO
http://wiki.eclipse.org/Net4j


>
> Thomas
>
> Eike Stepper schrieb:
>> Thomas schrieb:
>>> [stuff deleted]
>>>
>>>> why is the version part of the primary key ? that doesnt make sense
>>>> to me. maybe you have reasons but i would expect that the db has
>>>> only a single version stored. and again here pain in joining. CDO
>>>> is basically capable of auditing (retrieving historical states of
>>>> the overall model). I guess it's a similar effect like the one the
>>>> new Temporality project announces.
>>>
>>> Ok then you have mutliple versions. But I would (personal taste ?)
>>> prefer a single column surrogate primary key in any case. There are
>>> some techniques on versioning (take three add columns columns, a
>>> group id that groups the versions a counter/timestamp and a boolean,
>>> set the boolean true for the current version, put a unique
>>> constraint on group_id and version) timestamp makes problems on
>>> oracle as it not finegrained enough for have load, so i prefer a
>>> counter or a mix of both of it. its just the idea of having a clean
>>> surrogate key that i always prefer.
>> I'm not sure if I completely understand what you're saying about
>> versioning technique, but I'm sure you've been a DB expert before you
>> started modeling ;-)
>>
>> The current structure of the internal columns of CDO is carefully
>> chosen. There's no redundancy and all of the following operations are
>> possible efficiently:
>> a) loadLatestRevision (revised==null)
>> b) loadRevisionByVersion (version == v)
>> c) loadRevisionByTime (revised == UNSPECIFIED_DATE || revised >=
>> timeStamp) && timeStamp >= created
>> d) lockForWrite (set revised = now)
>>
>> As I said these structures are optimized for the repository access
>> (defined by the IStore API) and not for manual querying (although
>> this was a secondary requirement).
>>
>>> [stuff deleted]
>>>
>>> Hmm Eike, dont know if I should open bugs on this if we dig into
>>> teneo. Why put so much effort in there when we already have
>>> (nearly)everything we need at hand ?
>> Agreed ;-)
>>
>>>
>>> Regarding the task force I think I can try to support you. I just
>>> dont know how much time I can put in there, can be that I have a new
>>> project next week, can be that I have lots of time to spent in
>>> february.
>> I'm also about to start into a new customer project until beginning
>> of May.
>>
>> Regards,
>> Eike Stepper
>> ----
>> http://wiki.eclipse.org/CDO
>> http://wiki.eclipse.org/Net4j
>>
Re: [CDO] is it what I want ? [message #110076 is a reply to message #110051] Wed, 30 January 2008 13:21 Go to previous messageGo to next message
Eclipse UserFriend
Originally posted by: tom.eiswind.de

Ok, exported the migrator plugin from the current source, still the same
exception... ?

I do "new emf project", select "Ecore model (CDO native)", select my
ecore from yesterday, press finish, then it fails.

>> WRT. the exception below, what is test.cdo?
>> --> "Resource '/test.cdo' does not exist. "
>
> test.cdo is the project name i gave in the wizard.
Re: [CDO] is it what I want ? [message #110101 is a reply to message #110063] Wed, 30 January 2008 13:22 Go to previous messageGo to next message
Eclipse UserFriend
Originally posted by: tom.eiswind.de

Exactly.

Eike Stepper schrieb:
> Thomas schrieb:
>> HI Eike,
>>
>> Im almost fine with that, but I would prefer to see the version not
>> part of the primary key. I know this makes an additional column, but
>> then you can join solely on the single column surrogate key, thats all
>> what its about. Makes joining very efficient.
> Do you mean an additional technical key, i.e. an automatically assigned
> (long) integer number that has no association with the (also technical)
> CDOID which is at least visible at the client side? Just to circumvent
> joining via two columns?
>
Re: [CDO] is it what I want ? [message #110113 is a reply to message #110051] Wed, 30 January 2008 13:24 Go to previous messageGo to next message
Eclipse UserFriend
Originally posted by: stepper.sympedia.de

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

Thomas schrieb:
> I tried to build the sdk features.
> There seem to be some shell scripts in there ?
Not that I know about and I'm the author of all files under
/cvsroot/modeling/org.eclipse.emf/org.eclipse.emf.cdo ;-)

There are lots of scripts under
/cvsroot/modeling/org.eclipse.emf/org.eclipse.emf.cdo.*relen g *but
you shouldn't bother with these.

>
>> You don't need build scripts. BTW. which scripts do you refer to?
>> Just check out everything with All.psf.
>> The migrator doesn't have any other CDO/Net4j dependencies. Just
>> right-click org.eclipse.emf.cdo.migrator and export it as deployable
>> plugin to your eclipse installation. restart and it should be there.
> OK Ill try to export the migrator
>
>>
>> DTH?
>>
>> WRT. the exception below, what is test.cdo?
>> --> "Resource '/test.cdo' does not exist. "
>
> test.cdo is the project name i gave in the wizard.
Which wizard? Can you generate a normal Ecore model (w/o CDO)?
I just tried the CDO Migrator to verify Stefan's model and it worked
like a charme.

Regards,
Eike Stepper
----
http://wiki.eclipse.org/CDO
http://wiki.eclipse.org/Net4j



--------------090805030209020307070306
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">
Thomas schrieb:
<blockquote cite="mid:fnpta3$bra$2@build.eclipse.org" type="cite">I
tried to build the sdk features.
<br>
There seem to be some shell scripts in there ?
<br>
</blockquote>
Not that I know about and I'm the author of all files under <br>
Re: [CDO] is it what I want ? [message #110126 is a reply to message #110101] Wed, 30 January 2008 13:29 Go to previous messageGo to next message
Eclipse UserFriend
Originally posted by: stepper.sympedia.de

Thomas schrieb:
> Exactly.
Ok, I added an enhancement request just that we don't forget about this:
https://bugs.eclipse.org/bugs/show_bug.cgi?id=217083

I'd like to start with Hibernate first ;-)

BTW. if the DBStore was able to support non-auditing mode it would do so
with a single CDOID PK column.

Regards,
Eike Stepper
----
http://wiki.eclipse.org/CDO
http://wiki.eclipse.org/Net4j


>
> Eike Stepper schrieb:
>> Thomas schrieb:
>>> HI Eike,
>>>
>>> Im almost fine with that, but I would prefer to see the version not
>>> part of the primary key. I know this makes an additional column, but
>>> then you can join solely on the single column surrogate key, thats
>>> all what its about. Makes joining very efficient.
>> Do you mean an additional technical key, i.e. an automatically
>> assigned (long) integer number that has no association with the (also
>> technical) CDOID which is at least visible at the client side? Just
>> to circumvent joining via two columns?
>>
Re: [CDO] is it what I want ? [message #110139 is a reply to message #110076] Wed, 30 January 2008 13:30 Go to previous messageGo to next message
Eclipse UserFriend
Originally posted by: stepper.sympedia.de

Thomas schrieb:
> Ok, exported the migrator plugin from the current source, still the
> same exception... ?
>
> I do "new emf project",
Between this and the next step I usually copy the .ecore file into the
model folder of the new plugin. Have you done that, too?

> select "Ecore model (CDO native)", select my ecore from yesterday,
> press finish, then it fails.
>
>>> WRT. the exception below, what is test.cdo?
>>> --> "Resource '/test.cdo' does not exist. "
>>
>> test.cdo is the project name i gave in the wizard.
Re: [CDO] is it what I want ? [message #110146 is a reply to message #110113] Wed, 30 January 2008 13:34 Go to previous messageGo to next message
Eclipse UserFriend
Originally posted by: tom.eiswind.de

I used the File New EMF Project wizard.
Normal Ecore model works fine.

I dont see the CDO in the context menu (as it was on my 3.3
installation) any more.

Thomas
Re: [CDO] is it what I want ? [message #110158 is a reply to message #110139] Wed, 30 January 2008 13:41 Go to previous messageGo to next message
Eclipse UserFriend
Originally posted by: tom.eiswind.de

Sorry Eike I dont get it.
At this point there I have no new plugin project.

Eike Stepper schrieb:
> Thomas schrieb:
>> Ok, exported the migrator plugin from the current source, still the
>> same exception... ?
>>
>> I do "new emf project",
> Between this and the next step I usually copy the .ecore file into the
> model folder of the new plugin. Have you done that, too?
>
>> select "Ecore model (CDO native)", select my ecore from yesterday,
>> press finish, then it fails.
>>
>>>> WRT. the exception below, what is test.cdo?
>>>> --> "Resource '/test.cdo' does not exist. "
>>>
>>> test.cdo is the project name i gave in the wizard.
Re: [CDO] is it what I want ? [message #110177 is a reply to message #110158] Wed, 30 January 2008 13:46 Go to previous messageGo to next message
Eclipse UserFriend
Originally posted by: stepper.sympedia.de

Ok, once more ;-)

1) New Wizard "Empty EMF project" (this is the plugin project that I meant)
2) Create/copy an .ecore file to the model folder
3) Use the New Wizard "EMF Model" on the .ecore file and choose the
importer "Ecore model (CDO native)"
4) Adjust other genmodel settings (optional)
5) Generate the genmodel
6) Use the generated model plugin with CDO
7) Use the generated edit plugin with the CDO UI (optional)

Does that work?

Regards,
Eike Stepper
----
http://wiki.eclipse.org/CDO
http://wiki.eclipse.org/Net4j



Thomas schrieb:
> Sorry Eike I dont get it.
> At this point there I have no new plugin project.
>
> Eike Stepper schrieb:
>> Thomas schrieb:
>>> Ok, exported the migrator plugin from the current source, still the
>>> same exception... ?
>>>
>>> I do "new emf project",
>> Between this and the next step I usually copy the .ecore file into
>> the model folder of the new plugin. Have you done that, too?
>>
>>> select "Ecore model (CDO native)", select my ecore from yesterday,
>>> press finish, then it fails.
>>>
>>>>> WRT. the exception below, what is test.cdo?
>>>>> --> "Resource '/test.cdo' does not exist. "
>>>>
>>>> test.cdo is the project name i gave in the wizard.
Re: [CDO] is it what I want ? [message #110190 is a reply to message #110146] Wed, 30 January 2008 13:48 Go to previous messageGo to next message
Eclipse UserFriend
Originally posted by: stepper.sympedia.de

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

Thomas schrieb:
> I used the File New EMF Project wizard.
> Normal Ecore model works fine.
>
> I dont see the CDO in the context menu (as it was on my 3.3
> installation) any more.
It's in the context menu of the genmodel file, if you have already one.
If it's not, then please check if the following dependencies of the
migrator plugin are satisfied:



Regards,
Eike Stepper
----
http://wiki.eclipse.org/CDO
http://wiki.eclipse.org/Net4j



--------------020408060102070908060401
Content-Type: multipart/related;
boundary="------------070401020102050108070901"


--------------070401020102050108070901
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">
Thomas schrieb:
<blockquote cite="mid:fnpudg$pg1$1@build.eclipse.org" type="cite">I
used the File New EMF Project wizard.
<br>
Normal Ecore model works fine.
<br>
<br>
I dont see the CDO in the context menu (as it was on my 3.3
installation) any more.
<br>
</blockquote>
It's in the context menu of the genmodel file, if you have already one.<br>
If it's not, then please check if the following dependencies of the
migrator plugin are satisfied:<br>
<br>
<img src="cid:part1.00070207.08090103@sympedia.de" alt=""><br>
<br>
Regards,<br>
Eike Stepper<br>
----<br>
<a class="moz-txt-link-freetext" href="http://wiki.eclipse.org/CDO">http://wiki.eclipse.org/CDO</a><br>
<a class="moz-txt-link-freetext" href="http://wiki.eclipse.org/Net4j">http://wiki.eclipse.org/Net4j</a><br>
<br>
<br>
</body>
</html>

--------------070401020102050108070901
Content-Type: image/jpeg;
name="moz-screenshot-7.jpg"
Content-Transfer-Encoding: base64
Content-ID: <part1.00070207.08090103@sympedia.de>
Content-Disposition: inline;
filename="moz-screenshot-7.jpg"

/9j/4AAQSkZJRgABAQAAAQABAAD/2wBDABALDA4MChAODQ4SERATGCgaGBYW GDEjJR0oOjM9
PDkzODdASFxOQERXRTc4UG1RV19iZ2hnPk1xeXBkeFxlZ2P/2wBDARESEhgV GC8aGi9jQjhC
Y2NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2Nj Y2NjY2P/wAAR
CAEFAcUDASIAAhEBAxEB/8QAHwAAAQUBAQEBAQEAAAAAAAAAAAECAwQFBgcI CQoL/8QAtRAA
AgEDAwIEAwUFBAQAAAF9AQIDAAQRBRIhMUEGE1FhByJxFDKBkaEII0KxwRVS 0fAkM2JyggkK
FhcYGRolJicoKSo0NTY3ODk6Q0RFRkdISUpTVFVWV1hZWmNkZWZnaGlqc3R1 dnd4eXqDhIWG
h4iJipKTlJWWl5iZmqKjpKWmp6ipqrKztLW2t7i5usLDxMXGx8jJytLT1NXW 19jZ2uHi4+Tl
5ufo6erx8vP09fb3+Pn6/8QAHwEAAwEBAQEBAQEBAQAAAAAAAAECAwQFBgcI CQoL/8QAtREA
AgECBAQDBAcFBAQAAQJ3AAECAxEEBSExBhJBUQdhcRMiMoEIFEKRobHBCSMz UvAVYnLRChYk
NOEl8RcYGRomJygpKjU2Nzg5OkNERUZHSElKU1RVVldYWVpjZGVmZ2hpanN0 dXZ3eHl6goOE
hYaHiImKkpOUlZaXmJmaoqOkpaanqKmqsrO0tba3uLm6wsPExcbHyMnK0tPU 1dbX2Nna4uPk
5ebn6Onq8vP09fb3+Pn6/9oADAMBAAIRAxEAPwDupp0gTdISATgAAkk+wHJp Y5UlQOhypqlq
iSSW6+TC8sgfI2SBCvB5yePb8azoLmS0cCSR4kwco6bsNkE/XqxJH8sCmoyb 8hNxSOgzUE99
aWzhLi6hiYjIV5Apx681HaXMlwHLxCMKcAhw2f8AD8ao5/4q/wD7cP8A2pRC 0ldBK6NeKaOe
MSQyJIh6MhBB/GnZrn5JV07Xr14YwEaxNzIg43urHn24z+eaS11G8b7FMGnu PtDATRfZSiRh
udytt6L05Jz7VXJ2J5joc0ZrnY7rUJINUuhfEC0mkEcXlKVITnB4ycjjqMe9 SS6tJPdWkKtL
bpJbC5doY/Nc54C/dOB3zj8qORhzo3s0Zrm59Q1E6fbqHa3na9W285oceYhB w+xhxnjj2q02
oT2F7dW8rm6WO1N0jMArDHBU4GD0znH50cjDmRsSTRxbfMkRN7BV3EDcT0A9 6dmuXvPtUsGj
XU92ZBNdROYvLUKpbkY78DI5JzU0mp3U73zwyTI1vKY4oY7YyK5XruYD+Lpw Rj3p8gc50WaM
1hfar271i3gWeS0jazE7xhFLBicYyw46jt2qP+17r7D5WV+0/bfsPn7eM/39 vr7dM/lS5GHM
jflmjgjMk0iRoOrOQAPxp2awtWm1HTtNu5UuhIoCGORlXepLAEEAbSMd+v8A Oi51CaXU7q1S
ea2W3RQDDbmUuzDOT8pwB6cZ9aOS4cxu5ozWE19qE1tp8jxTWqyFxcmKLc6E A7cKQSASM9D2
59b+mz+dbsftX2nbIy7jHsZcH7rD1H0Hbik42GpXL2aM03NGaQx2aM03NGaA HZozTc0ZoAdm
jNNzRmgB2aM03NGaAHZozTc0ZoAdmjNNzRmgB2aM03NGaAHZozTc0ZoAdmjN NzRmgB2aM03N
GaAHZozTc0ZoAdmjNNzRmgB2aM03NGaAHZozTc0ZoAdmjNNzRmgB2aM03NGa AHZozTc0ZoAd
mjNNzRmgB2aKbmigCvcQx3MLQzLujbGRkjvntWfNo0awslk3kF/lfJLAj8T1 H+fUaf8A31/3
w3+FH/fX/fDf4Vak1sS0mMijKFndy7sACx46dgPTk1XnsFlvheJcTQzeV5WU 2kFc57g96t/9
9f8AfDf4Uf8AfX/fDf4VMVy6Ib13K1tp8Fv55O6Z7j/XPKdxfrwR0xg4wB0q OHSoYnh3SzSx
wEmGKRgVjPYjjJx0GScVd/76/wC+G/wo/wC+v++G/wAKd2KyMPT9MeZtRFxL dRRS3b5iB2rI
uc56ZwehIIyK05rCKSSKWJmt5Yl2K8OB8v8AdIIII9scVZ/76/74b/Cj/vr/ AL4b/Cm5Ngkk
Uv7JtvIgiBkHkzCfdnLO47sT1zUr2MMl812+WZofIKHBUrnPSrH/AH1/3w3+ FH/fX/fDf4Ur
sLIzjosRa3BuroxW0geKIuCq4OQOmSB0GTwKkm0qGV5tss0Uc5BmijYBZD3J 4yM9DgjNXf8A
vr/vhv8ACj/vr/vhv8KLsLIrpYwx3y3aZVlh8gIMBQuc9Ki/sm28ieImQ+dM Z92cMjnupHTF
Xf8Avr/vhv8ACj/vr/vhv8KLsLIz59GguYp1uJZpZJwqtKxXcFBBCjAwBkZ6 VLcaeks7zRzT
W8kibJGhIG8ds5B5HYjmrf8A31/3w3+FH/fX/fDf4UXYWRWNhGsMMVtJLarD naIWGMHrkEEH
15Gc0+ytI7KN1jZmMkjSO7kZZj1PHH5VN/31/wB8N/hR/wB9f98N/hRdjsh2 aM03/vr/AL4b
/Cj/AL6/74b/AApAOzRmm/8AfX/fDf4Uf99f98N/hQA7NGab/wB9f98N/hR/ 31/3w3+FADs0
Zpv/AH1/3w3+FH/fX/fDf4UAOzRmm/8AfX/fDf4Uf99f98N/hQA7NGab/wB9 f98N/hR/31/3
w3+FADs0Zpv/AH1/3w3+FH/fX/fDf4UAOzRmm/8AfX/fDf4Uf99f98N/hQA7 NGab/wB9f98N
/hR/31/3w3+FADs0Zpv/AH1/3w3+FH/fX/fDf4UAOzRmm/8AfX/fDf4Uf99f 98N/hQA7NGab
/wB9f98N/hR/31/3w3+FADs0Zpv/AH1/3w3+FH/fX/fDf4UAOzRmm/8AfX/f Df4Uf99f98N/
hQA7NGab/wB9f98N/hR/31/3w3+FADs0Zpv/AH1/3w3+FH/fX/fDf4UAOzRm m/8AfX/fDf4U
f99f98N/hQA7NGab/wB9f98N/hR/31/3w3+FADs0Zpv/AH1/3w3+FH/fX/fD f4UAOzRTf++v
++G/wooAtUVHI5XAHUgnJGf89aj81/7y/wDfH/16Vh3LFFV/Nf8AvL/3x/8A Xo81/wC8v/fH
/wBeiwXLFFV/Nf8AvL/3x/8AXo81/wC8v/fH/wBeiwXLFFV/Nf8AvL/3x/8A Xo81/wC8v/fH
/wBeiwXLFFV/Nf8AvL/3x/8AXo81/wC8v/fH/wBeiwXLFFV/Nf8AvL/3x/8A Xo81/wC8v/fH
/wBeiwXLFFV/Nf8AvL/3x/8AXo81/wC8v/fH/wBeiwXLFFV/Nf8AvL/3x/8A Xo81/wC8v/fH
/wBeiwXLFFV/Nf8AvL/3x/8AXo81/wC8v/fH/wBeiwXLFFV/Nf8AvL/3x/8A Xo81/wC8v/fH
/wBeiwXLFFV/Nf8AvL/3x/8AXo81/wC8v/fH/wBeiwXLFFV/Nf8AvL/3x/8A Xo81/wC8v/fH
/wBeiwXLFFV/Nf8AvL/3x/8AXo81/wC8v/fH/wBeiwXLFFV/Nf8AvL/3x/8A Xo81/wC8v/fH
/wBeiwXLFFV/Nf8AvL/3x/8AXo81/wC8v/fH/wBeiwXLFFV/Nf8AvL/3x/8A Xo81/wC8v/fH
/wBeiwXLFFV/Nf8AvL/3x/8AXo81/wC8v/fH/wBeiwXLFFV/Nf8AvL/3x/8A Xo81/wC8v/fH
/wBeiwXLFFV/Nf8AvL/3x/8AXo81/wC8v/fH/wBeiwXLFFV/Nf8AvL/3x/8A Xo81/wC8v/fH
/wBeiwXLFFV/Nf8AvL/3x/8AXo81/wC8v/fH/wBeiwXLFFV/Nf8AvL/3x/8A Xo81/wC8v/fH
/wBeiwXLFFV/Nf8AvL/3x/8AXo81/wC8v/fH/wBeiwXLFFV/Nf8AvL/3x/8A Xo81/wC8v/fH
/wBeiwXLFFV/Nf8AvL/3x/8AXo81/wC8v/fH/wBeiwXLFFV/Nf8AvL/3x/8A Xo81/wC8v/fH
/wBeiwXLFFV/Nf8AvL/3x/8AXo81/wC8v/fH/wBeiwXLFFQLI5IG5f8AvnH9 alRg6Bh0IzSG
OooooAilGWH+6f5iua1ud49Udd1x5Ysy+IpSoVt2Nxweg/H6V1DDJ/Cqz2UE lwbh4w0hjMRJ
J5UnOMdKqLsS1cyG1WS2WG3SI3swgWR3TdhvTGFPX3wKWTWmDO0doTFHIkbl 32sGb/ZwemfW
r40ayVYwkbp5alFKSurbSc4yDkj2NQajokdwA9uoSbzEdiXYKdp9BwTjvirv Fsi0kiIavvCD
yCPMneDh+m0Hnp7VDpmpySC2t0hLgwec8k0+WC7iD/DyfyrTGj2Qm80REPvM n+sbAY9TjOKf
b6ZaWrq8MW1lj8oHcT8uc45PrSvGw7SuZUev7ojO1lKLfYziQBu3TOVA59ia k064uJ9XnE6+
WvkRssYkLKM556Dmr6aTZxqyLEfLYEGMuxTnrhc4H4CnWum21nI0kCMHdQpZ pGY4HQck0c0e
gWkYFoL2e5meJ7jEV3IHdpcpsA+7tz1/D8ak0/V3i0z95G0rxWomLs/LckY6 e3Wt+Czht1kW
JNolcu/JOSepqs2h6eyKnkEKE8vAkYZXOcHB5/GnzLZhyu9yjJrTAu0dsGij kSJ2MmDubHQY
5Az61Lqt2i2b7RcKUkRSVDR9WA4YjBH0ou9F+0XS+XFHFEHR2cSsWbb/ALGN ue2cnitO5tYr
qLyp03JkHGSOQcjpReOjC0tUY8etM0oDWuI2neAFZMsWUemO/wBataVf/wBo xO5RI2Q4ZA5L
KfRgQMfrU40mzGMREYlMow7cOep61LbWUNqZGiVt0hBdncuzY6ckk0rxsOzu O20bal20bai5
RFto21Lto20XAi20bal20baLgRbaNtS7aNtFwIttG2pdtG2i4EW2jbUu2jbR cCLbRtqXbRto
uBFto21Lto20XAi20bal20baLgRbaNtS7aNtFwIttG2pdtG2i4EW2jbUu2jb RcCLbRtqXbRt
ouBFto21Lto20XAi20bal20baLgRbaNtS7aNtFwIttG2pdtG2i4EW2jbUu2j bRcCLbRtqXbS
MCqkhSxAzgdTRcDKubtgsSB3SSSVxmNVOVQnP3jgcDrU2kzSXWmwzSnLsDk4 x3NN08Q39s/n
Wh2rK+POjHdieAfToff6VSt2nXUHjguFitUuCr4iVVJJ4ReMk+p/w5rcmMG3 e5tqPmH1qWIY
iQf7IpAvIp68KB7VLKFooopDEopap6o9yli7WgYyZXOwAsFyNxUHgkDOB+h6 UAW6KyYtVjii
gija61GSYOUKxqr/ACkZDA7QpGe4HTHXq2fxNp8DW6szZmRZOWRSik4GQzAn vwoJ4+lAGxRW
bPqimC7dIrkQQI+65QJjK9QoY5JBB6jGRVa11SZtTuvtCXC20ckcEYIj25YK Qxwd2SSPbBHG
c0LUDborPvdSaLSr67t4WdrYOFBxhivU9RwDnPfg4qm+ty293I09rceStokz xqqExfM+5ic+
gHAJPoOtAG5RWY+v2Saqun7sykhSd6AAkZAwW3HqOQCOevWmXl+8GpTRvLIs KxwECNVJ3NIy
9x0PAPt05oA1qKxrvXXW0lmtLKaURzrDvJj2sd4VsDeCPTnHJHar91fC1ihZ oJXlmYIkKbd5
bBOOTjgA98cUAWqKxG1Se61Swgt47mKJ/Mab5Y8goQCpyTwM8465GD1q3e6t HZ3Dw/ZrmZo4
hM5iUEKhJGeSP7vQc+meaANCisu31P8A0+eKVmdHuUih2gfLmIPz7dfzqQ6x ESqxW9xM5eRN
iKuQEbazckDGce5z0oA0KKpWuq2d0lvtnSOW4jEkcLuBIQRn7ufr+VU11+GO 2jYQ3lwotluH
k2JlUOfmbkDPB4A+goA2aKqQaglxezW0UMjCHAeXK7QSAQMZ3dD6YqC51u3t Wu/NilEdqVDy
HaFLMFIUEnvuHJ4HcigDSorKg163uYo3toZp3csDHEUYqFxkkhtuOR0JPP1p 8euW0lq9wqTb
EtRdEFRnYd3HXr8poA0qKy21eOGWRQlzO7TrEsaqnDGPeAORxjuT19qYviTT zdz25cgwhyzb
lPKfeG0Hd2PVcHHHagDXorMsb+e61aeJ4ZoI1t43EUoXIJZucgnsB3qtYatO Y55rqG5Z5Lpo
ILcCP+EnhcH0UkljjjigDcorOTWI5JbeJLa4MsxcFMKDGUIDbuccZ7Zz2zxV bUtVuoJ9Rt4o
HVYLIzJP8pAbDc8npwB06g9sUDSubVFZP9vW8VtNJdRzQGFEciUKu8McKRzg ZI74x3xVi11e
1udNkv1bbDFu8z5lfbt5PKkg8ehNAlqXqKzG1uKKGR7i0uoGTYfLZVLMHbaC NpIPPbOfamz6
/bWtu8lzFLBIsoiMUpRW3EZHzFtuMc53e3XigDVorNttagu3RbeGaQNCJiyl NqjLDBO7GcqR
xkfhzVQeJBcfZjY2skwe58iQB42x8hbgh9pPTueh74oA3aKy11ZFAjiiuruZ pJQEUIGwjYY8
kDAOAOcnI96SXxBbxrvS3uZkEAuHZEGEQkjJyQeNp460AatFVry9S0jiPlyT PMwSOOPG5zgn
jJA6AnkjpWa2qT3WqWEFvHcxRP5jTfLHkFCAVOSeBnnHXIwetHkBt0Vi6lqt 1BPqNvFA6rBZ
GZJ/lIDYbnk9OAOnUHtipP7YR4WEiXVvIhhJyiZdXbaCAc8E5znBHoDQDNai qllfrevN5cMi
xxuU8xiuGIOCAASR07gVDFrMUtwIhb3CoZXgEzKNm9c8dc9jzjHvnigDRorH 0/WQdKWW68x5
YrJbqVgo+YHPT3+U1NPrUMMhX7PcPGrpG8qqNqs+MA5Of4gcgY9807a2A0qK oXOp2nlSeVdh
milRJBAyMyEuFwQc4569+uOabDrMUt0sIt7hVaZ4FmZV2F1zkdc/wnnGPx4p AaNFLRQAlFLR
QAlFLRQAlQfYrXzPM+zQ+Zu3bvLGc+ufWrFFACUUtFABRRRQAVFcRNNCUSaS BuCJI8bh+YI/
MVLRQBiSaNIt9bNBc3CALM0tyCm8uxTqCMcgHoOMdqsro8cTxPaXNxamOJYj 5ZU71HI3blPq
eRg8mtKigDObSEKXUQubhbe5Vw0A27VLfeIO3IOST1xk9KZd2Hl2l4lvFJPJ dkAjcoCHaFDZ
OOBgHjJ9K1KKAKi2EX9lmwYsY2iMbHPJyME/U81CdIieOZJZ5pGmt/szu20H b83PAAz8x7el
aNFALQoppoiu2nguriIOVMkS7SkhAxk5UkcADgjpRdaXBdTvLI0gZxGDtIx8 j7x29TzV6igD
Ll0SKaS4kluZ2km2gPhAUCtuXGF5wcfez/OrN1Yi6ihVp5UlhYOkybd4bBGe RjkE9sc1booA
pW+mQwSwyh5GkiDjcxGXLkFieOuR2wKq3elyXmrTu8s0NtJbJE3lsv7z5n3K cgkcEcjB561r
0UAZ0ukQu0jRyywyNKsyum3KMFCcAgjGB3B61UutMazhjNmL+adWkbfFJECd 53MG34GCcdBk
YrcooAqaXatZaXa2rkF4olRiDxkDmq8eiW0dtJAHl2vai1JJGdg3c9OvzGtO ih6gtCimmouo
JeNNLI0aFI0YJhAcZwQoY9O5Iom0uCZboM8gNy6yFlbBRlChSvHbaDzmr1FA Gc+ls/lu2oXZ
mj3ASjywxU4ypwuMcDtn3qlbaD5ulW8NxNPbSfZBbzrEyncuOhJB6ZPIPet6 igCgNKgFwJt8
m4TLNjIxuEez06Y/WmjSIx56C5uPs0+8vb5XZlvvEHbuHJJ69a0aKAKNlpot Lh52uri4leNY
y0xXopJHQD1NNfSYTCESaaN1nadJVI3IzEk4yCMfMRgg8VoUUAUrfTIYJYZQ 8jSRBxuYjLly
CxPHXI7YFNu9Liu5ppGmmTzoDBIqbcMvOOoJBG49P1q/RQBQudJt7lpGd5Qz xpGCrAFdjFlY
cdQT9OOlSizD2UlrdTy3SSgqzSbQSCMY+UAVaooAxb7R5GsZFSe4ubh3hHmS MoZUWQHjAA45
Pqffipzo0Zjybq4Nx5om+05XzAwG3pt2428Yxj8a06KAM99JilWcTzzTNPAI HdtoJUFjngAZ
+Y9qYNFTG43ly03nCbzjs3bgu3pt24xx0rTooAzW0aIFXhubiCVXkYSRlScO 25l5UjGcds8d
aU6Pa+VNGpkVJbYWxAboo3c89/mPJrRooC5Uu7FLmKJfNkieFg0csZG5Tgju CDwSOR3ptvpk
MEsMoeRpIg43MRly5BYnjrkdsCrtFAFC70uK7mmkaaZPOgMEiptwy846gkEb j0/WifSoJ5Gd
3kBZYl4I6RvuHb161fooAp22nrBezXbTSSyygLlwg2qCSANqjPXvmqen6S6S tLdSzYW5lljh
JUoCzNhuBnOD0zj2zWxRQBkSeH4GtlgS5uYkFv8AZn2FcyJzgHKn1PTHWq1/ ps8t6sVtHdrC
8sUkrGSMQnYQc4+/nCgY6Z5966CijzAgvLVLyDyZCwXer5XrlWDD9RUC6XAv l4eT93cPcDkf
ebdkdOnzH9KvUUARW8PkW8cPmSSbFC75Gyze5Pc1LRRQAUUUUAFFFFABRRRQ AUUUUAFFFFAB
VWdPMvIY2ZwvlucK5XJBX0PuatVXf/kIQ/8AXKT+aUAZl/e21hdeVc+dFHt3 ea9zIAQOuMZz
2GPXjjK7tP7HF/en/wC/7/41k+I44LjZDd2rSQou8StI6xqTkc7SMnHHJ7+/ K295LCJnEgbM
5HlEcElQ2F75J/n0p1GoQ5mKN3KxdeLN2YIldtqK7lrtwQC2OACT0DHnAyAB 3Ki20527osdM
4vZTj7ue3u/5L0ydtWfULgXcUcIjimudkY83cyx/605K7geduOi59WxgJDqV 7Nc20A+zgkzC
VwjEN5bKPlGeM5PUnB9ccyndXKasW1tpzt3RY6ZxeynH3c9vd/yXpk7Rbac7 d0WOmcXspx93
Pb3f8l6ZO2nZavcPPam6ktBb3Nu9x8mQYlG3AJJwepycDp0FO/tO+l1mWC3t Q9rA6pIwCk8q
G3ZLgjr02nOOvoxFpbac7d0WOmcXspx93Pb3f8l6ZO0W2nO3dFjpnF7Kcfdz 293/ACXpk7c6
5uLm80NLuZ4fKmlgaONEO5P3q8M2eT+A5pYtQumnjtbRbO382W5yzRnA2OBn AIyTk559/YgW
NBbac7d0WOmcXspx93Pb3f8AJemTtFtpzt3RY6ZxeynH3c9vd/yXpk7atvql 3K1lLKscNtPG
pyImfzHOflDAjb0GCRg560aLqt5eRfab2FILWVQ0TnaoBJwFzvbJ5HOF57c0 AWltpzt3RY6Z
xeynH3c9vd/yXpk7Rbac7d0WOmcXspx93Pb3f8l6ZO2v/aV0LW+v/wBz9ntv NAg2HzCUyMls
4GcZxt6Ec1FPqeoWscqO1pNMBCyOiMqgO+3BG4+5Bzz6cUAXVtpzt3RY6Zxe ynH3c9vd/wAl
6ZO0W2nO3dFjpnF7Kcfdz293/JemTtqRajqUmrvapbpJDbskczqqjJKgluZM qOem1unX0W91
S4Wa5Nm1u8EFl9pBKljITvwAQQMfKP8APQCxaW2nO3dFjpnF7Kcfdz293/Je mTtFtpzt3RY6
ZxeynH3c9vd/yXpk7al9q9xDJKkCwsyxW7ruz1kkKnOD0x0/rVee71OS8t7f 7RAkkN95TskT
BZAYi4yu/wBzxk84PbFMDTW2nO3dFjpnF7Kcfdz293/JemTtFtpzt3RY6Zxe ynH3c9vd/wAl
6ZO2hDfXjzJbWUdpCZJLnLNGSBscAHAIyTnnnvn2LU1y8jtUu7iOB45rOS5S OMEMpQKcFiec
7uuBj3pDtrY0Vtpzt3RY6ZxeynH3c9vd/wAl6ZO0W2nO3dFjpnF7Kcfdz293 /JemTtTSLi/u
IHa/gEfQxsAqhgR6B3/PPOelY0llB/wiNpKLK2IjtQ7SkASRZUEsgxy2eeq8 45piWptLbTnb
uix0zi9lOPu57e7/AJL0ydottOdu6LHTOL2U4+7nt7v+S9Mna3UoYb60ZBbW l40R5S5bhMjO
TwcHBHp16iqJeC40vR7ZpDLDIYvNSbG5k2Nt3DJ6sB6596QGgttOdu6LHTOL 2U4+7nt7v+S9
MnaLbTnbuix0zi9lOPu57e7/AJL0ydtSzuJLXw/M8EbyeVLLHAqIXwokKrwO SAMdOwqrptys
Phu9Fu8iyrJcLEZVKMzZYjAYDJ7/AJ+lA7GqttOdu6LHTOL2U4+7nt7v+S9M naLbTnbuix0z
i9lOPu57e7/kvTJ209LFtY3s8duY4rU28DnBAUyMWGfqRt+vFU9NtopHtFKL uu7OR7w45Zwy
8t7glgPSh6CWpsRQuZkjmjdNyFspdSsARt4zgDqW75wAcddtj7HF/en/AO/7 /wCNVNOke4j0
64lGXa0JZ9vc7O+3jPpkfQ4+XTpvQCv9ji/vT/8Af9/8aPscX96f/v8Av/jV iikBX+xxf3p/
+/7/AONH2OL+9P8A9/3/AMasUUAV/scX96f/AL/v/jR9ji/vT/8Af9/8asUU AV/scX96f/v+
/wDjR9ji/vT/APf9/wDGrFFAFf7HF/en/wC/7/40fY4v70//AH/f/GrFFAFf 7HF/en/7/v8A
40fY4v70/wD3/f8AxqxRQBX+xxf3p/8Av+/+NH2OL+9P/wB/3/xqxRQBXss/ ZyCzNiRwCxJO
A5A5NVrf7RPbxzPdyqZFD7UVMDIzgZUn9as2X+ob/rrJ/wChtVSykC2FsOf9 Sn/oIoAm8qb/
AJ/bj8o//iaPKm/5/bj8o/8A4mjzR71R1i/S1sCWmWAysIlkZgu3J5OT6DJ/ CgC95U3/AD+3
H5R//E0eVN/z+3H5R/8AxNY9nrO6wiS2ZLycTG3DebhWwCdxYA/wgHgHk02x 1S58rylgM07z
TsRJLgIqvjAODnqAB0+lAG15U3/P7cflH/8AE0eVN/z+3H5R/wDxNUtEuWk0 azeVnd2iUszH
JJx3NXfNHvTegB5U3/P7cflH/wDE1HcfaILeSZLuVjGpfa6pg4GcHCg/rUnm j3qG9kDWFyOf
9S//AKCaQGnRRRQAUUUUAFV3/wCQhD/1yk/mlWKrv/yEIf8ArlJ/NKAFuHt3 VreeRP3g2FC+
CQ2QB+OD+RqOy0+CyBMYLSN96R8bj+P4D8qyPElrKXWXT7mG1uWVhIzSlWII wCFCkk8df9ke
ildO31NHMglUoqyFVkx8pHUZ7jj8KqXuxu3oJauw66tWnlZZIILi2kRVaOYn AIbOcEFTwSeg
OVAJOflIYpY/J22VpH5ahV2SH5AduQvydPvemdq9M/LJPfW1vAszy5R22p5a lyx9AFySeD09
DUS6tZMYAsrM1wSI1EbE5BAbIxlcE85xj8Kla7DM+y0e5jvXubq300+YhRo4 EMancVLlsg7z
94dvuj+8dt42fm3EVxNpti00e0CQtuZPu9CUzxl8dOg6bjtfbatZXU6wQSsz sGZcxsAwGASp
IwRyORxT21G2W8FqXbzcgHEbFVJGQC2NoPsTnketAEEdkFdn/sywR5WVpWVu WOVOT8nJB3kZ
/ur0ydsE+lG6ureS4srJokVw8JO5WZzGS3KdQQ/1wOmTiS51iP7M0lnmQrLG m5onCEM4U7Ww
A3U9CaedXtYQBPcb3Z5FURQOSdjYICjJJHf15PSgYq2pNzFcvp1iJ0AUShss g+XIB2Zxy/p0
HTcdrYrBEkaT+y9PR5CDIynknKknOznB3EZ7qvTJ2zR6naSyxRxO8hlQOpSN mUKehLAYXOD1
Ip1pqFteOywOzFRnJjZQw9VJGGHuMigRElq32r7UdPsluHADyh8vj5cjOzJ/ i/75Xpk7W29k
IIvKj02wijZld0jbA3fLzjYMkfNj/dXpn5Zv7StfNlj8xv3IJkfy28tcdcvj bkemaiGtWBgk
mMrose3cJIXRsMcKdpGSCe+MUADWhmuY7mfTrFp0xiUtuZPu9CUzxl8dOg6b jtfDDLHt22Np
H8iodkh4UY4HydBl8D2HTcdqrqlo1wkAaTe2OsLgKSMgMcYU47HB5HrTptRt YLk28shWQR+Y
3yHCrz8xOMAfKepoAr29gkCBY9L0+JW2lhGcDgqf7gzglyPovTJ2ve2acEXG n2Th2V3DPuyw
2jPKckfNj/dXpk7U/tmy8vfmfltoT7NJvJxnhNu4jAPOMcU+TVbOO5EDyMHy oJ8ttqlugZsY
UnjgkHketABHFKro/wBitEYZJKyHI3FS+Pk7nd9dq+p2kUMqeV/oVonlrtXb IfkU7cgfJ0+9
6Z2r6/LIL+2bZiX78rQr8p5dc5HT/ZP5VAutWL26TpJK6SHCBYJCz8ZJChck e4GKACztDZgi
206ytg+C4hbbn7ueiDOMvj6DpuO2vaaUIYrVJ7K1uHtwqxyzMGdANvAPljp8 2On3V/vHFxtS
tVuRbl2EnGT5bbVJGQGbGFOOxIPI9aktLyG9iMkHmFB0LxMmfcbgMj3FHmBV msFuiDd6Xp8p
JDMXO/nCgnlOeNw/4CvTPyyPbvcAi4sLNxIqrIGfdkAqccpyAS+PoOm47c99 UvV0i0uzcWQn
mj3rbmJszEjIRPnzntnB9cCtDVLiS2thIt3a2vOC1ypYE9lGGXn8/pQ9AGw2 00dykwtoEKxL
EFWY7Y1ypO0bB/tfXYvTJw9IpfkzZWi4ffxITtY43MPk6/NJz3wP7x2xS3t0 LCyKxLDd3ZRN
sgLCMlSzZGQTgA8ZFPs9Q36a9zdbUaEukpUcZQkEj64zj3oASG1MUQiXTrGO NmDsiNxuypJx
s5IO7B/2V6Z+Vps5DHMqWttbPcY86SCTDn7uTnZyeX5PoOm47W2epyto9xe3 caq8DS7kT0Qk
Y+vFP067unuJba+8oyrEkwMSlRhsjGCTyCp5756CgCWCCUTQu8EMSxRGMCN9 2M7OBlQcZBHU
dASDn5blYlrqd9P5Z2wf6VA09sNjDaFI+VuechhyMY9DWrazrdWsNwgIWVA4 B9CM0BsTUUUU
AFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAV7L/UN/11k/9Das603NZ25UFh5S jjnkAA1o2X+o
b/rrJ/6G1D2No7FntYGYnJJjBJoAp7X/ALjflUb2/mSxyPExaMkoeeCRj+VX /wCzrL/nzt/+
/S/4Uf2dZf8APnb/APfpf8KAMqfTYZy7SQPudgxZWZSCBgEEHg444pn9j23l ogt5FCMzLtdw
csctyDkg9x0rY/s6y/587f8A79L/AIUf2dZf8+dv/wB+l/woAyV0q2VFRbZg qqiAZbgIcqPw
NTw24gVliiZQzFz1PJOT+pq//Z1l/wA+dv8A9+l/wo/s6y/587f/AL9L/hQB U2v/AHG/Korv
ctncFgVHlMOeOSCBWh/Z1l/z52//AH6X/ClSxtEYMlrArA5BEYBFAFiiiigA ooooAKrv/wAh
CH/rlJ/NKsVXf/kIQ/8AXKT+aUAQ6hpyXatIhKXQQrHJuIweccdO/pVWy064 eNzeMY0d93lD
G77oXk5IwRnp+dQeINYm0WdJZXVreQHZGpVWJUZxzng9yPboRh9yOVJQxjYN tYqfYjqKqUW4
2lsJNXutypd6eZY7f7NL5UtvJ5kbODIM4IIIyCRhj3FR2+lGK4hnefe6LL5m EwHaQqSRzwBt
6c/WtKioSS0RVzmrC2u5L2OOG4lEVrayQxTSWbRbCxULw33yNvJGBwPWrp0N f7Va+/0RzIys
5mtQ8gIAHyPkbeg7HmtiimIyU0mcWAsXu42t42j8nEJDqqMGAY7sHgAZwPWq 8mnXcGpW32SY
KT9pkMrwl1Xe6ttIBHvjntWzcTxW0XmTNtTcq5wTySAOnuRTo5FkUlQwAJHz KV6HHf8AnQBm
R6M0U1oY50WOBArERkSy4zwzBsFcnOCp9qj07Qn01CltLaR42qsqWYWUqGBw 7Zw2QMZwPWtq
igDL/sqTybq0Nwv2K48z5PL/AHil8k4fOMZJP3aa2kTzoxu7tJJT5QDRw7FC o4bpuPJPfP4e
uqeBUE17BBaC6lMixHb/AMsm3ckADbjOckcYoAoNoijWHv0FoxkdXbzrYPIp AA+R8jbwB2PN
PbSGmWcXdyZWuLRbaRggUnG7Len8XT2qyNRtjeLakyLK3C74XVWOM4DEYJx2 B7H0pZ9Qtre5
SCZpFZyFDeU+zJ6DfjaCfTPpR5BfqZi6BIlkYI206JywIkhsTGQQCMjbICG5 6gjvU7aRL5sg
W7/0aZ0kmRo8uzKFHDZ4B2jPB78jtcu9QtbOREuJCrPyMIzYGQMkgfKORycC pLq5hs7aS4uH
CRRjczYJwPwo8w8jPXSJlu42F2n2eO5a4WPyvm3MGyC27plielEekzW8FiLW 6RZ7SIw75Iiy
upxnKhgRyoPWr9xdw21uJ5WIQ4A2qWJJ6AADJPsKQXtsbL7Z5o+z7dxYgjA+ nXPt1o2C5nnQ
x/ar3w+xu0jK7eda73VgAPkfcCo4HHNWdLsJLGOVXlRw7ZVIkKRxjHRVLNj8 Dj2qSHUbWcRl
HYeY5QB42UhhyQQQCDjsat0dLAYkGn3txodvYzMltH5AhnjeIO54wSrB8DI6 cH+lXZre/PmC
3vIVRjwstuX2rtAwMMM85OTnrV6ih6gZZ0mRILeK3utiWqoIA8Ybay5BJ5Gc qcY4x2oi00+U
bGcb7YgyySBijPKX3HBU5UA8/iOeDWpRQBkwaKILKS0S5kMUssjyhyXLo275 csTjqOe+Pc0+
3025i3yPehrlxGnmLDgBEOcbSTyctk+/AGK06KAMiHTZrEGVG+0m3iaK1iVQ m1SQcEk4J4Az
xwOhrQsbf7JYwW+7d5Uapn1wOtT0UAFFFFABRRRQAUUUUAFFFFABRRRQAUUU UAFFFFAFey/1
Df8AXWT/ANDaooYYmhjZo0ZmUElhkkkVLZf6hv8ArrJ/6G1Nt/8Aj3i/3F/l QAjRQKpZoogA
MklRxTYxazAmJYHA6lQDS3v/AB5T/wDXNv5VTeSSBZXJXziiYIGBsz179Mn1 7UAXvIh/54x/
98CjyIf+eMf/AHwKpxyzytFGLlSGDkvGVfpjHOAM8+lIlxcCJJN/mNJCzhNo wGGMYxz3oAu+
RD/zxj/74FHkQ/8APGP/AL4FU1nfDNHcefGgVmbA/EcD059aSe4nCxsJVjSX cwZyFAHGBkg9
uaALvkQ/88Y/++BTJoYlhkZY0VlUkFRgggVLGS0akkEkAkr0/Cm3H/HvL/uN /KgC1RRRQAUU
UUAFV3/5CEP/AFyk/mlWKrv/AMhCH/rlJ/NKAKer/bUV5opMWsce50RtrkjJ yDj6d+1UrPfM
0xtkczeb/rOgHyjq3cZIOOfpWpNqlvBdm3k3BwASWwqgYJJySOAAT+Bxna2L UUUcMYjiRY0H
RVGAPwomuaHKxR0d0ZepC6WztRK07R+d/pJtixfZhsY2AN1252jP61XtYbuS 5sg7Xgt1EzLv
d1JAZfLD9+meG5x171v0lJKysU3c5iwuZoL23Mg1J5RazSXMUm875AU+4Dwe pxt+Xnipn+3N
4hZ3nuIo96eSggldGTaMglW2DndncuR69K17bTra1neeMSNKw2l5ZXkIGc4G 4nA9hVumI5oJ
JNpZV0vnv/NhNwJFkKZEqlimfkxwfu9qZNJMt3BHeSagIme7JWDzNzASLs+7 82MHjH8s11FR
NBE9xHOy5ljVlVsngHGf5CgdzCg+2Jd2H2j7VNMYVVkPmqsZwcszL8jHpkHn 09Kbocl5b75L
17yaYhVlh+zSjDlgCQzMUIGT9zAxzjiukooEYCTXYuoLYreF1vpGkbY+zyiH K/N0I5XjPFPP
nf8ACM2P2nzPO322/wAzO7PmJnOec1uVHPBDcwtFcRJLE3VHUMD+BoWg+ply s8+t2/lfaZFi
cl0lgZI4xtI3K20bjkgdW4JxjrUd5cPeyWnkx3ocvG5tpbdljxuBJZscEDnG 7GQODW2AAMAY
ApaBHO6n5s8l7ttLgm6tmtYsxE/OGYZJHRTuBBOBgU/Xo7m90yWOyVLhYUkS VGZlLPswNvyn
djJ49cc8Vv01I0jBEaKoJLEKMck5J/OjoO+tzIu5JcWJktZs2rJNL5aF1wVZ cLgZYgkEjHSq
7RzjSDD9mnLSzvdBQnRBMH2n0YqeB9a6GigRz7KzpcThHT7VfwtCroVYhdgJ 2nkfdY8joK6C
mNFG7o7IrOmdrEcrnrj0p9HSwBRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRR RQAUUUUAFFFF
ABRRRQAUUUUAV7L/AFDf9dZP/Q2qOJ9kSI6SBlUKRsJ6fQVJZf6hv+usn/ob U77TGem9h6qj
EfmBQAzzV9JP+/bf4UeavpJ/37b/AAp/2hPST/v23+FH2hPST/v23+FADPNX 0k/79t/hR5q+
kn/ftv8ACn/aE9JP+/bf4UfaE9JP+/bf4UAM81fST/v23+FHmr6Sf9+2/wAK f9oT0k/79t/h
R9oT0k/79t/hQAzzV9JP+/bf4UyV98ToiSFmUqBsI6/UVN9oT0k/79t/hR9p jHXeo9WRgPzI
oAmooooAKKKKACq7/wDIQh/65SfzSrFV3/5CEP8A1yk/mlAGN4nhtL54rS4a YSBSyiMooYHr
liCR93PHfHoMWbfUJoxNJIVeNZW+Un5lGN3B7/T9a07q3juraSCUZSRSp9vc e9VbLS4rYFpW
8+UtuLEYUHjBC5ODwOetObcoWjoxRVpXYk+pFYLZraESy3Mnlxq0gVcgEklh nAwp6ZqGPV5p
J7eAWiiRzIJcy8R7CoODj5uvHT8O1+7tIbyMRzqSFYMpVirKfUMCCD9KZDYW 0DRNHFhoVZUJ
Yk/MQWzk8kkA5PNSrpalOxUstVmubm2jks1ijuommicS7jtG3G4Y4Pzep+tN fWmGrNZx2kjx
xuEklCudpIB7KVwMjOWB9vWC00L/AEt3uLeKK38l4VhjuJJchyM/eA2DA4C8 cmtL+zbX7WLl
VkSXjOyZ1DY6blBw34g0xGfc391c6Ut0sYghkkgMLrMS7K0i/eGABkHpk9ad Hqk3mJb2ln5k
kkk4/e3BAHluASSQTg54AHHA6ci4mk2aI6KknlswfyzM5RSG3DaucLz6Yqvc aLDNewOoZIUE
xcJK6OXdlOQQc9jnnvQMSDWjPPbKIEiimjD75ZSpJOcqmFIYjHTIp2j6w+qM xNnJDEUDxuyv
hh7llAz0+6WHvVoabaiWFwjjyABGglYRrjgfJnbn3xUcej2UaMiRyCMkN5fn OUUhgw2rnC8g
dAKBFE+Im33ZSxkaC3WUiTDjcUznJ2bQCQRkMT049Fl1u8iWctpyZghFww+0 f8szn/Z+98p4
6f7VXm0iyZ522SAThhIizOEbcME7QduT64z3qWSwtpfN3xZ86HyH+Y8pzx+p oHoUNLkuLjWN
Rkm/1cbLHEBMxAUqrfcwBk5znrzjoKjXxCPPuS1nKLWASZmCOclM5/hC44OM MT04HbSbT7Vl
kUxcSukj/MeWXG09e20flTV0u0SeSVUcGUkunmt5bE9SUzt5+lAiCTULyKKE SWcIuLiTZFGL
glfuliWbbxwD0BpkerzST28AtFEjmQS5l4j2FQcHHzdeOn4dpxpFmLYW+Jig YMu64kLIRwNr
Fsrx6EVNDYW0DRNHFhoVZUJYk/MQWzk8kkA5PNAFPR9YfVGY/Y5IYigeN2V8 MPcsoGen3Sw9
6jk1yRI7giz3PbOkUqiUffZwAFOOeCGycdQPXFqPR7KNGRI5BGSG8vznKKQw YbVzheQOgFL/
AGTZYx5J7Z+dvmw+8E88ndzk+p9TQBT/ALZukdxNYxqsM6QzMs+7BfbtK/KN w+YZzj8adNdF
/D+pSw+ZE0YuFB80sQVLDIJ5HTIHar72FtJ5u+LPnSLI/wAx5ZcbT/46Pypk +nxvp11aQ/uh
cLJluWwz5yevqc4o6DVrlO8h2zWUdtPc/acptHnOyiMEbi4JwcjIycnJFL4h Vls2mT7Urxox
E0UxVIcc7nUH5h7Ybp0qcaVC04uZmlNyVUO8U0katt6fKGxjrwc9ac+kWbn5 kl2lmcoJ3CMS
dx3KDg5J6EUCRBqIa5vLS186WOGSOSRmikZCSu0DkYP8RP4UttI994etppkn lkkhR2W3k8t2
OB0O5cevUVPPpVncM7SRNud97MkjKc7dvUEY4GMdDQdOR/NWSWYRNtEccUrx CNVGMDaR3z+n
pQBnLPMvhw7Z5DIZvJLkkvGDLtwSeSVBxn2zk9akjuJbOy1hY3eT7GWMJkYu 3+rD4JOSeSet
XTpVk0SRtACqI0YBY9GwWyc8kkA5POacmmWiRxp5RYRuZAXdmJYggkknLcEj nND6jRjsZrNL
2OO5nfyLWO7VpJWY7/myCSfunaOOnpiuiU7lB9Rms86RAlo9tb5jSUgSFizl kH8IJOQMcDsM
nArQpki0UUUhhRRRQAUUUUAFFFFABRRRQAUUUUAFFFFAFey/1Df9dZP/AENq bb/8e8X+4v8A
KnWX+ob/AK6yf+htTbf/AI94v9xf5UASUUUUAMklWNkBB+dtox9Cf6UJKrvI gBzGQDn6Z/rU
d0jsI3Rd5jcNtBwSMEf1qpPGxKvJCT5k4Pl5GcBCMHnHb1oA0qKgtI2ig2su z5iQn90Z4FT0
AFR3H/HvL/uN/KpKjuP+PeX/AHG/lQBaooooAKKKKACq7/8AIQh/65SfzSrF V3/5CEP/AFyk
/mlAGN4jt72GRbzTk8yQjD+YybEIHyt85GDk8Y75PGWD61vqEMzuhOxlcoM9 G9MHpz6VBqmm
m5LXMLN9oSMqinBVuvBz9fWqtlZ3NzFJ5i+RC7kjcuHI2hT8p6d+T+VOo/cv HVij8Vnsa9xc
Q2sJluJo4Yl6vIwUD8TTPt1mFiY3UG2b/VHzBiToPl9eo6etVbvT5BDafZPL d7WbzFSU7VfI
YYJUcfeznHaorXSpY7u3uJDEConZ1TOFaRlPy8dsHnjPpzUq9tSmX4r60nma GG6gklUkMiSA
sCOuR7ZpWu7ZLpbVriFbhxlYi4DsPUDr2Nc3pple/ghs3sJnsrOSJZIXLrkl Qu/A+XOD8vPQ
81fOkT/2vJcsqyxyyJIT9qkj8tgoH3ACrdMjOKYi7datbQpJ5MsU8sUiRyRJ INybnC8jnHX9
KkOo20UZe6ubWEBmGTMMYBx1OOeRkdicVnx6bejSk09ltgkLxeXKsjZcK4JL Lt4JA9TyarPa
XNrq1oI47eaYm7lUSOVUBnU9dpwcH09aBm417aLNFC11CJZRmNDINzj1A70s F3bXMkkcFxDK
8RxIqOGKH0IHToay7bSru0ltFgaNESNY55RIcyAA/KI9uByeCCD9elM0rSrz TYwiJC0karGs
z3Urhl3DPyEYQ4HY9fagRrG/sxNJCbuASxLvkQyDci+pHYe9MOqaeOt/aj5/ L/1y/e/u9evt
WO2g3H+mxhY3EwmMcrXUvymQHrFgr3xkfXFWbnRmkF4I1gUTWC2qDGMEbvbp yPyoGWrTVI7z
VLu0hMLLbYV2EoLFuM/KB0GcZz1BGKlOo20UZe6ubWEBmGTMMYBx1OOeRkdi cVBBaXds93JE
0JeeWNl3k42hUVs+/Bx+FQ22kSR30U8vlMsb3LepHmOCMcemQfrQIvrf2bNK q3cBaFd0gEgy
g9TzwKVL60kSV0uoGSHPmssgITHXd6fjWDeaTLZ6EuTEPsumzwybc8kqvTjp 8pqf+ybq5gaR
ltYXEcKxRoSUYRtvG75RjPTABx70Aav9pWP2YXP2228gkgS+au0kdRnOOx/K obXW9OuraW5S
7hWGFyju0igDnAOc9D29arLplxLcx3M6wJJ9qE7xoxZQBGUGCQMnoeg/TmGf R7uSAoDEfKvH
uI8TvGZAxbILKMoRu6jOce9Af1+Zrre2jSRxrdQl5VDRqJBlwckEDuOD+VQC 8uZZryOC2jY2
7qilpiu8lQxz8pwAG9/pUWm6a9rdmdo441NusQRZWlIIdmPzMASDuFQSJetL qkVkmyWSdGDy
bkUp5aAlX2kZ4I74oAv2l5Ld2BmSBVnDMnls/wAu5WKn5sdMjrj8Kjt9SJtb uW7iWE2jMJNj
71OFDZBwM8H0HNNSG9js44Es7IRrGyNAZmZT0Cjdt6Y3ZyvpUEWmXIsJrXFv DFcuweGNiUhj
KbcR8DnOD0A5NHcEWtPv5bmSSG5txBMqJIFWTeCjZxzgc5BBH6mlhvLj+0fs lxbRpujaSN45
d/AIHzAqMHkeveq1vFeW9yLm5ijknmEdvthZiqqu4lySOOp4+gzzRFZXiXc9 1HBZ2shjcBI5
GZZnOMNJ8q9Me5+Y8+r6gSR6qz3yxGAC3eZoEm38mRQSQVxwOGGc9R0ouNVa G9aMQBreKSOK
WXfgqz4xhccjlcnI696jh025W7jEhi+zQzvcqVY7izA5UjGAAWY5z6cVGdNv pXInNvsnkimu
CjNkOm3IUEcg7V5JGOetJdA7mnaXP2hZAybJInMbrnIB68HvkEH8asVR01GL 3dwyMgnm3KrK
VOAoXJB9dufpir1ABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQBXsv9Q3 /XWT/wBDakSO
aNFTbGwUYB3kZH0xS2X+ob/rrJ/6G1CzyuodYk2tyNz4OPyoAMT/APPOP/v4 f/iaMT/884/+
/h/+JpfMm/55x/8Afw//ABNHmTf884/+/h/+JoATE/8Azzj/AO/h/wDiaQpK xBMURwcjLnj/
AMdp3mTf884/+/h/+Jo8yb/nnH/38P8A8TQAmJ/+ecf/AH8P/wATRif/AJ5x /wDfw/8AxNL5
k3/POP8A7+H/AOJo8yb/AJ5x/wDfw/8AxNACYn/55x/9/D/8TSPHNIjJtjUM ME7ycD6Yp3mT
f884/wDv4f8A4mkaeVFLtEm1eTtfJx+VAFiiiigAooooAKrv/wAhCH/rlJ/N KsVXf/kIQ/8A
XKT+aUAWKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKK ACiiigAooooA
KKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAr2X+ob/rrJ/6 G1Nt/wDj3i/3
F/lTrL/UN/11k/8AQ2ptv/x7xf7i/wAqAJKguZJE8pYioZ325YZA4J9R6VPU NxE0vllHCMjb
gSuR0I9R60AMS62B1uMB0bb8gJ3ZGRgdfwp4uoShbfwFLHg8Adf/ANVMNq2A wk/fB9+4rkZx
jGM9Me9J9jzsLPlgxZzj72TnHsMgflQBI91CmNz9cYwCc55HT6U+KRJUDocq fbFQR2YjCfPn
ZJv6dsYA/KpoIvKVhnOXZunqc0ASVHcf8e8v+438qkqO4/495f8Acb+VAFqi iigAooooAKrv
/wAhCH/rlJ/NKsVXf/kIQ/8AXKT+aUAWKKKKACiiigAooooAKKKKACiiigAo oooAKKKKACii
igAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKK ACiiigAooooA
r2X+ob/rrJ/6G1KtvtG1JZFUdBwcfmKSy/1Df9dZP/Q2psZkkjV2mcFgGwoX Az9RQBJ5Df8A
PeT8l/wo8hv+e8n5L/hTdr/895PyX/Cja/8Az3k/Jf8ACgB3kN/z3k/Jf8KP Ib/nvJ+S/wCF
N2v/AM95PyX/AAo2v/z3k/Jf8KAHeQ3/AD3k/Jf8KPIb/nvJ+S/4U3a//PeT 8l/wo2v/AM95
PyX/AAoAd5Df895PyX/Cka33Da8sjKeo4GfyFJtf/nvJ+S/4U2QyRxs6zOSo LYYLg4+goAtU
UUUAFFFFABVd/wDkIQ/9cpP5pViq7/8AIQh/65SfzSgCxRRRQAUUUUAFFFFA BRRRQAUUUUAF
FFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUU UUAFFFFABRRR
QAUUUUAFFFFAFey/1Df9dZP/AENqq3DFdMjILDiMEqTnGR6c1asv9Q3/AF1k /wDQ2qOJFltI
lYbl2r+Yx/UUAV45ZIlwqO6yS7YxKxBAxnnPPUGpVumZx+6AiZygbdzkZ7Y6 cHvU7xhypZcl
TuHsf8mmC1jWUyBDuyT1OAfXHTNAFdL8+UJJYdiNGXXDZPHtQt7Iyr/o+HZw oDFlHQnqVHp6
VJa2SQwqrrubZtbJJHvgHpUiWsabcBztOV3OxwcY7n3oArQ3EpCmdRkzMgKu eMZ9hnpQl+8k
bOtu2MAqSGxgnv8AL+PGasi1jDbgpzu39TgHnnH4mkWzjVSqiRVPZZGAH054 /CgCSJ/MjV8q
cjPytkfgabcf8e8v+438qT7JFjHlnoB1PY5H60kqLFazADaCGP4n/wCvQBco oooAKKKKACq7
/wDIQh/65SfzSrFV3/5CEP8A1yk/mlAFiiiigAooooAKKKKACiiigAooooAK KKKACiiigAoo
ooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiii gAooooAKKKKA
K9l/qG/66yf+htTzbwsSTDGSepKimWX+ob/rrJ/6G1WKAIvs0H/PCP8A74FH 2aD/AJ4R/wDf
AqWigCL7NB/zwj/74FH2aD/nhH/3wKlooAi+zQf88I/++BR9mg/54R/98Cpa KAIvs0H/ADwj
/wC+BQLeFSCIYwR0IUVLRQAUUUUAFFFFABVd/wDkIQ/9cpP5pRRQBYooooAK KKKACiiigAoo
ooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiii gAooooAKKKKA
CiiigAooooAKKKKACiiigCvZf6hv+usn/obVYoooAKKKKACiiigAooooAKKK KACiiigAoooo
A//Z
--------------070401020102050108070901--

--------------020408060102070908060401--
Re: [CDO] is it what I want ? [message #110253 is a reply to message #110177] Wed, 30 January 2008 14:11 Go to previous messageGo to next message
Eclipse UserFriend
Originally posted by: tom.eiswind.de

Eike Stepper schrieb:
> Ok, once more ;-)
>
> 1) New Wizard "Empty EMF project" (this is the plugin project that I meant)
> 2) Create/copy an .ecore file to the model folder
> 3) Use the New Wizard "EMF Model" on the .ecore file and choose the
> importer "Ecore model (CDO native)"
> 4) Adjust other genmodel settings (optional)
> 5) Generate the genmodel
> 6) Use the generated model plugin with CDO
> 7) Use the generated edit plugin with the CDO UI (optional)
>
> Does that work?
>
Yes :)

But it should work with the new EMF Project Wizard too, right (extra):) ?
Re: [CDO] is it what I want ? [message #110480 is a reply to message #110253] Wed, 30 January 2008 14:35 Go to previous messageGo to next message
Eclipse UserFriend
Originally posted by: stepper.sympedia.de

Thomas schrieb:
> Eike Stepper schrieb:
>> Ok, once more ;-)
>>
>> 1) New Wizard "Empty EMF project" (this is the plugin project that I
>> meant)
>> 2) Create/copy an .ecore file to the model folder
>> 3) Use the New Wizard "EMF Model" on the .ecore file and choose the
>> importer "Ecore model (CDO native)"
>> 4) Adjust other genmodel settings (optional)
>> 5) Generate the genmodel
>> 6) Use the generated model plugin with CDO
>> 7) Use the generated edit plugin with the CDO UI (optional)
>>
>> Does that work?
>>
> Yes :)
>
> But it should work with the new EMF Project Wizard too, right (extra):) ?
I never used that in my life ;-)
I'll try it and come back...

Regards,
Eike Stepper
----
http://wiki.eclipse.org/CDO
http://wiki.eclipse.org/Net4j
Re: [CDO] is it what I want ? [message #110490 is a reply to message #109206] Wed, 30 January 2008 14:39 Go to previous messageGo to next message
Simon Mc Duff is currently offline Simon Mc DuffFriend
Messages: 596
Registered: July 2009
Senior Member
I'm a litle busy for now but I will e-mail you the source code this
week-end.

You will see it is very simple.

See you!

"Thomas" <tom@eiswind.de> wrote in message
news:fnnlip$n43$1@build.eclipse.org...
> Hi Simon,
>
> Im just getting started, but I will love to have a look at it.
>
> Can I get access anywhere ?
>
> Thomas
>
> Simon McDuff schrieb:
>> It is not a closed source !! :-)
>>
>> You will not be able to query ... since your Store need to provide how
>> you will handle the ocl expression (or something else). We did it only
>> for our OODB database
>>
>> This is the only feature we've been implemented yet :
>>
>> refresh (You can refresh your resource, an object or a list of objects)
>> begin
>> commit
>> getReference
>> rollback
>>
>> XATransaction isn't supported yet :-(
>>
>> Let me know if this still interest you.
>>
>> If this is the case, I will maybe work on an implemtation to query other
>> Store...So the query mechanism will work for you as well.
>>
>> Simon
>
Re: [CDO] is it what I want ? [message #504387 is a reply to message #110490] Fri, 18 December 2009 10:52 Go to previous messageGo to next message
Joel Rosi-Schwartz is currently offline Joel Rosi-SchwartzFriend
Messages: 624
Registered: July 2009
Location: London. England
Senior Member
Hi Simon,

Did the OCL query that you developed for your OODB every get implemented for the SQL DBs? I would be very interested in that functionality.

Thanks,
Joel


Simon Mc Duff wrote on Wed, 30 January 2008 14:39
I'm a litle busy for now but I will e-mail you the source code this
week-end.

You will see it is very simple.

See you!

"Thomas" <tom@eiswind.de> wrote in message
news:fnnlip$n43$1@build.eclipse.org...
> Hi Simon,
>
> Im just getting started, but I will love to have a look at it.
>
> Can I get access anywhere ?
>
> Thomas
>
> Simon McDuff schrieb:
>> It is not a closed source !! Smile
>>
>> You will not be able to query ... since your Store need to provide how
>> you will handle the ocl expression (or something else). We did it only
>> for our OODB database
>>
>> This is the only feature we've been implemented yet :
>>
>> refresh (You can refresh your resource, an object or a list of objects)
>> begin
>> commit
>> getReference
>> rollback
>>
>> XATransaction isn't supported yet Sad
>>
>> Let me know if this still interest you.
>>
>> If this is the case, I will maybe work on an implemtation to query other
>> Store...So the query mechanism will work for you as well.
>>
>> Simon
>

[Updated on: Fri, 18 December 2009 10:52]

Report message to a moderator

Re: [CDO] is it what I want ? [message #504393 is a reply to message #504387] Fri, 18 December 2009 11:28 Go to previous messageGo to next message
Eike Stepper is currently offline Eike StepperFriend
Messages: 6579
Registered: July 2009
Senior Member
Hi Joel,

I don't think that Simon monitors the EMFT newsgroup ;-)

And I know that OCL has not been implemented as a CDOQuery language for
DBStore, at least not by the CDO team. I cc'ed Bernd because he might
give some infos about his plans to collaborate on an integration with
EMF Query.

Cheers
/Eike

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




Joel Rosi-Schwartz schrieb:
> Hi Simon,
>
> Did the OCL query the you developed for your OODB every get
> implemented for the SQL DBs? I would be very interested in that
> functionality.
>
> Thanks,
> Joel
>
>
> Simon Mc Duff wrote on Wed, 30 January 2008 14:39
>> I'm a litle busy for now but I will e-mail you the source code this
>> week-end.
>>
>> You will see it is very simple.
>>
>> See you!
>>
>> "Thomas" <tom@eiswind.de> wrote in message
>> news:fnnlip$n43$1@build.eclipse.org...
>> > Hi Simon,
>> >
>> > Im just getting started, but I will love to have a look at it.
>> >
>> > Can I get access anywhere ?
>> >
>> > Thomas
>> >
>> > Simon McDuff schrieb:
>> >> It is not a closed source !! :)
>> >>
>> >> You will not be able to query ... since your Store need to provide
>> how >> you will handle the ocl expression (or something else). We did
>> it only >> for our OODB database
>> >>
>> >> This is the only feature we've been implemented yet :
>> >>
>> >> refresh (You can refresh your resource, an object or a list of
>> objects)
>> >> begin
>> >> commit
>> >> getReference
>> >> rollback
>> >>
>> >> XATransaction isn't supported yet :(
>> >>
>> >> Let me know if this still interest you.
>> >>
>> >> If this is the case, I will maybe work on an implemtation to query
>> other >> Store...So the query mechanism will work for you as well.
>> >>
>> >> Simon
>> >
>
>


Re: [CDO] is it what I want ? [message #504395 is a reply to message #504393] Fri, 18 December 2009 16:37 Go to previous message
Joel Rosi-Schwartz is currently offline Joel Rosi-SchwartzFriend
Messages: 624
Registered: July 2009
Location: London. England
Senior Member
I was concerned about that, especially as the thread was a bit stale.

Eike Stepper wrote on Fri, 18 December 2009 11:28
Hi Joel,

I don't think that Simon monitors the EMFT newsgroup Wink



Great. Thanks for picking up the ball Wink

Quote:

And I know that OCL has not been implemented as a CDOQuery language for
DBStore, at least not by the CDO team. I cc'ed Bernd because he might
give some infos about his plans to collaborate on an integration with
EMF Query.


Re: [CDO] is it what I want ? [message #614141 is a reply to message #108921] Tue, 29 January 2008 14:01 Go to previous message
Eike Stepper is currently offline Eike StepperFriend
Messages: 6579
Registered: July 2009
Senior Member
This is a multi-part message in MIME format.
--------------030606020309080208060407
Content-Type: text/plain; charset=ISO-8859-15; format=flowed
Content-Transfer-Encoding: 7bit

Hi Thomas,

With CDO you need a CDOView to access model objects. CDOView in the
current 0.8 stream doesn't have API to query the repository. The former
stream had it, but since 0.8 is a complete rewrite this is one of the
few outstanding features to be rewritten. If you open an enhancement
request I can add a method like the following:
| /**
* Sends a query to the repository and returns a list of the matching objects or an empty list if no object matched
* the query. The query must be in a language that is supported by the store of the repository. For example, if the
* repository of this view's session has a DBStore configured, the query must be a valid SQL select statement.
*/
*public *EList<CDOObject> query(String query);|


CDO is basically DB independent. In fact it is even not bound to work
with JDBC databases. An IRepository works with an IStore which I have
implemented as DBStore (JDBC connection plus O/R mapping). There's also
a MEMStore and another user has developed an OODBStore (non-public so
far). The DBStore itself is independent of different DB vendors (driver
and dialect). CDO ships with DB adapters for Derby, Hsqldb and Mysql. It
is very easy to develop other DB adapters. An example is the DerbyAdapter:
|/********************************************************** *****************
* Copyright (c) 2004 - 2008 Eike Stepper, Germany.
* All rights reserved. This program and the accompanying materials
* are made available under the terms of the Eclipse Public License v1.0
* which accompanies this distribution, and is available at
* http://www.eclipse.org/legal/epl-v10.html
*
* Contributors:
* Eike Stepper - initial API and implementation
************************************************************ **************/
*package *org.eclipse.net4j.db.internal.derby;

*import *org.eclipse.net4j.db.DBType;
*import *org.eclipse.net4j.db.ddl.IDBField;
*import *org.eclipse.net4j.internal.db.DBAdapter;
*import *org.eclipse.net4j.internal.db.ddl.DBField;

*import *org.apache.derby.jdbc.EmbeddedDriver;

*import *java.sql.Driver;
*import *java.util.Arrays;

/**
* @author Eike Stepper
*/
*public class *DerbyAdapter *extends *DBAdapter
{
*private static final *String[] RESERVED_WORDS = { "ADD", "ALL", "ALLOCATE", "ALTER", "AND", "ANY", "ARE", "AS", "ASC",
"ASSERTION", "AT", "AUTHORIZATION", "AVG", "BEGIN", "BETWEEN", "BIGINT", "BIT", "BOOLEAN", "BOTH", "BY", "CALL",
"CASCADE", "CASCADED", "CASE", "CAST", "CHAR", "CHARACTER", "CHECK", "CLOSE", "COALESCE", "COLLATE", "COLLATION",
"COLUMN", "COMMIT", "CONNECT", "CONNECTION", "CONSTRAINT", "CONSTRAINTS", "CONTINUE", "CONVERT", "CORRESPONDING",
"CREATE", "CURRENT", "CURRENT_DATE", "CURRENT_TIME", "CURRENT_TIMESTAMP", "CURRENT_USER", "CURSOR", "DEALLOCATE",
"DEC", "DECIMAL", "DECLARE", "DEFAULT", "DEFERRABLE", "DEFERRED", "DELETE", "DESC", "DESCRIBE", "DIAGNOSTICS",
"DISCONNECT", "DISTINCT", "DOUBLE", "DROP", "ELSE", "END", "END-EXEC", "ESCAPE", "EXCEPT", "EXCEPTION", "EXEC",
"EXECUTE", "EXISTS", "EXPLAIN", "EXTERNAL", "FALSE", "FETCH", "FIRST", "FLOAT", "FOR", "FOREIGN", "FOUND",
"FROM", "FULL", "FUNCTION", "GET", "GETCURRENTCONNECTION", "GLOBAL", "GO", "GOTO", "GRANT", "GROUP", "HAVING",
"HOUR", "IDENTITY", "IMMEDIATE", "IN", "INDICATOR", "INITIALLY", "INNER", "INOUT", "INPUT", "INSENSITIVE",
"INSERT", "INT", "INTEGER", "INTERSECT", "INTO", "IS", "ISOLATION", "JOIN", "KEY", "LAST", "LEFT", "LIKE",
"LOWER", "LTRIM", "MATCH", "MAX", "MIN", "MINUTE", "NATIONAL", "NATURAL", "NCHAR", "NVARCHAR", "NEXT", "NO",
"NOT", "NULL", "NULLIF", "NUMERIC", "OF", "ON", "ONLY", "OPEN", "OPTION", "OR", "ORDER", "OUTER", "OUTPUT",
"OVERLAPS", "PAD", "PARTIAL", "PREPARE", "PRESERVE", "PRIMARY", "PRIOR", "PRIVILEGES", "PROCEDURE", "PUBLIC",
"READ", "REAL", "REFERENCES", "RELATIVE", "RESTRICT", "REVOKE", "RIGHT", "ROLLBACK", "ROWS", "RTRIM", "SCHEMA",
"SCROLL", "SECOND", "SELECT", "SESSION_USER", "SET", "SMALLINT", "SOME", "SPACE", "SQL", "SQLCODE", "SQLERROR",
"SQLSTATE", "SUBSTR", "SUBSTRING", "SUM", "SYSTEM_USER", "TABLE", "TEMPORARY", "TIMEZONE_HOUR",
"TIMEZONE_MINUTE", "TO", "TRANSACTION", "TRANSLATE", "TRANSLATION", "TRIM", "TRUE", "UNION", "UNIQUE", "UNKNOWN",
"UPDATE", "UPPER", "USER", "USING", "VALUES", "VARCHAR", "VARYING", "VIEW", "WHENEVER", "WHERE", "WITH", "WORK",
"WRITE", "XML", "XMLEXISTS", "XMLPARSE", "XMLQUERY", "XMLSERIALIZE", "YEAR" };

*public *DerbyAdapter()
{
*super*("derby", "10.2.2.0");
}

*public *Driver getJDBCDriver()
{
*return new *EmbeddedDriver();
}

@Override
*protected *String getTypeName(DBField field)
{
DBType type = field.getType();
*switch *(type)
{
*case *BOOLEAN:
*case *BIT:
*return *"SMALLINT";
}

*return super*.getTypeName(field);
}

@Override
*public **void *appendValue(StringBuilder builder, IDBField field, Object value)
{
*if *(value *instanceof *Boolean)
{
value = (Boolean)value ? 1 : 0;
}

*super*.appendValue(builder, field, value);
}

@Override
*protected **boolean *isReservedWord(String word)
{
*return *Arrays.binarySearch(RESERVED_WORDS, word.toUpperCase()) >= 0;
}
}|


The performance of CDO is highly optimized especially between the client
and the repository (above the store implementation). The DBStore (the
facility that is responsible for server side O/R mapping) seems fast to
me, but I have no evidence for it since we haven't started to implement
a comparable IStore on the base of server side Hibernate. I suggest that
you try the DBStore and report your experiences here ;-)

If you have more questions, please don't hesitate to ask them here.

Regards,
Eike Stepper
----
http://wiki.eclipse.org/CDO
http://wiki.eclipse.org/Net4j



Thomas schrieb:
> HI I learned about teneo and cdo only the last couple of days. I like
> soemthink about cdo, but I wonder if its hwat I actually want. I have
> a typical three tiered architecture. currently i have JPA entities
> persited with hibernate in my domain model. what I like is that CDO
> promises to handle the lazy loading of the model to the client (which
> I currently cant with hibernate) for a single business object i always
> have to load the whole object graph and transfer it to the client. But
> I come from relational database background. so I wonder if i have an
> emf model for everything, how can i query it (for e.g. give me all
> persons with name like '%Thomas%' ? how is the cdo persistence layer ?
> I want to be db independant (at least postgres, sql server, oracle). I
> have tons of data, what about performance issues ? with hibernate i
> can tune many things on the db. would be glad if you can teach me
> something about cdo :)
>
> Regards Thomas

--------------030606020309080208060407
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 Thomas,<br>
<br>
With CDO you need a CDOView to access model objects. CDOView in the
current 0.8 stream doesn't have API to query the repository. The former
stream had it, but since 0.8 is a complete rewrite this is one of the
few outstanding features to be rewritten. If you open an enhancement
request I can add a method like the following:<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] is it what I want ? [message #614144 is a reply to message #108996] Tue, 29 January 2008 14:16 Go to previous message
Thomas is currently offline ThomasFriend
Messages: 151
Registered: July 2009
Senior Member
Hello Eike,

thanks for your reply. Im just evaluating. So Ill open a request as soon
as I decide to dive deeper into it. If I understand you right the query
will be executed on the server and has to be pure sql. For that I would
have to learn about the mapping strategy (am used to hibernate though).
How would such an sql query have to look like ? I understand that I
would have to implement the queries on the client side then, but that
should be no problem. Another question I have is about mapping. Suggest
I have an EMF model (playing around with it right now) how is it mapped
qo the db ? are there annotations for eg varchar length, nullability etc
? I have to look into emf validation as for now I have hibernate
validators bound into the databinding framework that do client side
validation. many questions :)

Regards Thomas

Eike Stepper schrieb:
> Hi Thomas,
>
> With CDO you need a CDOView to access model objects. CDOView in the
> current 0.8 stream doesn't have API to query the repository. The former
> stream had it, but since 0.8 is a complete rewrite this is one of the
> few outstanding features to be rewritten. If you open an enhancement
> request I can add a method like the following:
> | /**
> * Sends a query to the repository and returns a list of the matching objects or an empty list if no object matched
> * the query. The query must be in a language that is supported by the store of the repository. For example, if the
> * repository of this view's session has a DBStore configured, the query must be a valid SQL select statement.
> */
> *public *EList<CDOObject> query(String query);|
>
>
> CDO is basically DB independent. In fact it is even not bound to work
> with JDBC databases. An IRepository works with an IStore which I have
> implemented as DBStore (JDBC connection plus O/R mapping). There's also
> a MEMStore and another user has developed an OODBStore (non-public so
> far). The DBStore itself is independent of different DB vendors (driver
> and dialect). CDO ships with DB adapters for Derby, Hsqldb and Mysql. It
> is very easy to develop other DB adapters. An example is the DerbyAdapter:
> |/********************************************************** *****************
> * Copyright (c) 2004 - 2008 Eike Stepper, Germany.
> * All rights reserved. This program and the accompanying materials
> * are made available under the terms of the Eclipse Public License v1.0
> * which accompanies this distribution, and is available at
> * http://www.eclipse.org/legal/epl-v10.html
> *
> * Contributors:
> * Eike Stepper - initial API and implementation
> ************************************************************ **************/
> *package *org.eclipse.net4j.db.internal.derby;
>
> *import *org.eclipse.net4j.db.DBType;
> *import *org.eclipse.net4j.db.ddl.IDBField;
> *import *org.eclipse.net4j.internal.db.DBAdapter;
> *import *org.eclipse.net4j.internal.db.ddl.DBField;
>
> *import *org.apache.derby.jdbc.EmbeddedDriver;
>
> *import *java.sql.Driver;
> *import *java.util.Arrays;
>
> /**
> * @author Eike Stepper
> */
> *public class *DerbyAdapter *extends *DBAdapter
> {
> *private static final *String[] RESERVED_WORDS = { "ADD", "ALL", "ALLOCATE", "ALTER", "AND", "ANY", "ARE", "AS", "ASC",
> "ASSERTION", "AT", "AUTHORIZATION", "AVG", "BEGIN", "BETWEEN", "BIGINT", "BIT", "BOOLEAN", "BOTH", "BY", "CALL",
> "CASCADE", "CASCADED", "CASE", "CAST", "CHAR", "CHARACTER", "CHECK", "CLOSE", "COALESCE", "COLLATE", "COLLATION",
> "COLUMN", "COMMIT", "CONNECT", "CONNECTION", "CONSTRAINT", "CONSTRAINTS", "CONTINUE", "CONVERT", "CORRESPONDING",
> "CREATE", "CURRENT", "CURRENT_DATE", "CURRENT_TIME", "CURRENT_TIMESTAMP", "CURRENT_USER", "CURSOR", "DEALLOCATE",
> "DEC", "DECIMAL", "DECLARE", "DEFAULT", "DEFERRABLE", "DEFERRED", "DELETE", "DESC", "DESCRIBE", "DIAGNOSTICS",
> "DISCONNECT", "DISTINCT", "DOUBLE", "DROP", "ELSE", "END", "END-EXEC", "ESCAPE", "EXCEPT", "EXCEPTION", "EXEC",
> "EXECUTE", "EXISTS", "EXPLAIN", "EXTERNAL", "FALSE", "FETCH", "FIRST", "FLOAT", "FOR", "FOREIGN", "FOUND",
> "FROM", "FULL", "FUNCTION", "GET", "GETCURRENTCONNECTION", "GLOBAL", "GO", "GOTO", "GRANT", "GROUP", "HAVING",
> "HOUR", "IDENTITY", "IMMEDIATE", "IN", "INDICATOR", "INITIALLY", "INNER", "INOUT", "INPUT", "INSENSITIVE",
> "INSERT", "INT", "INTEGER", "INTERSECT", "INTO", "IS", "ISOLATION", "JOIN", "KEY", "LAST", "LEFT", "LIKE",
> "LOWER", "LTRIM", "MATCH", "MAX", "MIN", "MINUTE", "NATIONAL", "NATURAL", "NCHAR", "NVARCHAR", "NEXT", "NO",
> "NOT", "NULL", "NULLIF", "NUMERIC", "OF", "ON", "ONLY", "OPEN", "OPTION", "OR", "ORDER", "OUTER", "OUTPUT",
> "OVERLAPS", "PAD", "PARTIAL", "PREPARE", "PRESERVE", "PRIMARY", "PRIOR", "PRIVILEGES", "PROCEDURE", "PUBLIC",
> "READ", "REAL", "REFERENCES", "RELATIVE", "RESTRICT", "REVOKE", "RIGHT", "ROLLBACK", "ROWS", "RTRIM", "SCHEMA",
> "SCROLL", "SECOND", "SELECT", "SESSION_USER", "SET", "SMALLINT", "SOME", "SPACE", "SQL", "SQLCODE", "SQLERROR",
> "SQLSTATE", "SUBSTR", "SUBSTRING", "SUM", "SYSTEM_USER", "TABLE", "TEMPORARY", "TIMEZONE_HOUR",
> "TIMEZONE_MINUTE", "TO", "TRANSACTION", "TRANSLATE", "TRANSLATION", "TRIM", "TRUE", "UNION", "UNIQUE", "UNKNOWN",
> "UPDATE", "UPPER", "USER", "USING", "VALUES", "VARCHAR", "VARYING", "VIEW", "WHENEVER", "WHERE", "WITH", "WORK",
> "WRITE", "XML", "XMLEXISTS", "XMLPARSE", "XMLQUERY", "XMLSERIALIZE", "YEAR" };
>
> *public *DerbyAdapter()
> {
> *super*("derby", "10.2.2.0");
> }
>
> *public *Driver getJDBCDriver()
> {
> *return new *EmbeddedDriver();
> }
>
> @Override
> *protected *String getTypeName(DBField field)
> {
> DBType type = field.getType();
> *switch *(type)
> {
> *case *BOOLEAN:
> *case *BIT:
> *return *"SMALLINT";
> }
>
> *return super*.getTypeName(field);
> }
>
> @Override
> *public **void *appendValue(StringBuilder builder, IDBField field, Object value)
> {
> *if *(value *instanceof *Boolean)
> {
> value = (Boolean)value ? 1 : 0;
> }
>
> *super*.appendValue(builder, field, value);
> }
>
> @Override
> *protected **boolean *isReservedWord(String word)
> {
> *return *Arrays.binarySearch(RESERVED_WORDS, word.toUpperCase()) >= 0;
> }
> }|
>
>
> The performance of CDO is highly optimized especially between the client
> and the repository (above the store implementation). The DBStore (the
> facility that is responsible for server side O/R mapping) seems fast to
> me, but I have no evidence for it since we haven't started to implement
> a comparable IStore on the base of server side Hibernate. I suggest that
> you try the DBStore and report your experiences here ;-)
>
> If you have more questions, please don't hesitate to ask them here.
>
> Regards,
> Eike Stepper
> ----
> http://wiki.eclipse.org/CDO
> http://wiki.eclipse.org/Net4j
>
>
>
> Thomas schrieb:
>> HI I learned about teneo and cdo only the last couple of days. I like
>> soemthink about cdo, but I wonder if its hwat I actually want. I have
>> a typical three tiered architecture. currently i have JPA entities
>> persited with hibernate in my domain model. what I like is that CDO
>> promises to handle the lazy loading of the model to the client (which
>> I currently cant with hibernate) for a single business object i always
>> have to load the whole object graph and transfer it to the client. But
>> I come from relational database background. so I wonder if i have an
>> emf model for everything, how can i query it (for e.g. give me all
>> persons with name like '%Thomas%' ? how is the cdo persistence layer ?
>> I want to be db independant (at least postgres, sql server, oracle). I
>> have tons of data, what about performance issues ? with hibernate i
>> can tune many things on the db. would be glad if you can teach me
>> something about cdo :)
>>
>> Regards Thomas
Re: [CDO] is it what I want ? [message #614145 is a reply to message #108996] Tue, 29 January 2008 14:22 Go to previous message
Thomas is currently offline ThomasFriend
Messages: 151
Registered: July 2009
Senior Member
Once again..
Another thing coming to my mind is about the object graph. Suggest I
have a Object Person with a Collection of Adresses. when I query for the
person did I get it right that the Adresse are only loaded when I try to
access them ? That would be the main decision factor for me. I have
expensive objects and the more the could be lazy loaded the better my ui
handling would be.

Regards Thomas
Re: [CDO] is it what I want ? [message #614147 is a reply to message #109034] Tue, 29 January 2008 14:31 Go to previous message
Simon Mc Duff is currently offline Simon Mc DuffFriend
Messages: 596
Registered: July 2009
Senior Member
Hi Thomas,

I would like to share our experience with CDO and Query.

To use a more standard API, we develop a basic (not complete yet) JPA
implementation using CDO.
For the query, (this is the part I want to mention you) we use OCL as our
language.

From EntityManager we use createNativeQuery() method to pass the string from
the client to the server.

On the server we delegate the call to the IStoreQuery

Now, to be able to execute it the database provider could have 2 choices :

- Convert the OCL language to an SQL
- Use extension point in OCL to interact with your database.

It returns a list of ID.. so you no dot load all tha data.

So far we used solutions number 2.

I hope this can help you.


"Thomas" <tom@eiswind.de> wrote in message
news:fnncgj$ktv$1@build.eclipse.org...
> Hello Eike,
>
> thanks for your reply. Im just evaluating. So Ill open a request as soon
> as I decide to dive deeper into it. If I understand you right the query
> will be executed on the server and has to be pure sql. For that I would
> have to learn about the mapping strategy (am used to hibernate though).
> How would such an sql query have to look like ? I understand that I would
> have to implement the queries on the client side then, but that should be
> no problem. Another question I have is about mapping. Suggest I have an
> EMF model (playing around with it right now) how is it mapped qo the db ?
> are there annotations for eg varchar length, nullability etc ? I have to
> look into emf validation as for now I have hibernate validators bound into
> the databinding framework that do client side validation. many questions
> :)
>
> Regards Thomas
>
> Eike Stepper schrieb:
>> Hi Thomas,
>>
>> With CDO you need a CDOView to access model objects. CDOView in the
>> current 0.8 stream doesn't have API to query the repository. The former
>> stream had it, but since 0.8 is a complete rewrite this is one of the few
>> outstanding features to be rewritten. If you open an enhancement request
>> I can add a method like the following:
>> | /**
>> * Sends a query to the repository and returns a list of the matching
>> objects or an empty list if no object matched
>> * the query. The query must be in a language that is supported by the
>> store of the repository. For example, if the
>> * repository of this view's session has a DBStore configured, the
>> query must be a valid SQL select statement.
>> */
>> *public *EList<CDOObject> query(String query);|
>>
>>
>> CDO is basically DB independent. In fact it is even not bound to work
>> with JDBC databases. An IRepository works with an IStore which I have
>> implemented as DBStore (JDBC connection plus O/R mapping). There's also a
>> MEMStore and another user has developed an OODBStore (non-public so far).
>> The DBStore itself is independent of different DB vendors (driver and
>> dialect). CDO ships with DB adapters for Derby, Hsqldb and Mysql. It is
>> very easy to develop other DB adapters. An example is the DerbyAdapter:
>> |/********************************************************** *****************
>> * Copyright (c) 2004 - 2008 Eike Stepper, Germany.
>> * All rights reserved. This program and the accompanying materials
>> * are made available under the terms of the Eclipse Public License v1.0
>> * which accompanies this distribution, and is available at
>> * http://www.eclipse.org/legal/epl-v10.html
>> * * Contributors:
>> * Eike Stepper - initial API and implementation
>>
>> ************************************************************ **************/
>> *package *org.eclipse.net4j.db.internal.derby;
>>
>> *import *org.eclipse.net4j.db.DBType;
>> *import *org.eclipse.net4j.db.ddl.IDBField;
>> *import *org.eclipse.net4j.internal.db.DBAdapter;
>> *import *org.eclipse.net4j.internal.db.ddl.DBField;
>>
>> *import *org.apache.derby.jdbc.EmbeddedDriver;
>>
>> *import *java.sql.Driver;
>> *import *java.util.Arrays;
>>
>> /**
>> * @author Eike Stepper
>> */
>> *public class *DerbyAdapter *extends *DBAdapter
>> {
>> *private static final *String[] RESERVED_WORDS = { "ADD", "ALL",
>> "ALLOCATE", "ALTER", "AND", "ANY", "ARE", "AS", "ASC",
>> "ASSERTION", "AT", "AUTHORIZATION", "AVG", "BEGIN", "BETWEEN",
>> "BIGINT", "BIT", "BOOLEAN", "BOTH", "BY", "CALL",
>> "CASCADE", "CASCADED", "CASE", "CAST", "CHAR", "CHARACTER",
>> "CHECK", "CLOSE", "COALESCE", "COLLATE", "COLLATION",
>> "COLUMN", "COMMIT", "CONNECT", "CONNECTION", "CONSTRAINT",
>> "CONSTRAINTS", "CONTINUE", "CONVERT", "CORRESPONDING",
>> "CREATE", "CURRENT", "CURRENT_DATE", "CURRENT_TIME",
>> "CURRENT_TIMESTAMP", "CURRENT_USER", "CURSOR", "DEALLOCATE",
>> "DEC", "DECIMAL", "DECLARE", "DEFAULT", "DEFERRABLE", "DEFERRED",
>> "DELETE", "DESC", "DESCRIBE", "DIAGNOSTICS",
>> "DISCONNECT", "DISTINCT", "DOUBLE", "DROP", "ELSE", "END",
>> "END-EXEC", "ESCAPE", "EXCEPT", "EXCEPTION", "EXEC",
>> "EXECUTE", "EXISTS", "EXPLAIN", "EXTERNAL", "FALSE", "FETCH",
>> "FIRST", "FLOAT", "FOR", "FOREIGN", "FOUND",
>> "FROM", "FULL", "FUNCTION", "GET", "GETCURRENTCONNECTION",
>> "GLOBAL", "GO", "GOTO", "GRANT", "GROUP", "HAVING",
>> "HOUR", "IDENTITY", "IMMEDIATE", "IN", "INDICATOR", "INITIALLY",
>> "INNER", "INOUT", "INPUT", "INSENSITIVE",
>> "INSERT", "INT", "INTEGER", "INTERSECT", "INTO", "IS", "ISOLATION",
>> "JOIN", "KEY", "LAST", "LEFT", "LIKE",
>> "LOWER", "LTRIM", "MATCH", "MAX", "MIN", "MINUTE", "NATIONAL",
>> "NATURAL", "NCHAR", "NVARCHAR", "NEXT", "NO",
>> "NOT", "NULL", "NULLIF", "NUMERIC", "OF", "ON", "ONLY", "OPEN",
>> "OPTION", "OR", "ORDER", "OUTER", "OUTPUT",
>> "OVERLAPS", "PAD", "PARTIAL", "PREPARE", "PRESERVE", "PRIMARY",
>> "PRIOR", "PRIVILEGES", "PROCEDURE", "PUBLIC",
>> "READ", "REAL", "REFERENCES", "RELATIVE", "RESTRICT", "REVOKE",
>> "RIGHT", "ROLLBACK", "ROWS", "RTRIM", "SCHEMA",
>> "SCROLL", "SECOND", "SELECT", "SESSION_USER", "SET", "SMALLINT",
>> "SOME", "SPACE", "SQL", "SQLCODE", "SQLERROR",
>> "SQLSTATE", "SUBSTR", "SUBSTRING", "SUM", "SYSTEM_USER", "TABLE",
>> "TEMPORARY", "TIMEZONE_HOUR",
>> "TIMEZONE_MINUTE", "TO", "TRANSACTION", "TRANSLATE", "TRANSLATION",
>> "TRIM", "TRUE", "UNION", "UNIQUE", "UNKNOWN",
>> "UPDATE", "UPPER", "USER", "USING", "VALUES", "VARCHAR", "VARYING",
>> "VIEW", "WHENEVER", "WHERE", "WITH", "WORK",
>> "WRITE", "XML", "XMLEXISTS", "XMLPARSE", "XMLQUERY",
>> "XMLSERIALIZE", "YEAR" };
>>
>> *public *DerbyAdapter()
>> {
>> *super*("derby", "10.2.2.0");
>> }
>>
>> *public *Driver getJDBCDriver()
>> {
>> *return new *EmbeddedDriver();
>> }
>>
>> @Override
>> *protected *String getTypeName(DBField field)
>> {
>> DBType type = field.getType();
>> *switch *(type)
>> {
>> *case *BOOLEAN:
>> *case *BIT:
>> *return *"SMALLINT";
>> }
>>
>> *return super*.getTypeName(field);
>> }
>>
>> @Override
>> *public **void *appendValue(StringBuilder builder, IDBField field,
>> Object value)
>> {
>> *if *(value *instanceof *Boolean)
>> {
>> value = (Boolean)value ? 1 : 0;
>> }
>>
>> *super*.appendValue(builder, field, value);
>> }
>>
>> @Override
>> *protected **boolean *isReservedWord(String word)
>> {
>> *return *Arrays.binarySearch(RESERVED_WORDS, word.toUpperCase()) >=
>> 0;
>> }
>> }|
>>
>>
>> The performance of CDO is highly optimized especially between the client
>> and the repository (above the store implementation). The DBStore (the
>> facility that is responsible for server side O/R mapping) seems fast to
>> me, but I have no evidence for it since we haven't started to implement a
>> comparable IStore on the base of server side Hibernate. I suggest that
>> you try the DBStore and report your experiences here ;-)
>>
>> If you have more questions, please don't hesitate to ask them here.
>>
>> Regards,
>> Eike Stepper
>> ----
>> http://wiki.eclipse.org/CDO
>> http://wiki.eclipse.org/Net4j
>>
>>
>>
>> Thomas schrieb:
>>> HI I learned about teneo and cdo only the last couple of days. I like
>>> soemthink about cdo, but I wonder if its hwat I actually want. I have a
>>> typical three tiered architecture. currently i have JPA entities
>>> persited with hibernate in my domain model. what I like is that CDO
>>> promises to handle the lazy loading of the model to the client (which I
>>> currently cant with hibernate) for a single business object i always
>>> have to load the whole object graph and transfer it to the client. But I
>>> come from relational database background. so I wonder if i have an emf
>>> model for everything, how can i query it (for e.g. give me all persons
>>> with name like '%Thomas%' ? how is the cdo persistence layer ? I want to
>>> be db independant (at least postgres, sql server, oracle). I have tons
>>> of data, what about performance issues ? with hibernate i can tune many
>>> things on the db. would be glad if you can teach me something about cdo
>>> :)
>>>
>>> Regards Thomas
Re: [CDO] is it what I want ? [message #614149 is a reply to message #109073] Tue, 29 January 2008 14:40 Go to previous message
Thomas is currently offline ThomasFriend
Messages: 151
Registered: July 2009
Senior Member
HI Simon,

will you share your JPA implementation or is it closed source ?
Would be great if I could have a look into it.

Regards Thomas

Simon McDuff schrieb:
> Hi Thomas,
>
> I would like to share our experience with CDO and Query.
>
> To use a more standard API, we develop a basic (not complete yet) JPA
> implementation using CDO.
> For the query, (this is the part I want to mention you) we use OCL as our
> language.
>
> From EntityManager we use createNativeQuery() method to pass the string from
> the client to the server.
>
> On the server we delegate the call to the IStoreQuery
>
> Now, to be able to execute it the database provider could have 2 choices :
>
> - Convert the OCL language to an SQL
> - Use extension point in OCL to interact with your database.
>
> It returns a list of ID.. so you no dot load all tha data.
>
> So far we used solutions number 2.
>
> I hope this can help you.
>
Re: [CDO] is it what I want ? [message #614152 is a reply to message #109047] Tue, 29 January 2008 15:23 Go to previous message
Eike Stepper is currently offline Eike StepperFriend
Messages: 6579
Registered: July 2009
Senior Member
Hi Thomas,

A CDOSession has a setReferenceChunkSize() method which you can call to
limit the number of objects (ids) to load on collection read accesses.
Since read access (loading) is handled by the CDOSession all CDOViews on
that session share this setting. We are currently discussing to provide
an additional session property: InitialReferenceChunkSize. Then you
could even configure to load nothing on the first access (of the source
object) and max n targets on subsequent reference accesses. At the
moment I'd suggest to set a value of 10-100 so that you're shielded
against huge collections.

Regards,
Eike Stepper
----
http://wiki.eclipse.org/CDO
http://wiki.eclipse.org/Net4j



Thomas schrieb:
> Once again..
> Another thing coming to my mind is about the object graph. Suggest I
> have a Object Person with a Collection of Adresses. when I query for
> the person did I get it right that the Adresse are only loaded when I
> try to access them ? That would be the main decision factor for me. I
> have expensive objects and the more the could be lazy loaded the
> better my ui handling would be.
>
> Regards Thomas


Re: [CDO] is it what I want ? [message #614154 is a reply to message #109034] Tue, 29 January 2008 15:54 Go to previous message
Eike Stepper is currently offline Eike StepperFriend
Messages: 6579
Registered: July 2009
Senior Member
This is a multi-part message in MIME format.
--------------020908040203020601060508
Content-Type: text/plain; charset=ISO-8859-15; format=flowed
Content-Transfer-Encoding: 7bit

Thomas schrieb:
> Hello Eike,
>
> thanks for your reply. Im just evaluating. So Ill open a request as
> soon as I decide to dive deeper into it. If I understand you right the
> query will be executed on the server and has to be pure sql. For that
> I would have to learn about the mapping strategy (am used to hibernate
> though). How would such an sql query have to look like ?
As you suspected this depends on the mapping strategy and its
configuration. Here some explanation about the default horizontal
mapping strategy of CDO:
1) Each concrete class of the model is mapped to one non-shared table.
There is potentially some name mangling applied which is DB adapter
specific. If you pay a bit attention when modeling class names and table
names should be identical.
2) Each table of 1) contains the following "system" columns:
| /**
* Field names of attribute tables
*/
*public static final *String ATTRIBUTES_ID = "cdo_id";

*public static final *String ATTRIBUTES_VERSION = "cdo_version";

*public static final *String ATTRIBUTES_CLASS = "cdo_class";

*public static final *String ATTRIBUTES_CREATED = "cdo_created";

*public static final *String ATTRIBUTES_REVISED = "cdo_revised";

*public static final *String ATTRIBUTES_RESOURCE = "cdo_resource";

*public static final *String ATTRIBUTES_CONTAINER = "cdo_container";

*public static final *String ATTRIBUTES_FEATURE = "cdo_feature";|


3) Each row in such tables is identified by cdo_id and cdo_version
columns (PK).
cdo_class is a foreign key into the table cdo_classes (mapped meta
model),
cdo_created and cdo_revised are timestamps,
cdo_resource is the CDOID of the containing Resource object
(cdo_resource table),
cdo_container is the CDOID of the containing EObject (same or
another model table),
cdo_feature is a foreign key into the table cdo_features (mapped
meta model).

4) The attributes and single references of the mapped class form the
additional columns.
5) Each *many* reference of a class is mapped to a separate table (per
default) with name := cdoClass.getName() + "_" + cdoFeature.getName() +
"_refs". These "collection tables" can also be shared on class, package
or repository level, names will change then, see
org.eclipse.emf.cdo.server.internal.db.ReferenceMapping.mapR eference(CDOClass,
CDOFeature).
6) A reference table has the following format:
| /**
* Field names of reference tables
*/
*public static final *String REFERENCES_FEATURE = "cdo_feature";

*public static final *String REFERENCES_SOURCE = "cdo_source";

*public static final *String REFERENCES_VERSION = "cdo_version";

*public static final *String REFERENCES_IDX = "cdo_idx";

*public static final *String REFERENCES_TARGET = "cdo_target";|

cdo_feature is only present if the table is shared by several
references.
cdo_source is the CDOID of the source object.
cdo_source is the version of the source object.
cdo_target is the CDOID of the target object.
cdo_idx is the ordinal position of the target object with the
reference list.

I know this is only rough information but I hope it helps to gain a picture.

> I understand that I would have to implement the queries on the client
> side then, but that should be no problem.
If by "implementing" you mean writing a java string literal, yes.

> Another question I have is about mapping. Suggest I have an EMF model
> (playing around with it right now) how is it mapped qo the db ? are
> there annotations for eg varchar length, nullability etc ?
Not so far. If you have a clear picture of what you'd like to configure
and how you'd like to do that (annotations?) I'm open for enhancement
requests.

Regards,
Eike Stepper
----
http://wiki.eclipse.org/CDO
http://wiki.eclipse.org/Net4j


> I have to look into emf validation as for now I have hibernate
> validators bound into the databinding framework that do client side
> validation. many questions :)
>
> Regards Thomas
>
> Eike Stepper schrieb:
>> Hi Thomas,
>>
>> With CDO you need a CDOView to access model objects. CDOView in the
>> current 0.8 stream doesn't have API to query the repository. The
>> former stream had it, but since 0.8 is a complete rewrite this is one
>> of the few outstanding features to be rewritten. If you open an
>> enhancement request I can add a method like the following:
>> | /**
>> * Sends a query to the repository and returns a list of the
>> matching objects or an empty list if no object matched
>> * the query. The query must be in a language that is supported by
>> the store of the repository. For example, if the
>> * repository of this view's session has a DBStore configured, the
>> query must be a valid SQL select statement.
>> */
>> *public *EList<CDOObject> query(String query);|
>>
>>
>> CDO is basically DB independent. In fact it is even not bound to work
>> with JDBC databases. An IRepository works with an IStore which I have
>> implemented as DBStore (JDBC connection plus O/R mapping). There's
>> also a MEMStore and another user has developed an OODBStore
>> (non-public so far). The DBStore itself is independent of different
>> DB vendors (driver and dialect). CDO ships with DB adapters for
>> Derby, Hsqldb and Mysql. It is very easy to develop other DB
>> adapters. An example is the DerbyAdapter:
>> |/********************************************************** *****************
>>
>> * Copyright (c) 2004 - 2008 Eike Stepper, Germany.
>> * All rights reserved. This program and the accompanying materials
>> * are made available under the terms of the Eclipse Public License v1.0
>> * which accompanies this distribution, and is available at
>> * http://www.eclipse.org/legal/epl-v10.html
>> * * Contributors:
>> * Eike Stepper - initial API and implementation
>> ************************************************************ **************/
>>
>> *package *org.eclipse.net4j.db.internal.derby;
>>
>> *import *org.eclipse.net4j.db.DBType;
>> *import *org.eclipse.net4j.db.ddl.IDBField;
>> *import *org.eclipse.net4j.internal.db.DBAdapter;
>> *import *org.eclipse.net4j.internal.db.ddl.DBField;
>>
>> *import *org.apache.derby.jdbc.EmbeddedDriver;
>>
>> *import *java.sql.Driver;
>> *import *java.util.Arrays;
>>
>> /**
>> * @author Eike Stepper
>> */
>> *public class *DerbyAdapter *extends *DBAdapter
>> {
>> *private static final *String[] RESERVED_WORDS = { "ADD", "ALL",
>> "ALLOCATE", "ALTER", "AND", "ANY", "ARE", "AS", "ASC",
>> "ASSERTION", "AT", "AUTHORIZATION", "AVG", "BEGIN", "BETWEEN",
>> "BIGINT", "BIT", "BOOLEAN", "BOTH", "BY", "CALL",
>> "CASCADE", "CASCADED", "CASE", "CAST", "CHAR", "CHARACTER",
>> "CHECK", "CLOSE", "COALESCE", "COLLATE", "COLLATION",
>> "COLUMN", "COMMIT", "CONNECT", "CONNECTION", "CONSTRAINT",
>> "CONSTRAINTS", "CONTINUE", "CONVERT", "CORRESPONDING",
>> "CREATE", "CURRENT", "CURRENT_DATE", "CURRENT_TIME",
>> "CURRENT_TIMESTAMP", "CURRENT_USER", "CURSOR", "DEALLOCATE",
>> "DEC", "DECIMAL", "DECLARE", "DEFAULT", "DEFERRABLE",
>> "DEFERRED", "DELETE", "DESC", "DESCRIBE", "DIAGNOSTICS",
>> "DISCONNECT", "DISTINCT", "DOUBLE", "DROP", "ELSE", "END",
>> "END-EXEC", "ESCAPE", "EXCEPT", "EXCEPTION", "EXEC",
>> "EXECUTE", "EXISTS", "EXPLAIN", "EXTERNAL", "FALSE", "FETCH",
>> "FIRST", "FLOAT", "FOR", "FOREIGN", "FOUND",
>> "FROM", "FULL", "FUNCTION", "GET", "GETCURRENTCONNECTION",
>> "GLOBAL", "GO", "GOTO", "GRANT", "GROUP", "HAVING",
>> "HOUR", "IDENTITY", "IMMEDIATE", "IN", "INDICATOR",
>> "INITIALLY", "INNER", "INOUT", "INPUT", "INSENSITIVE",
>> "INSERT", "INT", "INTEGER", "INTERSECT", "INTO", "IS",
>> "ISOLATION", "JOIN", "KEY", "LAST", "LEFT", "LIKE",
>> "LOWER", "LTRIM", "MATCH", "MAX", "MIN", "MINUTE", "NATIONAL",
>> "NATURAL", "NCHAR", "NVARCHAR", "NEXT", "NO",
>> "NOT", "NULL", "NULLIF", "NUMERIC", "OF", "ON", "ONLY", "OPEN",
>> "OPTION", "OR", "ORDER", "OUTER", "OUTPUT",
>> "OVERLAPS", "PAD", "PARTIAL", "PREPARE", "PRESERVE", "PRIMARY",
>> "PRIOR", "PRIVILEGES", "PROCEDURE", "PUBLIC",
>> "READ", "REAL", "REFERENCES", "RELATIVE", "RESTRICT", "REVOKE",
>> "RIGHT", "ROLLBACK", "ROWS", "RTRIM", "SCHEMA",
>> "SCROLL", "SECOND", "SELECT", "SESSION_USER", "SET",
>> "SMALLINT", "SOME", "SPACE", "SQL", "SQLCODE", "SQLERROR",
>> "SQLSTATE", "SUBSTR", "SUBSTRING", "SUM", "SYSTEM_USER",
>> "TABLE", "TEMPORARY", "TIMEZONE_HOUR",
>> "TIMEZONE_MINUTE", "TO", "TRANSACTION", "TRANSLATE",
>> "TRANSLATION", "TRIM", "TRUE", "UNION", "UNIQUE", "UNKNOWN",
>> "UPDATE", "UPPER", "USER", "USING", "VALUES", "VARCHAR",
>> "VARYING", "VIEW", "WHENEVER", "WHERE", "WITH", "WORK",
>> "WRITE", "XML", "XMLEXISTS", "XMLPARSE", "XMLQUERY",
>> "XMLSERIALIZE", "YEAR" };
>>
>> *public *DerbyAdapter()
>> {
>> *super*("derby", "10.2.2.0");
>> }
>>
>> *public *Driver getJDBCDriver()
>> {
>> *return new *EmbeddedDriver();
>> }
>>
>> @Override
>> *protected *String getTypeName(DBField field)
>> {
>> DBType type = field.getType();
>> *switch *(type)
>> {
>> *case *BOOLEAN:
>> *case *BIT:
>> *return *"SMALLINT";
>> }
>>
>> *return super*.getTypeName(field);
>> }
>>
>> @Override
>> *public **void *appendValue(StringBuilder builder, IDBField field,
>> Object value)
>> {
>> *if *(value *instanceof *Boolean)
>> {
>> value = (Boolean)value ? 1 : 0;
>> }
>>
>> *super*.appendValue(builder, field, value);
>> }
>>
>> @Override
>> *protected **boolean *isReservedWord(String word)
>> {
>> *return *Arrays.binarySearch(RESERVED_WORDS, word.toUpperCase())
>> >= 0;
>> }
>> }|
>>
>>
>> The performance of CDO is highly optimized especially between the
>> client and the repository (above the store implementation). The
>> DBStore (the facility that is responsible for server side O/R
>> mapping) seems fast to me, but I have no evidence for it since we
>> haven't started to implement a comparable IStore on the base of
>> server side Hibernate. I suggest that you try the DBStore and report
>> your experiences here ;-)
>>
>> If you have more questions, please don't hesitate to ask them here.
>>
>> Regards,
>> Eike Stepper
>> ----
>> http://wiki.eclipse.org/CDO
>> http://wiki.eclipse.org/Net4j
>>
>>
>>
>> Thomas schrieb:
>>> HI I learned about teneo and cdo only the last couple of days. I
>>> like soemthink about cdo, but I wonder if its hwat I actually want.
>>> I have a typical three tiered architecture. currently i have JPA
>>> entities persited with hibernate in my domain model. what I like is
>>> that CDO promises to handle the lazy loading of the model to the
>>> client (which I currently cant with hibernate) for a single business
>>> object i always have to load the whole object graph and transfer it
>>> to the client. But I come from relational database background. so I
>>> wonder if i have an emf model for everything, how can i query it
>>> (for e.g. give me all persons with name like '%Thomas%' ? how is the
>>> cdo persistence layer ? I want to be db independant (at least
>>> postgres, sql server, oracle). I have tons of data, what about
>>> performance issues ? with hibernate i can tune many things on the
>>> db. would be glad if you can teach me something about cdo :)
>>>
>>> Regards Thomas

--------------020908040203020601060508
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">
Thomas schrieb:
<blockquote cite="mid:fnncgj$ktv$1@build.eclipse.org" type="cite">Hello
Eike,
<br>
<br>
thanks for your reply. Im just evaluating. So Ill open a request as
soon as I decide to dive deeper into it. If I understand you right the
query will be executed on the server and has to be pure sql. For that I
would have to learn about the mapping strategy (am used to hibernate
though). How would such an sql query have to look like ? </blockquote>
As you suspected this depends on the mapping strategy and its
configuration. Here some explanation about the default horizontal
mapping strategy of CDO:<br>
1) Each concrete class of the model is mapped to one non-shared table.
There is potentially some name mangling applied which is DB adapter
specific. If you pay a bit attention when modeling class names and
table names should be identical.<br>
2) Each table of 1) contains the following "system" columns:<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] is it what I want ? [message #614155 is a reply to message #109099] Tue, 29 January 2008 15:55 Go to previous message
Simon Mc Duff is currently offline Simon Mc DuffFriend
Messages: 596
Registered: July 2009
Senior Member
It is not a closed source !! :-)

You will not be able to query ... since your Store need to provide how you
will handle the ocl expression (or something else). We did it only for our
OODB database

This is the only feature we've been implemented yet :

refresh (You can refresh your resource, an object or a list of objects)
begin
commit
getReference
rollback

XATransaction isn't supported yet :-(

Let me know if this still interest you.

If this is the case, I will maybe work on an implemtation to query other
Store...So the query mechanism will work for you as well.

Simon




"Thomas" <tom@eiswind.de> wrote in message
news:fnndtr$tpr$1@build.eclipse.org...
> HI Simon,
>
> will you share your JPA implementation or is it closed source ?
> Would be great if I could have a look into it.
>
> Regards Thomas
>
> Simon McDuff schrieb:
>> Hi Thomas,
>>
>> I would like to share our experience with CDO and Query.
>>
>> To use a more standard API, we develop a basic (not complete yet) JPA
>> implementation using CDO.
>> For the query, (this is the part I want to mention you) we use OCL as our
>> language.
>>
>> From EntityManager we use createNativeQuery() method to pass the string
>> from the client to the server.
>>
>> On the server we delegate the call to the IStoreQuery
>>
>> Now, to be able to execute it the database provider could have 2 choices
>> :
>>
>> - Convert the OCL language to an SQL
>> - Use extension point in OCL to interact with your database.
>>
>> It returns a list of ID.. so you no dot load all tha data.
>>
>> So far we used solutions number 2.
>>
>> I hope this can help you.
>>
>
Re: [CDO] is it what I want ? [message #614156 is a reply to message #109181] Tue, 29 January 2008 16:02 Go to previous message
Eike Stepper is currently offline Eike StepperFriend
Messages: 6579
Registered: July 2009
Senior Member
Simon,

After all the work with CDO it is a real pleasure to see you
contributing and together we've also managed to apply a lot of
enhancements. Thanks a lot!!!

Cheers
/Eike



Simon McDuff schrieb:
> It is not a closed source !! :-)
>
> You will not be able to query ... since your Store need to provide how you
> will handle the ocl expression (or something else). We did it only for our
> OODB database
>
> This is the only feature we've been implemented yet :
>
> refresh (You can refresh your resource, an object or a list of objects)
> begin
> commit
> getReference
> rollback
>
> XATransaction isn't supported yet :-(
>
> Let me know if this still interest you.
>
> If this is the case, I will maybe work on an implemtation to query other
> Store...So the query mechanism will work for you as well.
>
> Simon
>
>
>
>
> "Thomas" <tom@eiswind.de> wrote in message
> news:fnndtr$tpr$1@build.eclipse.org...
>
>> HI Simon,
>>
>> will you share your JPA implementation or is it closed source ?
>> Would be great if I could have a look into it.
>>
>> Regards Thomas
>>
>> Simon McDuff schrieb:
>>
>>> Hi Thomas,
>>>
>>> I would like to share our experience with CDO and Query.
>>>
>>> To use a more standard API, we develop a basic (not complete yet) JPA
>>> implementation using CDO.
>>> For the query, (this is the part I want to mention you) we use OCL as our
>>> language.
>>>
>>> From EntityManager we use createNativeQuery() method to pass the string
>>> from the client to the server.
>>>
>>> On the server we delegate the call to the IStoreQuery
>>>
>>> Now, to be able to execute it the database provider could have 2 choices
>>> :
>>>
>>> - Convert the OCL language to an SQL
>>> - Use extension point in OCL to interact with your database.
>>>
>>> It returns a list of ID.. so you no dot load all tha data.
>>>
>>> So far we used solutions number 2.
>>>
>>> I hope this can help you.
>>>
>>>
>
>
>


Re: [CDO] is it what I want ? [message #614157 is a reply to message #109181] Tue, 29 January 2008 16:51 Go to previous message
Thomas is currently offline ThomasFriend
Messages: 151
Registered: July 2009
Senior Member
Hi Simon,

Im just getting started, but I will love to have a look at it.

Can I get access anywhere ?

Thomas

Simon McDuff schrieb:
> It is not a closed source !! :-)
>
> You will not be able to query ... since your Store need to provide how you
> will handle the ocl expression (or something else). We did it only for our
> OODB database
>
> This is the only feature we've been implemented yet :
>
> refresh (You can refresh your resource, an object or a list of objects)
> begin
> commit
> getReference
> rollback
>
> XATransaction isn't supported yet :-(
>
> Let me know if this still interest you.
>
> If this is the case, I will maybe work on an implemtation to query other
> Store...So the query mechanism will work for you as well.
>
> Simon
Re: [CDO] is it what I want ? [message #614158 is a reply to message #109138] Tue, 29 January 2008 17:09 Go to previous message
Thomas is currently offline ThomasFriend
Messages: 151
Registered: July 2009
Senior Member
HI Eike, this seems to be what I would need.
I overlooked your mapping hints (will have to see this in an example
maybe tommorrow.) what I dislike is the relation tables. as i do
reporting with birt i will have to query the database with sql and th
relation tables make manual joining a pain. I know some dtabase gurus
recommend join tables but I still prefer a single foreign key in the
target table. ok you need a single column then for each relation (give
it a speaking name and everthing is clear) why is the version part of
the primary key ? that doesnt make sense to me. maybe you have reasons
but i would expect that the db has only a single version stored. and
again here pain in joining. what kinds of relations are supported ?

What about Lobs ? is there support for large objects ?

We would at least need to supply not null constraints on fields and
ManyToOne relations, field lengthes for character strings, plus I have
to dive into the validation problem. plus i need something for unique
key constraints and indexes.

Thomas

Eike Stepper schrieb:
> Hi Thomas,
>
> A CDOSession has a setReferenceChunkSize() method which you can call to
> limit the number of objects (ids) to load on collection read accesses.
> Since read access (loading) is handled by the CDOSession all CDOViews on
> that session share this setting. We are currently discussing to provide
> an additional session property: InitialReferenceChunkSize. Then you
> could even configure to load nothing on the first access (of the source
> object) and max n targets on subsequent reference accesses. At the
> moment I'd suggest to set a value of 10-100 so that you're shielded
> against huge collections.
>
> Regards,
> Eike Stepper
> ----
> http://wiki.eclipse.org/CDO
> http://wiki.eclipse.org/Net4j
>
>
>
> Thomas schrieb:
>> Once again..
>> Another thing coming to my mind is about the object graph. Suggest I
>> have a Object Person with a Collection of Adresses. when I query for
>> the person did I get it right that the Adresse are only loaded when I
>> try to access them ? That would be the main decision factor for me. I
>> have expensive objects and the more the could be lazy loaded the
>> better my ui handling would be.
>>
>> Regards Thomas
Re: [CDO] is it what I want ? [message #614225 is a reply to message #109216] Wed, 30 January 2008 10:19 Go to previous message
Eike Stepper is currently offline Eike StepperFriend
Messages: 6579
Registered: July 2009
Senior Member
Thomas schrieb:
> HI Eike, this seems to be what I would need.
> I overlooked your mapping hints (will have to see this in an example
> maybe tommorrow.) what I dislike is the relation tables. as i do
> reporting with birt i will have to query the database with sql and th
> relation tables make manual joining a pain. I know some dtabase gurus
> recommend join tables but I still prefer a single foreign key in the
> target table. ok you need a single column then for each relation (give
> it a speaking name and everthing is clear)
What I don't like with the foreign key joins you mention is the following:
Assume you are a big IT company and you have many application with one
development team being responsible for one application. The applications
have non-circular dependencies on each other and this is clearly
reflected within the models that form the applications. As long as
you're modeling there's at no time the need to modify foreign code (the
models you depend on). Consider the following example:
Team1, January 2008, develops a model Employees. There is an EClass
Employee.
Team2, March 2008, develops the model Supervisors. There is an EClass
Supervisor with a many-reference supervisedEmployees:List<Emplyoee>.

In the OO world there's no need for Team2 to touch code of Team1.
If the many-reference supervisedEmployees is mapped to a dedicated join
table there's also no responsibility conflict in the DB team of your
company.
But when it comes to O/R mapping of supervisedEmployees with foreign
keys in the table of Employee there is no longer a clear responsibility
for that class!
The same is true for m:n references across model boundaries.

> why is the version part of the primary key ? that doesnt make sense to
> me. maybe you have reasons but i would expect that the db has only a
> single version stored. and again here pain in joining.
CDO is basically capable of auditing (retrieving historical states of
the overall model). I guess it's a similar effect like the one the new
Temporality project announces. An Istore decides if it supports auditing
mode and if it supports non-auditing mode. The DBStore currently does
only support auditing mode! I'm currently a bit unsure what to
prioritize: Make DBStore support non-auditing mode or help Martin
develop a HibernateStore for CDO. I guess you'll vote for the latter ;-)
I'd agree.

> what kinds of relations are supported ?
Single-valued references are mapped to CDOID columns in the table of the
referencing EClass.
Multi-valued references are mapped to the join tables I mentioned before.
Was this what you asked for?

>
> What about Lobs ? is there support for large objects ?
In which context? For mapping multi-valued references? This is planned
via org.eclipse.emf.cdo.server.internal.db.ToMany.LIKE_ATTRIBUTE S. I'd
make querying even harder.

>
> We would at least need to supply not null constraints
That could make a good Bugzilla (A) ;-)

> on fields and ManyToOne relations,
See my above concerns. A separate Bugzilla (B) could be good to discuss
these concerns.

> field lengthes for character strings,
Fits well into the Bugzilla (A).

> plus I have to dive into the validation problem. plus i need something
> for unique key constraints and indexes.
What is the validation problem? The one Simon solved via OCL?
Unique key constraints and indexes could go into (A) as well.

One general comment to all this mapping stuff: As you correctly analyzed
in another thread, CDO is not mainly about providing a new O/R mapping
solution. Hibernate will probably always be better here and I didn't
plan to compete with it. CDO is more focused on providing a stable and
efficient 3-tier solution (client / repository / store) with distributed
shared model semantics (remote update notifications) and an auditing
mode. The store even doesn't need to be a relational database.

I think it's time for me to dig into the Hibernate code and work with
Martin to develop a HibernateStore for the CDO storage framework.

Regards,
Eike Stepper
----
http://wiki.eclipse.org/CDO
http://wiki.eclipse.org/Net4j


>
> Thomas
>
> Eike Stepper schrieb:
>> Hi Thomas,
>>
>> A CDOSession has a setReferenceChunkSize() method which you can call
>> to limit the number of objects (ids) to load on collection read
>> accesses. Since read access (loading) is handled by the CDOSession
>> all CDOViews on that session share this setting. We are currently
>> discussing to provide an additional session property:
>> InitialReferenceChunkSize. Then you could even configure to load
>> nothing on the first access (of the source object) and max n targets
>> on subsequent reference accesses. At the moment I'd suggest to set a
>> value of 10-100 so that you're shielded against huge collections.
>>
>> Regards,
>> Eike Stepper
>> ----
>> http://wiki.eclipse.org/CDO
>> http://wiki.eclipse.org/Net4j
>>
>>
>>
>> Thomas schrieb:
>>> Once again..
>>> Another thing coming to my mind is about the object graph. Suggest I
>>> have a Object Person with a Collection of Adresses. when I query for
>>> the person did I get it right that the Adresse are only loaded when
>>> I try to access them ? That would be the main decision factor for
>>> me. I have expensive objects and the more the could be lazy loaded
>>> the better my ui handling would be.
>>>
>>> Regards Thomas


Re: [CDO] is it what I want ? [message #614244 is a reply to message #109524] Wed, 30 January 2008 10:59 Go to previous message
Thomas is currently offline ThomasFriend
Messages: 151
Registered: July 2009
Senior Member
Consider the following example:
> Team1, January 2008, develops a model Employees. There is an EClass
> Employee.
> Team2, March 2008, develops the model Supervisors. There is an EClass
> Supervisor with a many-reference supervisedEmployees:List<Emplyoee>.
>
> In the OO world there's no need for Team2 to touch code of Team1.
> If the many-reference supervisedEmployees is mapped to a dedicated join
> table there's also no responsibility conflict in the DB team of your
> company.
> But when it comes to O/R mapping of supervisedEmployees with foreign
> keys in the table of Employee there is no longer a clear responsibility
> for that class!
> The same is true for m:n references across model boundaries.

OK I see your argument. I just want to be pragmatic all the time when it
comes to use native sql queries. :)

>
>> why is the version part of the primary key ? that doesnt make sense to
>> me. maybe you have reasons but i would expect that the db has only a
>> single version stored. and again here pain in joining.
> CDO is basically capable of auditing (retrieving historical states of
> the overall model). I guess it's a similar effect like the one the new
> Temporality project announces.

Ok then you have mutliple versions. But I would (personal taste ?)
prefer a single column surrogate primary key in any case. There are some
techniques on versioning (take three add columns columns, a group id
that groups the versions a counter/timestamp and a boolean, set the
boolean true for the current version, put a unique constraint on
group_id and version) timestamp makes problems on oracle as it not
finegrained enough for have load, so i prefer a counter or a mix of both
of it. its just the idea of having a clean surrogate key that i always
prefer.



>> what kinds of relations are supported ?
> Single-valued references are mapped to CDOID columns in the table of the
> referencing EClass.
> Multi-valued references are mapped to the join tables I mentioned before.
> Was this what you asked for?

yes

>
>>
>> What about Lobs ? is there support for large objects ?
> In which context? For mapping multi-valued references? This is planned
> via org.eclipse.emf.cdo.server.internal.db.ToMany.LIKE_ATTRIBUTE S. I'd
> make querying even harder.

I mean very long Strings or ByteArrays. Hibernate does that with @Lob

>> We would at least need to supply not null constraints
> That could make a good Bugzilla (A) ;-)
>
>> on fields and ManyToOne relations,
> See my above concerns. A separate Bugzilla (B) could be good to discuss
> these concerns.
>
>> field lengthes for character strings,
> Fits well into the Bugzilla (A).
>
>> plus I have to dive into the validation problem. plus i need something
>> for unique key constraints and indexes.
> What is the validation problem? The one Simon solved via OCL?
> Unique key constraints and indexes could go into (A) as well.
>
> One general comment to all this mapping stuff: As you correctly analyzed
> in another thread, CDO is not mainly about providing a new O/R mapping
> solution. Hibernate will probably always be better here and I didn't
> plan to compete with it. CDO is more focused on providing a stable and
> efficient 3-tier solution (client / repository / store) with distributed
> shared model semantics (remote update notifications) and an auditing
> mode. The store even doesn't need to be a relational database.
>
> I think it's time for me to dig into the Hibernate code and work with
> Martin to develop a HibernateStore for the CDO storage framework.
>


Hmm Eike, dont know if I should open bugs on this if we dig into teneo.
Why put so much effort in there when we already have (nearly)everything
we need at hand ?

Regarding the task force I think I can try to support you. I just dont
know how much time I can put in there, can be that I have a new project
next week, can be that I have lots of time to spent in february.

What Im not happy with (other thread..) is not your implementation at
all. Things are as they are :) I have to learn about your fetching
strategy and proxiing will try to look into that tonight. It is that
hibernate puts its own proxies in there and we have to find a way to
make it play together.

another point i see is that you put additional columns and tables in the
db, and teneo seems to have its own way to to that. dont know up to now
how much the dbstore api depends on that.

its another point that teneo builds on the hbm mapping files (that goes
to the teneo audience:). if we had pure jpa entities we could have
integration with eclipseLink, openJpa or whatever.


Regards Thomas
Re: [CDO] is it what I want ? [message #614246 is a reply to message #109524] Wed, 30 January 2008 11:01 Go to previous message
Martin Taal is currently offline Martin TaalFriend
Messages: 5468
Registered: July 2009
Senior Member
Hi Eike, Thomas,
I will start looking at the integration between CDO and Teneo today. I first need to get familiar
with cdo and then I can see how Teneo can be integrated. I'll keep you posted.

See my other additions below.

gr. Martin

Eike Stepper wrote:
> Thomas schrieb:
>> HI Eike, this seems to be what I would need.
>> I overlooked your mapping hints (will have to see this in an example
>> maybe tommorrow.) what I dislike is the relation tables. as i do
>> reporting with birt i will have to query the database with sql and th
>> relation tables make manual joining a pain. I know some dtabase gurus
>> recommend join tables but I still prefer a single foreign key in the
>> target table. ok you need a single column then for each relation (give
>> it a speaking name and everthing is clear)
> What I don't like with the foreign key joins you mention is the following:
> Assume you are a big IT company and you have many application with one
> development team being responsible for one application. The applications
> have non-circular dependencies on each other and this is clearly
> reflected within the models that form the applications. As long as
> you're modeling there's at no time the need to modify foreign code (the
> models you depend on). Consider the following example:
> Team1, January 2008, develops a model Employees. There is an EClass
> Employee.
> Team2, March 2008, develops the model Supervisors. There is an EClass
> Supervisor with a many-reference supervisedEmployees:List<Emplyoee>.
>
> In the OO world there's no need for Team2 to touch code of Team1.
> If the many-reference supervisedEmployees is mapped to a dedicated join
> table there's also no responsibility conflict in the DB team of your
> company.
> But when it comes to O/R mapping of supervisedEmployees with foreign
> keys in the table of Employee there is no longer a clear responsibility
> for that class!
> The same is true for m:n references across model boundaries.
MT>> I have a background in developing ERP systems and there it was also common to use a foreign key
field instead of join tables. A number of thoughts from my side regarding this topic:
- as Eike mentions foreign keys are more intruisive than join table as the target table gets changed
(has an extra foreign key field(s))
- Foreign keys are more efficient as there is one less join to do
- Foreign keys do not support duplicate occurences in a list (join tables do, assuming a join table
has a separate id column).
- Specifically for containment relations my feel is that a foreign key field is appropriate as it
reflects the stronger relation between the child and the parent. The same can be said for
bidirectional relations.

Overall I have the same feel as Thomas, with my background I like foreign keys (as they are more
efficient) but I understand that there are many people with other ideas. Teneo has an option to
specify if all non-containment relations should be mapped with a join table (or not).

>
>> why is the version part of the primary key ? that doesnt make sense to
>> me. maybe you have reasons but i would expect that the db has only a
>> single version stored. and again here pain in joining.
> CDO is basically capable of auditing (retrieving historical states of
> the overall model). I guess it's a similar effect like the one the new
> Temporality project announces. An Istore decides if it supports auditing
> mode and if it supports non-auditing mode. The DBStore currently does
> only support auditing mode! I'm currently a bit unsure what to
> prioritize: Make DBStore support non-auditing mode or help Martin
> develop a HibernateStore for CDO. I guess you'll vote for the latter ;-)
> I'd agree.
MT>> I will start looking at CDO today and try out the tutorial, etc. Maybe I can get a long way
without asking to much of your time Eike (so then you can do both :-).
MT>> Btw, imo it is great that CDO also considers topics like auditing, these generic topics can
really be solved at this level.

>
>> what kinds of relations are supported ?
> Single-valued references are mapped to CDOID columns in the table of the
> referencing EClass.
> Multi-valued references are mapped to the join tables I mentioned before.
> Was this what you asked for?
>
>>
>> What about Lobs ? is there support for large objects ?
> In which context? For mapping multi-valued references? This is planned
> via org.eclipse.emf.cdo.server.internal.db.ToMany.LIKE_ATTRIBUTE S. I'd
> make querying even harder.
>
>>
>> We would at least need to supply not null constraints
> That could make a good Bugzilla (A) ;-)
>
>> on fields and ManyToOne relations,
> See my above concerns. A separate Bugzilla (B) could be good to discuss
> these concerns.
>
>> field lengthes for character strings,
> Fits well into the Bugzilla (A).
>
>> plus I have to dive into the validation problem. plus i need something
>> for unique key constraints and indexes.
> What is the validation problem? The one Simon solved via OCL?
> Unique key constraints and indexes could go into (A) as well.
>
> One general comment to all this mapping stuff: As you correctly analyzed
> in another thread, CDO is not mainly about providing a new O/R mapping
> solution. Hibernate will probably always be better here and I didn't
> plan to compete with it. CDO is more focused on providing a stable and
> efficient 3-tier solution (client / repository / store) with distributed
> shared model semantics (remote update notifications) and an auditing
> mode. The store even doesn't need to be a relational database.
>
> I think it's time for me to dig into the Hibernate code and work with
> Martin to develop a HibernateStore for the CDO storage framework.
>
> Regards,
> Eike Stepper
> ----
> http://wiki.eclipse.org/CDO
> http://wiki.eclipse.org/Net4j
>
>
>>
>> Thomas
>>
>> Eike Stepper schrieb:
>>> Hi Thomas,
>>>
>>> A CDOSession has a setReferenceChunkSize() method which you can call
>>> to limit the number of objects (ids) to load on collection read
>>> accesses. Since read access (loading) is handled by the CDOSession
>>> all CDOViews on that session share this setting. We are currently
>>> discussing to provide an additional session property:
>>> InitialReferenceChunkSize. Then you could even configure to load
>>> nothing on the first access (of the source object) and max n targets
>>> on subsequent reference accesses. At the moment I'd suggest to set a
>>> value of 10-100 so that you're shielded against huge collections.
>>>
>>> Regards,
>>> Eike Stepper
>>> ----
>>> http://wiki.eclipse.org/CDO
>>> http://wiki.eclipse.org/Net4j
>>>
>>>
>>>
>>> Thomas schrieb:
>>>> Once again..
>>>> Another thing coming to my mind is about the object graph. Suggest I
>>>> have a Object Person with a Collection of Adresses. when I query for
>>>> the person did I get it right that the Adresse are only loaded when
>>>> I try to access them ? That would be the main decision factor for
>>>> me. I have expensive objects and the more the could be lazy loaded
>>>> the better my ui handling would be.
>>>>
>>>> Regards Thomas


--

With Regards, Martin Taal

Springsite/Elver.org
Office: Hardwareweg 4, 3821 BV Amersfoort
Postal: Nassaulaan 7, 3941 EC Doorn
The Netherlands
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] is it what I want ? [message #614250 is a reply to message #109576] Wed, 30 January 2008 11:14 Go to previous message
Martin Taal is currently offline Martin TaalFriend
Messages: 5468
Registered: July 2009
Senior Member
Hi Thomas,
Just to react on your last point (to the Teneo audience :) about jpa entities. Hidden within Teneo
there is already a possibility to create jpa annotations which can be placed in the source code (see
the PAnnotation class it has a method getJavaAnnotation(...). I use it myself when generating jpa
entities. However, I am not sure yet how to integrate this with the current code generation of EMF.

I wanted to post a question about this in the emf newsgroup (maybe I'll do that today).

Other then that, EMF has specific list implementations (for supporting bi-directional and
containment and notifications), these do not work out of the box with hibernate (or TopLink)
therefore Teneo also has a runtime layer. But depending on the business case ofcourse these list
implementations are important or not.

gr. Martin

Thomas wrote:
> Consider the following example:
>> Team1, January 2008, develops a model Employees. There is an EClass
>> Employee.
>> Team2, March 2008, develops the model Supervisors. There is an EClass
>> Supervisor with a many-reference supervisedEmployees:List<Emplyoee>.
>>
>> In the OO world there's no need for Team2 to touch code of Team1.
>> If the many-reference supervisedEmployees is mapped to a dedicated
>> join table there's also no responsibility conflict in the DB team of
>> your company.
>> But when it comes to O/R mapping of supervisedEmployees with foreign
>> keys in the table of Employee there is no longer a clear
>> responsibility for that class!
>> The same is true for m:n references across model boundaries.
>
> OK I see your argument. I just want to be pragmatic all the time when it
> comes to use native sql queries. :)
>
>>
>>> why is the version part of the primary key ? that doesnt make sense
>>> to me. maybe you have reasons but i would expect that the db has only
>>> a single version stored. and again here pain in joining.
>> CDO is basically capable of auditing (retrieving historical states of
>> the overall model). I guess it's a similar effect like the one the new
>> Temporality project announces.
>
> Ok then you have mutliple versions. But I would (personal taste ?)
> prefer a single column surrogate primary key in any case. There are some
> techniques on versioning (take three add columns columns, a group id
> that groups the versions a counter/timestamp and a boolean, set the
> boolean true for the current version, put a unique constraint on
> group_id and version) timestamp makes problems on oracle as it not
> finegrained enough for have load, so i prefer a counter or a mix of both
> of it. its just the idea of having a clean surrogate key that i always
> prefer.
>
>
>
>>> what kinds of relations are supported ?
>> Single-valued references are mapped to CDOID columns in the table of
>> the referencing EClass.
>> Multi-valued references are mapped to the join tables I mentioned before.
>> Was this what you asked for?
>
> yes
>
>>
>>>
>>> What about Lobs ? is there support for large objects ?
>> In which context? For mapping multi-valued references? This is planned
>> via org.eclipse.emf.cdo.server.internal.db.ToMany.LIKE_ATTRIBUTE S. I'd
>> make querying even harder.
>
> I mean very long Strings or ByteArrays. Hibernate does that with @Lob
>
>>> We would at least need to supply not null constraints
>> That could make a good Bugzilla (A) ;-)
>>
>>> on fields and ManyToOne relations,
>> See my above concerns. A separate Bugzilla (B) could be good to
>> discuss these concerns.
>>
>>> field lengthes for character strings,
>> Fits well into the Bugzilla (A).
>>
>>> plus I have to dive into the validation problem. plus i need
>>> something for unique key constraints and indexes.
>> What is the validation problem? The one Simon solved via OCL?
>> Unique key constraints and indexes could go into (A) as well.
>>
>> One general comment to all this mapping stuff: As you correctly
>> analyzed in another thread, CDO is not mainly about providing a new
>> O/R mapping solution. Hibernate will probably always be better here
>> and I didn't plan to compete with it. CDO is more focused on providing
>> a stable and efficient 3-tier solution (client / repository / store)
>> with distributed shared model semantics (remote update notifications)
>> and an auditing mode. The store even doesn't need to be a relational
>> database.
>>
>> I think it's time for me to dig into the Hibernate code and work with
>> Martin to develop a HibernateStore for the CDO storage framework.
>>
>
>
> Hmm Eike, dont know if I should open bugs on this if we dig into teneo.
> Why put so much effort in there when we already have (nearly)everything
> we need at hand ?
>
> Regarding the task force I think I can try to support you. I just dont
> know how much time I can put in there, can be that I have a new project
> next week, can be that I have lots of time to spent in february.
>
> What Im not happy with (other thread..) is not your implementation at
> all. Things are as they are :) I have to learn about your fetching
> strategy and proxiing will try to look into that tonight. It is that
> hibernate puts its own proxies in there and we have to find a way to
> make it play together.
>
> another point i see is that you put additional columns and tables in the
> db, and teneo seems to have its own way to to that. dont know up to now
> how much the dbstore api depends on that.
>
> its another point that teneo builds on the hbm mapping files (that goes
> to the teneo audience:). if we had pure jpa entities we could have
> integration with eclipseLink, openJpa or whatever.
>
>
> Regards Thomas


--

With Regards, Martin Taal

Springsite/Elver.org
Office: Hardwareweg 4, 3821 BV Amersfoort
Postal: Nassaulaan 7, 3941 EC Doorn
The Netherlands
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] is it what I want ? [message #614253 is a reply to message #109600] Wed, 30 January 2008 11:30 Go to previous message
Ed Merks is currently offline Ed MerksFriend
Messages: 31900
Registered: July 2009
Senior Member
Martin,

This sounds related a bit to
https://bugs.eclipse.org/bugs/show_bug.cgi?id=176726 I.e., if we had
some kind of GenModel annotation that could be converted to Java 5.0
annotations in the generator so they show up in the generated code. Is
something like that what you'd need? I imagine you already have
annotations though, so some way to being able to influence how they are
converted to Java 5.0 annotations would be nicer...


Martin Taal wrote:
> Hi Thomas,
> Just to react on your last point (to the Teneo audience :) about jpa
> entities. Hidden within Teneo there is already a possibility to create
> jpa annotations which can be placed in the source code (see the
> PAnnotation class it has a method getJavaAnnotation(...). I use it
> myself when generating jpa entities. However, I am not sure yet how to
> integrate this with the current code generation of EMF.
>
> I wanted to post a question about this in the emf newsgroup (maybe
> I'll do that today).
>
> Other then that, EMF has specific list implementations (for supporting
> bi-directional and containment and notifications), these do not work
> out of the box with hibernate (or TopLink) therefore Teneo also has a
> runtime layer. But depending on the business case ofcourse these list
> implementations are important or not.
>
> gr. Martin
>
> Thomas wrote:
>> Consider the following example:
>>> Team1, January 2008, develops a model Employees. There is an EClass
>>> Employee.
>>> Team2, March 2008, develops the model Supervisors. There is an
>>> EClass Supervisor with a many-reference
>>> supervisedEmployees:List<Emplyoee>.
>>>
>>> In the OO world there's no need for Team2 to touch code of Team1.
>>> If the many-reference supervisedEmployees is mapped to a dedicated
>>> join table there's also no responsibility conflict in the DB team of
>>> your company.
>>> But when it comes to O/R mapping of supervisedEmployees with foreign
>>> keys in the table of Employee there is no longer a clear
>>> responsibility for that class!
>>> The same is true for m:n references across model boundaries.
>>
>> OK I see your argument. I just want to be pragmatic all the time when
>> it comes to use native sql queries. :)
>>
>>>
>>>> why is the version part of the primary key ? that doesnt make sense
>>>> to me. maybe you have reasons but i would expect that the db has
>>>> only a single version stored. and again here pain in joining.
>>> CDO is basically capable of auditing (retrieving historical states
>>> of the overall model). I guess it's a similar effect like the one
>>> the new Temporality project announces.
>>
>> Ok then you have mutliple versions. But I would (personal taste ?)
>> prefer a single column surrogate primary key in any case. There are
>> some techniques on versioning (take three add columns columns, a
>> group id that groups the versions a counter/timestamp and a boolean,
>> set the boolean true for the current version, put a unique constraint
>> on group_id and version) timestamp makes problems on oracle as it not
>> finegrained enough for have load, so i prefer a counter or a mix of
>> both of it. its just the idea of having a clean surrogate key that i
>> always prefer.
>>
>>
>>
>>>> what kinds of relations are supported ?
>>> Single-valued references are mapped to CDOID columns in the table of
>>> the referencing EClass.
>>> Multi-valued references are mapped to the join tables I mentioned
>>> before.
>>> Was this what you asked for?
>>
>> yes
>>
>>>
>>>>
>>>> What about Lobs ? is there support for large objects ?
>>> In which context? For mapping multi-valued references? This is
>>> planned via
>>> org.eclipse.emf.cdo.server.internal.db.ToMany.LIKE_ATTRIBUTE S. I'd
>>> make querying even harder.
>>
>> I mean very long Strings or ByteArrays. Hibernate does that with @Lob
>>
>>>> We would at least need to supply not null constraints
>>> That could make a good Bugzilla (A) ;-)
>>>
>>>> on fields and ManyToOne relations,
>>> See my above concerns. A separate Bugzilla (B) could be good to
>>> discuss these concerns.
>>>
>>>> field lengthes for character strings,
>>> Fits well into the Bugzilla (A).
>>>
>>>> plus I have to dive into the validation problem. plus i need
>>>> something for unique key constraints and indexes.
>>> What is the validation problem? The one Simon solved via OCL?
>>> Unique key constraints and indexes could go into (A) as well.
>>>
>>> One general comment to all this mapping stuff: As you correctly
>>> analyzed in another thread, CDO is not mainly about providing a new
>>> O/R mapping solution. Hibernate will probably always be better here
>>> and I didn't plan to compete with it. CDO is more focused on
>>> providing a stable and efficient 3-tier solution (client /
>>> repository / store) with distributed shared model semantics (remote
>>> update notifications) and an auditing mode. The store even doesn't
>>> need to be a relational database.
>>>
>>> I think it's time for me to dig into the Hibernate code and work
>>> with Martin to develop a HibernateStore for the CDO storage framework.
>>>
>>
>>
>> Hmm Eike, dont know if I should open bugs on this if we dig into
>> teneo. Why put so much effort in there when we already have
>> (nearly)everything we need at hand ?
>>
>> Regarding the task force I think I can try to support you. I just
>> dont know how much time I can put in there, can be that I have a new
>> project next week, can be that I have lots of time to spent in february.
>>
>> What Im not happy with (other thread..) is not your implementation at
>> all. Things are as they are :) I have to learn about your fetching
>> strategy and proxiing will try to look into that tonight. It is that
>> hibernate puts its own proxies in there and we have to find a way to
>> make it play together.
>>
>> another point i see is that you put additional columns and tables in
>> the db, and teneo seems to have its own way to to that. dont know up
>> to now how much the dbstore api depends on that.
>>
>> its another point that teneo builds on the hbm mapping files (that
>> goes to the teneo audience:). if we had pure jpa entities we could
>> have integration with eclipseLink, openJpa or whatever.
>>
>>
>> Regards Thomas
>
>


Ed Merks
Professional Support: https://www.macromodeling.com/
Re: [CDO] is it what I want ? [message #614257 is a reply to message #109600] Wed, 30 January 2008 11:41 Go to previous message
Thomas is currently offline ThomasFriend
Messages: 151
Registered: July 2009
Senior Member
Hi Martin,

Martin Taal schrieb:
> Hi Thomas,
> Just to react on your last point (to the Teneo audience :) about jpa
> entities. Hidden within Teneo there is already a possibility to create
> jpa annotations which can be placed in the source code (see the
> PAnnotation class it has a method getJavaAnnotation(...). I use it
> myself when generating jpa entities. However, I am not sure yet how to
> integrate this with the current code generation of EMF.
I saw that before. Im just diving into it so forgive me :)
Its just that I believe theres is great power in bringing all this
together that makes me very interested.

I'm a little conscious about this annotation stuff as one doesnt have
any nice compiler checks on the syntax in the model.


>
> I wanted to post a question about this in the emf newsgroup (maybe I'll
> do that today).
>
> Other then that, EMF has specific list implementations (for supporting
> bi-directional and containment and notifications), these do not work out
> of the box with hibernate (or TopLink) therefore Teneo also has a
> runtime layer. But depending on the business case ofcourse these list
> implementations are important or not.

I was too dumb to do my first simple emf model yesterday, so I will
leave that up to you :)
>
> gr. Martin
>
Re: [CDO] is it what I want ? [message #614259 is a reply to message #109613] Wed, 30 January 2008 11:53 Go to previous message
Martin Taal is currently offline Martin TaalFriend
Messages: 5468
Registered: July 2009
Senior Member
Thanks Ed, I posted a question related to this in the EMF newsgroup.

gr. Martin

Ed Merks wrote:
> Martin,
>
> This sounds related a bit to
> https://bugs.eclipse.org/bugs/show_bug.cgi?id=176726 I.e., if we had
> some kind of GenModel annotation that could be converted to Java 5.0
> annotations in the generator so they show up in the generated code. Is
> something like that what you'd need? I imagine you already have
> annotations though, so some way to being able to influence how they are
> converted to Java 5.0 annotations would be nicer...
>
>
> Martin Taal wrote:
>> Hi Thomas,
>> Just to react on your last point (to the Teneo audience :) about jpa
>> entities. Hidden within Teneo there is already a possibility to create
>> jpa annotations which can be placed in the source code (see the
>> PAnnotation class it has a method getJavaAnnotation(...). I use it
>> myself when generating jpa entities. However, I am not sure yet how to
>> integrate this with the current code generation of EMF.
>>
>> I wanted to post a question about this in the emf newsgroup (maybe
>> I'll do that today).
>>
>> Other then that, EMF has specific list implementations (for supporting
>> bi-directional and containment and notifications), these do not work
>> out of the box with hibernate (or TopLink) therefore Teneo also has a
>> runtime layer. But depending on the business case ofcourse these list
>> implementations are important or not.
>>
>> gr. Martin
>>
>> Thomas wrote:
>>> Consider the following example:
>>>> Team1, January 2008, develops a model Employees. There is an EClass
>>>> Employee.
>>>> Team2, March 2008, develops the model Supervisors. There is an
>>>> EClass Supervisor with a many-reference
>>>> supervisedEmployees:List<Emplyoee>.
>>>>
>>>> In the OO world there's no need for Team2 to touch code of Team1.
>>>> If the many-reference supervisedEmployees is mapped to a dedicated
>>>> join table there's also no responsibility conflict in the DB team of
>>>> your company.
>>>> But when it comes to O/R mapping of supervisedEmployees with foreign
>>>> keys in the table of Employee there is no longer a clear
>>>> responsibility for that class!
>>>> The same is true for m:n references across model boundaries.
>>>
>>> OK I see your argument. I just want to be pragmatic all the time when
>>> it comes to use native sql queries. :)
>>>
>>>>
>>>>> why is the version part of the primary key ? that doesnt make sense
>>>>> to me. maybe you have reasons but i would expect that the db has
>>>>> only a single version stored. and again here pain in joining.
>>>> CDO is basically capable of auditing (retrieving historical states
>>>> of the overall model). I guess it's a similar effect like the one
>>>> the new Temporality project announces.
>>>
>>> Ok then you have mutliple versions. But I would (personal taste ?)
>>> prefer a single column surrogate primary key in any case. There are
>>> some techniques on versioning (take three add columns columns, a
>>> group id that groups the versions a counter/timestamp and a boolean,
>>> set the boolean true for the current version, put a unique constraint
>>> on group_id and version) timestamp makes problems on oracle as it not
>>> finegrained enough for have load, so i prefer a counter or a mix of
>>> both of it. its just the idea of having a clean surrogate key that i
>>> always prefer.
>>>
>>>
>>>
>>>>> what kinds of relations are supported ?
>>>> Single-valued references are mapped to CDOID columns in the table of
>>>> the referencing EClass.
>>>> Multi-valued references are mapped to the join tables I mentioned
>>>> before.
>>>> Was this what you asked for?
>>>
>>> yes
>>>
>>>>
>>>>>
>>>>> What about Lobs ? is there support for large objects ?
>>>> In which context? For mapping multi-valued references? This is
>>>> planned via
>>>> org.eclipse.emf.cdo.server.internal.db.ToMany.LIKE_ATTRIBUTE S. I'd
>>>> make querying even harder.
>>>
>>> I mean very long Strings or ByteArrays. Hibernate does that with @Lob
>>>
>>>>> We would at least need to supply not null constraints
>>>> That could make a good Bugzilla (A) ;-)
>>>>
>>>>> on fields and ManyToOne relations,
>>>> See my above concerns. A separate Bugzilla (B) could be good to
>>>> discuss these concerns.
>>>>
>>>>> field lengthes for character strings,
>>>> Fits well into the Bugzilla (A).
>>>>
>>>>> plus I have to dive into the validation problem. plus i need
>>>>> something for unique key constraints and indexes.
>>>> What is the validation problem? The one Simon solved via OCL?
>>>> Unique key constraints and indexes could go into (A) as well.
>>>>
>>>> One general comment to all this mapping stuff: As you correctly
>>>> analyzed in another thread, CDO is not mainly about providing a new
>>>> O/R mapping solution. Hibernate will probably always be better here
>>>> and I didn't plan to compete with it. CDO is more focused on
>>>> providing a stable and efficient 3-tier solution (client /
>>>> repository / store) with distributed shared model semantics (remote
>>>> update notifications) and an auditing mode. The store even doesn't
>>>> need to be a relational database.
>>>>
>>>> I think it's time for me to dig into the Hibernate code and work
>>>> with Martin to develop a HibernateStore for the CDO storage framework.
>>>>
>>>
>>>
>>> Hmm Eike, dont know if I should open bugs on this if we dig into
>>> teneo. Why put so much effort in there when we already have
>>> (nearly)everything we need at hand ?
>>>
>>> Regarding the task force I think I can try to support you. I just
>>> dont know how much time I can put in there, can be that I have a new
>>> project next week, can be that I have lots of time to spent in february.
>>>
>>> What Im not happy with (other thread..) is not your implementation at
>>> all. Things are as they are :) I have to learn about your fetching
>>> strategy and proxiing will try to look into that tonight. It is that
>>> hibernate puts its own proxies in there and we have to find a way to
>>> make it play together.
>>>
>>> another point i see is that you put additional columns and tables in
>>> the db, and teneo seems to have its own way to to that. dont know up
>>> to now how much the dbstore api depends on that.
>>>
>>> its another point that teneo builds on the hbm mapping files (that
>>> goes to the teneo audience:). if we had pure jpa entities we could
>>> have integration with eclipseLink, openJpa or whatever.
>>>
>>>
>>> Regards Thomas
>>
>>


--

With Regards, Martin Taal

Springsite/Elver.org
Office: Hardwareweg 4, 3821 BV Amersfoort
Postal: Nassaulaan 7, 3941 EC Doorn
The Netherlands
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] is it what I want ? [message #614263 is a reply to message #109626] Wed, 30 January 2008 11:56 Go to previous message
Martin Taal is currently offline Martin TaalFriend
Messages: 5468
Registered: July 2009
Senior Member
Hi Thomas,
Yes I also see the lack of compiler support when annotating models. The idea behind Teneo is really
that Teneo generates most annotations automatically and that the user only needs to manually specify
annotations for the parts which are not done correctly in automatic mode. So you only need to
annotate the exceptions.
But this approach ofcourse is mostly valid if there not so much to override (if the automatic
approach is mostly fine). So it all depends...
Also for me it always seemed nicer to annotate models and not the java source code. But I also see
that there is great value in having one location to edit this together with code completion and
syntax checking. Especially if the jpa annotations can first be generated automatically by Teneo and
then manually changed by the user.

gr. Martin

Thomas wrote:
> Hi Martin,
>
> Martin Taal schrieb:
>> Hi Thomas,
>> Just to react on your last point (to the Teneo audience :) about jpa
>> entities. Hidden within Teneo there is already a possibility to create
>> jpa annotations which can be placed in the source code (see the
>> PAnnotation class it has a method getJavaAnnotation(...). I use it
>> myself when generating jpa entities. However, I am not sure yet how to
>> integrate this with the current code generation of EMF.
> I saw that before. Im just diving into it so forgive me :)
> Its just that I believe theres is great power in bringing all this
> together that makes me very interested.
>
> I'm a little conscious about this annotation stuff as one doesnt have
> any nice compiler checks on the syntax in the model.
>
>
>>
>> I wanted to post a question about this in the emf newsgroup (maybe
>> I'll do that today).
>>
>> Other then that, EMF has specific list implementations (for supporting
>> bi-directional and containment and notifications), these do not work
>> out of the box with hibernate (or TopLink) therefore Teneo also has a
>> runtime layer. But depending on the business case ofcourse these list
>> implementations are important or not.
>
> I was too dumb to do my first simple emf model yesterday, so I will
> leave that up to you :)
>>
>> gr. Martin
>>
>


--

With Regards, Martin Taal

Springsite/Elver.org
Office: Hardwareweg 4, 3821 BV Amersfoort
Postal: Nassaulaan 7, 3941 EC Doorn
The Netherlands
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] is it what I want ? [message #614264 is a reply to message #109653] Wed, 30 January 2008 12:20 Go to previous message
Thomas is currently offline ThomasFriend
Messages: 151
Registered: July 2009
Senior Member
HI Martin,

Yes doing as much by convention as possible is a good idea. But for
example in my current model (CDO may change this) I have always eager
fetching. I use HiberObjects at the moment. I have to put manual
annotations on the fetch strategy on every relation I have. So
convention is good, but even better if one can define what the
convention actually is.

Thomas

Martin Taal schrieb:
> Hi Thomas,
> Yes I also see the lack of compiler support when annotating models. The
> idea behind Teneo is really that Teneo generates most annotations
> automatically and that the user only needs to manually specify
> annotations for the parts which are not done correctly in automatic
> mode. So you only need to annotate the exceptions.
> But this approach ofcourse is mostly valid if there not so much to
> override (if the automatic approach is mostly fine). So it all depends...
> Also for me it always seemed nicer to annotate models and not the java
> source code. But I also see that there is great value in having one
> location to edit this together with code completion and syntax checking.
> Especially if the jpa annotations can first be generated automatically
> by Teneo and then manually changed by the user.
>
> gr. Martin
>
> Thomas wrote:
>> Hi Martin,
>>
>> Martin Taal schrieb:
>>> Hi Thomas,
>>> Just to react on your last point (to the Teneo audience :) about jpa
>>> entities. Hidden within Teneo there is already a possibility to
>>> create jpa annotations which can be placed in the source code (see
>>> the PAnnotation class it has a method getJavaAnnotation(...). I use
>>> it myself when generating jpa entities. However, I am not sure yet
>>> how to integrate this with the current code generation of EMF.
>> I saw that before. Im just diving into it so forgive me :)
>> Its just that I believe theres is great power in bringing all this
>> together that makes me very interested.
>>
>> I'm a little conscious about this annotation stuff as one doesnt have
>> any nice compiler checks on the syntax in the model.
>>
>>
>>>
>>> I wanted to post a question about this in the emf newsgroup (maybe
>>> I'll do that today).
>>>
>>> Other then that, EMF has specific list implementations (for
>>> supporting bi-directional and containment and notifications), these
>>> do not work out of the box with hibernate (or TopLink) therefore
>>> Teneo also has a runtime layer. But depending on the business case
>>> ofcourse these list implementations are important or not.
>>
>> I was too dumb to do my first simple emf model yesterday, so I will
>> leave that up to you :)
>>>
>>> gr. Martin
>>>
>>
>
>
Re: [CDO] is it what I want ? [message #614268 is a reply to message #109588] Wed, 30 January 2008 12:54 Go to previous message
Eike Stepper is currently offline Eike StepperFriend
Messages: 6579
Registered: July 2009
Senior Member
Guys,

I just downloaded Hibernate ;-)

Regards,
Eike Stepper
----
http://wiki.eclipse.org/CDO
http://wiki.eclipse.org/Net4j



Martin Taal schrieb:
> Hi Eike, Thomas,
> I will start looking at the integration between CDO and Teneo today. I
> first need to get familiar with cdo and then I can see how Teneo can
> be integrated. I'll keep you posted.
>
> See my other additions below.
>
> gr. Martin
>
> Eike Stepper wrote:
>> Thomas schrieb:
>>> HI Eike, this seems to be what I would need.
>>> I overlooked your mapping hints (will have to see this in an example
>>> maybe tommorrow.) what I dislike is the relation tables. as i do
>>> reporting with birt i will have to query the database with sql and
>>> th relation tables make manual joining a pain. I know some dtabase
>>> gurus recommend join tables but I still prefer a single foreign key
>>> in the target table. ok you need a single column then for each
>>> relation (give it a speaking name and everthing is clear)
>> What I don't like with the foreign key joins you mention is the
>> following:
>> Assume you are a big IT company and you have many application with
>> one development team being responsible for one application. The
>> applications have non-circular dependencies on each other and this is
>> clearly reflected within the models that form the applications. As
>> long as you're modeling there's at no time the need to modify foreign
>> code (the models you depend on). Consider the following example:
>> Team1, January 2008, develops a model Employees. There is an EClass
>> Employee.
>> Team2, March 2008, develops the model Supervisors. There is an EClass
>> Supervisor with a many-reference supervisedEmployees:List<Emplyoee>.
>>
>> In the OO world there's no need for Team2 to touch code of Team1.
>> If the many-reference supervisedEmployees is mapped to a dedicated
>> join table there's also no responsibility conflict in the DB team of
>> your company.
>> But when it comes to O/R mapping of supervisedEmployees with foreign
>> keys in the table of Employee there is no longer a clear
>> responsibility for that class!
>> The same is true for m:n references across model boundaries.
> MT>> I have a background in developing ERP systems and there it was
> also common to use a foreign key field instead of join tables. A
> number of thoughts from my side regarding this topic:
> - as Eike mentions foreign keys are more intruisive than join table as
> the target table gets changed (has an extra foreign key field(s))
> - Foreign keys are more efficient as there is one less join to do
> - Foreign keys do not support duplicate occurences in a list (join
> tables do, assuming a join table has a separate id column).
> - Specifically for containment relations my feel is that a foreign key
> field is appropriate as it reflects the stronger relation between the
> child and the parent. The same can be said for bidirectional relations.
>
> Overall I have the same feel as Thomas, with my background I like
> foreign keys (as they are more efficient) but I understand that there
> are many people with other ideas. Teneo has an option to specify if
> all non-containment relations should be mapped with a join table (or
> not).
>
>>
>>> why is the version part of the primary key ? that doesnt make sense
>>> to me. maybe you have reasons but i would expect that the db has
>>> only a single version stored. and again here pain in joining.
>> CDO is basically capable of auditing (retrieving historical states of
>> the overall model). I guess it's a similar effect like the one the
>> new Temporality project announces. An Istore decides if it supports
>> auditing mode and if it supports non-auditing mode. The DBStore
>> currently does only support auditing mode! I'm currently a bit unsure
>> what to prioritize: Make DBStore support non-auditing mode or help
>> Martin develop a HibernateStore for CDO. I guess you'll vote for the
>> latter ;-) I'd agree.
> MT>> I will start looking at CDO today and try out the tutorial, etc.
> Maybe I can get a long way without asking to much of your time Eike
> (so then you can do both :-).
> MT>> Btw, imo it is great that CDO also considers topics like
> auditing, these generic topics can really be solved at this level.
>
>>
>>> what kinds of relations are supported ?
>> Single-valued references are mapped to CDOID columns in the table of
>> the referencing EClass.
>> Multi-valued references are mapped to the join tables I mentioned
>> before.
>> Was this what you asked for?
>>
>>>
>>> What about Lobs ? is there support for large objects ?
>> In which context? For mapping multi-valued references? This is
>> planned via
>> org.eclipse.emf.cdo.server.internal.db.ToMany.LIKE_ATTRIBUTE S. I'd
>> make querying even harder.
>>
>>>
>>> We would at least need to supply not null constraints
>> That could make a good Bugzilla (A) ;-)
>>
>>> on fields and ManyToOne relations,
>> See my above concerns. A separate Bugzilla (B) could be good to
>> discuss these concerns.
>>
>>> field lengthes for character strings,
>> Fits well into the Bugzilla (A).
>>
>>> plus I have to dive into the validation problem. plus i need
>>> something for unique key constraints and indexes.
>> What is the validation problem? The one Simon solved via OCL?
>> Unique key constraints and indexes could go into (A) as well.
>>
>> One general comment to all this mapping stuff: As you correctly
>> analyzed in another thread, CDO is not mainly about providing a new
>> O/R mapping solution. Hibernate will probably always be better here
>> and I didn't plan to compete with it. CDO is more focused on
>> providing a stable and efficient 3-tier solution (client / repository
>> / store) with distributed shared model semantics (remote update
>> notifications) and an auditing mode. The store even doesn't need to
>> be a relational database.
>>
>> I think it's time for me to dig into the Hibernate code and work with
>> Martin to develop a HibernateStore for the CDO storage framework.
>>
>> Regards,
>> Eike Stepper
>> ----
>> http://wiki.eclipse.org/CDO
>> http://wiki.eclipse.org/Net4j
>>
>>
>>>
>>> Thomas
>>>
>>> Eike Stepper schrieb:
>>>> Hi Thomas,
>>>>
>>>> A CDOSession has a setReferenceChunkSize() method which you can
>>>> call to limit the number of objects (ids) to load on collection
>>>> read accesses. Since read access (loading) is handled by the
>>>> CDOSession all CDOViews on that session share this setting. We are
>>>> currently discussing to provide an additional session property:
>>>> InitialReferenceChunkSize. Then you could even configure to load
>>>> nothing on the first access (of the source object) and max n
>>>> targets on subsequent reference accesses. At the moment I'd suggest
>>>> to set a value of 10-100 so that you're shielded against huge
>>>> collections.
>>>>
>>>> Regards,
>>>> Eike Stepper
>>>> ----
>>>> http://wiki.eclipse.org/CDO
>>>> http://wiki.eclipse.org/Net4j
>>>>
>>>>
>>>>
>>>> Thomas schrieb:
>>>>> Once again..
>>>>> Another thing coming to my mind is about the object graph. Suggest
>>>>> I have a Object Person with a Collection of Adresses. when I query
>>>>> for the person did I get it right that the Adresse are only loaded
>>>>> when I try to access them ? That would be the main decision factor
>>>>> for me. I have expensive objects and the more the could be lazy
>>>>> loaded the better my ui handling would be.
>>>>>
>>>>> Regards Thomas
>
>


Re: [CDO] is it what I want ? [message #614272 is a reply to message #109675] Wed, 30 January 2008 13:04 Go to previous message
Thomas is currently offline ThomasFriend
Messages: 151
Registered: July 2009
Senior Member
Hi Eike,

Be sure to have annotations and entitymanager too.

I tried to migrate my ecore from yesterday with new emf project, native
CDO. installed the latest integration build, as the build scripts are
unix only.

I get:
!MESSAGE
!STACK 0
java.lang.reflect.InvocationTargetException
at
org.eclipse.ui.actions.WorkspaceModifyOperation.run(Workspac eModifyOperation.java:119)
at
org.eclipse.jface.operation.ModalContext.runInCurrentThread( ModalContext.java:407)
at org.eclipse.jface.operation.ModalContext.run(ModalContext.ja va:347)
at org.eclipse.jface.wizard.WizardDialog.run(WizardDialog.java: 934)
at
org.eclipse.emf.converter.ui.contribution.base.ModelConverte rWizard.performFinish(ModelConverterWizard.java:246)
at
org.eclipse.emf.importer.ui.contribution.base.ModelImporterW izard.performFinish(ModelImporterWizard.java:157)
at
org.eclipse.jface.wizard.WizardDialog.finishPressed(WizardDi alog.java:742)
at
org.eclipse.jface.wizard.WizardDialog.buttonPressed(WizardDi alog.java:373)
at org.eclipse.jface.dialogs.Dialog$2.widgetSelected(Dialog.jav a:623)
at
org.eclipse.swt.widgets.TypedListener.handleEvent(TypedListe ner.java:227)
at org.eclipse.swt.widgets.EventTable.sendEvent(EventTable.java :66)
at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:952)
at org.eclipse.swt.widgets.Display.runDeferredEvents(Display.ja va:3750)
at org.eclipse.swt.widgets.Display.readAndDispatch(Display.java :3361)
at org.eclipse.jface.window.Window.runEventLoop(Window.java:825 )
at org.eclipse.jface.window.Window.open(Window.java:801)
at org.eclipse.ui.actions.NewProjectAction.run(NewProjectAction .java:116)
at org.eclipse.jface.action.Action.runWithEvent(Action.java:498 )
at
org.eclipse.jface.action.ActionContributionItem.handleWidget Selection(ActionContributionItem.java:582)
at
org.eclipse.jface.action.ActionContributionItem.access$2(Act ionContributionItem.java:499)
at
org.eclipse.jface.action.ActionContributionItem$5.handleEven t(ActionContributionItem.java:410)
at org.eclipse.swt.widgets.EventTable.sendEvent(EventTable.java :66)
at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:952)
at org.eclipse.swt.widgets.Display.runDeferredEvents(Display.ja va:3750)
at org.eclipse.swt.widgets.Display.readAndDispatch(Display.java :3361)
at org.eclipse.ui.internal.Workbench.runEventLoop(Workbench.jav a:2381)
at org.eclipse.ui.internal.Workbench.runUI(Workbench.java:2345)
at org.eclipse.ui.internal.Workbench.access$4(Workbench.java:22 11)
at org.eclipse.ui.internal.Workbench$4.run(Workbench.java:473)
at
org.eclipse.core.databinding.observable.Realm.runWithDefault (Realm.java:288)
at
org.eclipse.ui.internal.Workbench.createAndRunWorkbench(Work bench.java:468)
at org.eclipse.ui.PlatformUI.createAndRunWorkbench(PlatformUI.j ava:149)
at
org.eclipse.ui.internal.ide.application.IDEApplication.start (IDEApplication.java:106)
at
org.eclipse.equinox.internal.app.EclipseAppHandle.run(Eclips eAppHandle.java:193)
at
org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher .runApplication(EclipseAppLauncher.java:106)
at
org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher .start(EclipseAppLauncher.java:76)
at
org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseS tarter.java:362)
at
org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseS tarter.java:175)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
at java.lang.reflect.Method.invoke(Unknown Source)
at org.eclipse.equinox.launcher.Main.invokeFramework(Main.java: 561)
at org.eclipse.equinox.launcher.Main.basicRun(Main.java:501)
at org.eclipse.equinox.launcher.Main.run(Main.java:1239)
Caused by: org.eclipse.core.runtime.CoreException: An error occurred
while performing this operation.
at
org.eclipse.emf.common.util.DiagnosticException.toCoreExcept ion(DiagnosticException.java:47)
at
org.eclipse.emf.converter.ui.contribution.base.ModelConverte rWizard$1.execute(ModelConverterWizard.java:235)
at
org.eclipse.ui.actions.WorkspaceModifyOperation$1.run(Worksp aceModifyOperation.java:104)
at org.eclipse.core.internal.resources.Workspace.run(Workspace. java:1800)
at
org.eclipse.ui.actions.WorkspaceModifyOperation.run(Workspac eModifyOperation.java:116)
... 44 more
Root exception:
org.eclipse.core.runtime.CoreException: An error occurred while
performing this operation.
at
org.eclipse.emf.common.util.DiagnosticException.toCoreExcept ion(DiagnosticException.java:47)
at
org.eclipse.emf.converter.ui.contribution.base.ModelConverte rWizard$1.execute(ModelConverterWizard.java:235)
at
org.eclipse.ui.actions.WorkspaceModifyOperation$1.run(Worksp aceModifyOperation.java:104)
at org.eclipse.core.internal.resources.Workspace.run(Workspace. java:1800)
at
org.eclipse.ui.actions.WorkspaceModifyOperation.run(Workspac eModifyOperation.java:116)
at
org.eclipse.jface.operation.ModalContext.runInCurrentThread( ModalContext.java:407)
at org.eclipse.jface.operation.ModalContext.run(ModalContext.ja va:347)
at org.eclipse.jface.wizard.WizardDialog.run(WizardDialog.java: 934)
at
org.eclipse.emf.converter.ui.contribution.base.ModelConverte rWizard.performFinish(ModelConverterWizard.java:246)
at
org.eclipse.emf.importer.ui.contribution.base.ModelImporterW izard.performFinish(ModelImporterWizard.java:157)
at
org.eclipse.jface.wizard.WizardDialog.finishPressed(WizardDi alog.java:742)
at
org.eclipse.jface.wizard.WizardDialog.buttonPressed(WizardDi alog.java:373)
at org.eclipse.jface.dialogs.Dialog$2.widgetSelected(Dialog.jav a:623)
at
org.eclipse.swt.widgets.TypedListener.handleEvent(TypedListe ner.java:227)
at org.eclipse.swt.widgets.EventTable.sendEvent(EventTable.java :66)
at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:952)
at org.eclipse.swt.widgets.Display.runDeferredEvents(Display.ja va:3750)
at org.eclipse.swt.widgets.Display.readAndDispatch(Display.java :3361)
at org.eclipse.jface.window.Window.runEventLoop(Window.java:825 )
at org.eclipse.jface.window.Window.open(Window.java:801)
at org.eclipse.ui.actions.NewProjectAction.run(NewProjectAction .java:116)
at org.eclipse.jface.action.Action.runWithEvent(Action.java:498 )
at
org.eclipse.jface.action.ActionContributionItem.handleWidget Selection(ActionContributionItem.java:582)
at
org.eclipse.jface.action.ActionContributionItem.access$2(Act ionContributionItem.java:499)
at
org.eclipse.jface.action.ActionContributionItem$5.handleEven t(ActionContributionItem.java:410)
at org.eclipse.swt.widgets.EventTable.sendEvent(EventTable.java :66)
at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:952)
at org.eclipse.swt.widgets.Display.runDeferredEvents(Display.ja va:3750)
at org.eclipse.swt.widgets.Display.readAndDispatch(Display.java :3361)
at org.eclipse.ui.internal.Workbench.runEventLoop(Workbench.jav a:2381)
at org.eclipse.ui.internal.Workbench.runUI(Workbench.java:2345)
at org.eclipse.ui.internal.Workbench.access$4(Workbench.java:22 11)
at org.eclipse.ui.internal.Workbench$4.run(Workbench.java:473)
at
org.eclipse.core.databinding.observable.Realm.runWithDefault (Realm.java:288)
at
org.eclipse.ui.internal.Workbench.createAndRunWorkbench(Work bench.java:468)
at org.eclipse.ui.PlatformUI.createAndRunWorkbench(PlatformUI.j ava:149)
at
org.eclipse.ui.internal.ide.application.IDEApplication.start (IDEApplication.java:106)
at
org.eclipse.equinox.internal.app.EclipseAppHandle.run(Eclips eAppHandle.java:193)
at
org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher .runApplication(EclipseAppLauncher.java:106)
at
org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher .start(EclipseAppLauncher.java:76)
at
org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseS tarter.java:362)
at
org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseS tarter.java:175)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
at java.lang.reflect.Method.invoke(Unknown Source)
at org.eclipse.equinox.launcher.Main.invokeFramework(Main.java: 561)
at org.eclipse.equinox.launcher.Main.basicRun(Main.java:501)
at org.eclipse.equinox.launcher.Main.run(Main.java:1239)
org.eclipse.core.runtime.CoreException[2048]:
org.eclipse.emf.common.util.DiagnosticException: An error occurred while
performing this operation.
at
org.eclipse.emf.converter.ui.contribution.base.ModelConverte rWizard$1.execute(ModelConverterWizard.java:234)
at
org.eclipse.ui.actions.WorkspaceModifyOperation$1.run(Worksp aceModifyOperation.java:104)
at org.eclipse.core.internal.resources.Workspace.run(Workspace. java:1800)
at
org.eclipse.ui.actions.WorkspaceModifyOperation.run(Workspac eModifyOperation.java:116)
at
org.eclipse.jface.operation.ModalContext.runInCurrentThread( ModalContext.java:407)
at org.eclipse.jface.operation.ModalContext.run(ModalContext.ja va:347)
at org.eclipse.jface.wizard.WizardDialog.run(WizardDialog.java: 934)
at
org.eclipse.emf.converter.ui.contribution.base.ModelConverte rWizard.performFinish(ModelConverterWizard.java:246)
at
org.eclipse.emf.importer.ui.contribution.base.ModelImporterW izard.performFinish(ModelImporterWizard.java:157)
at
org.eclipse.jface.wizard.WizardDialog.finishPressed(WizardDi alog.java:742)
at
org.eclipse.jface.wizard.WizardDialog.buttonPressed(WizardDi alog.java:373)
at org.eclipse.jface.dialogs.Dialog$2.widgetSelected(Dialog.jav a:623)
at
org.eclipse.swt.widgets.TypedListener.handleEvent(TypedListe ner.java:227)
at org.eclipse.swt.widgets.EventTable.sendEvent(EventTable.java :66)
at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:952)
at org.eclipse.swt.widgets.Display.runDeferredEvents(Display.ja va:3750)
at org.eclipse.swt.widgets.Display.readAndDispatch(Display.java :3361)
at org.eclipse.jface.window.Window.runEventLoop(Window.java:825 )
at org.eclipse.jface.window.Window.open(Window.java:801)
at org.eclipse.ui.actions.NewProjectAction.run(NewProjectAction .java:116)
at org.eclipse.jface.action.Action.runWithEvent(Action.java:498 )
at
org.eclipse.jface.action.ActionContributionItem.handleWidget Selection(ActionContributionItem.java:582)
at
org.eclipse.jface.action.ActionContributionItem.access$2(Act ionContributionItem.java:499)
at
org.eclipse.jface.action.ActionContributionItem$5.handleEven t(ActionContributionItem.java:410)
at org.eclipse.swt.widgets.EventTable.sendEvent(EventTable.java :66)
at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:952)
at org.eclipse.swt.widgets.Display.runDeferredEvents(Display.ja va:3750)
at org.eclipse.swt.widgets.Display.readAndDispatch(Display.java :3361)
at org.eclipse.ui.internal.Workbench.runEventLoop(Workbench.jav a:2381)
at org.eclipse.ui.internal.Workbench.runUI(Workbench.java:2345)
at org.eclipse.ui.internal.Workbench.access$4(Workbench.java:22 11)
at org.eclipse.ui.internal.Workbench$4.run(Workbench.java:473)
at
org.eclipse.core.databinding.observable.Realm.runWithDefault (Realm.java:288)
at
org.eclipse.ui.internal.Workbench.createAndRunWorkbench(Work bench.java:468)
at org.eclipse.ui.PlatformUI.createAndRunWorkbench(PlatformUI.j ava:149)
at
org.eclipse.ui.internal.ide.application.IDEApplication.start (IDEApplication.java:106)
at
org.eclipse.equinox.internal.app.EclipseAppHandle.run(Eclips eAppHandle.java:193)
at
org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher .runApplication(EclipseAppLauncher.java:106)
at
org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher .start(EclipseAppLauncher.java:76)
at
org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseS tarter.java:362)
at
org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseS tarter.java:175)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
at java.lang.reflect.Method.invoke(Unknown Source)
at org.eclipse.equinox.launcher.Main.invokeFramework(Main.java: 561)
at org.eclipse.equinox.launcher.Main.basicRun(Main.java:501)
at org.eclipse.equinox.launcher.Main.run(Main.java:1239)
Caused by: org.eclipse.emf.common.util.WrappedException:
org.eclipse.core.internal.resources.ResourceException: Resource
'/test.cdo' does not exist.
at
org.eclipse.emf.cdo.migrator.CDOMigrator.adjustGenModel(CDOM igrator.java:91)
at
org.eclipse.emf.cdo.migrator.CDOImporter.adjustGenModel(CDOI mporter.java:125)
at
org.eclipse.emf.importer.ModelImporter.prepareGenModelAndEPa ckages(ModelImporter.java:718)
at
org.eclipse.emf.importer.ui.contribution.base.ModelImporterW izard.doPerformFinish(ModelImporterWizard.java:149)
at
org.eclipse.emf.converter.ui.contribution.base.ModelConverte rWizard$1.execute(ModelConverterWizard.java:228)
... 47 more
Caused by: org.eclipse.core.internal.resources.ResourceException:
Resource '/test.cdo' does not exist.
at
org.eclipse.core.internal.resources.Resource.checkExists(Res ource.java:309)
at
org.eclipse.core.internal.resources.Resource.checkAccessible (Resource.java:192)
at
org.eclipse.core.internal.resources.Project.checkAccessible( Project.java:113)
at
org.eclipse.core.internal.resources.Folder.assertCreateRequi rements(Folder.java:32)
at org.eclipse.core.internal.resources.Folder.create(Folder.jav a:88)
at org.eclipse.core.internal.resources.Folder.create(Folder.jav a:118)
at
org.eclipse.emf.cdo.migrator.CDOMigrator.adjustGenModel(CDOM igrator.java:86)
... 51 more

Eike Stepper schrieb:
> Guys,
>
> I just downloaded Hibernate ;-)
>
> Regards,
> Eike Stepper
> ----
> http://wiki.eclipse.org/CDO
> http://wiki.eclipse.org/Net4j
>
>
>
> Martin Taal schrieb:
>> Hi Eike, Thomas,
>> I will start looking at the integration between CDO and Teneo today. I
>> first need to get familiar with cdo and then I can see how Teneo can
>> be integrated. I'll keep you posted.
>>
>> See my other additions below.
>>
>> gr. Martin
>>
>> Eike Stepper wrote:
>>> Thomas schrieb:
>>>> HI Eike, this seems to be what I would need.
>>>> I overlooked your mapping hints (will have to see this in an example
>>>> maybe tommorrow.) what I dislike is the relation tables. as i do
>>>> reporting with birt i will have to query the database with sql and
>>>> th relation tables make manual joining a pain. I know some dtabase
>>>> gurus recommend join tables but I still prefer a single foreign key
>>>> in the target table. ok you need a single column then for each
>>>> relation (give it a speaking name and everthing is clear)
>>> What I don't like with the foreign key joins you mention is the
>>> following:
>>> Assume you are a big IT company and you have many application with
>>> one development team being responsible for one application. The
>>> applications have non-circular dependencies on each other and this is
>>> clearly reflected within the models that form the applications. As
>>> long as you're modeling there's at no time the need to modify foreign
>>> code (the models you depend on). Consider the following example:
>>> Team1, January 2008, develops a model Employees. There is an EClass
>>> Employee.
>>> Team2, March 2008, develops the model Supervisors. There is an EClass
>>> Supervisor with a many-reference supervisedEmployees:List<Emplyoee>.
>>>
>>> In the OO world there's no need for Team2 to touch code of Team1.
>>> If the many-reference supervisedEmployees is mapped to a dedicated
>>> join table there's also no responsibility conflict in the DB team of
>>> your company.
>>> But when it comes to O/R mapping of supervisedEmployees with foreign
>>> keys in the table of Employee there is no longer a clear
>>> responsibility for that class!
>>> The same is true for m:n references across model boundaries.
>> MT>> I have a background in developing ERP systems and there it was
>> also common to use a foreign key field instead of join tables. A
>> number of thoughts from my side regarding this topic:
>> - as Eike mentions foreign keys are more intruisive than join table as
>> the target table gets changed (has an extra foreign key field(s))
>> - Foreign keys are more efficient as there is one less join to do
>> - Foreign keys do not support duplicate occurences in a list (join
>> tables do, assuming a join table has a separate id column).
>> - Specifically for containment relations my feel is that a foreign key
>> field is appropriate as it reflects the stronger relation between the
>> child and the parent. The same can be said for bidirectional relations.
>>
>> Overall I have the same feel as Thomas, with my background I like
>> foreign keys (as they are more efficient) but I understand that there
>> are many people with other ideas. Teneo has an option to specify if
>> all non-containment relations should be mapped with a join table (or
>> not).
>>
>>>
>>>> why is the version part of the primary key ? that doesnt make sense
>>>> to me. maybe you have reasons but i would expect that the db has
>>>> only a single version stored. and again here pain in joining.
>>> CDO is basically capable of auditing (retrieving historical states of
>>> the overall model). I guess it's a similar effect like the one the
>>> new Temporality project announces. An Istore decides if it supports
>>> auditing mode and if it supports non-auditing mode. The DBStore
>>> currently does only support auditing mode! I'm currently a bit unsure
>>> what to prioritize: Make DBStore support non-auditing mode or help
>>> Martin develop a HibernateStore for CDO. I guess you'll vote for the
>>> latter ;-) I'd agree.
>> MT>> I will start looking at CDO today and try out the tutorial, etc.
>> Maybe I can get a long way without asking to much of your time Eike
>> (so then you can do both :-).
>> MT>> Btw, imo it is great that CDO also considers topics like
>> auditing, these generic topics can really be solved at this level.
>>
>>>
>>>> what kinds of relations are supported ?
>>> Single-valued references are mapped to CDOID columns in the table of
>>> the referencing EClass.
>>> Multi-valued references are mapped to the join tables I mentioned
>>> before.
>>> Was this what you asked for?
>>>
>>>>
>>>> What about Lobs ? is there support for large objects ?
>>> In which context? For mapping multi-valued references? This is
>>> planned via
>>> org.eclipse.emf.cdo.server.internal.db.ToMany.LIKE_ATTRIBUTE S. I'd
>>> make querying even harder.
>>>
>>>>
>>>> We would at least need to supply not null constraints
>>> That could make a good Bugzilla (A) ;-)
>>>
>>>> on fields and ManyToOne relations,
>>> See my above concerns. A separate Bugzilla (B) could be good to
>>> discuss these concerns.
>>>
>>>> field lengthes for character strings,
>>> Fits well into the Bugzilla (A).
>>>
>>>> plus I have to dive into the validation problem. plus i need
>>>> something for unique key constraints and indexes.
>>> What is the validation problem? The one Simon solved via OCL?
>>> Unique key constraints and indexes could go into (A) as well.
>>>
>>> One general comment to all this mapping stuff: As you correctly
>>> analyzed in another thread, CDO is not mainly about providing a new
>>> O/R mapping solution. Hibernate will probably always be better here
>>> and I didn't plan to compete with it. CDO is more focused on
>>> providing a stable and efficient 3-tier solution (client / repository
>>> / store) with distributed shared model semantics (remote update
>>> notifications) and an auditing mode. The store even doesn't need to
>>> be a relational database.
>>>
>>> I think it's time for me to dig into the Hibernate code and work with
>>> Martin to develop a HibernateStore for the CDO storage framework.
>>>
>>> Regards,
>>> Eike Stepper
>>> ----
>>> http://wiki.eclipse.org/CDO
>>> http://wiki.eclipse.org/Net4j
>>>
>>>
>>>>
>>>> Thomas
>>>>
>>>> Eike Stepper schrieb:
>>>>> Hi Thomas,
>>>>>
>>>>> A CDOSession has a setReferenceChunkSize() method which you can
>>>>> call to limit the number of objects (ids) to load on collection
>>>>> read accesses. Since read access (loading) is handled by the
>>>>> CDOSession all CDOViews on that session share this setting. We are
>>>>> currently discussing to provide an additional session property:
>>>>> InitialReferenceChunkSize. Then you could even configure to load
>>>>> nothing on the first access (of the source object) and max n
>>>>> targets on subsequent reference accesses. At the moment I'd suggest
>>>>> to set a value of 10-100 so that you're shielded against huge
>>>>> collections.
>>>>>
>>>>> Regards,
>>>>> Eike Stepper
>>>>> ----
>>>>> http://wiki.eclipse.org/CDO
>>>>> http://wiki.eclipse.org/Net4j
>>>>>
>>>>>
>>>>>
>>>>> Thomas schrieb:
>>>>>> Once again..
>>>>>> Another thing coming to my mind is about the object graph. Suggest
>>>>>> I have a Object Person with a Collection of Adresses. when I query
>>>>>> for the person did I get it right that the Adresse are only loaded
>>>>>> when I try to access them ? That would be the main decision factor
>>>>>> for me. I have expensive objects and the more the could be lazy
>>>>>> loaded the better my ui handling would be.
>>>>>>
>>>>>> Regards Thomas
>>
>>
Re: [CDO] is it what I want ? [message #614280 is a reply to message #109576] Wed, 30 January 2008 13:05 Go to previous message
Eike Stepper is currently offline Eike StepperFriend
Messages: 6579
Registered: July 2009
Senior Member
Thomas schrieb:
> [stuff deleted]
>
>> why is the version part of the primary key ? that doesnt make sense
>> to me. maybe you have reasons but i would expect that the db has only
>> a single version stored. and again here pain in joining. CDO is
>> basically capable of auditing (retrieving historical states of the
>> overall model). I guess it's a similar effect like the one the new
>> Temporality project announces.
>
> Ok then you have mutliple versions. But I would (personal taste ?)
> prefer a single column surrogate primary key in any case. There are
> some techniques on versioning (take three add columns columns, a group
> id that groups the versions a counter/timestamp and a boolean, set the
> boolean true for the current version, put a unique constraint on
> group_id and version) timestamp makes problems on oracle as it not
> finegrained enough for have load, so i prefer a counter or a mix of
> both of it. its just the idea of having a clean surrogate key that i
> always prefer.
I'm not sure if I completely understand what you're saying about
versioning technique, but I'm sure you've been a DB expert before you
started modeling ;-)

The current structure of the internal columns of CDO is carefully
chosen. There's no redundancy and all of the following operations are
possible efficiently:
a) loadLatestRevision (revised==null)
b) loadRevisionByVersion (version == v)
c) loadRevisionByTime (revised == UNSPECIFIED_DATE || revised >=
timeStamp) && timeStamp >= created
d) lockForWrite (set revised = now)

As I said these structures are optimized for the repository access
(defined by the IStore API) and not for manual querying (although this
was a secondary requirement).

> [stuff deleted]
>
> Hmm Eike, dont know if I should open bugs on this if we dig into
> teneo. Why put so much effort in there when we already have
> (nearly)everything we need at hand ?
Agreed ;-)

>
> Regarding the task force I think I can try to support you. I just dont
> know how much time I can put in there, can be that I have a new
> project next week, can be that I have lots of time to spent in february.
I'm also about to start into a new customer project until beginning of May.

Regards,
Eike Stepper
----
http://wiki.eclipse.org/CDO
http://wiki.eclipse.org/Net4j


Re: [CDO] is it what I want ? [message #614283 is a reply to message #109683] Wed, 30 January 2008 13:09 Go to previous message
Eike Stepper is currently offline Eike StepperFriend
Messages: 6579
Registered: July 2009
Senior Member
Thomas schrieb:
> Hi Eike,
>
> Be sure to have annotations and entitymanager too.
Got them ;-)

>
> I tried to migrate my ecore from yesterday with new emf project,
> native CDO. installed the latest integration build, as the build
> scripts are unix only.
You don't need build scripts. BTW. which scripts do you refer to?
Just check out everything with All.psf.
The migrator doesn't have any other CDO/Net4j dependencies. Just
right-click org.eclipse.emf.cdo.migrator and export it as deployable
plugin to your eclipse installation. restart and it should be there.

DTH?

WRT. the exception below, what is test.cdo?
--> "Resource '/test.cdo' does not exist. "


Regards,
Eike Stepper
----
http://wiki.eclipse.org/CDO
http://wiki.eclipse.org/Net4j


>
> I get:
> !MESSAGE
> !STACK 0
> java.lang.reflect.InvocationTargetException
> at
> org.eclipse.ui.actions.WorkspaceModifyOperation.run(Workspac eModifyOperation.java:119)
>
> at
> org.eclipse.jface.operation.ModalContext.runInCurrentThread( ModalContext.java:407)
>
> at
> org.eclipse.jface.operation.ModalContext.run(ModalContext.ja va:347)
> at org.eclipse.jface.wizard.WizardDialog.run(WizardDialog.java: 934)
> at
> org.eclipse.emf.converter.ui.contribution.base.ModelConverte rWizard.performFinish(ModelConverterWizard.java:246)
>
> at
> org.eclipse.emf.importer.ui.contribution.base.ModelImporterW izard.performFinish(ModelImporterWizard.java:157)
>
> at
> org.eclipse.jface.wizard.WizardDialog.finishPressed(WizardDi alog.java:742)
>
> at
> org.eclipse.jface.wizard.WizardDialog.buttonPressed(WizardDi alog.java:373)
>
> at org.eclipse.jface.dialogs.Dialog$2.widgetSelected(Dialog.jav a:623)
> at
> org.eclipse.swt.widgets.TypedListener.handleEvent(TypedListe ner.java:227)
> at org.eclipse.swt.widgets.EventTable.sendEvent(EventTable.java :66)
> at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:952)
> at
> org.eclipse.swt.widgets.Display.runDeferredEvents(Display.ja va:3750)
> at org.eclipse.swt.widgets.Display.readAndDispatch(Display.java :3361)
> at org.eclipse.jface.window.Window.runEventLoop(Window.java:825 )
> at org.eclipse.jface.window.Window.open(Window.java:801)
> at
> org.eclipse.ui.actions.NewProjectAction.run(NewProjectAction .java:116)
> at org.eclipse.jface.action.Action.runWithEvent(Action.java:498 )
> at
> org.eclipse.jface.action.ActionContributionItem.handleWidget Selection(ActionContributionItem.java:582)
>
> at
> org.eclipse.jface.action.ActionContributionItem.access$2(Act ionContributionItem.java:499)
>
> at
> org.eclipse.jface.action.ActionContributionItem$5.handleEven t(ActionContributionItem.java:410)
>
> at org.eclipse.swt.widgets.EventTable.sendEvent(EventTable.java :66)
> at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:952)
> at
> org.eclipse.swt.widgets.Display.runDeferredEvents(Display.ja va:3750)
> at org.eclipse.swt.widgets.Display.readAndDispatch(Display.java :3361)
> at
> org.eclipse.ui.internal.Workbench.runEventLoop(Workbench.jav a:2381)
> at org.eclipse.ui.internal.Workbench.runUI(Workbench.java:2345)
> at org.eclipse.ui.internal.Workbench.access$4(Workbench.java:22 11)
> at org.eclipse.ui.internal.Workbench$4.run(Workbench.java:473)
> at
> org.eclipse.core.databinding.observable.Realm.runWithDefault (Realm.java:288)
>
> at
> org.eclipse.ui.internal.Workbench.createAndRunWorkbench(Work bench.java:468)
>
> at
> org.eclipse.ui.PlatformUI.createAndRunWorkbench(PlatformUI.j ava:149)
> at
> org.eclipse.ui.internal.ide.application.IDEApplication.start (IDEApplication.java:106)
>
> at
> org.eclipse.equinox.internal.app.EclipseAppHandle.run(Eclips eAppHandle.java:193)
>
> at
> org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher .runApplication(EclipseAppLauncher.java:106)
>
> at
> org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher .start(EclipseAppLauncher.java:76)
>
> at
> org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseS tarter.java:362)
>
> at
> org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseS tarter.java:175)
>
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
> at java.lang.reflect.Method.invoke(Unknown Source)
> at org.eclipse.equinox.launcher.Main.invokeFramework(Main.java: 561)
> at org.eclipse.equinox.launcher.Main.basicRun(Main.java:501)
> at org.eclipse.equinox.launcher.Main.run(Main.java:1239)
> Caused by: org.eclipse.core.runtime.CoreException: An error occurred
> while performing this operation.
> at
> org.eclipse.emf.common.util.DiagnosticException.toCoreExcept ion(DiagnosticException.java:47)
>
> at
> org.eclipse.emf.converter.ui.contribution.base.ModelConverte rWizard$1.execute(ModelConverterWizard.java:235)
>
> at
> org.eclipse.ui.actions.WorkspaceModifyOperation$1.run(Worksp aceModifyOperation.java:104)
>
> at
> org.eclipse.core.internal.resources.Workspace.run(Workspace. java:1800)
> at
> org.eclipse.ui.actions.WorkspaceModifyOperation.run(Workspac eModifyOperation.java:116)
>
> ... 44 more
> Root exception:
> org.eclipse.core.runtime.CoreException: An error occurred while
> performing this operation.
> at
> org.eclipse.emf.common.util.DiagnosticException.toCoreExcept ion(DiagnosticException.java:47)
>
> at
> org.eclipse.emf.converter.ui.contribution.base.ModelConverte rWizard$1.execute(ModelConverterWizard.java:235)
>
> at
> org.eclipse.ui.actions.WorkspaceModifyOperation$1.run(Worksp aceModifyOperation.java:104)
>
> at
> org.eclipse.core.internal.resources.Workspace.run(Workspace. java:1800)
> at
> org.eclipse.ui.actions.WorkspaceModifyOperation.run(Workspac eModifyOperation.java:116)
>
> at
> org.eclipse.jface.operation.ModalContext.runInCurrentThread( ModalContext.java:407)
>
> at
> org.eclipse.jface.operation.ModalContext.run(ModalContext.ja va:347)
> at org.eclipse.jface.wizard.WizardDialog.run(WizardDialog.java: 934)
> at
> org.eclipse.emf.converter.ui.contribution.base.ModelConverte rWizard.performFinish(ModelConverterWizard.java:246)
>
> at
> org.eclipse.emf.importer.ui.contribution.base.ModelImporterW izard.performFinish(ModelImporterWizard.java:157)
>
> at
> org.eclipse.jface.wizard.WizardDialog.finishPressed(WizardDi alog.java:742)
>
> at
> org.eclipse.jface.wizard.WizardDialog.buttonPressed(WizardDi alog.java:373)
>
> at org.eclipse.jface.dialogs.Dialog$2.widgetSelected(Dialog.jav a:623)
> at
> org.eclipse.swt.widgets.TypedListener.handleEvent(TypedListe ner.java:227)
> at org.eclipse.swt.widgets.EventTable.sendEvent(EventTable.java :66)
> at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:952)
> at
> org.eclipse.swt.widgets.Display.runDeferredEvents(Display.ja va:3750)
> at org.eclipse.swt.widgets.Display.readAndDispatch(Display.java :3361)
> at org.eclipse.jface.window.Window.runEventLoop(Window.java:825 )
> at org.eclipse.jface.window.Window.open(Window.java:801)
> at
> org.eclipse.ui.actions.NewProjectAction.run(NewProjectAction .java:116)
> at org.eclipse.jface.action.Action.runWithEvent(Action.java:498 )
> at
> org.eclipse.jface.action.ActionContributionItem.handleWidget Selection(ActionContributionItem.java:582)
>
> at
> org.eclipse.jface.action.ActionContributionItem.access$2(Act ionContributionItem.java:499)
>
> at
> org.eclipse.jface.action.ActionContributionItem$5.handleEven t(ActionContributionItem.java:410)
>
> at org.eclipse.swt.widgets.EventTable.sendEvent(EventTable.java :66)
> at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:952)
> at
> org.eclipse.swt.widgets.Display.runDeferredEvents(Display.ja va:3750)
> at org.eclipse.swt.widgets.Display.readAndDispatch(Display.java :3361)
> at
> org.eclipse.ui.internal.Workbench.runEventLoop(Workbench.jav a:2381)
> at org.eclipse.ui.internal.Workbench.runUI(Workbench.java:2345)
> at org.eclipse.ui.internal.Workbench.access$4(Workbench.java:22 11)
> at org.eclipse.ui.internal.Workbench$4.run(Workbench.java:473)
> at
> org.eclipse.core.databinding.observable.Realm.runWithDefault (Realm.java:288)
>
> at
> org.eclipse.ui.internal.Workbench.createAndRunWorkbench(Work bench.java:468)
>
> at
> org.eclipse.ui.PlatformUI.createAndRunWorkbench(PlatformUI.j ava:149)
> at
> org.eclipse.ui.internal.ide.application.IDEApplication.start (IDEApplication.java:106)
>
> at
> org.eclipse.equinox.internal.app.EclipseAppHandle.run(Eclips eAppHandle.java:193)
>
> at
> org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher .runApplication(EclipseAppLauncher.java:106)
>
> at
> org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher .start(EclipseAppLauncher.java:76)
>
> at
> org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseS tarter.java:362)
>
> at
> org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseS tarter.java:175)
>
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
> at java.lang.reflect.Method.invoke(Unknown Source)
> at org.eclipse.equinox.launcher.Main.invokeFramework(Main.java: 561)
> at org.eclipse.equinox.launcher.Main.basicRun(Main.java:501)
> at org.eclipse.equinox.launcher.Main.run(Main.java:1239)
> org.eclipse.core.runtime.CoreException[2048]:
> org.eclipse.emf.common.util.DiagnosticException: An error occurred
> while performing this operation.
> at
> org.eclipse.emf.converter.ui.contribution.base.ModelConverte rWizard$1.execute(ModelConverterWizard.java:234)
>
> at
> org.eclipse.ui.actions.WorkspaceModifyOperation$1.run(Worksp aceModifyOperation.java:104)
>
> at
> org.eclipse.core.internal.resources.Workspace.run(Workspace. java:1800)
> at
> org.eclipse.ui.actions.WorkspaceModifyOperation.run(Workspac eModifyOperation.java:116)
>
> at
> org.eclipse.jface.operation.ModalContext.runInCurrentThread( ModalContext.java:407)
>
> at
> org.eclipse.jface.operation.ModalContext.run(ModalContext.ja va:347)
> at org.eclipse.jface.wizard.WizardDialog.run(WizardDialog.java: 934)
> at
> org.eclipse.emf.converter.ui.contribution.base.ModelConverte rWizard.performFinish(ModelConverterWizard.java:246)
>
> at
> org.eclipse.emf.importer.ui.contribution.base.ModelImporterW izard.performFinish(ModelImporterWizard.java:157)
>
> at
> org.eclipse.jface.wizard.WizardDialog.finishPressed(WizardDi alog.java:742)
>
> at
> org.eclipse.jface.wizard.WizardDialog.buttonPressed(WizardDi alog.java:373)
>
> at org.eclipse.jface.dialogs.Dialog$2.widgetSelected(Dialog.jav a:623)
> at
> org.eclipse.swt.widgets.TypedListener.handleEvent(TypedListe ner.java:227)
> at org.eclipse.swt.widgets.EventTable.sendEvent(EventTable.java :66)
> at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:952)
> at
> org.eclipse.swt.widgets.Display.runDeferredEvents(Display.ja va:3750)
> at org.eclipse.swt.widgets.Display.readAndDispatch(Display.java :3361)
> at org.eclipse.jface.window.Window.runEventLoop(Window.java:825 )
> at org.eclipse.jface.window.Window.open(Window.java:801)
> at
> org.eclipse.ui.actions.NewProjectAction.run(NewProjectAction .java:116)
> at org.eclipse.jface.action.Action.runWithEvent(Action.java:498 )
> at
> org.eclipse.jface.action.ActionContributionItem.handleWidget Selection(ActionContributionItem.java:582)
>
> at
> org.eclipse.jface.action.ActionContributionItem.access$2(Act ionContributionItem.java:499)
>
> at
> org.eclipse.jface.action.ActionContributionItem$5.handleEven t(ActionContributionItem.java:410)
>
> at org.eclipse.swt.widgets.EventTable.sendEvent(EventTable.java :66)
> at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:952)
> at
> org.eclipse.swt.widgets.Display.runDeferredEvents(Display.ja va:3750)
> at org.eclipse.swt.widgets.Display.readAndDispatch(Display.java :3361)
> at
> org.eclipse.ui.internal.Workbench.runEventLoop(Workbench.jav a:2381)
> at org.eclipse.ui.internal.Workbench.runUI(Workbench.java:2345)
> at org.eclipse.ui.internal.Workbench.access$4(Workbench.java:22 11)
> at org.eclipse.ui.internal.Workbench$4.run(Workbench.java:473)
> at
> org.eclipse.core.databinding.observable.Realm.runWithDefault (Realm.java:288)
>
> at
> org.eclipse.ui.internal.Workbench.createAndRunWorkbench(Work bench.java:468)
>
> at
> org.eclipse.ui.PlatformUI.createAndRunWorkbench(PlatformUI.j ava:149)
> at
> org.eclipse.ui.internal.ide.application.IDEApplication.start (IDEApplication.java:106)
>
> at
> org.eclipse.equinox.internal.app.EclipseAppHandle.run(Eclips eAppHandle.java:193)
>
> at
> org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher .runApplication(EclipseAppLauncher.java:106)
>
> at
> org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher .start(EclipseAppLauncher.java:76)
>
> at
> org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseS tarter.java:362)
>
> at
> org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseS tarter.java:175)
>
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
> at java.lang.reflect.Method.invoke(Unknown Source)
> at org.eclipse.equinox.launcher.Main.invokeFramework(Main.java: 561)
> at org.eclipse.equinox.launcher.Main.basicRun(Main.java:501)
> at org.eclipse.equinox.launcher.Main.run(Main.java:1239)
> Caused by: org.eclipse.emf.common.util.WrappedException:
> org.eclipse.core.internal.resources.ResourceException: Resource
> '/test.cdo' does not exist.
> at
> org.eclipse.emf.cdo.migrator.CDOMigrator.adjustGenModel(CDOM igrator.java:91)
>
> at
> org.eclipse.emf.cdo.migrator.CDOImporter.adjustGenModel(CDOI mporter.java:125)
>
> at
> org.eclipse.emf.importer.ModelImporter.prepareGenModelAndEPa ckages(ModelImporter.java:718)
>
> at
> org.eclipse.emf.importer.ui.contribution.base.ModelImporterW izard.doPerformFinish(ModelImporterWizard.java:149)
>
> at
> org.eclipse.emf.converter.ui.contribution.base.ModelConverte rWizard$1.execute(ModelConverterWizard.java:228)
>
> ... 47 more
> Caused by: org.eclipse.core.internal.resources.ResourceException:
> Resource '/test.cdo' does not exist.
> at
> org.eclipse.core.internal.resources.Resource.checkExists(Res ource.java:309)
>
> at
> org.eclipse.core.internal.resources.Resource.checkAccessible (Resource.java:192)
>
> at
> org.eclipse.core.internal.resources.Project.checkAccessible( Project.java:113)
>
> at
> org.eclipse.core.internal.resources.Folder.assertCreateRequi rements(Folder.java:32)
>
> at org.eclipse.core.internal.resources.Folder.create(Folder.jav a:88)
> at org.eclipse.core.internal.resources.Folder.create(Folder.jav a:118)
> at
> org.eclipse.emf.cdo.migrator.CDOMigrator.adjustGenModel(CDOM igrator.java:86)
>
> ... 51 more
>
> Eike Stepper schrieb:
>> Guys,
>>
>> I just downloaded Hibernate ;-)
>>
>> Regards,
>> Eike Stepper
>> ----
>> http://wiki.eclipse.org/CDO
>> http://wiki.eclipse.org/Net4j
>>
>>
>>
>> Martin Taal schrieb:
>>> Hi Eike, Thomas,
>>> I will start looking at the integration between CDO and Teneo today.
>>> I first need to get familiar with cdo and then I can see how Teneo
>>> can be integrated. I'll keep you posted.
>>>
>>> See my other additions below.
>>>
>>> gr. Martin
>>>
>>> Eike Stepper wrote:
>>>> Thomas schrieb:
>>>>> HI Eike, this seems to be what I would need.
>>>>> I overlooked your mapping hints (will have to see this in an
>>>>> example maybe tommorrow.) what I dislike is the relation tables.
>>>>> as i do reporting with birt i will have to query the database with
>>>>> sql and th relation tables make manual joining a pain. I know some
>>>>> dtabase gurus recommend join tables but I still prefer a single
>>>>> foreign key in the target table. ok you need a single column then
>>>>> for each relation (give it a speaking name and everthing is clear)
>>>> What I don't like with the foreign key joins you mention is the
>>>> following:
>>>> Assume you are a big IT company and you have many application with
>>>> one development team being responsible for one application. The
>>>> applications have non-circular dependencies on each other and this
>>>> is clearly reflected within the models that form the applications.
>>>> As long as you're modeling there's at no time the need to modify
>>>> foreign code (the models you depend on). Consider the following
>>>> example:
>>>> Team1, January 2008, develops a model Employees. There is an EClass
>>>> Employee.
>>>> Team2, March 2008, develops the model Supervisors. There is an
>>>> EClass Supervisor with a many-reference
>>>> supervisedEmployees:List<Emplyoee>.
>>>>
>>>> In the OO world there's no need for Team2 to touch code of Team1.
>>>> If the many-reference supervisedEmployees is mapped to a dedicated
>>>> join table there's also no responsibility conflict in the DB team
>>>> of your company.
>>>> But when it comes to O/R mapping of supervisedEmployees with
>>>> foreign keys in the table of Employee there is no longer a clear
>>>> responsibility for that class!
>>>> The same is true for m:n references across model boundaries.
>>> MT>> I have a background in developing ERP systems and there it was
>>> also common to use a foreign key field instead of join tables. A
>>> number of thoughts from my side regarding this topic:
>>> - as Eike mentions foreign keys are more intruisive than join table
>>> as the target table gets changed (has an extra foreign key field(s))
>>> - Foreign keys are more efficient as there is one less join to do
>>> - Foreign keys do not support duplicate occurences in a list (join
>>> tables do, assuming a join table has a separate id column).
>>> - Specifically for containment relations my feel is that a foreign
>>> key field is appropriate as it reflects the stronger relation
>>> between the child and the parent. The same can be said for
>>> bidirectional relations.
>>>
>>> Overall I have the same feel as Thomas, with my background I like
>>> foreign keys (as they are more efficient) but I understand that
>>> there are many people with other ideas. Teneo has an option to
>>> specify if all non-containment relations should be mapped with a
>>> join table (or not).
>>>
>>>>
>>>>> why is the version part of the primary key ? that doesnt make
>>>>> sense to me. maybe you have reasons but i would expect that the db
>>>>> has only a single version stored. and again here pain in joining.
>>>> CDO is basically capable of auditing (retrieving historical states
>>>> of the overall model). I guess it's a similar effect like the one
>>>> the new Temporality project announces. An Istore decides if it
>>>> supports auditing mode and if it supports non-auditing mode. The
>>>> DBStore currently does only support auditing mode! I'm currently a
>>>> bit unsure what to prioritize: Make DBStore support non-auditing
>>>> mode or help Martin develop a HibernateStore for CDO. I guess
>>>> you'll vote for the latter ;-) I'd agree.
>>> MT>> I will start looking at CDO today and try out the tutorial,
>>> etc. Maybe I can get a long way without asking to much of your time
>>> Eike (so then you can do both :-).
>>> MT>> Btw, imo it is great that CDO also considers topics like
>>> auditing, these generic topics can really be solved at this level.
>>>
>>>>
>>>>> what kinds of relations are supported ?
>>>> Single-valued references are mapped to CDOID columns in the table
>>>> of the referencing EClass.
>>>> Multi-valued references are mapped to the join tables I mentioned
>>>> before.
>>>> Was this what you asked for?
>>>>
>>>>>
>>>>> What about Lobs ? is there support for large objects ?
>>>> In which context? For mapping multi-valued references? This is
>>>> planned via
>>>> org.eclipse.emf.cdo.server.internal.db.ToMany.LIKE_ATTRIBUTE S. I'd
>>>> make querying even harder.
>>>>
>>>>>
>>>>> We would at least need to supply not null constraints
>>>> That could make a good Bugzilla (A) ;-)
>>>>
>>>>> on fields and ManyToOne relations,
>>>> See my above concerns. A separate Bugzilla (B) could be good to
>>>> discuss these concerns.
>>>>
>>>>> field lengthes for character strings,
>>>> Fits well into the Bugzilla (A).
>>>>
>>>>> plus I have to dive into the validation problem. plus i need
>>>>> something for unique key constraints and indexes.
>>>> What is the validation problem? The one Simon solved via OCL?
>>>> Unique key constraints and indexes could go into (A) as well.
>>>>
>>>> One general comment to all this mapping stuff: As you correctly
>>>> analyzed in another thread, CDO is not mainly about providing a new
>>>> O/R mapping solution. Hibernate will probably always be better here
>>>> and I didn't plan to compete with it. CDO is more focused on
>>>> providing a stable and efficient 3-tier solution (client /
>>>> repository / store) with distributed shared model semantics (remote
>>>> update notifications) and an auditing mode. The store even doesn't
>>>> need to be a relational database.
>>>>
>>>> I think it's time for me to dig into the Hibernate code and work
>>>> with Martin to develop a HibernateStore for the CDO storage framework.
>>>>
>>>> Regards,
>>>> Eike Stepper
>>>> ----
>>>> http://wiki.eclipse.org/CDO
>>>> http://wiki.eclipse.org/Net4j
>>>>
>>>>
>>>>>
>>>>> Thomas
>>>>>
>>>>> Eike Stepper schrieb:
>>>>>> Hi Thomas,
>>>>>>
>>>>>> A CDOSession has a setReferenceChunkSize() method which you can
>>>>>> call to limit the number of objects (ids) to load on collection
>>>>>> read accesses. Since read access (loading) is handled by the
>>>>>> CDOSession all CDOViews on that session share this setting. We
>>>>>> are currently discussing to provide an additional session
>>>>>> property: InitialReferenceChunkSize. Then you could even
>>>>>> configure to load nothing on the first access (of the source
>>>>>> object) and max n targets on subsequent reference accesses. At
>>>>>> the moment I'd suggest to set a value of 10-100 so that you're
>>>>>> shielded against huge collections.
>>>>>>
>>>>>> Regards,
>>>>>> Eike Stepper
>>>>>> ----
>>>>>> http://wiki.eclipse.org/CDO
>>>>>> http://wiki.eclipse.org/Net4j
>>>>>>
>>>>>>
>>>>>>
>>>>>> Thomas schrieb:
>>>>>>> Once again..
>>>>>>> Another thing coming to my mind is about the object graph.
>>>>>>> Suggest I have a Object Person with a Collection of Adresses.
>>>>>>> when I query for the person did I get it right that the Adresse
>>>>>>> are only loaded when I try to access them ? That would be the
>>>>>>> main decision factor for me. I have expensive objects and the
>>>>>>> more the could be lazy loaded the better my ui handling would be.
>>>>>>>
>>>>>>> Regards Thomas
>>>
>>>


Re: [CDO] is it what I want ? [message #614285 is a reply to message #109697] Wed, 30 January 2008 13:13 Go to previous message
Thomas is currently offline ThomasFriend
Messages: 151
Registered: July 2009
Senior Member
HI Eike,

Im almost fine with that, but I would prefer to see the version not part
of the primary key. I know this makes an additional column, but then you
can join solely on the single column surrogate key, thats all what its
about. Makes joining very efficient.

Thomas

Eike Stepper schrieb:
> Thomas schrieb:
>> [stuff deleted]
>>
>>> why is the version part of the primary key ? that doesnt make sense
>>> to me. maybe you have reasons but i would expect that the db has only
>>> a single version stored. and again here pain in joining. CDO is
>>> basically capable of auditing (retrieving historical states of the
>>> overall model). I guess it's a similar effect like the one the new
>>> Temporality project announces.
>>
>> Ok then you have mutliple versions. But I would (personal taste ?)
>> prefer a single column surrogate primary key in any case. There are
>> some techniques on versioning (take three add columns columns, a group
>> id that groups the versions a counter/timestamp and a boolean, set the
>> boolean true for the current version, put a unique constraint on
>> group_id and version) timestamp makes problems on oracle as it not
>> finegrained enough for have load, so i prefer a counter or a mix of
>> both of it. its just the idea of having a clean surrogate key that i
>> always prefer.
> I'm not sure if I completely understand what you're saying about
> versioning technique, but I'm sure you've been a DB expert before you
> started modeling ;-)
>
> The current structure of the internal columns of CDO is carefully
> chosen. There's no redundancy and all of the following operations are
> possible efficiently:
> a) loadLatestRevision (revised==null)
> b) loadRevisionByVersion (version == v)
> c) loadRevisionByTime (revised == UNSPECIFIED_DATE || revised >=
> timeStamp) && timeStamp >= created
> d) lockForWrite (set revised = now)
>
> As I said these structures are optimized for the repository access
> (defined by the IStore API) and not for manual querying (although this
> was a secondary requirement).
>
>> [stuff deleted]
>>
>> Hmm Eike, dont know if I should open bugs on this if we dig into
>> teneo. Why put so much effort in there when we already have
>> (nearly)everything we need at hand ?
> Agreed ;-)
>
>>
>> Regarding the task force I think I can try to support you. I just dont
>> know how much time I can put in there, can be that I have a new
>> project next week, can be that I have lots of time to spent in february.
> I'm also about to start into a new customer project until beginning of May.
>
> Regards,
> Eike Stepper
> ----
> http://wiki.eclipse.org/CDO
> http://wiki.eclipse.org/Net4j
>
Re: [CDO] is it what I want ? [message #614294 is a reply to message #109705] Wed, 30 January 2008 13:15 Go to previous message
Thomas is currently offline ThomasFriend
Messages: 151
Registered: July 2009
Senior Member
Eike Stepper schrieb:
> Thomas schrieb:
>> Hi Eike,
>>
>> Be sure to have annotations and entitymanager too.
> Got them ;-)
>
>>
>> I tried to migrate my ecore from yesterday with new emf project,
>> native CDO. installed the latest integration build, as the build
>> scripts are unix only.
I tried to build the sdk features.
There seem to be some shell scripts in there ?

> You don't need build scripts. BTW. which scripts do you refer to?
> Just check out everything with All.psf.
> The migrator doesn't have any other CDO/Net4j dependencies. Just
> right-click org.eclipse.emf.cdo.migrator and export it as deployable
> plugin to your eclipse installation. restart and it should be there.
OK Ill try to export the migrator

>
> DTH?
>
> WRT. the exception below, what is test.cdo?
> --> "Resource '/test.cdo' does not exist. "

test.cdo is the project name i gave in the wizard.
Re: [CDO] is it what I want ? [message #614297 is a reply to message #110013] Wed, 30 January 2008 13:19 Go to previous message
Eike Stepper is currently offline Eike StepperFriend
Messages: 6579
Registered: July 2009
Senior Member
Thomas schrieb:
> HI Eike,
>
> Im almost fine with that, but I would prefer to see the version not
> part of the primary key. I know this makes an additional column, but
> then you can join solely on the single column surrogate key, thats all
> what its about. Makes joining very efficient.
Do you mean an additional technical key, i.e. an automatically assigned
(long) integer number that has no association with the (also technical)
CDOID which is at least visible at the client side? Just to circumvent
joining via two columns?

Regards,
Eike Stepper
----
http://wiki.eclipse.org/CDO
http://wiki.eclipse.org/Net4j


>
> Thomas
>
> Eike Stepper schrieb:
>> Thomas schrieb:
>>> [stuff deleted]
>>>
>>>> why is the version part of the primary key ? that doesnt make sense
>>>> to me. maybe you have reasons but i would expect that the db has
>>>> only a single version stored. and again here pain in joining. CDO
>>>> is basically capable of auditing (retrieving historical states of
>>>> the overall model). I guess it's a similar effect like the one the
>>>> new Temporality project announces.
>>>
>>> Ok then you have mutliple versions. But I would (personal taste ?)
>>> prefer a single column surrogate primary key in any case. There are
>>> some techniques on versioning (take three add columns columns, a
>>> group id that groups the versions a counter/timestamp and a boolean,
>>> set the boolean true for the current version, put a unique
>>> constraint on group_id and version) timestamp makes problems on
>>> oracle as it not finegrained enough for have load, so i prefer a
>>> counter or a mix of both of it. its just the idea of having a clean
>>> surrogate key that i always prefer.
>> I'm not sure if I completely understand what you're saying about
>> versioning technique, but I'm sure you've been a DB expert before you
>> started modeling ;-)
>>
>> The current structure of the internal columns of CDO is carefully
>> chosen. There's no redundancy and all of the following operations are
>> possible efficiently:
>> a) loadLatestRevision (revised==null)
>> b) loadRevisionByVersion (version == v)
>> c) loadRevisionByTime (revised == UNSPECIFIED_DATE || revised >=
>> timeStamp) && timeStamp >= created
>> d) lockForWrite (set revised = now)
>>
>> As I said these structures are optimized for the repository access
>> (defined by the IStore API) and not for manual querying (although
>> this was a secondary requirement).
>>
>>> [stuff deleted]
>>>
>>> Hmm Eike, dont know if I should open bugs on this if we dig into
>>> teneo. Why put so much effort in there when we already have
>>> (nearly)everything we need at hand ?
>> Agreed ;-)
>>
>>>
>>> Regarding the task force I think I can try to support you. I just
>>> dont know how much time I can put in there, can be that I have a new
>>> project next week, can be that I have lots of time to spent in
>>> february.
>> I'm also about to start into a new customer project until beginning
>> of May.
>>
>> Regards,
>> Eike Stepper
>> ----
>> http://wiki.eclipse.org/CDO
>> http://wiki.eclipse.org/Net4j
>>


Re: [CDO] is it what I want ? [message #614300 is a reply to message #110051] Wed, 30 January 2008 13:21 Go to previous message
Thomas is currently offline ThomasFriend
Messages: 151
Registered: July 2009
Senior Member
Ok, exported the migrator plugin from the current source, still the same
exception... ?

I do "new emf project", select "Ecore model (CDO native)", select my
ecore from yesterday, press finish, then it fails.

>> WRT. the exception below, what is test.cdo?
>> --> "Resource '/test.cdo' does not exist. "
>
> test.cdo is the project name i gave in the wizard.
Re: [CDO] is it what I want ? [message #614305 is a reply to message #110063] Wed, 30 January 2008 13:22 Go to previous message
Thomas is currently offline ThomasFriend
Messages: 151
Registered: July 2009
Senior Member
Exactly.

Eike Stepper schrieb:
> Thomas schrieb:
>> HI Eike,
>>
>> Im almost fine with that, but I would prefer to see the version not
>> part of the primary key. I know this makes an additional column, but
>> then you can join solely on the single column surrogate key, thats all
>> what its about. Makes joining very efficient.
> Do you mean an additional technical key, i.e. an automatically assigned
> (long) integer number that has no association with the (also technical)
> CDOID which is at least visible at the client side? Just to circumvent
> joining via two columns?
>
Re: [CDO] is it what I want ? [message #614308 is a reply to message #110051] Wed, 30 January 2008 13:24 Go to previous message
Eike Stepper is currently offline Eike StepperFriend
Messages: 6579
Registered: July 2009
Senior Member
This is a multi-part message in MIME format.
--------------090805030209020307070306
Content-Type: text/plain; charset=ISO-8859-15; format=flowed
Content-Transfer-Encoding: 7bit

Thomas schrieb:
> I tried to build the sdk features.
> There seem to be some shell scripts in there ?
Not that I know about and I'm the author of all files under
/cvsroot/modeling/org.eclipse.emf/org.eclipse.emf.cdo ;-)

There are lots of scripts under
/cvsroot/modeling/org.eclipse.emf/org.eclipse.emf.cdo.*relen g *but
you shouldn't bother with these.

>
>> You don't need build scripts. BTW. which scripts do you refer to?
>> Just check out everything with All.psf.
>> The migrator doesn't have any other CDO/Net4j dependencies. Just
>> right-click org.eclipse.emf.cdo.migrator and export it as deployable
>> plugin to your eclipse installation. restart and it should be there.
> OK Ill try to export the migrator
>
>>
>> DTH?
>>
>> WRT. the exception below, what is test.cdo?
>> --> "Resource '/test.cdo' does not exist. "
>
> test.cdo is the project name i gave in the wizard.
Which wizard? Can you generate a normal Ecore model (w/o CDO)?
I just tried the CDO Migrator to verify Stefan's model and it worked
like a charme.

Regards,
Eike Stepper
----
http://wiki.eclipse.org/CDO
http://wiki.eclipse.org/Net4j



--------------090805030209020307070306
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">
Thomas schrieb:
<blockquote cite="mid:fnpta3$bra$2@build.eclipse.org" type="cite">I
tried to build the sdk features.
<br>
There seem to be some shell scripts in there ?
<br>
</blockquote>
Not that I know about and I'm the author of all files under <br>


Re: [CDO] is it what I want ? [message #614311 is a reply to message #110101] Wed, 30 January 2008 13:29 Go to previous message
Eike Stepper is currently offline Eike StepperFriend
Messages: 6579
Registered: July 2009
Senior Member
Thomas schrieb:
> Exactly.
Ok, I added an enhancement request just that we don't forget about this:
https://bugs.eclipse.org/bugs/show_bug.cgi?id=217083

I'd like to start with Hibernate first ;-)

BTW. if the DBStore was able to support non-auditing mode it would do so
with a single CDOID PK column.

Regards,
Eike Stepper
----
http://wiki.eclipse.org/CDO
http://wiki.eclipse.org/Net4j


>
> Eike Stepper schrieb:
>> Thomas schrieb:
>>> HI Eike,
>>>
>>> Im almost fine with that, but I would prefer to see the version not
>>> part of the primary key. I know this makes an additional column, but
>>> then you can join solely on the single column surrogate key, thats
>>> all what its about. Makes joining very efficient.
>> Do you mean an additional technical key, i.e. an automatically
>> assigned (long) integer number that has no association with the (also
>> technical) CDOID which is at least visible at the client side? Just
>> to circumvent joining via two columns?
>>


Re: [CDO] is it what I want ? [message #614312 is a reply to message #110076] Wed, 30 January 2008 13:30 Go to previous message
Eike Stepper is currently offline Eike StepperFriend
Messages: 6579
Registered: July 2009
Senior Member
Thomas schrieb:
> Ok, exported the migrator plugin from the current source, still the
> same exception... ?
>
> I do "new emf project",
Between this and the next step I usually copy the .ecore file into the
model folder of the new plugin. Have you done that, too?

> select "Ecore model (CDO native)", select my ecore from yesterday,
> press finish, then it fails.
>
>>> WRT. the exception below, what is test.cdo?
>>> --> "Resource '/test.cdo' does not exist. "
>>
>> test.cdo is the project name i gave in the wizard.


Re: [CDO] is it what I want ? [message #614314 is a reply to message #110113] Wed, 30 January 2008 13:34 Go to previous message
Thomas is currently offline ThomasFriend
Messages: 151
Registered: July 2009
Senior Member
I used the File New EMF Project wizard.
Normal Ecore model works fine.

I dont see the CDO in the context menu (as it was on my 3.3
installation) any more.

Thomas
Re: [CDO] is it what I want ? [message #614317 is a reply to message #110139] Wed, 30 January 2008 13:41 Go to previous message
Thomas is currently offline ThomasFriend
Messages: 151
Registered: July 2009
Senior Member
Sorry Eike I dont get it.
At this point there I have no new plugin project.

Eike Stepper schrieb:
> Thomas schrieb:
>> Ok, exported the migrator plugin from the current source, still the
>> same exception... ?
>>
>> I do "new emf project",
> Between this and the next step I usually copy the .ecore file into the
> model folder of the new plugin. Have you done that, too?
>
>> select "Ecore model (CDO native)", select my ecore from yesterday,
>> press finish, then it fails.
>>
>>>> WRT. the exception below, what is test.cdo?
>>>> --> "Resource '/test.cdo' does not exist. "
>>>
>>> test.cdo is the project name i gave in the wizard.
Re: [CDO] is it what I want ? [message #614321 is a reply to message #110158] Wed, 30 January 2008 13:46 Go to previous message
Eike Stepper is currently offline Eike StepperFriend
Messages: 6579
Registered: July 2009
Senior Member
Ok, once more ;-)

1) New Wizard "Empty EMF project" (this is the plugin project that I meant)
2) Create/copy an .ecore file to the model folder
3) Use the New Wizard "EMF Model" on the .ecore file and choose the
importer "Ecore model (CDO native)"
4) Adjust other genmodel settings (optional)
5) Generate the genmodel
6) Use the generated model plugin with CDO
7) Use the generated edit plugin with the CDO UI (optional)

Does that work?

Regards,
Eike Stepper
----
http://wiki.eclipse.org/CDO
http://wiki.eclipse.org/Net4j



Thomas schrieb:
> Sorry Eike I dont get it.
> At this point there I have no new plugin project.
>
> Eike Stepper schrieb:
>> Thomas schrieb:
>>> Ok, exported the migrator plugin from the current source, still the
>>> same exception... ?
>>>
>>> I do "new emf project",
>> Between this and the next step I usually copy the .ecore file into
>> the model folder of the new plugin. Have you done that, too?
>>
>>> select "Ecore model (CDO native)", select my ecore from yesterday,
>>> press finish, then it fails.
>>>
>>>>> WRT. the exception below, what is test.cdo?
>>>>> --> "Resource '/test.cdo' does not exist. "
>>>>
>>>> test.cdo is the project name i gave in the wizard.


Re: [CDO] is it what I want ? [message #614324 is a reply to message #110146] Wed, 30 January 2008 13:48 Go to previous message
Eike Stepper is currently offline Eike StepperFriend
Messages: 6579
Registered: July 2009
Senior Member
This is a multi-part message in MIME format.
--------------020408060102070908060401
Content-Type: text/plain; charset=ISO-8859-15; format=flowed
Content-Transfer-Encoding: 7bit

Thomas schrieb:
> I used the File New EMF Project wizard.
> Normal Ecore model works fine.
>
> I dont see the CDO in the context menu (as it was on my 3.3
> installation) any more.
It's in the context menu of the genmodel file, if you have already one.
If it's not, then please check if the following dependencies of the
migrator plugin are satisfied:



Regards,
Eike Stepper
----
http://wiki.eclipse.org/CDO
http://wiki.eclipse.org/Net4j



--------------020408060102070908060401
Content-Type: multipart/related;
boundary="------------070401020102050108070901"


--------------070401020102050108070901
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">
Thomas schrieb:
<blockquote cite="mid:fnpudg$pg1$1@build.eclipse.org" type="cite">I
used the File New EMF Project wizard.
<br>
Normal Ecore model works fine.
<br>
<br>
I dont see the CDO in the context menu (as it was on my 3.3
installation) any more.
<br>
</blockquote>
It's in the context menu of the genmodel file, if you have already one.<br>
If it's not, then please check if the following dependencies of the
migrator plugin are satisfied:<br>
<br>
<img src="cid:part1.00070207.08090103@sympedia.de" alt=""><br>
<br>
Regards,<br>
Eike Stepper<br>
----<br>
<a class="moz-txt-link-freetext" href="http://wiki.eclipse.org/CDO">http://wiki.eclipse.org/CDO</a><br>
<a class="moz-txt-link-freetext" href="http://wiki.eclipse.org/Net4j">http://wiki.eclipse.org/Net4j</a><br>
<br>
<br>
</body>
</html>

--------------070401020102050108070901
Content-Type: image/jpeg;
name="moz-screenshot-7.jpg"
Content-Transfer-Encoding: base64
Content-ID: <part1.00070207.08090103@sympedia.de>
Content-Disposition: inline;
filename="moz-screenshot-7.jpg"

/9j/4AAQSkZJRgABAQAAAQABAAD/2wBDABALDA4MChAODQ4SERATGCgaGBYW GDEjJR0oOjM9
PDkzODdASFxOQERXRTc4UG1RV19iZ2hnPk1xeXBkeFxlZ2P/2wBDARESEhgV GC8aGi9jQjhC
Y2NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2Nj Y2NjY2P/wAAR
CAEFAcUDASIAAhEBAxEB/8QAHwAAAQUBAQEBAQEAAAAAAAAAAAECAwQFBgcI CQoL/8QAtRAA
AgEDAwIEAwUFBAQAAAF9AQIDAAQRBRIhMUEGE1FhByJxFDKBkaEII0KxwRVS 0fAkM2JyggkK
FhcYGRolJicoKSo0NTY3ODk6Q0RFRkdISUpTVFVWV1hZWmNkZWZnaGlqc3R1 dnd4eXqDhIWG
h4iJipKTlJWWl5iZmqKjpKWmp6ipqrKztLW2t7i5usLDxMXGx8jJytLT1NXW 19jZ2uHi4+Tl
5ufo6erx8vP09fb3+Pn6/8QAHwEAAwEBAQEBAQEBAQAAAAAAAAECAwQFBgcI CQoL/8QAtREA
AgECBAQDBAcFBAQAAQJ3AAECAxEEBSExBhJBUQdhcRMiMoEIFEKRobHBCSMz UvAVYnLRChYk
NOEl8RcYGRomJygpKjU2Nzg5OkNERUZHSElKU1RVVldYWVpjZGVmZ2hpanN0 dXZ3eHl6goOE
hYaHiImKkpOUlZaXmJmaoqOkpaanqKmqsrO0tba3uLm6wsPExcbHyMnK0tPU 1dbX2Nna4uPk
5ebn6Onq8vP09fb3+Pn6/9oADAMBAAIRAxEAPwDupp0gTdISATgAAkk+wHJp Y5UlQOhypqlq
iSSW6+TC8sgfI2SBCvB5yePb8azoLmS0cCSR4kwco6bsNkE/XqxJH8sCmoyb 8hNxSOgzUE99
aWzhLi6hiYjIV5Apx681HaXMlwHLxCMKcAhw2f8AD8ao5/4q/wD7cP8A2pRC 0ldBK6NeKaOe
MSQyJIh6MhBB/GnZrn5JV07Xr14YwEaxNzIg43urHn24z+eaS11G8b7FMGnu PtDATRfZSiRh
udytt6L05Jz7VXJ2J5joc0ZrnY7rUJINUuhfEC0mkEcXlKVITnB4ycjjqMe9 SS6tJPdWkKtL
bpJbC5doY/Nc54C/dOB3zj8qORhzo3s0Zrm59Q1E6fbqHa3na9W285oceYhB w+xhxnjj2q02
oT2F7dW8rm6WO1N0jMArDHBU4GD0znH50cjDmRsSTRxbfMkRN7BV3EDcT0A9 6dmuXvPtUsGj
XU92ZBNdROYvLUKpbkY78DI5JzU0mp3U73zwyTI1vKY4oY7YyK5XruYD+Lpw Rj3p8gc50WaM
1hfar271i3gWeS0jazE7xhFLBicYyw46jt2qP+17r7D5WV+0/bfsPn7eM/39 vr7dM/lS5GHM
jflmjgjMk0iRoOrOQAPxp2awtWm1HTtNu5UuhIoCGORlXepLAEEAbSMd+v8A Oi51CaXU7q1S
ea2W3RQDDbmUuzDOT8pwB6cZ9aOS4cxu5ozWE19qE1tp8jxTWqyFxcmKLc6E A7cKQSASM9D2
59b+mz+dbsftX2nbIy7jHsZcH7rD1H0Hbik42GpXL2aM03NGaQx2aM03NGaA HZozTc0ZoAdm
jNNzRmgB2aM03NGaAHZozTc0ZoAdmjNNzRmgB2aM03NGaAHZozTc0ZoAdmjN NzRmgB2aM03N
GaAHZozTc0ZoAdmjNNzRmgB2aM03NGaAHZozTc0ZoAdmjNNzRmgB2aM03NGa AHZozTc0ZoAd
mjNNzRmgB2aKbmigCvcQx3MLQzLujbGRkjvntWfNo0awslk3kF/lfJLAj8T1 H+fUaf8A31/3
w3+FH/fX/fDf4Vak1sS0mMijKFndy7sACx46dgPTk1XnsFlvheJcTQzeV5WU 2kFc57g96t/9
9f8AfDf4Uf8AfX/fDf4VMVy6Ib13K1tp8Fv55O6Z7j/XPKdxfrwR0xg4wB0q OHSoYnh3SzSx
wEmGKRgVjPYjjJx0GScVd/76/wC+G/wo/wC+v++G/wAKd2KyMPT9MeZtRFxL dRRS3b5iB2rI
uc56ZwehIIyK05rCKSSKWJmt5Yl2K8OB8v8AdIIII9scVZ/76/74b/Cj/vr/ AL4b/Cm5Ngkk
Uv7JtvIgiBkHkzCfdnLO47sT1zUr2MMl812+WZofIKHBUrnPSrH/AH1/3w3+ FH/fX/fDf4Ur
sLIzjosRa3BuroxW0geKIuCq4OQOmSB0GTwKkm0qGV5tss0Uc5BmijYBZD3J 4yM9DgjNXf8A
vr/vhv8ACj/vr/vhv8KLsLIrpYwx3y3aZVlh8gIMBQuc9Ki/sm28ieImQ+dM Z92cMjnupHTF
Xf8Avr/vhv8ACj/vr/vhv8KLsLIz59GguYp1uJZpZJwqtKxXcFBBCjAwBkZ6 VLcaeks7zRzT
W8kibJGhIG8ds5B5HYjmrf8A31/3w3+FH/fX/fDf4UXYWRWNhGsMMVtJLarD naIWGMHrkEEH
15Gc0+ytI7KN1jZmMkjSO7kZZj1PHH5VN/31/wB8N/hR/wB9f98N/hRdjsh2 aM03/vr/AL4b
/Cj/AL6/74b/AApAOzRmm/8AfX/fDf4Uf99f98N/hQA7NGab/wB9f98N/hR/ 31/3w3+FADs0
Zpv/AH1/3w3+FH/fX/fDf4UAOzRmm/8AfX/fDf4Uf99f98N/hQA7NGab/wB9 f98N/hR/31/3
w3+FADs0Zpv/AH1/3w3+FH/fX/fDf4UAOzRmm/8AfX/fDf4Uf99f98N/hQA7 NGab/wB9f98N
/hR/31/3w3+FADs0Zpv/AH1/3w3+FH/fX/fDf4UAOzRmm/8AfX/fDf4Uf99f 98N/hQA7NGab
/wB9f98N/hR/31/3w3+FADs0Zpv/AH1/3w3+FH/fX/fDf4UAOzRmm/8AfX/f Df4Uf99f98N/
hQA7NGab/wB9f98N/hR/31/3w3+FADs0Zpv/AH1/3w3+FH/fX/fDf4UAOzRm m/8AfX/fDf4U
f99f98N/hQA7NGab/wB9f98N/hR/31/3w3+FADs0Zpv/AH1/3w3+FH/fX/fD f4UAOzRTf++v
++G/wooAtUVHI5XAHUgnJGf89aj81/7y/wDfH/16Vh3LFFV/Nf8AvL/3x/8A Xo81/wC8v/fH
/wBeiwXLFFV/Nf8AvL/3x/8AXo81/wC8v/fH/wBeiwXLFFV/Nf8AvL/3x/8A Xo81/wC8v/fH
/wBeiwXLFFV/Nf8AvL/3x/8AXo81/wC8v/fH/wBeiwXLFFV/Nf8AvL/3x/8A Xo81/wC8v/fH
/wBeiwXLFFV/Nf8AvL/3x/8AXo81/wC8v/fH/wBeiwXLFFV/Nf8AvL/3x/8A Xo81/wC8v/fH
/wBeiwXLFFV/Nf8AvL/3x/8AXo81/wC8v/fH/wBeiwXLFFV/Nf8AvL/3x/8A Xo81/wC8v/fH
/wBeiwXLFFV/Nf8AvL/3x/8AXo81/wC8v/fH/wBeiwXLFFV/Nf8AvL/3x/8A Xo81/wC8v/fH
/wBeiwXLFFV/Nf8AvL/3x/8AXo81/wC8v/fH/wBeiwXLFFV/Nf8AvL/3x/8A Xo81/wC8v/fH
/wBeiwXLFFV/Nf8AvL/3x/8AXo81/wC8v/fH/wBeiwXLFFV/Nf8AvL/3x/8A Xo81/wC8v/fH
/wBeiwXLFFV/Nf8AvL/3x/8AXo81/wC8v/fH/wBeiwXLFFV/Nf8AvL/3x/8A Xo81/wC8v/fH
/wBeiwXLFFV/Nf8AvL/3x/8AXo81/wC8v/fH/wBeiwXLFFV/Nf8AvL/3x/8A Xo81/wC8v/fH
/wBeiwXLFFV/Nf8AvL/3x/8AXo81/wC8v/fH/wBeiwXLFFV/Nf8AvL/3x/8A Xo81/wC8v/fH
/wBeiwXLFFV/Nf8AvL/3x/8AXo81/wC8v/fH/wBeiwXLFFV/Nf8AvL/3x/8A Xo81/wC8v/fH
/wBeiwXLFFV/Nf8AvL/3x/8AXo81/wC8v/fH/wBeiwXLFFV/Nf8AvL/3x/8A Xo81/wC8v/fH
/wBeiwXLFFV/Nf8AvL/3x/8AXo81/wC8v/fH/wBeiwXLFFQLI5IG5f8AvnH9 alRg6Bh0IzSG
OooooAilGWH+6f5iua1ud49Udd1x5Ysy+IpSoVt2Nxweg/H6V1DDJ/Cqz2UE lwbh4w0hjMRJ
J5UnOMdKqLsS1cyG1WS2WG3SI3swgWR3TdhvTGFPX3wKWTWmDO0doTFHIkbl 32sGb/ZwemfW
r40ayVYwkbp5alFKSurbSc4yDkj2NQajokdwA9uoSbzEdiXYKdp9BwTjvirv Fsi0kiIavvCD
yCPMneDh+m0Hnp7VDpmpySC2t0hLgwec8k0+WC7iD/DyfyrTGj2Qm80REPvM n+sbAY9TjOKf
b6ZaWrq8MW1lj8oHcT8uc45PrSvGw7SuZUev7ojO1lKLfYziQBu3TOVA59ia k064uJ9XnE6+
WvkRssYkLKM556Dmr6aTZxqyLEfLYEGMuxTnrhc4H4CnWum21nI0kCMHdQpZ pGY4HQck0c0e
gWkYFoL2e5meJ7jEV3IHdpcpsA+7tz1/D8ak0/V3i0z95G0rxWomLs/LckY6 e3Wt+Czht1kW
JNolcu/JOSepqs2h6eyKnkEKE8vAkYZXOcHB5/GnzLZhyu9yjJrTAu0dsGij kSJ2MmDubHQY
5Az61Lqt2i2b7RcKUkRSVDR9WA4YjBH0ou9F+0XS+XFHFEHR2cSsWbb/ALGN ue2cnitO5tYr
qLyp03JkHGSOQcjpReOjC0tUY8etM0oDWuI2neAFZMsWUemO/wBataVf/wBo xO5RI2Q4ZA5L
KfRgQMfrU40mzGMREYlMow7cOep61LbWUNqZGiVt0hBdncuzY6ckk0rxsOzu O20bal20bai5
RFto21Lto20XAi20bal20baLgRbaNtS7aNtFwIttG2pdtG2i4EW2jbUu2jbR cCLbRtqXbRto
uBFto21Lto20XAi20bal20baLgRbaNtS7aNtFwIttG2pdtG2i4EW2jbUu2jb RcCLbRtqXbRt
ouBFto21Lto20XAi20bal20baLgRbaNtS7aNtFwIttG2pdtG2i4EW2jbUu2j bRcCLbRtqXbS
MCqkhSxAzgdTRcDKubtgsSB3SSSVxmNVOVQnP3jgcDrU2kzSXWmwzSnLsDk4 x3NN08Q39s/n
Wh2rK+POjHdieAfToff6VSt2nXUHjguFitUuCr4iVVJJ4ReMk+p/w5rcmMG3 e5tqPmH1qWIY
iQf7IpAvIp68KB7VLKFooopDEopap6o9yli7WgYyZXOwAsFyNxUHgkDOB+h6 UAW6KyYtVjii
gija61GSYOUKxqr/ACkZDA7QpGe4HTHXq2fxNp8DW6szZmRZOWRSik4GQzAn vwoJ4+lAGxRW
bPqimC7dIrkQQI+65QJjK9QoY5JBB6jGRVa11SZtTuvtCXC20ckcEYIj25YK Qxwd2SSPbBHG
c0LUDborPvdSaLSr67t4WdrYOFBxhivU9RwDnPfg4qm+ty293I09rceStokz xqqExfM+5ic+
gHAJPoOtAG5RWY+v2Saqun7sykhSd6AAkZAwW3HqOQCOevWmXl+8GpTRvLIs KxwECNVJ3NIy
9x0PAPt05oA1qKxrvXXW0lmtLKaURzrDvJj2sd4VsDeCPTnHJHar91fC1ihZ oJXlmYIkKbd5
bBOOTjgA98cUAWqKxG1Se61Swgt47mKJ/Mab5Y8goQCpyTwM8465GD1q3e6t HZ3Dw/ZrmZo4
hM5iUEKhJGeSP7vQc+meaANCisu31P8A0+eKVmdHuUih2gfLmIPz7dfzqQ6x ESqxW9xM5eRN
iKuQEbazckDGce5z0oA0KKpWuq2d0lvtnSOW4jEkcLuBIQRn7ufr+VU11+GO 2jYQ3lwotluH
k2JlUOfmbkDPB4A+goA2aKqQaglxezW0UMjCHAeXK7QSAQMZ3dD6YqC51u3t Wu/NilEdqVDy
HaFLMFIUEnvuHJ4HcigDSorKg163uYo3toZp3csDHEUYqFxkkhtuOR0JPP1p 8euW0lq9wqTb
EtRdEFRnYd3HXr8poA0qKy21eOGWRQlzO7TrEsaqnDGPeAORxjuT19qYviTT zdz25cgwhyzb
lPKfeG0Hd2PVcHHHagDXorMsb+e61aeJ4ZoI1t43EUoXIJZucgnsB3qtYatO Y55rqG5Z5Lpo
ILcCP+EnhcH0UkljjjigDcorOTWI5JbeJLa4MsxcFMKDGUIDbuccZ7Zz2zxV bUtVuoJ9Rt4o
HVYLIzJP8pAbDc8npwB06g9sUDSubVFZP9vW8VtNJdRzQGFEciUKu8McKRzg ZI74x3xVi11e
1udNkv1bbDFu8z5lfbt5PKkg8ehNAlqXqKzG1uKKGR7i0uoGTYfLZVLMHbaC NpIPPbOfamz6
/bWtu8lzFLBIsoiMUpRW3EZHzFtuMc53e3XigDVorNttagu3RbeGaQNCJiyl NqjLDBO7GcqR
xkfhzVQeJBcfZjY2skwe58iQB42x8hbgh9pPTueh74oA3aKy11ZFAjiiuruZ pJQEUIGwjYY8
kDAOAOcnI96SXxBbxrvS3uZkEAuHZEGEQkjJyQeNp460AatFVry9S0jiPlyT PMwSOOPG5zgn
jJA6AnkjpWa2qT3WqWEFvHcxRP5jTfLHkFCAVOSeBnnHXIwetHkBt0Vi6lqt 1BPqNvFA6rBZ
GZJ/lIDYbnk9OAOnUHtipP7YR4WEiXVvIhhJyiZdXbaCAc8E5znBHoDQDNai qllfrevN5cMi
xxuU8xiuGIOCAASR07gVDFrMUtwIhb3CoZXgEzKNm9c8dc9jzjHvnigDRorH 0/WQdKWW68x5
YrJbqVgo+YHPT3+U1NPrUMMhX7PcPGrpG8qqNqs+MA5Of4gcgY9807a2A0qK oXOp2nlSeVdh
milRJBAyMyEuFwQc4569+uOabDrMUt0sIt7hVaZ4FmZV2F1zkdc/wnnGPx4p AaNFLRQAlFLR
QAlFLRQAlQfYrXzPM+zQ+Zu3bvLGc+ufWrFFACUUtFABRRRQAVFcRNNCUSaS BuCJI8bh+YI/
MVLRQBiSaNIt9bNBc3CALM0tyCm8uxTqCMcgHoOMdqsro8cTxPaXNxamOJYj 5ZU71HI3blPq
eRg8mtKigDObSEKXUQubhbe5Vw0A27VLfeIO3IOST1xk9KZd2Hl2l4lvFJPJ dkAjcoCHaFDZ
OOBgHjJ9K1KKAKi2EX9lmwYsY2iMbHPJyME/U81CdIieOZJZ5pGmt/szu20H b83PAAz8x7el
aNFALQoppoiu2nguriIOVMkS7SkhAxk5UkcADgjpRdaXBdTvLI0gZxGDtIx8 j7x29TzV6igD
Ll0SKaS4kluZ2km2gPhAUCtuXGF5wcfez/OrN1Yi6ihVp5UlhYOkybd4bBGe RjkE9sc1booA
pW+mQwSwyh5GkiDjcxGXLkFieOuR2wKq3elyXmrTu8s0NtJbJE3lsv7z5n3K cgkcEcjB561r
0UAZ0ukQu0jRyywyNKsyum3KMFCcAgjGB3B61UutMazhjNmL+adWkbfFJECd 53MG34GCcdBk
YrcooAqaXatZaXa2rkF4olRiDxkDmq8eiW0dtJAHl2vai1JJGdg3c9OvzGtO ih6gtCimmouo
JeNNLI0aFI0YJhAcZwQoY9O5Iom0uCZboM8gNy6yFlbBRlChSvHbaDzmr1FA Gc+ls/lu2oXZ
mj3ASjywxU4ypwuMcDtn3qlbaD5ulW8NxNPbSfZBbzrEyncuOhJB6ZPIPet6 igCgNKgFwJt8
m4TLNjIxuEez06Y/WmjSIx56C5uPs0+8vb5XZlvvEHbuHJJ69a0aKAKNlpot Lh52uri4leNY
y0xXopJHQD1NNfSYTCESaaN1nadJVI3IzEk4yCMfMRgg8VoUUAUrfTIYJYZQ 8jSRBxuYjLly
CxPHXI7YFNu9Liu5ppGmmTzoDBIqbcMvOOoJBG49P1q/RQBQudJt7lpGd5Qz xpGCrAFdjFlY
cdQT9OOlSizD2UlrdTy3SSgqzSbQSCMY+UAVaooAxb7R5GsZFSe4ubh3hHmS MoZUWQHjAA45
Pqffipzo0Zjybq4Nx5om+05XzAwG3pt2428Yxj8a06KAM99JilWcTzzTNPAI HdtoJUFjngAZ
+Y9qYNFTG43ly03nCbzjs3bgu3pt24xx0rTooAzW0aIFXhubiCVXkYSRlScO 25l5UjGcds8d
aU6Pa+VNGpkVJbYWxAboo3c89/mPJrRooC5Uu7FLmKJfNkieFg0csZG5Tgju CDwSOR3ptvpk
MEsMoeRpIg43MRly5BYnjrkdsCrtFAFC70uK7mmkaaZPOgMEiptwy846gkEb j0/WifSoJ5Gd
3kBZYl4I6RvuHb161fooAp22nrBezXbTSSyygLlwg2qCSANqjPXvmqen6S6S tLdSzYW5lljh
JUoCzNhuBnOD0zj2zWxRQBkSeH4GtlgS5uYkFv8AZn2FcyJzgHKn1PTHWq1/ ps8t6sVtHdrC
8sUkrGSMQnYQc4+/nCgY6Z5966CijzAgvLVLyDyZCwXer5XrlWDD9RUC6XAv l4eT93cPcDkf
ebdkdOnzH9KvUUARW8PkW8cPmSSbFC75Gyze5Pc1LRRQAUUUUAFFFFABRRRQ AUUUUAFFFFAB
VWdPMvIY2ZwvlucK5XJBX0PuatVXf/kIQ/8AXKT+aUAZl/e21hdeVc+dFHt3 ea9zIAQOuMZz
2GPXjjK7tP7HF/en/wC/7/41k+I44LjZDd2rSQou8StI6xqTkc7SMnHHJ7+/ K295LCJnEgbM
5HlEcElQ2F75J/n0p1GoQ5mKN3KxdeLN2YIldtqK7lrtwQC2OACT0DHnAyAB 3Ki20527osdM
4vZTj7ue3u/5L0ydtWfULgXcUcIjimudkY83cyx/605K7geduOi59WxgJDqV 7Nc20A+zgkzC
VwjEN5bKPlGeM5PUnB9ccyndXKasW1tpzt3RY6ZxeynH3c9vd/yXpk7Rbac7 d0WOmcXspx93
Pb3f8l6ZO2nZavcPPam6ktBb3Nu9x8mQYlG3AJJwepycDp0FO/tO+l1mWC3t Q9rA6pIwCk8q
G3ZLgjr02nOOvoxFpbac7d0WOmcXspx93Pb3f8l6ZO0W2nO3dFjpnF7Kcfdz 293/ACXpk7c6
5uLm80NLuZ4fKmlgaONEO5P3q8M2eT+A5pYtQumnjtbRbO382W5yzRnA2OBn AIyTk559/YgW
NBbac7d0WOmcXspx93Pb3f8AJemTtFtpzt3RY6ZxeynH3c9vd/yXpk7atvql 3K1lLKscNtPG
pyImfzHOflDAjb0GCRg560aLqt5eRfab2FILWVQ0TnaoBJwFzvbJ5HOF57c0 AWltpzt3RY6Z
xeynH3c9vd/yXpk7Rbac7d0WOmcXspx93Pb3f8l6ZO2v/aV0LW+v/wBz9ntv NAg2HzCUyMls
4GcZxt6Ec1FPqeoWscqO1pNMBCyOiMqgO+3BG4+5Bzz6cUAXVtpzt3RY6Zxe ynH3c9vd/wAl
6ZO0W2nO3dFjpnF7Kcfdz293/JemTtqRajqUmrvapbpJDbskczqqjJKgluZM qOem1unX0W91
S4Wa5Nm1u8EFl9pBKljITvwAQQMfKP8APQCxaW2nO3dFjpnF7Kcfdz293/Je mTtFtpzt3RY6
ZxeynH3c9vd/yXpk7al9q9xDJKkCwsyxW7ruz1kkKnOD0x0/rVee71OS8t7f 7RAkkN95TskT
BZAYi4yu/wBzxk84PbFMDTW2nO3dFjpnF7Kcfdz293/JemTtFtpzt3RY6Zxe ynH3c9vd/wAl
6ZO2hDfXjzJbWUdpCZJLnLNGSBscAHAIyTnnnvn2LU1y8jtUu7iOB45rOS5S OMEMpQKcFiec
7uuBj3pDtrY0Vtpzt3RY6ZxeynH3c9vd/wAl6ZO0W2nO3dFjpnF7Kcfdz293 /JemTtTSLi/u
IHa/gEfQxsAqhgR6B3/PPOelY0llB/wiNpKLK2IjtQ7SkASRZUEsgxy2eeq8 45piWptLbTnb
uix0zi9lOPu57e7/AJL0ydottOdu6LHTOL2U4+7nt7v+S9Mna3UoYb60ZBbW l40R5S5bhMjO
TwcHBHp16iqJeC40vR7ZpDLDIYvNSbG5k2Nt3DJ6sB6596QGgttOdu6LHTOL 2U4+7nt7v+S9
MnaLbTnbuix0zi9lOPu57e7/AJL0ydtSzuJLXw/M8EbyeVLLHAqIXwokKrwO SAMdOwqrptys
Phu9Fu8iyrJcLEZVKMzZYjAYDJ7/AJ+lA7GqttOdu6LHTOL2U4+7nt7v+S9M naLbTnbuix0z
i9lOPu57e7/kvTJ209LFtY3s8duY4rU28DnBAUyMWGfqRt+vFU9NtopHtFKL uu7OR7w45Zwy
8t7glgPSh6CWpsRQuZkjmjdNyFspdSsARt4zgDqW75wAcddtj7HF/en/AO/7 /wCNVNOke4j0
64lGXa0JZ9vc7O+3jPpkfQ4+XTpvQCv9ji/vT/8Af9/8aPscX96f/v8Av/jV iikBX+xxf3p/
+/7/AONH2OL+9P8A9/3/AMasUUAV/scX96f/AL/v/jR9ji/vT/8Af9/8asUU AV/scX96f/v+
/wDjR9ji/vT/APf9/wDGrFFAFf7HF/en/wC/7/40fY4v70//AH/f/GrFFAFf 7HF/en/7/v8A
40fY4v70/wD3/f8AxqxRQBX+xxf3p/8Av+/+NH2OL+9P/wB/3/xqxRQBXss/ ZyCzNiRwCxJO
A5A5NVrf7RPbxzPdyqZFD7UVMDIzgZUn9as2X+ob/rrJ/wChtVSykC2FsOf9 Sn/oIoAm8qb/
AJ/bj8o//iaPKm/5/bj8o/8A4mjzR71R1i/S1sCWmWAysIlkZgu3J5OT6DJ/ CgC95U3/AD+3
H5R//E0eVN/z+3H5R/8AxNY9nrO6wiS2ZLycTG3DebhWwCdxYA/wgHgHk02x 1S58rylgM07z
TsRJLgIqvjAODnqAB0+lAG15U3/P7cflH/8AE0eVN/z+3H5R/wDxNUtEuWk0 azeVnd2iUszH
JJx3NXfNHvTegB5U3/P7cflH/wDE1HcfaILeSZLuVjGpfa6pg4GcHCg/rUnm j3qG9kDWFyOf
9S//AKCaQGnRRRQAUUUUAFV3/wCQhD/1yk/mlWKrv/yEIf8ArlJ/NKAFuHt3 VreeRP3g2FC+
CQ2QB+OD+RqOy0+CyBMYLSN96R8bj+P4D8qyPElrKXWXT7mG1uWVhIzSlWII wCFCkk8df9ke
ildO31NHMglUoqyFVkx8pHUZ7jj8KqXuxu3oJauw66tWnlZZIILi2kRVaOYn AIbOcEFTwSeg
OVAJOflIYpY/J22VpH5ahV2SH5AduQvydPvemdq9M/LJPfW1vAszy5R22p5a lyx9AFySeD09
DUS6tZMYAsrM1wSI1EbE5BAbIxlcE85xj8Kla7DM+y0e5jvXubq300+YhRo4 EMancVLlsg7z
94dvuj+8dt42fm3EVxNpti00e0CQtuZPu9CUzxl8dOg6bjtfbatZXU6wQSsz sGZcxsAwGASp
IwRyORxT21G2W8FqXbzcgHEbFVJGQC2NoPsTnketAEEdkFdn/sywR5WVpWVu WOVOT8nJB3kZ
/ur0ydsE+lG6ureS4srJokVw8JO5WZzGS3KdQQ/1wOmTiS51iP7M0lnmQrLG m5onCEM4U7Ww
A3U9CaedXtYQBPcb3Z5FURQOSdjYICjJJHf15PSgYq2pNzFcvp1iJ0AUShss g+XIB2Zxy/p0
HTcdrYrBEkaT+y9PR5CDIynknKknOznB3EZ7qvTJ2zR6naSyxRxO8hlQOpSN mUKehLAYXOD1
Ip1pqFteOywOzFRnJjZQw9VJGGHuMigRElq32r7UdPsluHADyh8vj5cjOzJ/ i/75Xpk7W29k
IIvKj02wijZld0jbA3fLzjYMkfNj/dXpn5Zv7StfNlj8xv3IJkfy28tcdcvj bkemaiGtWBgk
mMrose3cJIXRsMcKdpGSCe+MUADWhmuY7mfTrFp0xiUtuZPu9CUzxl8dOg6b jtfDDLHt22Np
H8iodkh4UY4HydBl8D2HTcdqrqlo1wkAaTe2OsLgKSMgMcYU47HB5HrTptRt YLk28shWQR+Y
3yHCrz8xOMAfKepoAr29gkCBY9L0+JW2lhGcDgqf7gzglyPovTJ2ve2acEXG n2Th2V3DPuyw
2jPKckfNj/dXpk7U/tmy8vfmfltoT7NJvJxnhNu4jAPOMcU+TVbOO5EDyMHy oJ8ttqlugZsY
UnjgkHketABHFKro/wBitEYZJKyHI3FS+Pk7nd9dq+p2kUMqeV/oVonlrtXb IfkU7cgfJ0+9
6Z2r6/LIL+2bZiX78rQr8p5dc5HT/ZP5VAutWL26TpJK6SHCBYJCz8ZJChck e4GKACztDZgi
206ytg+C4hbbn7ueiDOMvj6DpuO2vaaUIYrVJ7K1uHtwqxyzMGdANvAPljp8 2On3V/vHFxtS
tVuRbl2EnGT5bbVJGQGbGFOOxIPI9aktLyG9iMkHmFB0LxMmfcbgMj3FHmBV msFuiDd6Xp8p
JDMXO/nCgnlOeNw/4CvTPyyPbvcAi4sLNxIqrIGfdkAqccpyAS+PoOm47c99 UvV0i0uzcWQn
mj3rbmJszEjIRPnzntnB9cCtDVLiS2thIt3a2vOC1ypYE9lGGXn8/pQ9AGw2 00dykwtoEKxL
EFWY7Y1ypO0bB/tfXYvTJw9IpfkzZWi4ffxITtY43MPk6/NJz3wP7x2xS3t0 LCyKxLDd3ZRN
sgLCMlSzZGQTgA8ZFPs9Q36a9zdbUaEukpUcZQkEj64zj3oASG1MUQiXTrGO NmDsiNxuypJx
s5IO7B/2V6Z+Vps5DHMqWttbPcY86SCTDn7uTnZyeX5PoOm47W2epyto9xe3 caq8DS7kT0Qk
Y+vFP067unuJba+8oyrEkwMSlRhsjGCTyCp5756CgCWCCUTQu8EMSxRGMCN9 2M7OBlQcZBHU
dASDn5blYlrqd9P5Z2wf6VA09sNjDaFI+VuechhyMY9DWrazrdWsNwgIWVA4 B9CM0BsTUUUU
AFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAV7L/UN/11k/9Das603NZ25UFh5S jjnkAA1o2X+o
b/rrJ/6G1D2No7FntYGYnJJjBJoAp7X/ALjflUb2/mSxyPExaMkoeeCRj+VX /wCzrL/nzt/+
/S/4Uf2dZf8APnb/APfpf8KAMqfTYZy7SQPudgxZWZSCBgEEHg444pn9j23l ogt5FCMzLtdw
csctyDkg9x0rY/s6y/587f8A79L/AIUf2dZf8+dv/wB+l/woAyV0q2VFRbZg qqiAZbgIcqPw
NTw24gVliiZQzFz1PJOT+pq//Z1l/wA+dv8A9+l/wo/s6y/587f/AL9L/hQB U2v/AHG/Korv
ctncFgVHlMOeOSCBWh/Z1l/z52//AH6X/ClSxtEYMlrArA5BEYBFAFiiiigA ooooAKrv/wAh
CH/rlJ/NKsVXf/kIQ/8AXKT+aUAQ6hpyXatIhKXQQrHJuIweccdO/pVWy064 eNzeMY0d93lD
G77oXk5IwRnp+dQeINYm0WdJZXVreQHZGpVWJUZxzng9yPboRh9yOVJQxjYN tYqfYjqKqUW4
2lsJNXutypd6eZY7f7NL5UtvJ5kbODIM4IIIyCRhj3FR2+lGK4hnefe6LL5m EwHaQqSRzwBt
6c/WtKioSS0RVzmrC2u5L2OOG4lEVrayQxTSWbRbCxULw33yNvJGBwPWrp0N f7Va+/0RzIys
5mtQ8gIAHyPkbeg7HmtiimIyU0mcWAsXu42t42j8nEJDqqMGAY7sHgAZwPWq 8mnXcGpW32SY
KT9pkMrwl1Xe6ttIBHvjntWzcTxW0XmTNtTcq5wTySAOnuRTo5FkUlQwAJHz KV6HHf8AnQBm
R6M0U1oY50WOBArERkSy4zwzBsFcnOCp9qj07Qn01CltLaR42qsqWYWUqGBw 7Zw2QMZwPWtq
igDL/sqTybq0Nwv2K48z5PL/AHil8k4fOMZJP3aa2kTzoxu7tJJT5QDRw7FC o4bpuPJPfP4e
uqeBUE17BBaC6lMixHb/AMsm3ckADbjOckcYoAoNoijWHv0FoxkdXbzrYPIp AA+R8jbwB2PN
PbSGmWcXdyZWuLRbaRggUnG7Len8XT2qyNRtjeLakyLK3C74XVWOM4DEYJx2 B7H0pZ9Qtre5
SCZpFZyFDeU+zJ6DfjaCfTPpR5BfqZi6BIlkYI206JywIkhsTGQQCMjbICG5 6gjvU7aRL5sg
W7/0aZ0kmRo8uzKFHDZ4B2jPB78jtcu9QtbOREuJCrPyMIzYGQMkgfKORycC pLq5hs7aS4uH
CRRjczYJwPwo8w8jPXSJlu42F2n2eO5a4WPyvm3MGyC27plielEekzW8FiLW 6RZ7SIw75Iiy
upxnKhgRyoPWr9xdw21uJ5WIQ4A2qWJJ6AADJPsKQXtsbL7Z5o+z7dxYgjA+ nXPt1o2C5nnQ
x/ar3w+xu0jK7eda73VgAPkfcCo4HHNWdLsJLGOVXlRw7ZVIkKRxjHRVLNj8 Dj2qSHUbWcRl
HYeY5QB42UhhyQQQCDjsat0dLAYkGn3txodvYzMltH5AhnjeIO54wSrB8DI6 cH+lXZre/PmC
3vIVRjwstuX2rtAwMMM85OTnrV6ih6gZZ0mRILeK3utiWqoIA8Ybay5BJ5Gc qcY4x2oi00+U
bGcb7YgyySBijPKX3HBU5UA8/iOeDWpRQBkwaKILKS0S5kMUssjyhyXLo275 csTjqOe+Pc0+
3025i3yPehrlxGnmLDgBEOcbSTyctk+/AGK06KAMiHTZrEGVG+0m3iaK1iVQ m1SQcEk4J4Az
xwOhrQsbf7JYwW+7d5Uapn1wOtT0UAFFFFABRRRQAUUUUAFFFFABRRRQAUUU UAFFFFAFey/1
Df8AXWT/ANDaooYYmhjZo0ZmUElhkkkVLZf6hv8ArrJ/6G1Nt/8Aj3i/3F/l QAjRQKpZoogA
MklRxTYxazAmJYHA6lQDS3v/AB5T/wDXNv5VTeSSBZXJXziiYIGBsz179Mn1 7UAXvIh/54x/
98CjyIf+eMf/AHwKpxyzytFGLlSGDkvGVfpjHOAM8+lIlxcCJJN/mNJCzhNo wGGMYxz3oAu+
RD/zxj/74FHkQ/8APGP/AL4FU1nfDNHcefGgVmbA/EcD059aSe4nCxsJVjSX cwZyFAHGBkg9
uaALvkQ/88Y/++BTJoYlhkZY0VlUkFRgggVLGS0akkEkAkr0/Cm3H/HvL/uN /KgC1RRRQAUU
UUAFV3/5CEP/AFyk/mlWKrv/AMhCH/rlJ/NKAKer/bUV5opMWsce50RtrkjJ yDj6d+1UrPfM
0xtkczeb/rOgHyjq3cZIOOfpWpNqlvBdm3k3BwASWwqgYJJySOAAT+Bxna2L UUUcMYjiRY0H
RVGAPwomuaHKxR0d0ZepC6WztRK07R+d/pJtixfZhsY2AN1252jP61XtYbuS 5sg7Xgt1EzLv
d1JAZfLD9+meG5x171v0lJKysU3c5iwuZoL23Mg1J5RazSXMUm875AU+4Dwe pxt+Xnipn+3N
4hZ3nuIo96eSggldGTaMglW2DndncuR69K17bTra1neeMSNKw2l5ZXkIGc4G 4nA9hVumI5oJ
JNpZV0vnv/NhNwJFkKZEqlimfkxwfu9qZNJMt3BHeSagIme7JWDzNzASLs+7 82MHjH8s11FR
NBE9xHOy5ljVlVsngHGf5CgdzCg+2Jd2H2j7VNMYVVkPmqsZwcszL8jHpkHn 09Kbocl5b75L
17yaYhVlh+zSjDlgCQzMUIGT9zAxzjiukooEYCTXYuoLYreF1vpGkbY+zyiH K/N0I5XjPFPP
nf8ACM2P2nzPO322/wAzO7PmJnOec1uVHPBDcwtFcRJLE3VHUMD+BoWg+ply s8+t2/lfaZFi
cl0lgZI4xtI3K20bjkgdW4JxjrUd5cPeyWnkx3ocvG5tpbdljxuBJZscEDnG 7GQODW2AAMAY
ApaBHO6n5s8l7ttLgm6tmtYsxE/OGYZJHRTuBBOBgU/Xo7m90yWOyVLhYUkS VGZlLPswNvyn
djJ49cc8Vv01I0jBEaKoJLEKMck5J/OjoO+tzIu5JcWJktZs2rJNL5aF1wVZ cLgZYgkEjHSq
7RzjSDD9mnLSzvdBQnRBMH2n0YqeB9a6GigRz7KzpcThHT7VfwtCroVYhdgJ 2nkfdY8joK6C
mNFG7o7IrOmdrEcrnrj0p9HSwBRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRR RQAUUUUAFFFF
ABRRRQAUUUUAV7L/AFDf9dZP/Q2qOJ9kSI6SBlUKRsJ6fQVJZf6hv+usn/ob U77TGem9h6qj
EfmBQAzzV9JP+/bf4UeavpJ/37b/AAp/2hPST/v23+FH2hPST/v23+FADPNX 0k/79t/hR5q+
kn/ftv8ACn/aE9JP+/bf4UfaE9JP+/bf4UAM81fST/v23+FHmr6Sf9+2/wAK f9oT0k/79t/h
R9oT0k/79t/hQAzzV9JP+/bf4UyV98ToiSFmUqBsI6/UVN9oT0k/79t/hR9p jHXeo9WRgPzI
oAmooooAKKKKACq7/wDIQh/65SfzSrFV3/5CEP8A1yk/mlAGN4nhtL54rS4a YSBSyiMooYHr
liCR93PHfHoMWbfUJoxNJIVeNZW+Un5lGN3B7/T9a07q3juraSCUZSRSp9vc e9VbLS4rYFpW
8+UtuLEYUHjBC5ODwOetObcoWjoxRVpXYk+pFYLZraESy3Mnlxq0gVcgEklh nAwp6ZqGPV5p
J7eAWiiRzIJcy8R7CoODj5uvHT8O1+7tIbyMRzqSFYMpVirKfUMCCD9KZDYW 0DRNHFhoVZUJ
Yk/MQWzk8kkA5PNSrpalOxUstVmubm2jks1ijuommicS7jtG3G4Y4Pzep+tN fWmGrNZx2kjx
xuEklCudpIB7KVwMjOWB9vWC00L/AEt3uLeKK38l4VhjuJJchyM/eA2DA4C8 cmtL+zbX7WLl
VkSXjOyZ1DY6blBw34g0xGfc391c6Ut0sYghkkgMLrMS7K0i/eGABkHpk9ad Hqk3mJb2ln5k
kkk4/e3BAHluASSQTg54AHHA6ci4mk2aI6KknlswfyzM5RSG3DaucLz6Yqvc aLDNewOoZIUE
xcJK6OXdlOQQc9jnnvQMSDWjPPbKIEiimjD75ZSpJOcqmFIYjHTIp2j6w+qM xNnJDEUDxuyv
hh7llAz0+6WHvVoabaiWFwjjyABGglYRrjgfJnbn3xUcej2UaMiRyCMkN5fn OUUhgw2rnC8g
dAKBFE+Im33ZSxkaC3WUiTDjcUznJ2bQCQRkMT049Fl1u8iWctpyZghFww+0 f8szn/Z+98p4
6f7VXm0iyZ522SAThhIizOEbcME7QduT64z3qWSwtpfN3xZ86HyH+Y8pzx+p oHoUNLkuLjWN
Rkm/1cbLHEBMxAUqrfcwBk5znrzjoKjXxCPPuS1nKLWASZmCOclM5/hC44OM MT04HbSbT7Vl
kUxcSukj/MeWXG09e20flTV0u0SeSVUcGUkunmt5bE9SUzt5+lAiCTULyKKE SWcIuLiTZFGL
glfuliWbbxwD0BpkerzST28AtFEjmQS5l4j2FQcHHzdeOn4dpxpFmLYW+Jig YMu64kLIRwNr
Fsrx6EVNDYW0DRNHFhoVZUJYk/MQWzk8kkA5PNAFPR9YfVGY/Y5IYigeN2V8 MPcsoGen3Sw9
6jk1yRI7giz3PbOkUqiUffZwAFOOeCGycdQPXFqPR7KNGRI5BGSG8vznKKQw YbVzheQOgFL/
AGTZYx5J7Z+dvmw+8E88ndzk+p9TQBT/ALZukdxNYxqsM6QzMs+7BfbtK/KN w+YZzj8adNdF
/D+pSw+ZE0YuFB80sQVLDIJ5HTIHar72FtJ5u+LPnSLI/wAx5ZcbT/46Pypk +nxvp11aQ/uh
cLJluWwz5yevqc4o6DVrlO8h2zWUdtPc/acptHnOyiMEbi4JwcjIycnJFL4h Vls2mT7Urxox
E0UxVIcc7nUH5h7Ybp0qcaVC04uZmlNyVUO8U0katt6fKGxjrwc9ac+kWbn5 kl2lmcoJ3CMS
dx3KDg5J6EUCRBqIa5vLS186WOGSOSRmikZCSu0DkYP8RP4UttI994etppkn lkkhR2W3k8t2
OB0O5cevUVPPpVncM7SRNud97MkjKc7dvUEY4GMdDQdOR/NWSWYRNtEccUrx CNVGMDaR3z+n
pQBnLPMvhw7Z5DIZvJLkkvGDLtwSeSVBxn2zk9akjuJbOy1hY3eT7GWMJkYu 3+rD4JOSeSet
XTpVk0SRtACqI0YBY9GwWyc8kkA5POacmmWiRxp5RYRuZAXdmJYggkknLcEj nND6jRjsZrNL
2OO5nfyLWO7VpJWY7/myCSfunaOOnpiuiU7lB9Rms86RAlo9tb5jSUgSFizl kH8IJOQMcDsM
nArQpki0UUUhhRRRQAUUUUAFFFFABRRRQAUUUUAFFFFAFey/1Df9dZP/AENq bb/8e8X+4v8A
KnWX+ob/AK6yf+htTbf/AI94v9xf5UASUUUUAMklWNkBB+dtox9Cf6UJKrvI gBzGQDn6Z/rU
d0jsI3Rd5jcNtBwSMEf1qpPGxKvJCT5k4Pl5GcBCMHnHb1oA0qKgtI2ig2su z5iQn90Z4FT0
AFR3H/HvL/uN/KpKjuP+PeX/AHG/lQBaooooAKKKKACq7/8AIQh/65SfzSrF V3/5CEP/AFyk
/mlAGN4jt72GRbzTk8yQjD+YybEIHyt85GDk8Y75PGWD61vqEMzuhOxlcoM9 G9MHpz6VBqmm
m5LXMLN9oSMqinBVuvBz9fWqtlZ3NzFJ5i+RC7kjcuHI2hT8p6d+T+VOo/cv HVij8Vnsa9xc
Q2sJluJo4Yl6vIwUD8TTPt1mFiY3UG2b/VHzBiToPl9eo6etVbvT5BDafZPL d7WbzFSU7VfI
YYJUcfeznHaorXSpY7u3uJDEConZ1TOFaRlPy8dsHnjPpzUq9tSmX4r60nma GG6gklUkMiSA
sCOuR7ZpWu7ZLpbVriFbhxlYi4DsPUDr2Nc3pple/ghs3sJnsrOSJZIXLrkl Qu/A+XOD8vPQ
81fOkT/2vJcsqyxyyJIT9qkj8tgoH3ACrdMjOKYi7datbQpJ5MsU8sUiRyRJ INybnC8jnHX9
KkOo20UZe6ubWEBmGTMMYBx1OOeRkdicVnx6bejSk09ltgkLxeXKsjZcK4JL Lt4JA9TyarPa
XNrq1oI47eaYm7lUSOVUBnU9dpwcH09aBm417aLNFC11CJZRmNDINzj1A70s F3bXMkkcFxDK
8RxIqOGKH0IHToay7bSru0ltFgaNESNY55RIcyAA/KI9uByeCCD9elM0rSrz TYwiJC0karGs
z3Urhl3DPyEYQ4HY9fagRrG/sxNJCbuASxLvkQyDci+pHYe9MOqaeOt/aj5/ L/1y/e/u9evt
WO2g3H+mxhY3EwmMcrXUvymQHrFgr3xkfXFWbnRmkF4I1gUTWC2qDGMEbvbp yPyoGWrTVI7z
VLu0hMLLbYV2EoLFuM/KB0GcZz1BGKlOo20UZe6ubWEBmGTMMYBx1OOeRkdi cVBBaXds93JE
0JeeWNl3k42hUVs+/Bx+FQ22kSR30U8vlMsb3LepHmOCMcemQfrQIvrf2bNK q3cBaFd0gEgy
g9TzwKVL60kSV0uoGSHPmssgITHXd6fjWDeaTLZ6EuTEPsumzwybc8kqvTjp 8pqf+ybq5gaR
ltYXEcKxRoSUYRtvG75RjPTABx70Aav9pWP2YXP2228gkgS+au0kdRnOOx/K obXW9OuraW5S
7hWGFyju0igDnAOc9D29arLplxLcx3M6wJJ9qE7xoxZQBGUGCQMnoeg/TmGf R7uSAoDEfKvH
uI8TvGZAxbILKMoRu6jOce9Af1+Zrre2jSRxrdQl5VDRqJBlwckEDuOD+VQC 8uZZryOC2jY2
7qilpiu8lQxz8pwAG9/pUWm6a9rdmdo441NusQRZWlIIdmPzMASDuFQSJetL qkVkmyWSdGDy
bkUp5aAlX2kZ4I74oAv2l5Ld2BmSBVnDMnls/wAu5WKn5sdMjrj8Kjt9SJtb uW7iWE2jMJNj
71OFDZBwM8H0HNNSG9js44Es7IRrGyNAZmZT0Cjdt6Y3ZyvpUEWmXIsJrXFv DFcuweGNiUhj
KbcR8DnOD0A5NHcEWtPv5bmSSG5txBMqJIFWTeCjZxzgc5BBH6mlhvLj+0fs lxbRpujaSN45
d/AIHzAqMHkeveq1vFeW9yLm5ijknmEdvthZiqqu4lySOOp4+gzzRFZXiXc9 1HBZ2shjcBI5
GZZnOMNJ8q9Me5+Y8+r6gSR6qz3yxGAC3eZoEm38mRQSQVxwOGGc9R0ouNVa G9aMQBreKSOK
WXfgqz4xhccjlcnI696jh025W7jEhi+zQzvcqVY7izA5UjGAAWY5z6cVGdNv pXInNvsnkimu
CjNkOm3IUEcg7V5JGOetJdA7mnaXP2hZAybJInMbrnIB68HvkEH8asVR01GL 3dwyMgnm3KrK
VOAoXJB9dufpir1ABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQBXsv9Q3 /XWT/wBDakSO
aNFTbGwUYB3kZH0xS2X+ob/rrJ/6G1CzyuodYk2tyNz4OPyoAMT/APPOP/v4 f/iaMT/884/+
/h/+JpfMm/55x/8Afw//ABNHmTf884/+/h/+JoATE/8Azzj/AO/h/wDiaQpK xBMURwcjLnj/
AMdp3mTf884/+/h/+Jo8yb/nnH/38P8A8TQAmJ/+ecf/AH8P/wATRif/AJ5x /wDfw/8AxNL5
k3/POP8A7+H/AOJo8yb/AJ5x/wDfw/8AxNACYn/55x/9/D/8TSPHNIjJtjUM ME7ycD6Yp3mT
f884/wDv4f8A4mkaeVFLtEm1eTtfJx+VAFiiiigAooooAKrv/wAhCH/rlJ/N KsVXf/kIQ/8A
XKT+aUAWKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKK ACiiigAooooA
KKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAr2X+ob/rrJ/6 G1Nt/wDj3i/3
F/lTrL/UN/11k/8AQ2ptv/x7xf7i/wAqAJKguZJE8pYioZ325YZA4J9R6VPU NxE0vllHCMjb
gSuR0I9R60AMS62B1uMB0bb8gJ3ZGRgdfwp4uoShbfwFLHg8Adf/ANVMNq2A wk/fB9+4rkZx
jGM9Me9J9jzsLPlgxZzj72TnHsMgflQBI91CmNz9cYwCc55HT6U+KRJUDocq fbFQR2YjCfPn
ZJv6dsYA/KpoIvKVhnOXZunqc0ASVHcf8e8v+438qkqO4/495f8Acb+VAFqi iigAooooAKrv
/wAhCH/rlJ/NKsVXf/kIQ/8AXKT+aUAWKKKKACiiigAooooAKKKKACiiigAo oooAKKKKACii
igAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKK ACiiigAooooA
r2X+ob/rrJ/6G1KtvtG1JZFUdBwcfmKSy/1Df9dZP/Q2psZkkjV2mcFgGwoX Az9RQBJ5Df8A
PeT8l/wo8hv+e8n5L/hTdr/895PyX/Cja/8Az3k/Jf8ACgB3kN/z3k/Jf8KP Ib/nvJ+S/wCF
N2v/AM95PyX/AAo2v/z3k/Jf8KAHeQ3/AD3k/Jf8KPIb/nvJ+S/4U3a//PeT 8l/wo2v/AM95
PyX/AAoAd5Df895PyX/Cka33Da8sjKeo4GfyFJtf/nvJ+S/4U2QyRxs6zOSo LYYLg4+goAtU
UUUAFFFFABVd/wDkIQ/9cpP5pViq7/8AIQh/65SfzSgCxRRRQAUUUUAFFFFA BRRRQAUUUUAF
FFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUU UUAFFFFABRRR
QAUUUUAFFFFAFey/1Df9dZP/AENqq3DFdMjILDiMEqTnGR6c1asv9Q3/AF1k /wDQ2qOJFltI
lYbl2r+Yx/UUAV45ZIlwqO6yS7YxKxBAxnnPPUGpVumZx+6AiZygbdzkZ7Y6 cHvU7xhypZcl
TuHsf8mmC1jWUyBDuyT1OAfXHTNAFdL8+UJJYdiNGXXDZPHtQt7Iyr/o+HZw oDFlHQnqVHp6
VJa2SQwqrrubZtbJJHvgHpUiWsabcBztOV3OxwcY7n3oArQ3EpCmdRkzMgKu eMZ9hnpQl+8k
bOtu2MAqSGxgnv8AL+PGasi1jDbgpzu39TgHnnH4mkWzjVSqiRVPZZGAH054 /CgCSJ/MjV8q
cjPytkfgabcf8e8v+438qT7JFjHlnoB1PY5H60kqLFazADaCGP4n/wCvQBco oooAKKKKACq7
/wDIQh/65SfzSrFV3/5CEP8A1yk/mlAFiiiigAooooAKKKKACiiigAooooAK KKKACiiigAoo
ooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiii gAooooAKKKKA
K9l/qG/66yf+htTzbwsSTDGSepKimWX+ob/rrJ/6G1WKAIvs0H/PCP8A74FH 2aD/AJ4R/wDf
AqWigCL7NB/zwj/74FH2aD/nhH/3wKlooAi+zQf88I/++BR9mg/54R/98Cpa KAIvs0H/ADwj
/wC+BQLeFSCIYwR0IUVLRQAUUUUAFFFFABVd/wDkIQ/9cpP5pRRQBYooooAK KKKACiiigAoo
ooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiii gAooooAKKKKA
CiiigAooooAKKKKACiiigCvZf6hv+usn/obVYoooAKKKKACiiigAooooAKKK KACiiigAoooo
A//Z
--------------070401020102050108070901--

--------------020408060102070908060401--


Re: [CDO] is it what I want ? [message #614336 is a reply to message #110177] Wed, 30 January 2008 14:11 Go to previous message
Thomas is currently offline ThomasFriend
Messages: 151
Registered: July 2009
Senior Member
Eike Stepper schrieb:
> Ok, once more ;-)
>
> 1) New Wizard "Empty EMF project" (this is the plugin project that I meant)
> 2) Create/copy an .ecore file to the model folder
> 3) Use the New Wizard "EMF Model" on the .ecore file and choose the
> importer "Ecore model (CDO native)"
> 4) Adjust other genmodel settings (optional)
> 5) Generate the genmodel
> 6) Use the generated model plugin with CDO
> 7) Use the generated edit plugin with the CDO UI (optional)
>
> Does that work?
>
Yes :)

But it should work with the new EMF Project Wizard too, right (extra):) ?
Re: [CDO] is it what I want ? [message #614343 is a reply to message #110253] Wed, 30 January 2008 14:35 Go to previous message
Eike Stepper is currently offline Eike StepperFriend
Messages: 6579
Registered: July 2009
Senior Member
Thomas schrieb:
> Eike Stepper schrieb:
>> Ok, once more ;-)
>>
>> 1) New Wizard "Empty EMF project" (this is the plugin project that I
>> meant)
>> 2) Create/copy an .ecore file to the model folder
>> 3) Use the New Wizard "EMF Model" on the .ecore file and choose the
>> importer "Ecore model (CDO native)"
>> 4) Adjust other genmodel settings (optional)
>> 5) Generate the genmodel
>> 6) Use the generated model plugin with CDO
>> 7) Use the generated edit plugin with the CDO UI (optional)
>>
>> Does that work?
>>
> Yes :)
>
> But it should work with the new EMF Project Wizard too, right (extra):) ?
I never used that in my life ;-)
I'll try it and come back...

Regards,
Eike Stepper
----
http://wiki.eclipse.org/CDO
http://wiki.eclipse.org/Net4j


Re: [CDO] is it what I want ? [message #614344 is a reply to message #109206] Wed, 30 January 2008 14:39 Go to previous message
Simon Mc Duff is currently offline Simon Mc DuffFriend
Messages: 596
Registered: July 2009
Senior Member
I'm a litle busy for now but I will e-mail you the source code this
week-end.

You will see it is very simple.

See you!

"Thomas" <tom@eiswind.de> wrote in message
news:fnnlip$n43$1@build.eclipse.org...
> Hi Simon,
>
> Im just getting started, but I will love to have a look at it.
>
> Can I get access anywhere ?
>
> Thomas
>
> Simon McDuff schrieb:
>> It is not a closed source !! :-)
>>
>> You will not be able to query ... since your Store need to provide how
>> you will handle the ocl expression (or something else). We did it only
>> for our OODB database
>>
>> This is the only feature we've been implemented yet :
>>
>> refresh (You can refresh your resource, an object or a list of objects)
>> begin
>> commit
>> getReference
>> rollback
>>
>> XATransaction isn't supported yet :-(
>>
>> Let me know if this still interest you.
>>
>> If this is the case, I will maybe work on an implemtation to query other
>> Store...So the query mechanism will work for you as well.
>>
>> Simon
>
Re: [CDO] is it what I want ? [message #621942 is a reply to message #110490] Fri, 18 December 2009 10:52 Go to previous message
Joel Rosi-Schwartz is currently offline Joel Rosi-SchwartzFriend
Messages: 624
Registered: July 2009
Location: London. England
Senior Member
Hi Simon,

Did the OCL query the you developed for your OODB every get implemented for the SQL DBs? I would be very interested in that functionality.

Thanks,
Joel


Simon Mc Duff wrote on Wed, 30 January 2008 14:39
> I'm a litle busy for now but I will e-mail you the source code this
> week-end.
>
> You will see it is very simple.
>
> See you!
>
> "Thomas" <tom@eiswind.de> wrote in message
> news:fnnlip$n43$1@build.eclipse.org...
> > Hi Simon,
> >
> > Im just getting started, but I will love to have a look at it.
> >
> > Can I get access anywhere ?
> >
> > Thomas
> >
> > Simon McDuff schrieb:
> >> It is not a closed source !! :)
> >>
> >> You will not be able to query ... since your Store need to provide how
> >> you will handle the ocl expression (or something else). We did it only
> >> for our OODB database
> >>
> >> This is the only feature we've been implemented yet :
> >>
> >> refresh (You can refresh your resource, an object or a list of objects)
> >> begin
> >> commit
> >> getReference
> >> rollback
> >>
> >> XATransaction isn't supported yet :(
> >>
> >> Let me know if this still interest you.
> >>
> >> If this is the case, I will maybe work on an implemtation to query other
> >> Store...So the query mechanism will work for you as well.
> >>
> >> Simon
> >
Re: [CDO] is it what I want ? [message #621943 is a reply to message #621942] Fri, 18 December 2009 15:57 Go to previous message
Eike Stepper is currently offline Eike StepperFriend
Messages: 6579
Registered: July 2009
Senior Member
Hi Joel,

I don't think that Simon monitors the EMFT newsgroup ;-)

And I know that OCL has not been implemented as a CDOQuery language for
DBStore, at least not by the CDO team. I cc'ed Bernd because he might
give some infos about his plans to collaborate on an integration with
EMF Query.

Cheers
/Eike

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




Joel Rosi-Schwartz schrieb:
> Hi Simon,
>
> Did the OCL query the you developed for your OODB every get
> implemented for the SQL DBs? I would be very interested in that
> functionality.
>
> Thanks,
> Joel
>
>
> Simon Mc Duff wrote on Wed, 30 January 2008 14:39
>> I'm a litle busy for now but I will e-mail you the source code this
>> week-end.
>>
>> You will see it is very simple.
>>
>> See you!
>>
>> "Thomas" <tom@eiswind.de> wrote in message
>> news:fnnlip$n43$1@build.eclipse.org...
>> > Hi Simon,
>> >
>> > Im just getting started, but I will love to have a look at it.
>> >
>> > Can I get access anywhere ?
>> >
>> > Thomas
>> >
>> > Simon McDuff schrieb:
>> >> It is not a closed source !! :)
>> >>
>> >> You will not be able to query ... since your Store need to provide
>> how >> you will handle the ocl expression (or something else). We did
>> it only >> for our OODB database
>> >>
>> >> This is the only feature we've been implemented yet :
>> >>
>> >> refresh (You can refresh your resource, an object or a list of
>> objects)
>> >> begin
>> >> commit
>> >> getReference
>> >> rollback
>> >>
>> >> XATransaction isn't supported yet :(
>> >>
>> >> Let me know if this still interest you.
>> >>
>> >> If this is the case, I will maybe work on an implemtation to query
>> other >> Store...So the query mechanism will work for you as well.
>> >>
>> >> Simon
>> >
>
>


Re: [CDO] is it what I want ? [message #621944 is a reply to message #621943] Fri, 18 December 2009 16:37 Go to previous message
Joel Rosi-Schwartz is currently offline Joel Rosi-SchwartzFriend
Messages: 624
Registered: July 2009
Location: London. England
Senior Member
I was concerned about that, especially as the thread was a bit stale.

Eike Stepper wrote on Fri, 18 December 2009 11:28
> Hi Joel,
>
> I don't think that Simon monitors the EMFT newsgroup ;)


Great. Thanks for picking up the ball ;)

Quote:
> And I know that OCL has not been implemented as a CDOQuery language for
> DBStore, at least not by the CDO team. I cc'ed Bernd because he might
> give some infos about his plans to collaborate on an integration with
> EMF Query.
Previous Topic:EEF CanĀ“t display the property view
Next Topic:EcoreTools cannot be installed on Eclipse 3.6 M4
Goto Forum:
  


Current Time: Mon Jun 14 22:44:37 GMT 2021

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

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

Back to the top