You can use the low-order bits, or have a look at what the UUID class does to hash itself to 32 bits in hashCode() and emulate that for 64 bits. Collisions in a 64-bit space are very very very rare, enough to not care about here by a wide margin. A collision only means you confuse prefs from two users -- it still mostly works anyway.
Yes keys were originally Comparable. It was just too much memory / performance overhead. Instead, you can use a mapping to/from 64-bit values. See IDMigrator for instance. On Mon, Apr 8, 2013 at 3:51 AM, Phoenix Bai <baizh...@gmail.com> wrote: > Hi All, > > the input format required for mahout recommender is : > > *userId (long), itemId (long), rating (optional)* > > while, currently, my input format is: > > *userId (UUID, which is 128bit long), itemId (long), boolean* > > so, my question is, how could I convert userId in UUID format to long > datatype? > e.g. how to map value like "*550e8400-e29b-41d4-a716-446655440000*" to long > datatype? > > My current solution is to convert it to java UUID instance and extract the > least significant bits and use it as long type userId. > But I am worried about the collision that is not supposed to exist with > uuid. > > I am wondering two things: > 1) if the collision is low, could I use above approach? what`s the possible > pros and cons? > 2) is it possible to change or extend Preference class to modify userId to > String datatype? is it feasible? > > thanks
