Ryan, yes, you stumbled across a limitation of the abstract data model specified in EJB 2.0, i.e. the lack of support for relationship attributes, which IMHO is a real shame because I have encountered relationship attributes in almost every real life data model in projects I have been a part of. There is no clean solution for this but a few workarounds. You could extend your CMP entity beans and put some SQL there to manipulate the relationship attributes from either side of the relationship or from a home method (both not pretty) or you could both model the n-m relationship with standard CMP means and in addition to that model the link table as an entity for manipulating the relationship attributes. however, you must be very careful with that because then you can manipulate the relationship (by creating entities of that type or removing them) without giving the CMP engine in your container a chance of noticing which micht give you inconsistent cached values (also messy). You could of course do a mixture of both and only use the link table entity from home methods (or the relationship attribute manipulation methods from the two related entities) to avoid SQL and protect yourself from your own errors just a little bit by not exp�osing the home interface to any other part of the application than the entities that implement those manipulation methods (it's no real protection of course).
I would like to hear the spec author's opinion on why no relationship attributes are addressed (and still aren't planned to be addressed in future developments in the recently released draft). I posted a comment related to that when 2.0 was final but got no response. Hope this helps somewhat, Robert On Sunday 30 June 2002 17:00, you wrote: > Hello all, > > I'm coming across a little problem. In my database design I have the > following tables: > > PROPOSAL is linked to PROPOSAL_ROLE by 1-M > PROPOSAL_ROLE is linked to USER by M-1. > > Therefore PROPOSAL_ROLE is used as a join table that will link the two > other tables. This is used because a user can play a certain role on many > different proposals, and a proposal can have many users that it's involved > with. > > I've currently implemented the PROPOSAL_ROLE table as ProposalRole CMP > Entity bean and specified the above relationships in ejb-jar.xml, but I'm > looking at another example using WebLogic 6.1, and in the file > weblogic-cmp-rdbms-jar.xml, they are specifiying the join table > relationships and NOT creating a CMP entity bean for the join table, but > instead just specifying the MANY-TO-MANY relationships between the two > beans in ejb-jar.xml. Therefore in my example the proposal bean would > proposal.getUsers(), and the user bean would have user.getProposals(). This > way I would not have to model the ProposalRole as an entity bean with > getProposal() and getUser() methods, rather this would happen "behind the > scenes." However, in my join table PROPOSAL_ROLE, I am storing two other > fields that are important in recognizing the particular relationship. I've > included a "role" and "effort percent" column that give particular data > about the relationship that a user has with a particular proposal in the > system. So I can see why I would want to have a ProposalRoleBean in this > case to be able to access that data. > > I guess what I'm really asking is this: Do all JOIN tables have to modeled > as CMP Entity beans if the table in itself contains columns of data on top > of just storing the two foreign keys of the other two linked tables? Also, > how does one specify the links between the join table and the two other > tables in Resin (similar to how weblogic-cmp-rdbms-jar.xml does it)? > > Thanks for any suggestions! > Ryan LeCompte > [EMAIL PROTECTED] > http://www.louisiana.edu/~rml7669 =========================================================================== To unsubscribe, send email to [EMAIL PROTECTED] and include in the body of the message "signoff EJB-INTEREST". For general help, send email to [EMAIL PROTECTED] and include in the body of the message "help".
