>From my point of view Felix's point is correct in term of definition of how a >vanity path can be set. >From the Oak query point of view, if I'm not wrong, the Lucene index should >chime in for this case since it indexes properties and can return paths so >that should be turned into a fielded query on the given WHERE clause property.
My 2 cents, Tommaso On 21/feb/2013, at 16:11, Marcel Reutegger wrote: > Hi, > > it means it will traverse the entire workspace to find nodes with > a sling:vanityPath property. > > Regards > Marcel > >> -----Original Message----- >> From: Felix Meschberger [mailto:[email protected]] >> Sent: Donnerstag, 21. Februar 2013 14:33 >> To: [email protected] >> Subject: Re: Vanity Path query >> >> Hi >> >> You mean "property exists" querying will be slow out of the box ? >> >> What does slow mean compared to Jackrabbit 2.x ? >> >> Regards >> Felix >> >> Am 21.02.2013 um 12:57 schrieb Marcel Reutegger: >> >>> one more thing to consider... >>> >>> while it probably won't have that much of an impact with Jackrabbit 2.x >>> the situation is different with Jackrabbit Oak. Oak currently comes with >>> default indexes for jcr:primaryType and jcr:mixinTypes. If you now >>> turn your query into 'FROM nt:base' Oak won't be able to leverage >>> those indexes and the query will be terribly inefficient. You will have >>> to add an index on sling:vanityPath to make if efficient again. >>> >>> regards >>> marcel >>> >>>> -----Original Message----- >>>> From: Marcel Reutegger [mailto:[email protected]] >>>> Sent: Donnerstag, 21. Februar 2013 12:53 >>>> To: [email protected] >>>> Subject: RE: Vanity Path query >>>> >>>> Hi, >>>> >>>>> Does changing "FROM sling:VanityPath" to "FROM nt:base" have any >>>>> noticeable impact on performance or cost of the query ? >>>>> Ian >>>> >>>> probably not. it might even be a bit faster because the query does >>>> not have to filter by node type. >>>> >>>> regards >>>> marcel >> >> >> -- >> Felix Meschberger | Principal Scientist | Adobe >> >> >> >> >> >> >
