directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Emmanuel Lecharny <>
Subject About Partition, AdministrativePoints and the whole universe...
Date Mon, 02 Aug 2010 14:33:38 GMT
  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)

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.

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.

Ok, those are just ideas, but I think it can fit well with the big picture.

feel free to comment !

Emmanuel L├ęcharny

View raw message