Home » Modeling » EMF » [CDO] Query on an audit view
|
| Re: [CDO] Query on an audit view [message #500580 is a reply to message #500044] |
Thu, 26 November 2009 20:11   |
 Victor Roldan Betancort
Messages: 524
Registered: July 2009 |
Senior Member |
|
|
Hi Lothar,
please find some comments inlined below:
> Hi,
>
> If I do a SQL query on an audit view today like
> SELECT DISTINCT C.cdo_id FROM C WHERE C.name LIKE "%MG";
>
> I may get more OID's than those which were present in the repository that
> was selected with the timestamp. Currently a query like this does not work
> and won't return anything due to an exception
>
>> org.eclipse.emf.cdo.util.ObjectNotFoundException:
>> Object OID1323 not found (temporary = false)
>
> It would be nice if one could configure the query to ignore the OIDs that
> don't resolve to valid objects in this view. Would such a change be welcome
> in CDO?
I would say that's a bit business-specific. If one doesn't mind querying
backend-specific data structures, I guess one could also choose whether
to get latest revisions or past revisions by adding the corresponding
constraints in the query.
> P.S.
> I can't change the query as it does not know if it will be used against an
> audit or current view.
Why not? You might return back the constructed query, and then just
inject the timestamp value in the place where you have the CDOView
instance (or CDOAudit) (then you would know whether it is a read-only
view or an audit). You can call:
org.eclipse.emf.cdo.common.CDOCommonView.getTimeStamp()
- if its a view, you will always get the latest
- if its an audit, you will get the selected audits timestamp.
In the other hand, have you considered using EMF Query? I guess it might
have major impact in performance, but at least it is not
backend-specific: you only talk in terms of object interfaces, not
hard-coded SQL strings. What if you want to move to a different backend
implementation? (i.e. Object-Oriented DB, which seem to perform much
better).
Cheers,
Víctor.
|
|
|
| Re: [CDO] Query on an audit view [message #500583 is a reply to message #500580] |
Thu, 26 November 2009 20:44 |
Lothar Werzinger
Messages: 153
Registered: July 2009
Location: Bay Area |
Senior Member |
|
|
Víctor Roldán Betancort wrote:
> Hi Lothar,
>
> please find some comments inlined below:
>
>> Hi,
>>
>> If I do a SQL query on an audit view today like
>> SELECT DISTINCT C.cdo_id FROM C WHERE C.name LIKE "%MG";
>>
>> I may get more OID's than those which were present in the repository that
>> was selected with the timestamp. Currently a query like this does not
>> work and won't return anything due to an exception
>>
>>> org.eclipse.emf.cdo.util.ObjectNotFoundException:
>>> Object OID1323 not found (temporary = false)
>>
>> It would be nice if one could configure the query to ignore the OIDs that
>> don't resolve to valid objects in this view. Would such a change be
>> welcome in CDO?
>
> I would say that's a bit business-specific. If one doesn't mind querying
> backend-specific data structures, I guess one could also choose whether
> to get latest revisions or past revisions by adding the corresponding
> constraints in the query.
I am currently evaluating CDO queries and backand specific queries are the
only one available yet. I heard from Eike that some work is underway to
provide a more generic query in the future.
>> P.S.
>> I can't change the query as it does not know if it will be used against
>> an audit or current view.
>
> Why not? You might return back the constructed query, and then just
> inject the timestamp value in the place where you have the CDOView
> instance (or CDOAudit) (then you would know whether it is a read-only
> view or an audit). You can call:
>
> org.eclipse.emf.cdo.common.CDOCommonView.getTimeStamp()
>
> - if its a view, you will always get the latest
> - if its an audit, you will get the selected audits timestamp.
That's a good suggestion, thanks!
> In the other hand, have you considered using EMF Query? I guess it might
> have major impact in performance, but at least it is not
> backend-specific: you only talk in terms of object interfaces, not
> hard-coded SQL strings. What if you want to move to a different backend
> implementation? (i.e. Object-Oriented DB, which seem to perform much
> better).
Yes, I am evaluating server side queries for scalability, but I am aware
that client side EMF Query exists.
> Cheers,
> Víctor.
Thanks!
Lothar
|
|
|
| Re: [CDO] Query on an audit view [message #500586 is a reply to message #500583] |
Thu, 26 November 2009 21:38 |
Victor Roldan Betancort
Messages: 524
Registered: July 2009 |
Senior Member |
|
|
Lothar,
while driving back home I reconsidered my previous conclusions about
your proposal. I think I was plain wrong. Some comments below:
>> I would say that's a bit business-specific. If one doesn't mind querying
>> backend-specific data structures, I guess one could also choose whether
>> to get latest revisions or past revisions by adding the corresponding
>> constraints in the query.
>
> I am currently evaluating CDO queries and backand specific queries are the
> only one available yet. I heard from Eike that some work is underway to
> provide a more generic query in the future.
Yes, that's right. The only way to perform server-side queries currently
is using SQL.
Regarding you question of whether it would be of general interest some
kind of filter for CDOAudits, I reconsidered it, and I would say your
requirement is not business-specific (apologies for my quick answer, I
should have thought it twice). The problem here is that then only way to
query the CDO-Server is the SQL language executed by the database behind
a DBStore instance. I was confused by the fact the SQL would allow you
to use some backend data that is not business related, and that users
shouldn't be using/taking into account (it is, at least, not the most
elegant way...).
If we forget about SQL for a while, I think one would expect using an
IStore-agnostic Query Language (there is bugzilla for that), executed
through an arbitrary CDOView instance. If that CDOView instance is an
CDOAudit, the the query should be clever enough to return objects that
make sense under the context of that audit.
So I think that any query language implemention for CDO should take this
as a requirement. Or make clear that it is not "CDOAudit" aware.
>>> I can't change the query as it does not know if it will be used against
>>> an audit or current view.
>> Why not? You might return back the constructed query, and then just
>> inject the timestamp value in the place where you have the CDOView
>> instance (or CDOAudit) (then you would know whether it is a read-only
>> view or an audit). You can call:
>>
>> org.eclipse.emf.cdo.common.CDOCommonView.getTimeStamp()
>>
>> - if its a view, you will always get the latest
>> - if its an audit, you will get the selected audits timestamp.
>
> That's a good suggestion, thanks!
Despite the fact I hate using SQL for CDO, I agree that is the best (and
currently, only) way to obtain server-side queries, considering that
most of our IStore implementations are for RDBMS.
>> In the other hand, have you considered using EMF Query? I guess it might
>> have major impact in performance, but at least it is not
>> backend-specific: you only talk in terms of object interfaces, not
>> hard-coded SQL strings. What if you want to move to a different backend
>> implementation? (i.e. Object-Oriented DB, which seem to perform much
>> better).
>
> Yes, I am evaluating server side queries for scalability, but I am aware
> that client side EMF Query exists.
Yes, fetching all the object tree and executing the query at the client
seems like a bad idea ...
Cheers,
Víctor.
|
|
|
Goto Forum:
Current Time: Fri Apr 19 02:21:39 GMT 2024
Powered by FUDForum. Page generated in 0.01894 seconds |
] 
Search
Help
Register
Login
Home
