[OASIS Issue Tracker] Commented: (CMIS-742) Query model for secondary type

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

    [ http://tools.oasis-open.org/issues/browse/CMIS-742?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=30618#action_30618 ] 

David Choy commented on CMIS-742:
---------------------------------

This proposal does not change the secondary object type itself. It only changes its query model (i.e. how a secondary type appears in the relational view). A secondary type would not take on cmis:objectId as an extra property. Only the virtual table that corresponds to a queryable secondary type would have an extra column to capture the cmis:objectId property that all CMIS objects have. This cmis:objectId property is defined by each object's primary type, not by any secondary type. This cmis:objectId column in the virtual table identifies the individual objects that the secondary type is applied to, and it may be used for Joining with other virtual tables. If a queryable secondary type is merely a "marker" and does not define any property, then its virtual table would consist of a single cmis:objectId column. This single-column table would not be needed for joining with other tables, but it is still useful for finding all objects that this secondary type is applied to. (It functions just like an index for the secondary type.) A user may Join virtual tables on columns other than cmis:objectId, but the semantics is application-specific and outside the scope of CMIS (e.g. joining a mailing address with a work address). If a secondary type is non-queryable, then it does not appear in the relational view under this proposal.

> Query model for secondary type
> ------------------------------
>
>                 Key: CMIS-742
>                 URL: http://tools.oasis-open.org/issues/browse/CMIS-742
>             Project: OASIS Content Management Interoperability Services (CMIS) TC
>          Issue Type: Improvement
>          Components: Domain Model
>    Affects Versions: V1.1
>            Reporter: David Choy
>             Fix For: V1.1
>
>
> The query model for a secondary type in V1.1 Draft 03 (see 2.1.14.1.2) is the following. In the relational view, every secondary type property defined in the repository appears as an additional column in every virtual table. If a secondary type is not applied to an object, then the corresponding column or columns for that object will contain a SQL NULL value. This model is a bit clumsy, and it deviates from the relational model because the number of columns in a table is no longer fixed. A "SELECT *" query would include in the result all secondary type properties defined in the repository. Nevertheless, this approach probably would work - for queryable primary types. However, if a queryable secondary type is applied to an object of a non-queryable primary type, we have a problem. Initially, the non-queryable primary type does not even appear in the relational view. Once a queryable secondary type is applied to one of its objects, a virtual table suddenly comes into existence for that non-queryable primary type and the target object suddenly becomes queryable, not only the secondary properties but also the primary properties that were not queryable before. If we now remove the secondary type from this object, then the object suddenly disappears from the relational view.
> One way to fix this problem is to let primary type solely control an object's queryability. That is, an object's secondary properties are queryable only if its primary type is queryable. This solution is undesirable because there are use cases where one would like to be able to search on secondary type properties regardless of primary type queryability. It is also undesirable that a secondary type is only queryable for some objects it is applied to but not every.
> One way to solve this problem cleanly is to separate primary type from secondary type in the query model. For each queryable primary type there is a virtual table just as before. Separately, for each queryable secondary type there is another virtual table consisting of a column for the cmis:objectId property and a column for each secondary type property. The rows of this table correspond to the objects that the secondary type is applied to. They can be of different primary types. With this approach, a primary type controls the queryability of the primary properties and a secondary type controls the queryability of the secondary properties. If one wants to query both primary properties and secondary properties, then a SQL JOIN may be performed.
> This approach also solved another query problem. Under the Draft03 query model, to find all the objects that a secondary type is applied to, a user has to query every virtual table in the relational view and then merge the results. With the proposed model, the user only needs to query a single table.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://tools.oasis-open.org/issues/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira