On 10/31/10 10:38 PM, Alex Karasulu wrote:
On Sun, Oct 31, 2010 at 11:11 PM, Emmanuel Lécharny<[email protected]>wrote:
On 10/31/10 9:54 PM, Alex Karasulu wrote:
On Sun, Oct 31, 2010 at 6:42 PM, Emmanuel Lecharny<[email protected]
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
configurtion
- 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).
--
Regards,
Cordialement,
Emmanuel Lécharny
www.iktek.com
