So I'm going to keep the jdbm-partition module.
Alex Karasulu wrote: > > > On Fri, Jun 4, 2010 at 1:16 AM, Emmanuel Lecharny <elecha...@gmail.com > <mailto:elecha...@gmail.com>> wrote: > > On 6/4/10 12:01 AM, Stefan Seelmann wrote: > > Emmanuel Lecharny wrote: > > > On 6/3/10 10:51 PM, Stefan Seelmann wrote: > > > Hi dev, > > another easy refactoring is to merge the modules > jdbm-store and > jdbm-partiton. > > > > +1. Which one will you keep ? jdbm-store ? > > To me, a partition is associated with a naming context, > not with an > underlying store. That implies we should get rid of those > XXX-partition > to just keep xxx-store, and keep the partitions at a upper > layer (ie, core) > > > I wanted to keep the jdbm-partition module. > > To me the partition is the concept that the core knows. The > core knows > nothing about stores. We also define partitions in the > configuration, > not stores. > > This is how I understand the architecture: > > 1. The core defines the Partition interface > > > +1 > > > Yes. > > > > 2. XDBM provides an abstract implemementation of the Partition > interface > and additionally defines the Store interface and search engine. > > > > Yes. Also eventually with global identifiers (UUID) acting as primary > keys for the XDBM db scheme we will be able to pull the search > functionality out of the partition and place it above the partition > nexus. This will make the store interface/concept less important as well. > > > > 3. The JDBM partition is a concrete implementation of the XDBM > partition. It contains a Store implementation because this is > forced by > XDBM. > > > Here, I disagree. JDBM is a store, not a partition. XDBM = > XXX-Data Base Manager, nothing connected to the idea of Partition. > We could probably say that XDBM and Store is the same concept. > > > I think we're overloading too much meaning into Store here. Treat it > as a simple interface and forget about trying to draw more meaning out > of it such as "Database Manager" etc. Search happens on this Store > which exposes all the methods needed to perform various operations. > It's just an interface coalescing all these functions together into a > single place so for example we can hand off a store to different parts > of the XDBM implementation and have it operate on that object. > > > But let's discuss this aspect further, I may perfectly be wrong, > I'm just trying to manipulate concepts here. > > > I think we're trying to draw more meaning from this concept which we > do not need to. > -- > Alex Karasulu > My Blog :: http://www.jroller.com/akarasulu/ > Apache Directory Server :: http://directory.apache.org > Apache MINA :: http://mina.apache.org > To set up a meeting with me: http://tungle.me/AlexKarasulu
