CMR

[Deepa Malhotra]

Lets say I have Person entity bean and Credit card entity bean. I'm defining a 1:* relationship between them.
Lets say the current status in my appln is Person A has 5 credit cards and Person B has 3 credit cards. Where is this info stored. What happens when I move my appln to another container. How is this info not lost?

[Rufus BugleWeed]

The beans ( Person CreditCard ) are stored in the data store, Oracle, DB2 or some other. If you want to move to another container say from JBoss to Websphere you have to migrate the beans and the datastore.

[Rashmi Tambe]

Entity Beans only represent the underlying data...u can think of them as object oriented wrapper on the data. so they do no store any data themselves, so there is no question of getting data lost from one container to another.
When u say one person has * credit cards, this relationship must be existing in your underlying database.

[Deepa Malhotra]

Thanks Rashmi,
I know I'm kind of confused on this. Are you saying that if the Persons Table and Credit Card table do not have a foreign key constraint, the corresponding entity beans can not have a relationship??

[David Harkness]

Originally posted by Deepa Malhotra:
Are you saying that if the Persons Table and Credit Card table do not have a foreign key constraint, the corresponding entity beans can not have a relationship??

No, a constraint is not necessary (but still advisable). You simply need the same things you'd need to perform a join in SQL between your tables: a foreign key. As long as your credit_card table has a person_id you can create an EJB relationship between them. Whether or not you denote this in the database with an actual constraint is up to you.

[Rashmi Tambe]

Originally posted by Deepa Malhotra:
Thanks Rashmi,
I know I'm kind of confused on this. Are you saying that if the Persons Table and Credit Card table do not have a foreign key constraint, the corresponding entity beans can not have a relationship??

You cannot define CMR if you dont have underlying foreign key relationship in the databse table. This is becaue you need to specify the foreign key field name in the deployment descriptor.
For e.g. In case on entity beans deployed on weblogic, u need to spcify this in weblogic-cmp-rdbms-jar.xml file.
So If there is not relationship between credit card and person table, u can not define CMR between them. Moderators, correct me if i am wrong.

[Lasse Koskela]

I believe it is not strictly required that the actual database schema has foreign key constraints (i.e. it is enough to declare in your deployment descriptor that column A contains a reference to table B, but it doesn't have to be enforced by the database).

[Deepa Malhotra]

I did some research and here is what I think:
Lets say you have two tables that do not have any common columns. Create your entity beans. After this, if you establish a CMR between these beans, the container automatically creates a new table with necessary columns that can serve as a link between the original two tables.
Expert opinion please!

[Pradeep bhatt]

the container automatically creates a new table with necessary columns that can serve as a link between the original two tables.

The container may create tables during deployment(varies from vendor to another) but you will need to specify the structure of table.

[David Harkness]

Originally posted by Rashmi Tambe:
You cannot define CMR if you dont have underlying foreign key relationship in the databse table. This is becaue you need to specify the foreign key field name in the deployment descriptor.

Keep in mind that three levels to a relationship between two entities (at least off the top of my head):

The logical concept of the relationship: A Person has zero or more CreditCards.

The physical column definitions: The CREDIT_CARD table has a column called PERSON_ID with the same type as PERSON.ID, and where those values are equal, we say the rows are related.

A database-enforced foreign key constraint: [Oracle] CREDIT_CARD.PERSON_ID references PERSON.ID (the PK).

A CMR requires only the second level -- the same requirement of performing a SQL join, which the CMR effectively does. Defining a foreign key constraint is not necessary, but it's still a good practice, especially if the database is acted upon by other tools that bypass the EJB layer.

[Vishwa Kumba]

One of the advantages of EJB2.0 is that the abstract persistence schema(relationships defined by the participating entity beans) can be different from the underlying database schema.
For example: the One-to-Many uni-directional relationship between Customer and Address tables.
At the database level, it is usually the Address table that has the foreign-key to the Customer table.
At the EJB level, it is the Customer EJB that has a CMR(collection) field to the Address EJB.

[Rashmi Tambe]

The physical column definitions: The CREDIT_CARD table has a column called PERSON_ID with the same type as PERSON.ID, and where those values are equal, we say the rows are related.
I think, what david says is correct. The above requirement is necessay. However, the foriegn key is not. thanks David.