Query model for secondary type

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.