Home » Modeling » EMF » [CDO] Backends and query languages
| | |
| Re: [CDO] Backends and query languages [message #857486 is a reply to message #857478] |
Thu, 26 April 2012 15:22   |
|
Am 26.04.2012 17:16, schrieb Guido Scalise:
> That's what I'm considering right now...
> I found I need to (manually) add a cdo_revised=0 condition for every entity included in the query, in order to get the
> last version of the model. Am I right?
Yes, you're right. If branching is enabled, too, you need to add " AND cdo_branch=?".
Have a look at these methds for historical queries:
org.eclipse.emf.cdo.server.internal.db.mapping.horizontal.HorizontalAuditClassMapping.initSQLStrings()
org.eclipse.emf.cdo.server.internal.db.mapping.horizontal.HorizontalBranchingClassMapping.initSQLStrings()
>
> Also, a second question (that might need to go to a different thread)... Suppose I want to keep the audit views only
> for the last three months.. would it be right to delete any entities having cdo_revised <= (NOW() - 3 months) using
> plain SQL?
That sounds as if it could work. I've never tried it, though.
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] Backends and query languages [message #858805 is a reply to message #857486] |
Fri, 27 April 2012 09:54 |
 Guido Scalise
Messages: 16
Registered: April 2012 |
Junior Member |
|
|
Having the ability to change the DBStore to a different vendor poses an
interesting twist: if your SQL uses any nonstandard calls, your code
turns useless unless you somehow provide a method for the client to either:
a) identify the DBStore SQL flavour/dialect and use that data to "pick"
the correct SQL for a query.
b) create a method for the client to delegate the creation of a query to
a Handler able to create the "correct" SQL depending on the DBStore SQL
flavour. This could be done with a QueryHandler, and would also allow
the client queries to become completely decoupled of any DBStore/model
changes. This QueryHandler could either start from DBMS-agnostic SQL and
turn it into implementation-specific SQL or either have the queries
defined for each implementation.
I know it's possible with the correct queries to have the option "a",
but I really like the option "b", and I think it might be useful for
many CDO users.
What do you think about this?
Regards
/Guido
El 26/04/2012 17:22, Eike Stepper escribió:
> Am 26.04.2012 17:16, schrieb Guido Scalise:
>> That's what I'm considering right now...
>> I found I need to (manually) add a cdo_revised=0 condition for every
>> entity included in the query, in order to get the last version of the
>> model. Am I right?
> Yes, you're right. If branching is enabled, too, you need to add " AND
> cdo_branch=?".
>
> Have a look at these methds for historical queries:
>
> org.eclipse.emf.cdo.server.internal.db.mapping.horizontal.HorizontalAuditClassMapping.initSQLStrings()
>
> org.eclipse.emf.cdo.server.internal.db.mapping.horizontal.HorizontalBranchingClassMapping.initSQLStrings()
>
>
>>
>> Also, a second question (that might need to go to a different
>> thread)... Suppose I want to keep the audit views only for the last
>> three months.. would it be right to delete any entities having
>> cdo_revised <= (NOW() - 3 months) using plain SQL?
> That sounds as if it could work. I've never tried it, though.
>
> Cheers
> /Eike
>
> ----
> http://www.esc-net.de
> http://thegordian.blogspot.com
> http://twitter.com/eikestepper
>
>
|
|
|
| Re: [CDO] Backends and query languages [message #859003 is a reply to message #858805] |
Fri, 27 April 2012 12:02 |
|
Am 27.04.2012 11:54, schrieb Guido Scalise:
> Having the ability to change the DBStore to a different vendor poses an interesting twist: if your SQL uses any
> nonstandard calls, your code turns useless unless you somehow provide a method for the client to either:
>
> a) identify the DBStore SQL flavour/dialect and use that data to "pick" the correct SQL for a query.
The store type is already accessible at the client side via CDOSession.getRepositoryInfo().getStoreType(). If you would
like to access more store-specific infos such as mapping strategy or DB adapter for the DBStore, please submit an
enhancement request.
> b) create a method for the client to delegate the creation of a query to a Handler able to create the "correct" SQL
> depending on the DBStore SQL flavour. This could be done with a QueryHandler, and would also allow the client queries
> to become completely decoupled of any DBStore/model changes. This QueryHandler could either start from DBMS-agnostic
> SQL and turn it into implementation-specific SQL or either have the queries defined for each implementation.
That's already possible. You can easily implement your own IQueryHandler and register it with the repository. Have a
look at the existing query handlers for examples.
>
> I know it's possible with the correct queries to have the option "a", but I really like the option "b", and I think it
> might be useful for many CDO users.
That's why it's possible today :P
Cheers
/Eike
----
http://www.esc-net.de
http://thegordian.blogspot.com
http://twitter.com/eikestepper
>
> What do you think about this?
>
> Regards
> /Guido
>
>
> El 26/04/2012 17:22, Eike Stepper escribió:
>> Am 26.04.2012 17:16, schrieb Guido Scalise:
>>> That's what I'm considering right now...
>>> I found I need to (manually) add a cdo_revised=0 condition for every
>>> entity included in the query, in order to get the last version of the
>>> model. Am I right?
>> Yes, you're right. If branching is enabled, too, you need to add " AND
>> cdo_branch=?".
>>
>> Have a look at these methds for historical queries:
>>
>> org.eclipse.emf.cdo.server.internal.db.mapping.horizontal.HorizontalAuditClassMapping.initSQLStrings()
>>
>> org.eclipse.emf.cdo.server.internal.db.mapping.horizontal.HorizontalBranchingClassMapping.initSQLStrings()
>>
>>
>>>
>>> Also, a second question (that might need to go to a different
>>> thread)... Suppose I want to keep the audit views only for the last
>>> three months.. would it be right to delete any entities having
>>> cdo_revised <= (NOW() - 3 months) using plain SQL?
>> That sounds as if it could work. I've never tried it, though.
>>
>> 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] Backends and query languages [message #879571 is a reply to message #857486] |
Thu, 31 May 2012 13:00 |
Guido Scalise
Messages: 16
Registered: April 2012 |
Junior Member |
|
|
Eike Stepper wrote on Thu, 26 April 2012 11:22Am 26.04.2012 17:16, schrieb Guido Scalise:
> That's what I'm considering right now...
> I found I need to (manually) add a cdo_revised=0 condition for every entity included in the query, in order to get the
> last version of the model. Am I right?
Yes, you're right. If branching is enabled, too, you need to add " AND cdo_branch=?".
Would it make sense to add also cdo_version >= 0 so removed entities don't appear in the results?
[Updated on: Thu, 31 May 2012 13:01] Report message to a moderator |
|
| | | |
Goto Forum:
Current Time: Fri Apr 26 21:04:56 GMT 2024
Powered by FUDForum. Page generated in 0.05602 seconds |
] 
Search
Help
Register
Login
Home
