On 4 nov. 2011, at 10:24, Alex Karasulu wrote:

I vote for the second option and to get rid of Generics on these interfaces. Why?

(1) We need to go to UUIDs since we will soon be living in a replicated world and there's no point to a partition specific id.
(2) We can still do (1) with a Long but why bother? 
(3) Using a UUID as the PK for entries gets rid of the need for the UUID index since the master automatically becomes the UUID index.
(4) Generics have made everything way too complex in this region of the code and I do not foresee a need to use anything else at this point in time. If the need arises we can consider it after everything is working ... a simple maneuver/re-factoring. 

+1

Although I like Generics a lot, it makes probably more sense to avoid them here in this particular context.

Regards,
Pierre-Arnaud



Regards,
Alex

On Fri, Nov 4, 2011 at 10:12 AM, Selcuk AYA <ayaselcuk@gmail.com> wrote:
I discussed using generics for ID with Emmanuel a little more. The
related change is mostly mechanical but it is a big change so I would
like to see if people have any opinion. Remember that alongside with
transaction changes, we are going towards a generic transactional
modification layer on top of partitions and a transactional search
engine that can work with any partition. Default search engine
achieves what we want in this sense but it works with Store interface
rather than Partition interface. Default Search Engine is designed to
work with generic ID. Store interface also uses generic ID. Now, if we
want to move DefaultSearchEngine to core and want it to work with
Partition interfaces, we have to options:
1)Make partition interface parametrized too. Change it to
Partition<ID> and make it expose master tables and indices using
generic ID. DefaultSearch engine can currently work with such an
interface. We will also make the transactional modification layer use
this parametrized interface.We will also need to implement partitions
using the generic  ID type rather than Long or UUID

2) Use UUID all over rather than generics. Basically get rid of
generic ID type. Change search engine to use UUID as well.


First option has the flexibility of changing ID to a different type
but I am not sure it makes sense to change the ID from release to
release. I am inclined to go with the second option at the moment.

regards,
Selcuk

On Thu, Nov 3, 2011 at 5:52 PM, Emmanuel Lecharny <elecharny@gmail.com> wrote:
> On 11/3/11 4:44 PM, Selcuk AYA wrote:
>>
>> On Wed, Nov 2, 2011 at 12:15 PM, Alex Karasulu<akarasulu@apache.org>
>>  wrote:
>>>
>>> On Wed, Nov 2, 2011 at 10:12 AM, Selcuk AYA<ayaselcuk@gmail.com>  wrote:
>>>>
>>>> Hi,
>>>> a few points and questions:
>>>> *I am planning to use a common ID for all partitions. I checked Hbase
>>>> partition and it uses UUID as the ID. Is it ok to use this for all
>>>> partitions?
>>>>
>>> This great and something we wanted to do for a very long time as Emmanuel
>>> stated.
>>
>> I am working on JDBM and AVL partitions to make them usee UUID. Also I
>> am making partitions expose their master tabe and indices. For making
>> all partitions use UUID:
>> * I can  change partitions to work with UUID directly  and make them
>> return master tables as MasterTable<Entry,UUID>  and index tables in a
>> similar way
>> *or I can paratmetrize partition interface like Partition<ID>  . They
>> can return master table as<MasterTable,ID>  and index tables in a
>> similar way. This is looks to me the right way but it eventually leads
>> to more changes.
>>
>> which one do you think is better?
>
> Let's not use generic when it's not needed...
>
>
> --
> Regards,
> Cordialement,
> Emmanuel Lécharny
> www.iktek.com
>
>



--
Best Regards,
-- Alex