Hi, I separated the two because I think it's the responsibility of the query engine to use multiple indexes based on cost when there is more than one restriction on a filter. This is not implemented right now, but I think we will have to do that anyway to efficiently execute this query:
//element(*, nt:resource)[jcr:contains(., 'foo')] the node type index can take care of 'element(*, nt:resource)' but for the jcr:contains(., 'foo') we'd probably want to leverage the lucene index implementation. neither of the two should know about the other. Regards Marcel > -----Original Message----- > From: Jukka Zitting [mailto:[email protected]] > Sent: Dienstag, 6. November 2012 11:18 > To: Oak devs > Subject: Re: svn commit: r1406080 - in /jackrabbit/oak/trunk: oak-core/ oak- > core/src/main/java/org/apache/jackrabbit/oak/plugins/index/nodetype/ > oak-core/src/main/java/org/apache/jackrabbit/oak/plugins/index/property/ > oak-core/src/main/java/org/apache/jackrabbi... > > Hi, > > On Tue, Nov 6, 2012 at 11:04 AM, <[email protected]> wrote: > > Added: > > jackrabbit/oak/trunk/oak- > core/src/main/java/org/apache/jackrabbit/oak/plugins/index/nodetype/ > > Do we need a separate index implementation for this? I'd rather simply > have this functionality as a part of PropertyIndex. That way a query > that combines node type and property restrictions could still be > efficiently executed. > > BR, > > Jukka Zitting
