Hi, On Mon, Oct 28, 2013 at 2:48 PM, Jukka Zitting <[email protected]> wrote: > Hi, > > On Mon, Oct 28, 2013 at 3:12 PM, Tobias Bocanegra <[email protected]> wrote: >> I don't know anymore where I heard/read this, but I had the >> assumption, that oak will no longer support properties and child nodes >> with the same name. > > Yes, you're correct. However, we don't really actively enforce this > limitation and the data structures used by our all our backends > actually do make it possible for a node and a property to have the > same name, so it might well be that it's in practice possible to > create such content structures. The original idea as implemented by > the older H2 MK was to use just a single JSON-like map for both nodes > and properties, but that approach is troublesome given the need to > support flat hierarchies. > > I think we should fix that in one way or another: either explicitly > check for such name collisions at the storage level or alternatively > revert the earlier decision and allow a property and a child node to > have the same name.
I would rather keep the support for same name properties and nodes in order to ensure backward compatibility for existing repositories. It would also keep the support for importing XML documents where attribute and element names can have equal values. Are there any other areas where the item name ambiguity is not properly handled, because we assume no same name property and node names? e.g. in permission evaluation, search, etc? >> If this is no longer supported, we should add it to the list of >> changes [0] and add it as issue to [1]. > > Right. > >> If the support varies by persistence implementation, we need to >> propagate this information to the repository descriptor accordingly. > > It's probably cleaner if the behavior is the same regardless of the > storage backend. I agree. Regards, Toby
