On 30.07.2014, at 07:44, Thomas Mueller <[email protected]> wrote: > As a user of the JCR API, I wouldn't expect getSize to potentially take > multiple minutes. So following the principle of least surprise, I wouldn't > want that.
I agree with Jukka. Since any combination has people come back and ask "why is it slow" or "why is it not returning -1" as we now know :), why not go back to the simplest solution and have getSize() return the correct total, even if it is slow. Then maybe add the convenient getSize(int max) (either Jackrabbit API or a simple wrapper in jcr commons) and remove all the partly iterating tricks in the oak-jcr or lower layers again, simplifying the stack. And clearly document that getSize() can be slow. The trick in Jackrabbit 2 with the orderby to force the getSize() is a bit ugly, especially given that orderby can be very costly, relies on the default (oderby @jcr:score) and last but not least requires applications to change the query – whereas retrieving the total should be an orthogonal thing. > I think we did do that before, (never return -1), and run into performance > problems because some application / tools call getSize() quite often. With the switch to Oak, it's a good time to change that. Since the orderby trick was removed (and if we don't introduce it back), applications have to adapt anyway. Cheers, Alex
