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 !
--
Regards,
Cordialement,
Emmanuel Lécharny
www.iktek.com
