Re: [cmis] queries, joins and objects

[David Nuescheler <david@day.com>]

Hi guys,

introducing JOINs in JCR 2.0 lead to the exact same issue. We needed to extend
the QueryResult. As mentioned on an earlier call I think that the JCR 2.0 query
is specified very precisely (thanks again to Oracle) to address the
same issues and I
think it is really necessary to bring the CMIS query section to the
same level of detail.

Since JCR 2.0 is already implemented in Jackrabbit we are fairly sure that the
specification is complete and could very much be used as a guideline on
what the query section of the specification in CMIS should look like.

Thoughts?

regards,
david


On Wed, Jul 1, 2009 at 1:56 PM, David Caruana<david.caruana@alfresco.com> wrote:
> Hi Florent,
>
> That's a good point. The select list is really driving the kind of result
> set, not join vs no-join. It's just that the select list is limited in
> no-join scenario. This reminds me of Hibernate where the query language and
> result set allow for both row-based and object-based queries (which itself
> is driven from select list).
>
> I don't have an answer to how to represent the result set, but I agree,
> where possible it would be good to decorate result set row with object info,
> or treat result row as object. But we do have to cater for the case where a
> row may map to multiple objects. Do we ignore all but one, or attempt to
> provide object info for all of them. In the case of getChildren there's only
> ever one object per row.
>
> Dave
>
>
> On 1 Jul 2009, at 10:56, Florent Guillaume wrote:
>
>> Hi,
>>
>> We've discussed queries and returning objects quite a few times, and it's
>> been mentioned several times that when you do a query with a JOIN, then you
>> can't get objects returned.
>>
>> I'd like to stress that the above is true in general, but not always, far
>> from it. Here's a common example of a JOIN that will return objects:
>>
>>  SELECT doc.* FROM Document doc JOIN Relation rel ON ( rel.TargetId =
>> doc.ObjectId ) WHERE rel.foo = 123
>>
>> To me this shows that objects returned from queries, even with JOINs,
>> should be treated mostly in the same way as objects returned from
>> getChildren (which itself will be implemented as an internal query for many
>> vendors).
>>
>> Florent
>>
>> --
>> Florent Guillaume, Head of R&D, Nuxeo
>> Open Source, Java EE based, Enterprise Content Management (ECM)
>> http://www.nuxeo.com   http://www.nuxeo.org   +33 1 40 33 79 87
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe from this mail list, you must leave the OASIS TC that
>> generates this mail.  Follow this link to all your TCs in OASIS at:
>> https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php
>
>
> ---------------------------------------------------------------------
> To unsubscribe from this mail list, you must leave the OASIS TC that
> generates this mail.  Follow this link to all your TCs in OASIS at:
> https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php
>



-- 
David Nuescheler
Chief Technology Officer
mailto: david.nuescheler@day.com

web:  http://www.day.com/ http://dev.day.com
twitter: @daysoftware