directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Kiran Ayyagari <>
Subject Re: About Partition, AdministrativePoints and the whole universe...
Date Mon, 02 Aug 2010 18:27:07 GMT
On Mon, Aug 2, 2010 at 8:03 PM, Emmanuel Lecharny <> wrote:
>  Hi guys,
> as I'm slowly refactoring the data structure we use to manage
> NamingContexts, I just realized that we may have a way to handle
> encapsulated partitions...
> One of the Graal we were chasing was the possibility to define encapsulated
> partitions. Let me give you an example :
> if we define dc=example,dc=org as a naming context, then we have to define a
> dedicated partition (be it JDBM, LDIF, HBase, in-memory, SQL-based). That's
> good, but if we want to define a sub-partition for, say
> ou=apache,dc=example,dc=org, we currenty can't. That means this ou=apache...
> thing will be stored in the same backend than the partition it's defined
> into (dc=example,dc=org).
so this kind of partition won't be shown as a naming context anymore,
its base is always dc=example,dc=org from a user POV, is that right?
> We also have some issue currently, like DIRSERVER_1517 : we can't move an
> entry from one partition to another one (this is a bug)
> Ok, how can we manage encapsulated partitions ? Here is one idea I had :
> - what about leveraging the X500 administrative model ? We currently can
> manage AccessControl, CollectoveAttribute, SubSchema (even if we don't
> support it atm), TriggerExecution, so why not add a new role, the
> PartitionLayout role which defines a new partition starting at the defined
> Administrativepoint ?
sounds like a cool idea
> So a partition is a role, defining the storage, and all of it's
> characteristics, using a subentry  for that. Of course, a PL AP won't be an
> Inner AP. We won't allow any subtree specification for this subentry, and
> the base will always be the AP.  It should work.
> Now, a few more thoughts : the current partitions configuration is stored
> into the ou=config partition (a LDIF partition). How can we continue using
> this config partition in sync with the subentries ? What if subentries are
> just aliases pointing to the config partition ? As we have to load all the
> subentries at startup, it would be far easier to do that if they are stored
> into the config partition.
+1, it is better to make it as a alias and keep the config in
configuration partition
> Ok, those are just ideas, but I think it can fit well with the big picture.
> feel free to comment !
> --
> Regards,
> Cordialement,
> Emmanuel Lécharny

thanks Emmanuel

Kiran Ayyagari

View raw message