Query on jcr:isCheckedOut

[jamat]

Hello,

I was playing with versioning with some of the nodes in my repository and I wanted to run a query to get all the nodes that were checked out.

Alas, I was not able to make it work.

I am probably doing something wrong. The query I have used is:

"SELECT * FROM [mynode:name] AS mynode WHERE mynode.[jcr:isCheckedOut] = true"

So my question, assuming that my syntax was correct, is it possible to query on this property ?

This is with modeshape 2.5.0 Final

(note: I did try a similar query on a BOOLEAN property and it was working fine).

Anyway, as this is my first post, I would like to thank all the people who make it possible for me to use ModeShape.

[rhauch]

Anyway, as this is my first post, I would like to thank all the people who make it possible for me to use ModeShape.

Welcome, and thanks for using ModeShape and for posting your question here!

The short answer is that this query should work:

SELECT * FROM [mynode:name] AS mynode WHERE mynode.[jcr:isCheckedOut] = true

I presume that the 'mynode:name' node type or mixin type is a direct or indirect subtype of 'mix:versionable' -- otherwise you should have gotten an error that 'jcr:isCheckedOut' is not on the 'mynode:name' table.

For the benefit of other readers, if instead 'mynode:name' does not extend 'mix:versionable' and 'mix:versionable' is added as a mixin type on your nodes, then you can perform a join:

SELECT * FROM [mynode:name] AS mynode 
         JOIN [mix:versionable] AS versionable 
         ON ISSAMENODE(mynode,versionable) 
         WHERE versionable.[jcr:isCheckedOut] = true

This query creates a single view that contains all of the columns from 'mynode:name' and 'mix:versionable', where each row contains the values from a single node.

Now, why does your query not work with 'jcr:isCheckedIn'? I start investigating this, and I discovered two errors that combine to make criteria against BOOLEAN properties work correctly for all custom property definitions, but to work incorrectly against all built-in property definitions. I've logged this as MODE-1234, and there is a workaround that involves using '1' or '0' for the literal values in criteria against the built-in properties. See the issue for details and a suggestion.

I do have a fix in the works, and so far my integration build is passing all of the tests. So if this continues, expect to see a fix in the 2.6.0.Final release due out in just a few weeks.

Try the workaround and let us know if that does not work.

Best regards

[jamat]

Thank you for the quick answer.

I was slow to answer because unfortunately the workaround did not work for me and I was trying other combinations.

I have tried with the latest modeshape 2.6.0beta2, then I have modified the configuration to persist jcr:system in the db.

But no luck.

The 'jcr:isCheckedOut' property is there on my node as a query with a constraint clause like 'name.[jcr:isCheckedOut] IS NOT NULL'

works fine. And getString() will return true and getType() will return 6, which is BOOLEAN I guess.

I may try some other stuff.

[rhauch]

The fix for this has been committed and will be in the next release. Feel free to pull the latest code and build locally if you really need it.

I was slow to answer because unfortunately the workaround did not work for me and I was trying other combinations.

Can you post some of the criteria you used?

then I have modified the configuration to persist jcr:system in the db.

That will have no impact on query functionality, as JCR queries are executed using ModeShape's internal indexes and not those in the database.

Best regards

[jamat]

Thanks. I may wait for the next available release.

Things that I have tried are mostly what you suggested, that is, using the JOIN with ISSAMENODE or using only mix:versionable.

Then I have tried crazy stuff like '<> 0' or "= CAST(1 AS BOOLEAN)".

BTW another comment which is kind of related.

I have tried to use the QOM query and for the list of columns I used: {qomFactory.column("mynode", null, null)}.

The javadoc says that you can use null for the column name. Modeshape does not like it:

java.lang.IllegalArgumentException: The propertyName argument may not be null

        org.modeshape.common.util.CheckArg.isNotNull(CheckArg.java:387)

        org.modeshape.graph.query.model.Column.<init>;(Column.java:64)

        org.modeshape.graph.query.plan.PlanUtil.replaceViewReferences(PlanUtil.java:686)

        org.modeshape.graph.query.plan.PlanUtil.replaceViewReferences(PlanUtil.java:630)

        org.modeshape.graph.query.optimize.ReplaceViews.execute(ReplaceViews.java:144)

        org.modeshape.graph.query.optimize.RuleBasedOptimizer.optimize(RuleBasedOptimizer.java:58)

        org.modeshape.graph.query.QueryEngine.execute(QueryEngine.java:97)

        org.modeshape.jcr.RepositoryQueryManager$SelfContained.query(RepositoryQueryManager.java:415)

        org.modeshape.jcr.JcrQueryManager$SessionQueryContext.execute(JcrQueryManager.java:1422)

        org.modeshape.jcr.query.JcrQuery.execute(JcrQuery.java:103)

I may have misunderstood the doc.

[rhauch]

Thanks. I may wait for the next available release.

Ok.

BTW another comment which is kind of related.

I have tried to use the QOM query and for the list of columns I used: {qomFactory.column("mynode", null, null)}.

The javadoc says that you can use null for the column name. Modeshape does not like it:

It should be possible to specify null for the property name and column name (the last two parameters in the "column" method). Can you log a defect and include in it an example of the query you are trying to build?