directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Emmanuel Lecharny <>
Subject Partition and Backend confusion
Date Wed, 29 Jun 2011 12:10:37 GMT
Hi guys,

I'd like to address some issue I have with the current Partition 
interface and the inherited classes. Let me explain.

<side note>
First, please excuse me if some of the terms I'm using may not be 
totally semantically correct. I may use the wrong ones in some cases, 
but what I have in mind is pretty clear, it's just that I may use the 
incorrect name for the concept I'm discussing. So bear with me, and feel 
free to correct me.
</side note>

<side note>
I don't try to put some blame on anyone here, I just try to get a clue 
about this part of the code I'm discovering. The question I raise are 
more or less to get a better vision on the why and how the existing code 
was layered, and my perception might be iconoclast here. Just to be sure 
that I don't hurt anyone's feeling, this is certainly not my intention. 
Remember,  i'm quite a virgin in the partition/store code :)
</side note>

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

The current hierarchy is (<XXX> : interface, [YYY] : abstract class) :
     DefaultPartitionNexus (also implement <PartitionNexus>)

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?

Emmanuel L├ęcharny

View raw message