Hi, I have made the changes to use UUID for ID. I have also removed some unnecessary type parameters. In particular, master table is not generic anymore. For index and index cursors, only value type is a generic parameter. Search engine and partitions and tests are changes accordingly. Note that counter maintained for ID generation in Btree partitions are not necessary anymore. Also, admin table for Jdbm parition is removed. One thing I noticed in the tests were implicit assumption of master table and indices with the key ID having the same order as the insertion order of entries. This assumption is not valid anymore as UUID generation is random.
There is one outstanding issue. Attribute types for system indices having UUID as the key has integer comparator as their ordering rule in the LDAP attribute type definition. This should be changed to use UUID ldap comparator. This is not done yet as I dont know how to do it. Instead, we check for specific attribute types during index initializations and use UUID comparator if necessary. Currently all tests are passing. regards, Selcuk On Fri, Nov 4, 2011 at 9:02 PM, Stefan Seelmann <[email protected]> wrote: > On Fri, Nov 4, 2011 at 9: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. > > +1 to the 2nd option. > > I introduced the generid <ID> two years ago [1] while I as was > implementing the HBase partition prototype. Prior to that the ID was a > Long which didn't work well with HBase. Now that we all agree that > UUID should be used I see no reason why the generic ID should be kept. > > Kind Regards, > Stefan > > [1] https://issues.apache.org/jira/browse/DIRSERVER-1472 >
