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 <[email protected]> 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 <[email protected]> wrote: > > On 11/3/11 4:44 PM, Selcuk AYA wrote: > >> > >> On Wed, Nov 2, 2011 at 12:15 PM, Alex Karasulu<[email protected]> > >> wrote: > >>> > >>> On Wed, Nov 2, 2011 at 10:12 AM, Selcuk AYA<[email protected]> 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 >
