You are viewing a plain text version of this content. The canonical link for it is here.
Posted to oak-dev@jackrabbit.apache.org by Marcel Reutegger <mr...@adobe.com> on 2012/10/25 10:56:30 UTC

unique indexes in InitialContent

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

RE: unique indexes in InitialContent

Posted by Marcel Reutegger <mr...@adobe.com>.
> 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.

there's indeed a FIXME in the InitialContent class. so that's me who
needs to be embarrassed, because I didn't see it before.

Regards
 Marcel

Re: unique indexes in InitialContent

Posted by Angela Schreiber <an...@adobe.com>.
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

Re: unique indexes in InitialContent

Posted by Jukka Zitting <ju...@gmail.com>.
Hi,

On Thu, Oct 25, 2012 at 10:56 AM, Marcel Reutegger <mr...@adobe.com> wrote:
> 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.

The latter.

BR,

Jukka Zitting