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