Rules for indexing are determined with only built-in node types, causing queries with criteria against non-built-in property definitions to miss rows

ModeShape uses an internal rule set to build the internal indexes used by the query engine to answer queries and searches. These rules are based upon the registered node types and determine how property values are to be treated, including (among other things) whether the value is to be treated as a string, an integer/float numeric value, a date, etc. For example, property definitions of type BOOLEAN result in the corresponding values being treated as numeric values with a range of [0,1]. Any property for which there is no rule (e.g., there is no property definition) is treated as a string.

So when custom node types are registered, ModeShape internally updates its indexing rule set. However, the problem is that the indexing logic was not using the new indexing rule sets. As a result, any nodes that used custom node types might have their properties stored in a non-ideal manner within the indexes.

In many cases, the query logic would still work, simply because of how the values are stored in the indexes. But the case of BOOLEAN property definitions is complicated by another error in the query processing logic that incorrectly converted the boolean value in criteria into a string value for comparison against the indexes.

Thus, for custom BOOLEAN property definitions, the two errors resulted in the correct query behavior, but for built-in BOOLEAN property definitions, queries using 'true' or 'false' for criteria values would not match the expected nodes.

For example, the following query would work:

SELECT * FROM [my:type] WHERE [my:type].[my:booleanProperty] = true

whereas the following query would not:

SELECT * FROM [mix:versionable] WHERE [mix:versionable].[jcr:isCheckedIn] = true