Alex Karasulu wrote:
On Thu, Sep 3, 2009 at 2:59 PM, Kiran Ayyagari <[email protected]>wrote:

 Hi guys,
right now, the Partition interface is used in two places :
- as the interceptor chain entry point
- as the facade for the specific backends (JDBM, LDIF, Oracle...)

We are using the same interface in both case.

What about defining two different interfaces ? One for the chain, one for
the backend ?

+1


Don't know for sure. Need to think a bit more about this.  What specific
entry point into the chain are you citing as using the Partition interface?
I thought we used LdapSession which has similar methods yet adapted to deal
with session related concerns.

LdapSession is the adaptation of Partition that you're looking for I think.
Let me bit more precies. We have a CoreSession which uses an OperationManager which pushes the operation into the InterceptorChain which calls the NexusPartition method. Pfeww...

This is this NexusPartition I suggest to be the base interface, and when we hit the backend, we use an extended interface.

Is it more clear ?


The chain interface (ie, Partition, to keep the existing name), will carry
the operations (add, delete, search...), the other interface, named
BackendPartition, which expose a bit more methods, like the sync() method,
get/set Id, get/set SuffixDn, etc.

Does it make sense to you ?


yeap, and one more thing is to change the BTreePartition class name too.
(I somehow feel that it doesn't sound like a generic base class)


I agree.  I think this is a base XdbmPartition implementation really.
Then we have to define it. We can rename the BTreePartion to be XdbmPartition


A problem I often encounter when writing a new partition is with the cast
in DefaultDirectoryService
where it assumes that all partitions are JdbmPartitionS, I think the time
is right to get this fixed.


Right and I think I already removed this.  It's pretty clear at this point
that some of the code in DDS can be moved into the XdbmPartition's
initialization.  For example these is a fragment of code that checks to make
sure the XdbmPartition indexes objectClass and therefore applies casts in
the DDS exposing and binding us to the Jdbm implementation.  This need not
be present anymore and may no longer be there as of last night.

I will make sure with re-factoring this will go away.

But most importantly we should review this stuff.  Emmanuel it's great that
you posted this because it puts all our thoughts out there to be
investigated.  I'll try to do the same and give people a basis to review
what we are doing.
Ok, waiting for your brain dump then :)

--
--
cordialement, regards,
Emmanuel Lécharny
www.iktek.com
directory.apache.org


Reply via email to