You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@directory.apache.org by Stefan Seelmann <se...@apache.org> on 2010/06/03 22:51:28 UTC

[ApacheDS] Merge jdbm-store into jdbm-partition

Hi dev,

another easy refactoring is to merge the modules jdbm-store and
jdbm-partiton.

Kind Regards,
Stefan




Re: [ApacheDS] Merge jdbm-store into jdbm-partition

Posted by Kiran Ayyagari <ka...@apache.org>.
On Fri, Jun 4, 2010 at 1:16 AM, Emmanuel Lecharny <el...@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:
>>
>> 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.
the problem is here that, a Partition though backed by a store(a.k.a a
DB) is still
aware of LDAP related details like OperationContext. Store *is* the
real DB manager.
Moreover a Store's implementation is specific to a partition.

P.S: I think in future we can really separate the Store from Partition
completely
       but requires a lot more effort in generalizing the
initialization across partition
       implementations

Kiran Ayyagari

Re: [ApacheDS] Merge jdbm-store into jdbm-partition

Posted by Stefan Seelmann <se...@apache.org>.
Done.

> So I'm going to keep the jdbm-partition module.
> 
> 
> Alex Karasulu wrote:
>>
>> On Fri, Jun 4, 2010 at 1:16 AM, Emmanuel Lecharny <elecharny@gmail.com
>> <ma...@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
> 


Re: [ApacheDS] Merge jdbm-store into jdbm-partition

Posted by Stefan Seelmann <se...@apache.org>.
So I'm going to keep the jdbm-partition module.


Alex Karasulu wrote:
>
>
> On Fri, Jun 4, 2010 at 1:16 AM, Emmanuel Lecharny <elecharny@gmail.com
> <ma...@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


Re: [ApacheDS] Merge jdbm-store into jdbm-partition

Posted by Alex Karasulu <ak...@apache.org>.
On Fri, Jun 4, 2010 at 1:16 AM, Emmanuel Lecharny <el...@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

Re: [ApacheDS] Merge jdbm-store into jdbm-partition

Posted by Emmanuel Lecharny <el...@gmail.com>.
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
> 2. XDBM provides an abstract implemementation of the Partition interface
> and additionally defines the Store interface and search engine.
>    
+1
> 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.

But let's discuss this aspect further, I may perfectly be wrong, I'm 
just trying to manipulate concepts here.


-- 
Regards,
Cordialement,
Emmanuel Lécharny
www.nextury.com



Re: [ApacheDS] Merge jdbm-store into jdbm-partition

Posted by Stefan Seelmann <se...@apache.org>.
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

2. XDBM provides an abstract implemementation of the Partition interface
and additionally defines the Store interface and search engine.

3. The JDBM partition is a concrete implementation of the XDBM
partition. It contains a Store implementation because this is forced by
XDBM.

Kind Regards,
Stefan


Re: [ApacheDS] Merge jdbm-store into jdbm-partition

Posted by Emmanuel Lecharny <el...@gmail.com>.
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)



-- 
Regards,
Cordialement,
Emmanuel Lécharny
www.nextury.com



Re: [ApacheDS] Merge jdbm-store into jdbm-partition

Posted by Kiran Ayyagari <ka...@apache.org>.
On Thu, Jun 3, 2010 at 11:51 PM, Stefan Seelmann <se...@apache.org> wrote:
> Hi dev,
>
> another easy refactoring is to merge the modules jdbm-store and
> jdbm-partiton.
+1, sounds good too

Kiran Ayyagari