Re: [cmis] queries, joins and objects

[David Caruana <david.caruana@alfresco.com>]

David,

Thanks for the reminder of JCR 2.0 query support which has lead me to  
re-read the query section. The query result provides both row and node  
access, but node access is only supported if the query contains a  
single selector.

CMIS can follow suit providing full atom entries for single selector  
result sets, otherwise just a raw properties result.

I think there's a query call starting about now...

Regards,
Dave


On 1 Jul 2009, at 15:11, David Nuescheler wrote:

> 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