[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [cmis] queries, joins and objects
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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]