On 25.10.11 18:06, "[email protected]" <[email protected]> wrote:
>> Use the getSize() method of the returned node or row iterator. > >I think that returns the size of elements in the iterator and that is >hopefully not the complete size if I used the limit and offset options... Yes, I also think it is the actual result "window" size (if given), but not the total. (But I am not 100% sure). >I used an XPath query before switching to jackrabbit 2.2.9 but I thought >I should change my query to SQL2 because xpath is deprecated now. It is deprecated in the spec - but most Jackrabbit based systems use xpath heavily so it is not going away soon. SQL2 on the other hand is still very young - and while having some new features, such as joins, it is not as optimized and proven as Xpath or SQL1. (We should really put that in a FAQ). >So what is your recommendation now? Should I switch to SQL2? What about >the total size then? Or should I still use xpath? I am currently >switching because it seems that my xpath queries do not work any longer. >A lot of tests do fail now... I have to track this down but it seems that >I run into another backward incompatibility issue here... I guess it's only that getSize() returns -1 for you now in most cases (if you come from Jackrabbit 1.x), as that is an optimization in the engine. To force a result, use the orderby @jcr:score trick mentioned by Ard. You can't be using limit & offset with Jackrabbit 1.x and Xpath... Cheers, Alex -- Alexander Klimetschek Developer // Adobe (Day) // Berlin - Basel
