[OASIS Issue Tracker] (CMIS-771) Clarify the query support for secondary types

[OASIS Issues Tracker <workgroup_mailer@lists.oasis-open.org>]

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

David Choy commented on CMIS-771:
---------------------------------

The phenomenon of "a query returning non-homogeneous objects" occurs only when the SQL query results are mapped back to the CMIS data model. Within the relational framework, a SQL query always produces a homogeneous set of rows, representing a newly created table (even though the table may not be persistent). But when the results of a CMIS SQL query are mapped back to the CMIS data model, we do not treat the result rows as newly created CMIS objects. Instead, we look to map each result row back to an existing CMIS object. This view is natural for a query that filters objects out of a large set of candidates. But for a query that merely
extracts data values or statistics from the metadata database, mapping the result rows 1:1 back to existing CMIS objects may not always be possible, let alone mapping them to objects of the same primary type. From the start, the v1.0 spec did not impose restriction on the joining of (primary) object types and did not impose restriction on query results. We should try our best to preserve this generality. The introduction of secondary object type in v1.1 added a great deal of "power" to the data model, but it also created challenges to some existing repository implementations. Since the rows in a secondary object type table correspond to objects of various primary types, querying on a standalone secondary object type (without joining with another object type) would produce a non-homogeneous set of objects. There are use cases for query to return non-homogeneous objects, such as: to find the objects that a particular policy object is applied to, to find objects linked by certain relationship to a given object, or to find objects that have a certain secondary type property meeting a certain criteria, etc. On the other hand, some repositories may find it difficult or expensive to support query that would return non-homogeneous objects. Our challenge is to find a workable solution while minimize any imposed restriction on query.

As pointed out by Andy, there is a bug in the v1.1 query BNF. In Section 2.1.14.1.1 and Figure 2.5, joining a primary object type with secondary object type(s) is described. Yet in the BNF Grammar (Section 2.1.14.2.1), the <secondary type table name> node only appears in the SELECT list and in the WHERE clause, it does not appear in the FROM clause (probably our oversight). This means that secondary object types cannot be queried because of query syntax limitation even if the object types are set to be "queryable". If a secondary object type (property) is included either in the SELECT list or in the WHERE clause of a query, as permitted by the grammar, it would trigger a semantic error. A proposal to fix this problem was appended 22 January. Below is an alternative proposal which seemed to be less restrictive.

Proposal 2A:
In v1.1 Errata, point out the error in the BNF and its inconsistency with the narrative, and clarify that
(1) Queryable secondary object types are allowed in the FROM clause if they are joined with at least one queryable primary object type, and
(2) A standalone (i.e. not joined) secondary object type is not allowed in the FROM clause even if the object type is queryable.
If fixing broken BNF is not considered a "Substantive change", then we should correct the BNF as well.
(Note: What is "Substantive Change" is determined by TC. Ultimately the TC needs to confirm that the Errata does not constitute a Substantive Change by a Full Majority Vote.)

Proposal 2B:
In v2.0,
(1) Add a "standalone-queryable" attribute to secondary object type definition.
(2) Correct the BNF to allow queryable secondary object type(s) in the FROM clause so long as they are joined with at least one queryable primary object type, and to allow a standalone-queryable secondary object type in the FROM clause without joining with another object type.

(Q: BTW, is there a use case for joining secondary types without joining them with a primary type?)


> Clarify the query support for secondary types
> ---------------------------------------------
>
>                 Key: CMIS-771
>                 URL: https://issues.oasis-open.org/browse/CMIS-771
>             Project: OASIS Content Management Interoperability Services (CMIS) TC
>          Issue Type: Bug
>          Components: Domain Model
>    Affects Versions: V1.1 Errata
>            Reporter: Andy Hind
>            Priority: Critical
>
> The query support for secondary types is not clear.
> CMIS-742 defined the query behaviour for secondary types in CMIS 1.1.
> CMIS-742 and section  2.1.14.2 of the 1.1 specification imply that secondary types can be used alone.
> For example
> SELECT * from cmis:rm_hold
> There are two issues with this.
> 1) It implies that heterogeneous objects may be returned from a query, as the same secondary type could be applied to both documents and folders.  Heterogeneous object can not be returned for all repositories.
> 2) Section 2.1.14.2.1, BNF Grammar, allows only <table name> in both the <from clause> and <joined table>. <table name> is defined to identify a primary type. There is a <secondary type table name> defined but only used in <column reference>. It looks like this was overlooked in the changes made for CMIS-742. The current BNF implies that only primary types may appear in FROM and JOIN clauses.



--
This message was sent by Atlassian JIRA
(v6.2.2#6258)