On Wed, Jun 29, 2011 at 3:10 PM, Emmanuel Lecharny <[email protected]> wrote:
SNIP ... > We currently have a common Partition interface, which is the base on which > all the backend implementations are built. It's also used as an interface > for the Nexus. Yes. > In fact, we can split the Partition implementations in two categories : > 1) those which are manipulation an opertation context (AddContext, > DeleteOperationContext, etc) > 2) those which are interacting with the underlying store This does not make any sense to me at all. I can't see these as being two distinct categories. I must not be understanding you, can you elaborate? > The current hierarchy is (<XXX> : interface, [YYY] : abstract class) : > <Partition> > [AbstractPartition] > [BTreePartition<ID>] > [AbstractLdifPartition] > LdifPartition > ReadOnlyConfigurationPartition > SingleFileLdifPartition > [AbstractXdbmPartition<ID>] > AvlPartition > JdbmPartition > DefaultPartitionNexus (also implement <PartitionNexus>) > NullPartition > SchemaPartition > > Some few remarks : > - the BTreePartition<ID> should be renamed AbstractBTreePartition > - we should have a BTreePartition interface Why? > I'm also wondering if we should not make a better distinction between what > is backed by a store (ie, BTreePartition and SchemaPartition) and what is > not (ie PartitionNexus). Morever, why should the PartitionNexus extend the > Partition interface ? Does it make sense? The PartitionNexus is a proxy to partitions so it implements the interface. It's a single point to apply operations and have the route to the appropriate partition. There's work to be done in this area for sure. First off I'd like to see partitions that hash entries across other partitions and some that contain entries and still can nest other partitions: acting both as entry stores and routers of operations. For example I've wanted a root partition that could also mount (nest) other partitions while still storing entries so the root DSE can be mastered in it and we can manage other subentries for the server in it instead of at the namingContext level. Incidentally the store interface might be able to be gotten rid of. The key to several things we're going to do down the line around partitions rests around having entry ID be globally unique rather than unique within just the partition. After this is done it opens the door to several solutions ... including solutions to a couple recent problems: (1) aliases referring to entry targets across partitions (2) moddn operations across partitions (3) virtualization, via views, and other constructs need it .... There's more. But first we need a globally unique UUID for entries as the PK and we need to get rid of using long partition specific entry IDs as the PK. I would not change around interfaces right now. It's just going shift things without a clear direction and as you said yourself you're new to this code. Class renames and a few interface changes just to get familiar and comfortable with the code base is not going to help down the line. Let's go global on the UUID and look at the big partition picture. We can redesign things to best suite small steps to get to our ultimate destination. Regards, Alex
