directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alex Karasulu <akaras...@apache.org>
Subject Re: TXN work update
Date Fri, 04 Nov 2011 09:24:01 GMT
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.

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

Mime
View raw message