On Mon, Aug 2, 2010 at 5:33 PM, Emmanuel Lecharny <firstname.lastname@example.org>
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.