What about adding an optional interface to do so that store may or may
not implement. That's what I have done for sequences... How would such a
store look like?
Oliver
Martin Holz wrote:
Oliver Zeigermann <[EMAIL PROTECTED]> writes:
I have no real idea of DeltaV, but I think applying the history folder
workaround by Martin Holz is not the best solution. We should rather
find out why it is slow to access collections with many children.
Thats quite obvious. NodeStore has no notation of modifing
ObjectNodes in place. So for any modification you have to fetch
the node, modify it and store it. The price of fetching/storing
is proportional to the size of the ObjectNode. And the size of the
ObjectNode is proportional to the number of direct children.
If the store interface changes performance could increase
a lot. This would be a rather large change, changing the
architecture and objectives of slide.
Stores were simple and easy to implement in slide 1.0. Now they have to care
about bindings,transactions and now it needs additional methods for changing
nodes in place.
Martin
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
