directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Emmanuel Lécharny <>
Subject Re: Moving the configuration beans to core-api
Date Sun, 31 Oct 2010 23:23:52 GMT
On 10/31/10 10:38 PM, Alex Karasulu wrote:
> On Sun, Oct 31, 2010 at 11:11 PM, Emmanuel Lécharny<>wrote:
>> On 10/31/10 9:54 PM, Alex Karasulu wrote:
>>> On Sun, Oct 31, 2010 at 6:42 PM, Emmanuel Lecharny<
>>>> 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.
Nor can the GenericIndex. I see no difference here.
> 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.
Again, using what we have does not allow such extended system to be 
initialized in any better way. And, yes, I have in mind the dynamic 
extension of the system (more specifically thinking about HBase index 
and Oracle Index here)
> 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.
What brute force approach are you talking about ?

My point is that defining a class called GenericIndex inheriting the 
Index interface, but having *all* the methods throwing a 
UnsupportedOperationException is just bad design.

I'm also saying that having a convertAndInit is just useless : it takes 
the base informations we have put into the GenericIndex object (which 
does not hold anything more than what we have in the IndexBean, and in 
fact, it contains less parameter), and initialize the index the way it 
should be considering the Index type. How is it different with calling 
the Index constructor passing the IndexBean containing the configurtion 
for this index, and then the init() method ?

In any case, if someone want to define a different kind of Partition, 
which a specific kind of Index, having some specific configuration which 
are not supported currently, then it's not an issue :
- the implementer will have to define a new OC describing the parameters 
as AT.
- he will also have to extend the IndexBean class to fit this new 
- the configReader will feed this newly created configuration class 
based on the newly defined OC
- then this bean will be passed to his new Store which will be able to 
initialize the index as needed.

Base line : the core server code won't have to be changed, as all is 
already written to support such extensions.

If we don't do that, then we are forced to modify the GenericIndex to 
accept the new parameters, which in a way is a brute force approach. 
Plus it's a duplicated effort, because you still have to write your own 
version of the Bean.

There is only one remaining issue atm : the @ used to write unit tests 
have to benefit from this approach (should not be an issue, as soon as 
the @ tells which is the index type).

Emmanuel Lécharny

View raw message