directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alex Karasulu <akaras...@apache.org>
Subject Re: Moving the configuration beans to core-api
Date Sun, 31 Oct 2010 21:38:34 GMT
On Sun, Oct 31, 2010 at 11:11 PM, Emmanuel L├ęcharny <elecharny@apache.org>wrote:

> On 10/31/10 9:54 PM, Alex Karasulu wrote:
>
>> On Sun, Oct 31, 2010 at 6:42 PM, Emmanuel Lecharny<elecharny@gmail.com
>> >wrote:
>>
>>  Hi guys,
>>>
>>> There is a base Index class, with two main children : AvlIndex and
>>> JdbmIndex. There is a third child, named genericIndex, which is only used
>>> to
>>> deal with junit annotations used to create a new server instance (it's a
>>> holder class).
>>>
>>
>> What's a holder class?
>>
> A POJO, if you prefer. It holds some value, but does not have any logic
> inside. A Bean. A container.
>
> As I'm going a but further in the code analysis, I see that Index are
> handled in two steps in the server :
> - first we create them
> - then we initialize them.
>
> When adding a partition with indices, the Index will have a different type
> depending on the Partition's store type. We can create a JdbmIndex, an
> AvlIndex, etc. That means we need to have an object containing the Index
> description which will be used to instantiate the correct index (and this is
> why we have this GenericIndex, plus some convertAndInit() method in the
> different kinds of stores).
>
> This does not seems to be the correct approach to me. What I would prefer
> do is to use either the IndexBean (which has all the needed parameters
> necessary to create an index), and let the Store creates the correct index
> directly, instead of calling this convertAndInit method.
>
>

There will be subtypes that will need to carry more information associated
with the specific partition implementation index. How will you account for
all that. You cannot now foresee all the different kinds of wacky
implementations our users will come up with down the line.

I think you're making a big mistake and not thinking of dynamic extension
scenarios here where someone adds FooPartition that has FooIndex with bar
property specific to it. If you take the brute force hardcoded approach to
having just an IndexBean with what you at this point see as all foreseen
values we're going to have serious problems with extension points on
Partition.


-- 
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

Mime
View raw message