Hi

"Java Persistence with Hibernate", page 161:

"You'll often find this kind of mixed behavior; however, your first reaction should be to make everyting a value-typed class and promote it to an entity only when absolutely necessary."

Would anyone care to provide more details on why this is true?

In my experience, this seems fairly odd. For instance, I have a child object with lots of data, and its existence depends on the parent object, making it a perfect candidate for value-type. However, I wanted to persist it in a secondary table, and it seems that in order to do so, I would have to use @AttributeOverride for every element of the child object to embed it in the parent, which is simply horrible to manage. This is also done in the CaveatEmptor example, in the relationship User to BillingAddress. Is there a better way to achieve this?

Thanks
Andre

er, for those of us (like me) who don't have the book/article, could you pls clarify what they mean by "value typed"?
thanks.

From the book:

"An object of entity type has its own database identity (primary key value). An object reference to an entity instance is persisted as a reference in the database (a foreign key value). An entity has its own lifecycle; it may exist independently of any other entity. Examples in CaveatEmptor are User, Item and Category."

"An object of value type has no database identity; it belongs to an entity instance and its persistent state is embedded in the table row of the owning entity. Value types don't have identifiers or identifier properties. The lifespan of a value type instance is bounded by the lifespan of the owning entity instance. A value type doesn't support shared references: if two users live in the same apartment, they each have a reference to their own homeAddress instance. The most obvious value types are classes like Strings and Integers, but all JDK clases are considered value types. User-defined classes can also be mapped as value types; for example, CaveatEmptor has Address and MonetaryAmount."

I have a question: why do you try to make your child a value type in the parent? In case for 1:n relationship, wouldn't it make a lot more sense to let children exist in their own table? The lifecycle dependency can be acheived in other ways, such as deletion cascading.

Yes, I'm aware of that, in fact that's how I implemented my relationships, everything works fine, but that does not agree with the book, so I wanted to know why.

I was talking of a 1:1 relationship (say Parent has only one Child) where Child cannot exist without the Parent. At the same time, I want Child to be represented in its own table. It seems the way to do it is to use @AttributeOverride and @AssociationOverride in every element of Child as it is embedded in the Parent. Why can't I just say "the Child is in this table" ?

Since I don't know the discussed chapter in the book, I cannot argue for/against it, however, I do know that I use 1:1 relationship, where the "child" is in its own table, separate from the parent, and it works great. Initially I had some issues with that, but I resolved them. See my following post:
http://forum.hibernate.org/viewtopic.php?t=985898
You may "project" this information onto .hbm files instead of annotations, if needed.

As per my understanding : mapping one-to-one can be tricky at times.

<one-to-one> can be mapped by 2 types :

a) on the basis of primary key
b) on the basis of foreign key

If you think the child is of value type and can not exist independently, it makes sense to have it in the same table as of the parent i.e. value type.

But lets assume, if the child has got huge data and if it is not mandatory that a parent would have a child always, then it makes sense to have Child mapped in its own table otherwise all the child columns would be empty in the parent table. Which might not be a good approach.


But even mapping a child (of value type) in its own table could be done using one-to-one foreign key concept.