[Cosmo-dev] object identity in cosmo

[Bobby Rullo]

Good stuff. You're killing several birds with one stone here:

	a) The whole problem of identity of objects that have not been  
persisted yet
	b) This could help us out a lot of we have several different  
database instances - we won't have to worry about colliding sequences  
or anything

and potentially

	c) I notice right now that Item's have at least two and sometimes  
three ID fields:
			1) The database ID
			2) The Item UID
			3) The VEVENT UID

I know we can't collapse the third into the first two, since the  
VEVENT UID is something the client gets to choose. But do we really  
need 1 and 2? Could we combine them, and if so would this help?

bobby

On Sep 14, 2006, at 5:47 PM, Brian Moseley wrote:

> good onjava article yesterday on object identity with hibernate:
>
> <http://redirx.com/?7zd8>
> <http://www.onjava.com/pub/a/onjava/2006/09/13/dont-let-hibernate- 
> steal-your-identity.html?CMP=OTC-FP2116136014&ATT=Don+t+Let 
> +Hibernate+Steal+Your+Identity>
>
> the basic assertion is that the equals and hashCode methods on
> persistent hibernate objects don't usually work right because they
> typically depend on an object id that hasn't yet been assigned by the
> database. this can cause problems especially when these objects are
> added to collections.
>
> 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.
>
> thoughts?
> _______________________________________________
> cosmo-dev mailing list
> cosmo-dev at lists.osafoundation.org
> http://lists.osafoundation.org/mailman/listinfo/cosmo-dev