Hi tobias
I think there's no need to store the entire entry list, not even with more than one added/remoded entry, that's the problem and a/r/m aware object would fix.
- NodeState. Parents and Child Node entries collection handling A single add/remove/modify aware object for child node entries would be very useful. If a NodeState is added or removed both parent and child are stored, a ChildNodeEntryChangeLog would be enough to notify the PersistenceManager about changes in parents and children.
true. but i guess, the entire child-node-entries list must be stored, because the number of added/removed entries could be greater than 1 and for orderable childnode entries
> also the ordering of the list could have been changed. then it should be an add/remove/modify/relative position aware object
Anyway, I'll try to deal with this by following the Dominique's advice.
It took me many hours to realize the jackrabbit policy regarding MV properties, I think it should be added explicitly to the documentation. Something as clear as: "try not to use MV properties, specially heavy-weighted ones". English is not my native language so probably it's not as clear as I suppose :).
- PropertyState. InternalValues collection handling An add/remove/modify aware object would be an improvement. This would reduce the overhead of writing all the values for multivalue properties. This is particularly important in networked deployments. I think that an InternalValueId would be needed and it should have the following fields: uuid, name, index and type.
true. but we would like to discourage people to make intensive use of MV-properties. especially the use of binary-mv-properties need a good legitimacy :-)
regards edgar
