CMIS

[jeffandcarrie]

We have a custom content model with an text attribute wm:configAcctId.  When we perform a CMIS query that includes this attribute we see results as if it is being treated as a term.

ie.  
if we query where  wm:configAcctId = '3301' we will see results where
wm:configAcctId == '3A3301'

The query we are issuing is this
SELECT cs.cmisbjectId, cs.cmis:contentStreamMimeType, cs.cmis:lastModificationDate, cs.cmis:contentStreamLength, cs.wm:docId, cs.wm:reportTitle, cs.wm:reportingLevel, cs.wm:reportType, cs.wm:reportCategory, cs.wm:reportAccountId, cs.wm:docLevel,cmd.wm:clientId, cs.wm:isExpressDelivery, cs.wm:lastInsiteDeliveryDate, cmd.wm:effectiveDate, cmd.wm:frequency, cmd.wm:renditionStatus FROM wm:report as cs join wm:common_metadata as cmd on cs.cmisbjectId = cmd.cmisbjectId where cs.wm:isInsiteEligible = true AND cs.wm:configAcctId = '"^3301"' AND cmd.wm:asOfDate = '201606' AND cmd.wm:frequency = 'Q' ORDER BY cs.wm:reportAccountId

Is there some way that we can force an exact match in the query?

Thanks
Jeff

[afaust]

It would be very interesting to know how you have configured the wm:configAcctId in your data model. I assume you have set it with "tokenised" being "true" or potentially "both". It is also relevant to know if you have enabled the database indices to support <a href="http://docs.alfresco.com/5.1/concepts/intrans-metadata.html">transactional metadata queries</a>.

If you have it set to "true" than that explains the result, as there will be a match with 3A3301 due to the fact that this value is split (tokenised) before and after the A, so it has three tokens 3 A 3301 that can be matched. This tokenisation is only relevant if searches are performed against the index. This happens when the query is too complex, contains elements not supported by a database query or the indices relevant for transactional metadata query have not been created in the database. Your query contains a comparison with a boolean value, which last I checked is not supported by queries against the database (due performance / lack of index).
If "tokenised" is set to "both" I would expect the intended result to be returned, potentially accompanied with the "wrong" one since "both" will result in 4 tokens for 3A3301, the full term and the same tokens from the "tokenised=true" case.