Yeah it's a good question. Older versions let you use any Comparable as a key. The problem was memory and performance. Using objects was just very expensive. This change improved memory requirements and speed by 3-4x. But yes it is limiting.
You can still use string keys, but will need to do some work to 'translate' back and forth, and that will slow things down a little. Look at the IDMigrator class. This will manage translation to and from your own object keys. If you want to pursue this let me know because it takes a little bit of work. You'll have to subclass standard DataModel implementations to stick in this translation at key places, so that it too can translate your data appropriately. On Wed, Nov 18, 2009 at 7:40 AM, Jeff Zhang <[email protected]> wrote: > Hi all, > > I'd like to integrate taste to our system. Unfortunately I found that > Taste's DataModel require me using long type as user id and item id. > > I don't thinkg it make sence to enforce user use long type as id. String > type will be more extensible and flexible. Because sometimes user use email > address as id or other times use uuid as user id. > > > Thank you. > > Jeff Zhang >
