directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alex Karasulu <>
Subject Re: About Partition, AdministrativePoints and the whole universe...
Date Tue, 31 Aug 2010 06:18:18 GMT
On Mon, Aug 2, 2010 at 5:33 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).
> 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)
Yep that's certainly 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 ?
> 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.
Very interesting idea - I never thought or imagined using the X.500 admin
model for this. However don't we need inner AP's if the point in the first
place is to have nesting and the partition is rooted at the AP?

> 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.
Yes this is a great idea. I agree with this approach at first sight. It
would be much easier and faster to pull out the subentries from the
configuration area but this creates some oddities though on second thought.
We basically have subentries located under the configuration area but they
are not subordinate to APs.  Technically subentries should subordinate to
APs according to implicit ditStructureRules built into the protocol.

> Ok, those are just ideas, but I think it can fit well with the big picture.
> feel free to comment !
Very interesting thought but I think we need to think about this a bit more.
I have also some ideas on implementing nested partitions and  a new
organization in the backend to partitions which will facilitate handling
entry relocations across partitions as well as cross partition aliases. More
to follow in the coming days.

Alex Karasulu
My Blog ::
Apache Directory Server ::
Apache MINA ::
To set up a meeting with me:

View raw message