On 10/24/06, Jukka Zitting <[EMAIL PROTECTED]> wrote:
Hi,
On 10/24/06, Alex Popescu <[EMAIL PROTECTED]> wrote:
> You are right Julian, but the spec doesn't say anything about batch
> propery fetching; so Steffan is right: it is an implementation detail.
> And if the implementation proves itself to go over the wire to fetch
> each property then this would be considered an important design bug in
> that implementation.
I'd call it a feature rather than a bug since there are cases where
aggressive caching of property values is not a good idea, for example
if you're just traversing the node tree, then prefetching the property
values will just slow things down. In any case it's an important
consideration that I certainly wouldn't discard as an implementation
detail. In fact I'd call the property access performance a major
non-functional feature, that we might want to specify some benchmarks
for to guide application developers on what to expect.
You can look at it in both ways. And it is a delicate one. We cannot
ignore the fact that network round-trips are very expensive, nor the
points that you are raising :-).
PS. There actually is one way to achieve batch property access in JCR,
namely the XML export feature. Create a custom ContentHandler that
simpy records the Attributes instance and ignores all other SAX event
information. Note that the received XML attributes may be encoded as
described in JSR 170, but for many use cases this is not a problem.
It's a bit of a hack, but if you're limited by a network layer like
JCR-RMI that needs to do a network roundtrip for each property access,
it might be the best option there is...
Hmm... interesing. Never thought of this functionality in this way.
./alex
--
.w( the_mindstorm )p.
BR,
Jukka Zitting
