[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