I was wondering if it is possible to have a concatenated primary key for an entity bean where part of the primary key is a reference to another entity via CMR in the same bean?
For example, imagine I have a bean called HouseBean, and I have another bean called PartyBean. A house can host zero or more parties. However, a party must have at least one house (one to many relationship). A party is unique based on a party date and for the house it is held at. The tables look as follows:
HouseBean is simple enough to create. It has a CMR relationship to PartyBean on the many side.
PartyBean on the otherhand gets a little more tricky. PartyBean theoretically participates in a CMR relationship with HouseBean. And PartyBean's uniqueness is enforced by a concatenated primary key consisting of a start date and the house ID that the party is being held at in the database.
Can I create a primary key class consisting of a start date and a house ID, but not define the houseId as a persistent field in the PartyBean and define it as a CMR to HouseBean instead? If so, how do I get the database to recognize that the houseId from the HouseBean CMR is part of the primary key?
I am not sure this is possible to do? Any suggested references that illustrate the solution to this problem is more than welcome!
All fields in the primary key class must be declared as public. The names of the fields in the primary key class must be a subset of the names of the container-managed fields. (This allows the container to extract the primary key fields from an instance�s container-managed fields, and vice versa.)
So, it�s not allowed to have an PK with an CMR field. In this case, you should party_date and house_id and not the entity house.
Interesting situation. But in the case you have mentioned House_ID would be a CMP in the House Bean and Party Date would be a CMP in Party Bean. So why can't we make a combination of these as a primary key. I don't think it is mentioned in the specs that the primary key has to a CMP of the same Bean. I may be wrong as I have never encountered this situation practically.