Return-Path: X-Original-To: apmail-directory-dev-archive@www.apache.org Delivered-To: apmail-directory-dev-archive@www.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id 6716996D7 for ; Fri, 4 Nov 2011 10:48:55 +0000 (UTC) Received: (qmail 16153 invoked by uid 500); 4 Nov 2011 10:48:55 -0000 Delivered-To: apmail-directory-dev-archive@directory.apache.org Received: (qmail 16109 invoked by uid 500); 4 Nov 2011 10:48:55 -0000 Mailing-List: contact dev-help@directory.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: "Apache Directory Developers List" Delivered-To: mailing list dev@directory.apache.org Received: (qmail 16099 invoked by uid 99); 4 Nov 2011 10:48:55 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 04 Nov 2011 10:48:55 +0000 X-ASF-Spam-Status: No, hits=1.5 required=5.0 tests=FREEMAIL_FROM,HTML_MESSAGE,RCVD_IN_DNSWL_LOW,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (nike.apache.org: domain of pajbam@gmail.com designates 74.125.82.44 as permitted sender) Received: from [74.125.82.44] (HELO mail-ww0-f44.google.com) (74.125.82.44) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 04 Nov 2011 10:48:47 +0000 Received: by wwi36 with SMTP id 36so3276785wwi.1 for ; Fri, 04 Nov 2011 03:48:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=sender:from:mime-version:content-type:subject:date:in-reply-to:to :references:message-id:x-mailer; bh=txkirquti6VuTHFtTESjneUPIWPV3XmonEB8HonQWDc=; b=ERnK3oFapL5n8i5Tfiq5PRM03zffvE10lbDTpPjzmoriAVZ1uNFyhyQQgHexDYPhq0 t1G2CGQ5N32D+YuY6RuIsoduQm+ZYZAbD901oj9AXC9kZueeZ9xEXpEn5/HjzknekvcB QrC5eS1ehb0Xt0PHg8a8Zizy6HoDYnGl0lpL8= Received: by 10.180.92.169 with SMTP id cn9mr445567wib.62.1320403706105; Fri, 04 Nov 2011 03:48:26 -0700 (PDT) Received: from [192.168.0.12] (lon92-10-78-226-4-211.fbx.proxad.net. [78.226.4.211]) by mx.google.com with ESMTPS id t5sm243182wif.14.2011.11.04.03.48.23 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 04 Nov 2011 03:48:24 -0700 (PDT) Sender: Pierre-Arnaud Marcelot From: Pierre-Arnaud Marcelot Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: multipart/alternative; boundary=Apple-Mail-4-646602443 Subject: Re: TXN work update Date: Fri, 4 Nov 2011 11:48:22 +0100 In-Reply-To: To: "Apache Directory Developers List" References: <4EAFFDAE.5030107@gmail.com> <4EB2B8A7.70307@gmail.com> Message-Id: <38052D59-56BF-436E-9E67-10CFC6FD9109@marcelot.net> X-Mailer: Apple Mail (2.1084) X-Virus-Checked: Checked by ClamAV on apache.org --Apple-Mail-4-646602443 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 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? >=20 > (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?=20 > (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.=20 +1 Although I like Generics a lot, it makes probably more sense to avoid = them here in this particular context. Regards, Pierre-Arnaud >=20 > Regards, > Alex >=20 > On Fri, Nov 4, 2011 at 10:12 AM, Selcuk AYA = 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 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 >=20 > 2) Use UUID all over rather than generics. Basically get rid of > generic ID type. Change search engine to use UUID as well. >=20 >=20 > 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. >=20 > regards, > Selcuk >=20 > On Thu, Nov 3, 2011 at 5:52 PM, Emmanuel Lecharny = wrote: > > On 11/3/11 4:44 PM, Selcuk AYA wrote: > >> > >> On Wed, Nov 2, 2011 at 12:15 PM, Alex = Karasulu > >> wrote: > >>> > >>> On Wed, Nov 2, 2011 at 10:12 AM, Selcuk AYA = 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 and index tables = in a > >> similar way > >> *or I can paratmetrize partition interface like Partition . = They > >> can return master table as 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=E9charny > > www.iktek.com > > > > >=20 >=20 >=20 > --=20 > Best Regards, > -- Alex >=20 --Apple-Mail-4-646602443 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=iso-8859-1
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=E9charny
> www.iktek.com
>
>



-- =
Best Regards,
-- Alex


= --Apple-Mail-4-646602443--