On Sun, Oct 31, 2010 at 11:11 PM, Emmanuel Lécharny <email@example.com>
A POJO, if you prefer. It holds some value, but does not have any logic inside. A Bean. A container.
On 10/31/10 9:54 PM, Alex Karasulu wrote:
On Sun, Oct 31, 2010 at 6:42 PM, Emmanuel Lecharny<firstname.lastname@example.org>wrote:
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
What's a holder class?
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.