OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

cmis message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: [OASIS Issue Tracker] (CMIS-768) Simplify CMIS query


    [ https://tools.oasis-open.org/issues/browse/CMIS-768?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=37005#comment-37005 ] 

Andy Hind commented on CMIS-768:
--------------------------------

Querying for heterogeneous objects.

1) For the "folder defined by query", it would allow both documents, folders and other base types to be found in one step, rather than a query for each base type. Each of the queries would be more complicated as it would have to include a join/from clause for the base type. 

2) If ordering is required, and can be supported by the repository, it would be simpler and more efficient than executing several queries and ordering the results. This may require the properties of many more objects to be obtained in order to merge sort the result sets on the client side.

3) Some queries may have no type constraint. e.g. a full text search over all objects (documents, folders, items, etc)
     SELECT * from "*" where CONTAINS('lion') 

4) As heterogeneous objects cannot be returned by all repositories, support for this feature would need to be defined by some capability.

> Simplify CMIS query
> -------------------
>
>                 Key: CMIS-768
>                 URL: https://tools.oasis-open.org/issues/browse/CMIS-768
>             Project: OASIS Content Management Interoperability Services (CMIS) TC
>          Issue Type: Improvement
>          Components: Domain Model
>    Affects Versions: Proposals for 2.0
>            Reporter: Andy Hind
>
> This follows on from CMIS-758 where some discussion took place related to query and over lap with bulk get.
> There are 3 main issues with CMIS query that I see:
> 1) Now that we have secondary types, joining to all the secondary types you may wish to use is cumbersome
>      You also have to left outer join to any specific sub-types for which you may want properties.
> 2) To batch fetch all properties as part of a query requires that you know before hand what secondary types are applied to build the complex query above
>      While it may be possible to get the ids and use the new batch operations it would be good to get all you want in one shot.
> 3)  To get heterogeneous objects may require several calls for folders, documents, items
>      (I am not sure if we have considered selecting a secondary type and then outer joining to the base types - I would like to make that easy too) 
> An example use case for both would be to generate a dynamic folder/view of documents and folders defined by a query.
> To support this the query would have similar requirements to listing children of a folder. 



--
This message was sent by Atlassian JIRA
(v6.1.1#6155)


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]