Home » Modeling » EMF » [CDO] CDO Query which is not DB specific
| [CDO] CDO Query which is not DB specific [message #989258] |
Wed, 05 December 2012 11:36  |
 Christophe Bouhier
Messages: 937
Registered: July 2009 |
Senior Member |
|
|
Hi,
I think I know the answer, but just to be sure about this. Is there an option to create queries which directly interact with the Store and are not DB vendor specific?
If not, would an OCL query which potentially narrows down a Collection of object, have to fetch all objects from the CDO Server, before applying a restriction?
I am looking for optimizing the roundtrips, and creation of objects, so a way to specify by query, which objects should be created by CDO. At the moment, my code tends to get collections, and apply filters, but this doesn't give the best performance, and also consumes more memory.
Thank You,
Christophe Bouhier
|
|
| |
| Re: [CDO] CDO Query which is not DB specific [message #989417 is a reply to message #989258] |
Thu, 06 December 2012 07:29  |
|
Am 05.12.2012 12:36, schrieb Christophe Bouhier:
> Hi,
> I think I know the answer, but just to be sure about this. Is there an option to create queries which directly
> interact with the Store and are not DB vendor specific?
By "the store" you mean the DBStore?
The problem with the SQLQueryHandler is (IMHO) not so much that the queries are vDB vendor specific but that they must
be aware of the specific O/R mapping, which is in fact very unfortunate.
Currently I know of no DBStore query handler that interprets the query string in terms of the model and not of the
relational schema. It would be nice to have!
> If not, would an OCL query which potentially narrows down a Collection of object, have to fetch all objects from the
> CDO Server, before applying a restriction?
No, the OCLqueryHandler (which is in fact independent of the store type) operates, like all query handlers, purely on
the server side.
But yes, due to its generic nature, it involves lazy EClass extent iterators, i.e. linear effort. Ed Willink commented
on the performance impact just the other day.
> I am looking for optimizing the roundtrips, and creation of objects, so a way to specify by query, which objects
> should be created by CDO. At the moment, my code tends to get collections, and apply filters, but this doesn't give
> the best performance, and also consumes more memory.
You should try the OCLueryHandler. I have customers that are ry happy with its performance.
Cheers
/Eike
----
http://www.esc-net.de
http://thegordian.blogspot.com
http://twitter.com/eikestepper
Cheers
/Eike
----
http://www.esc-net.de
http://thegordian.blogspot.com
http://twitter.com/eikestepper
|
|
| |
| Re: [CDO] CDO Query which is not DB specific [message #989444 is a reply to message #989417] |
Thu, 06 December 2012 09:20 |
Christophe Bouhier
Messages: 937
Registered: July 2009 |
Senior Member |
|
|
Thank you, Eike,
Quote:By "the store" you mean the DBStore?
By Store, I really mean the underlying persistence system, so RDBMS.
I will look into the various Query handlers, I need to understand better how this works.
My experience sofar with queries is limited, What I have tried sofar is a query which worked on a testbed, but failed on the customer test system.
It had something todo with case sensitive column names. When writing the query, I use mysql command line to test it, than I paste the query in the code, but from your reply I get the impression that the SQL statements are agnostic to the DB vendor? I am not sure what "aware of o/r mapping" means in terms of defining the sql query.
I will certainly have a go at the OCL Query Handler!
Thanks
Christophe
|
|
|
| Re: [CDO] CDO Query which is not DB specific [message #989503 is a reply to message #989444] |
Thu, 06 December 2012 14:26 |
|
Am 06.12.2012 10:20, schrieb Christophe Bouhier:
> Thank you, Eike,
> Quote:
>> By "the store" you mean the DBStore?
>
> By Store, I really mean the underlying persistence system, so RDBMS.
But that's not necessarily an RDBMS in general (see MongoDBStore, ObjectivityStore, DB4OStore, LissomeStore, ...).
Mostly for the DBStore, as I said.
> I will look into the various Query handlers, I need to understand better how this works.
> My experience sofar with queries is limited, What I have tried sofar is a query which worked on a testbed, but failed
> on the customer test system.
> It had something todo with case sensitive column names. When writing the query, I use mysql command line to test it,
> than I paste the query in the code, but from your reply I get the impression that the SQL statements are agnostic to
> the DB vendor? I am not sure what "aware of o/r mapping" means in terms of defining the sql query.
AFAIK the part of SQL that is the most dependent on a vendor is DDL. And that's typically not used in (select) queries.
But, as you said, you need to specifiy table and column names and those depend on the used mapping mechansim, the one
that maps EClasses to tables and EStructuralFeatures to columns (EReferences are handled differently).
Cheers
/Eike
----
http://www.esc-net.de
http://thegordian.blogspot.com
http://twitter.com/eikestepper
> I will certainly have a go at the OCL Query Handler! Thanks Christophe
Cheers
/Eike
----
http://www.esc-net.de
http://thegordian.blogspot.com
http://twitter.com/eikestepper
|
|
| |
| Re: [CDO] CDO Query which is not DB specific [message #990337 is a reply to message #989258] |
Tue, 11 December 2012 23:17 |
|
Hi all,
so for what I read, given the following requirements
1) server-side execution (i.e. filtering)
2) available with DBStore
3) model-oriented (no "sql"/RDBMS)
OCL Query Language should be a good choice, is this correct ?
Are there alternatives, like for instance a EMF Query/EMF Query2 language implementation?
Thank you
Vincenzo
|
|
| |
Goto Forum:
Current Time: Wed Apr 24 17:59:36 GMT 2024
Powered by FUDForum. Page generated in 0.02664 seconds |
] 
Search
Help
Register
Login
Home
