parent/child Vs. component

[Sandeep Vaid]

In the book "Hibernate In Action"

They define Item -> Bid as one-to-many relationship WHILE
User -> Address as composition (component)

Why we can't make Bid as component of Item entity ?

What's the exact criteria for a class to become a component of other entity ?

As far as i have understood, the difference between a parent/child relationship and a component is that the in parent/child, child may be loaded individually or referenced directly by another entity while in component, it can't be shared (as it don't have its own identity).

Also on page 134 - It's mentioned :

A bid, for example, may be loaded and manipulated without retrieving the owning
item. It may be stored without storing the owning item at the same time. Furthermore,
we reference the same Bid instance in a second property of Item, the single
successfulBid (see figure 3.2, page 63).

In what scenario, Bid be loaded and manipulated without retrieving the owning item ?

[Mark Spritzler]

Well the issue with bid, is that it is a many to one relationship with Item, so if can't be a component. Also, bid does have its own identity in its own database table. As a user I make bids, so bids is also related to User, but again not a part of User.

Also think of the distinction between Composition and Association in OO, it really is that same distinction.

Mark

[Sandeep Vaid]

So Do you mean that we can have component(composition) when there is only one-to-one relationship. (User->Address)

and where there is one -> many relationship we need to use the collection of value-types instances.

Is my understanding correct ?

[Mark Spritzler]

No, composition is not a "one-to-one" relationship in the database, it most likely will be in the object world.

See, here is one of the mismatches that ORM tools try to resolve. In the object world we have associations and compositions (not even going to mention aggrevation er aggregation). There is no such concept in the database world, So we might have a database table that has user information including their address, but in the object world we want two seperate objects, a User object and an Address object, and Address is dependent on the User object being in existence, that is composition and what was being explained as a "component"

Hope that helps.

Mark

[Sandeep Vaid]

Originally posted by Sandeep Vaid:
So Do you mean that we can have component(composition) when there is only one-to-one relationship. (User->Address)

and where there is one -> many relationship we need to use the collection of value-types instances.

Is my understanding correct ?

Mark, I know what you have explained. I think my original question didn't conveyed the meaning properly. I was talking in terms of Object Oriented terms only(and not database). Let me put my question in other words :

In OO, when we have 1-1 relationship between entities + one entity (User) is responsible for life-cycle of the other entity (Address) + The other entity(Address) is not shared, then this is the case of composition(component)
BUT
where there is one-to-many relationship between entities (e.q Item - Images) we can't use composition here (as entities don't have 1-1 relationship here), we need to use the collection of value-types instances.

[Mark Spritzler]

Yep, that is eactly right, how you put it. For one-to-many it is a collection value-types.

Mark