directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alex Karasulu <>
Subject Re: Partition and Backend confusion
Date Thu, 07 Jul 2011 22:10:59 GMT
On Wed, Jun 29, 2011 at 3:10 PM, Emmanuel Lecharny <> 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.


> 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

> 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


> 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

  (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


View raw message