[Cosmo-dev] object identity in cosmo

Randy Letness rletness at gmail.com
Thu Sep 14 20:40:53 PDT 2006


On 9/14/06, Brian Moseley <bcm at osafoundation.org> wrote:

> the suggested solution is to assign ids when objects are instantiated
> rather than waiting for them to be saved for the first time by
> hibernate. we could use the java.util.UUID class (added in java 1.5 -
> somehow i missed it!) to do this. we wouldn't have to depend on our
> database implementing sequences or anything like it. and then we could
> get rid of Item.uid since Item.id would already by definition be
> globally unique.
>

One thing to think about is that Item.id is the primary key, so it is
going to be stored in a bunch of other tables (attribute/cal_prop_index/etc)
as a foreign key.  If this is changed to varchar(128), which I think is
what the current uid field is set to, then that means that much more
data (vs 4 or 8 byte integers) will be stored in each row.  There might
be performance implications when doing joins using varchar uids vs
integer ids.  Something to investigate.

What about keeping the id, and uid, but just use uid in equals()
and hashCode()?

-Randy


More information about the cosmo-dev mailing list