Why user id and item id must be long type ?

[Jeff Zhang <zj...@gmail.com>]

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

Re: Why user id and item id must be long type ?

[Sean Owen <sr...@gmail.com>]

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 <zj...@gmail.com> 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
>

Re: Why user id and item id must be long type ?

[Sean Owen <sr...@gmail.com>]

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 <zj...@gmail.com> 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
>

Re: Why user id and item id must be long type ?

[Gökhan Çapan <gk...@gmail.com>]

That is one of the important changes in Mahout 0.2. Now the Taste framework
operate only on long id values.
Sean will reply your post better,
but I think that change is about performance issues.

And I know Taste is able to migrate String ids to long ones, you can find
related interfaces and classes under the package
org.apache.mahout.cf.taste.model, and org.apache.mahout.cf.taste.impl.model

On Wed, Nov 18, 2009 at 9:40 AM, Jeff Zhang <zj...@gmail.com> 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
>



-- 
Gökhan Çapan