jackrabbit-oak-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Angela Schreiber <anch...@adobe.com>
Subject Re: unique indexes in InitialContent
Date Thu, 25 Oct 2012 09:12:33 GMT
hi marcel

isn't there a TODO/FIXME in the code regarding this issue? i already
added it twice as it seems that TODO/FIXME tags get removed without
the corresponding issues being addressed... that's embarrassing.

i kept stating both in the code and in the corresponding issue
that this change didn't work and will fail as soon as access
control mgt is added to the code base.

apart from that the problem is not limited to the unique properties
mandated by the user management! the same applies for a jcr:uuid
property that was perfectly legal when being used with a non
referenceable node and in which case there is no requirement
whatsoever that it was unique in that case... it can be a binary
or a boolean...

IMO the proper fix would be to add additional node type information
to the unique-index setup. something like:

index.child("uuid")
.setProperty("jcr:primaryType", "oak:queryIndexDefinition", Type.NAME)
.setProperty("propertyNames", "jcr:uuid")
.setProperty("declaringNodeType", "mix:referenceable")
.setProperty("unique", true);

or

index.child("principalName")
.setProperty("jcr:primaryType", "oak:queryIndexDefinition", Type.NAME)
.setProperty("propertyNames", "rep:principalName")
.setProperty("declaringNodeType", "rep:Authorizable")
.setProperty("unique", true);

kind regards
angela



On 10/25/12 10:56 AM, Marcel Reutegger wrote:
> Hi,
>
> we currently have the following two unique indexes that don't
> work well IMO:
>
>              index.child("authorizableId")
>                  .setProperty("jcr:primaryType", "oak:queryIndexDefinition", Type.NAME)
>                  .setProperty("propertyNames", "rep:authorizableId")
>                  .setProperty("unique", true);
>              index.child("principalName")
>                  .setProperty("jcr:primaryType", "oak:queryIndexDefinition", Type.NAME)
>                  .setProperty("propertyNames", "rep:principalName")
>                  .setProperty("unique", true);
>
>
> this limits the use of the two property names. E.g. in Jackrabbit 2.x we
> also use rep:principalName in the access control entry nodes. this means
> we won't be able to use the same access control content structure in
> Oak with the existing indexes defined in InitialContent.
>
> Was this intended or is this rather a limitation of the property index
> we should fix? e.g. constrain the index to nodes of a certain type.
> on the other hand that would make index selection more complicated.
>
> Hmm, actually thinking a bit more about this, I'd say we have to enhance
> the property index. Otherwise it is possible to affect a central part of the
> repository (user management) by simply creating an unstructured node
> with a rep:principalName property. Alternatively we might limit the use
> of those system properties to nodes with an appropriate type in a
> validator.
>
> Thoughts?
>
> Regards
>   Marcel

Mime
View raw message