On Fri, Jun 4, 2010 at 1:16 AM, Emmanuel Lecharny <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
