> > This is not part of the JCR 1.0 spec and will be possible > with the advanced query model of JCR 2.0 in a Jackrabbit 2.0 version.
Just out of curiosity: AFAIK, there is no scalable solution for this within lucene. To efficiently compare properties with eachother, this comparison result already needs to indexed. But, as we do not know this on beforehand, this cannot be done, at least, I wouldn't know how. So is there already some trick somebody thought of how this actually could be implemented? Regards Ard > > > Support comparison of properties in queries (on both sides of > > comparison) > > > ---------------------------------------------------------------------- > > --- > > > > Key: JCR-1146 > > URL: https://issues.apache.org/jira/browse/JCR-1146 > > Project: Jackrabbit Content Repository > > Issue Type: Improvement > > Components: jackrabbit-core, query > > Affects Versions: 1.3.1 > > Reporter: Amir Mistric > > > > Currently Jackrabbit does not support having properties on > both sides of a comparison in a query. > > For example, neither one of the following queries return > results (and they should) nor they throw an exception!!! > > 1. > > > /jcr:root/www-mysite-org//element(*,mgnl:content)[MetaData/@mgnl:activ > > ated='true' and MetaData/@mgnl:lastmodified > > > MetaData/@mgnl:lastaction] 2. > > > /jcr:root/www-mysite-org//element(*,mgnl:content)[MetaData/@mgnl:activ > > ated='true' and xs:dateTime(MetaData/@mgnl:lastmodified) > > > xs:dateTime(MetaData/@mgnl:lastaction)] > > 3. > > > /jcr:root/www-mysite-org//element(*,mgnl:content)[MetaData/@mgnl:activ > > ated='true' and MetaData/xs:dateTime(@mgnl:lastmodified) > > > MetaData/xs:dateTime(@mgnl:lastaction)] > > The problem is that one of the comparison fields has to be > literal which is very limiting... > > -- > This message is automatically generated by JIRA. > - > You can reply to this email to add a comment to the issue online. > >
