On 10/14/03 9:29 AM, "Hugh Allen" <[EMAIL PROTECTED]> wrote:
> Been working for too long on trying to set up a uni-directional one-to-many > container managed relationship that will persist the relationship using a > database foreign key. Hoping to get some help from the JUG. > > I am using J2EE Reference Implementation version 1.3.1. My search for good > sample code has turned up very few examples that explain uni-directional > one-to-many relationships, even though I expect that this is a very common > type of relationship. The best example of one-to-many relationships I can find > is the Parts-Suppliers example from the SunOne App Server. There are also some > good examples at www.caucho.com <http://www.caucho.com/> , but they have > proprietary extensions in their container that allow you to specify a SQL > table and column - this appears to do exactly what I need in J2EE, but can't > find how to accomplish it. > > So umm, since I work for JBoss Group, and I haven't used SunOne since it was called iPlanet (and more experience when it was called Netscape Application Server)... I'll answer your questions in regards to the container I know best. Please don't think I'm being salesy, its just I'm speaking to what I know. Besides, the other vendors will pipe up once I do this ;-) Maybe I'm your huckleberry. Here is an example: http://www.onjava.com/pub/a/onjava/2001/09/19/ejbql.html > > > In any case, I have lots of working code, but it doesn't behave as expected. I > have JSPs communicating with a Stateless Session Bean communicating with two > CMP2.0 Entity Beans. Backend Database is MySql. > > My application involves 2 very simple database tables with container managed > persistent fields: > > 1) evalform table (An evaluation form containing questions): > > CREATE TABLE evalformBeanTable > ( evalform_id VARCHAR(8) PRIMARY KEY, > evalform_name VARCHAR(30), > ); > > 2) evalformquestion table (The questions related to the evaluation form): > > CREATE TABLE evalformquestionBeanTable > ( evalformquestion_id VARCHAR(17) PRIMARY KEY, > evalform VARCHAR(8), [This is the FOREIGN KEY that refers to > evalform PK] > evalformquestion_question_id VARCHAR(8), > evalformquestion_text VARCHAR(120), > ); > > The problem is this: > > J2EE RI doesn't seem to recognize that I want to have the relationship > persisted via the FOREIGN key in the evalformquestion table. Instead, J2EE is > creating a SEPARATE database table to store the relationship data. > Correct, this is vendor specific. In JBoss it goes in your jbosscmp-jdbc.xml like so: <ejb-relation> <ejb-relation-name>Parent-Child</ejb-relation-name> <foreign-key-mapping/> <ejb-relationship-role> <ejb-relationship-role-name>Parent-has-Children</ejb-relationship-role -name> <key-fields> <key-field> <field-name>id</field-name> <column-name>parentid</column-name> </key-field> </key-fields> </ejb-relationship-role> <ejb-relationship-role> <ejb-relationship-role-name>Child-of-Parent</ejb-relationship-role-nam e> <key-fields/> </ejb-relationship-role> </ejb-relation> Now by default in JBoss there is no middle table. You can turn that on, but we use the Table-Table mapping by default. I don't think this is in the specification and I think its up to each vendor to determine what the default behavior is. Now don't get Unidirectional relationships mixed up with the table mapping. It has to do with whether Child can look up Parent and so forth. Not how its mapped in the DB. > Is there a way I can tell J2EE to use the foreign key, rather than creating a > new table? > No, this is up to each vendor. I had thought the Table->Table was specified, but *shrug*. > Below is deployment descriptor for the relationship. I realize that this > really indicates a BI-directional, rather than uni-directional relationship. > However, it seems I really need both CMR fields, even though I think of the > relationship as uni-directional: So you mean to say that you DON�T need a unidirectional relationship, but you need a normal table mapping. Is that right? In jboss the non-relation-table mapping is default and you have to over-ride it like so: Jbosscmp-jdbc.xml (peer to ejb-jar.xml) <ejb-relation> <ejb-relation-name>Product-ProductCategory</ejb-relation-name> <relation-table-mapping> <table-name>PRODUCT_CATEGORY</table-name> <datasource>java:/DefaultDS</datasource> <datasource-mapping>Hypersonic SQL</datasource-mapping> <create-table>true</create-table> <remove-table>false</remove-table> <row-locking>false</row-locking> <pk-constraint>false</pk-constraint> </relation-table-mapping> ..snip.. I might point out that if you need to support multiple appservers (assuming since you talk about targeting J2EE specifically and two other appservers), XDoclet might be your best solution. (http://xdoclet.sf.net). Its generally not possible to create a high-performance, scalable application using just what is available in the J2EE spec. I think IBM and BEA folks monitoring this list will agree with me on this point. The fact is that the spec specifies two commit semantics "cache everything" and "cache nothing" aka "dumb" and "dumber". This isn't a big deal, because nearly every J2EE container has ways to do it and mostly via your descriptors. With XDoclet, you can include tags for each container you're targeting and the relevant code/descriptor is generated. Meaning you write once and Ant writes everywhere. Granted it has all of the disadvantages of a pre-processor (it is a preprocessor) but I personally find all of the EJB descriptors overwhelming otherwise. All of the above examples are from one of two places: The Jboss testsuite (Junit tests for jboss) in the "testsuite" directory from the main JBoss 3.2 branch. ( grab the source from http://sf.net/projects/jboss) Or from the j2ee-intro or advanced training. (Again not trying to be salesy, but since I've been marching up and down the country teaching showing that slide, its what comes to mind first). > - need the collection side so that I can request all the questions related to > the evalform > - also need the String CMR field for the evalform foreign key - otherwise how > will the container know which database field contains the FK? > > <relationships> > <ejb-relation> > > <ejb-relationship-name>Evalform-EvalformQuestion</ejb-relationship-name> > > <ejb-relationship-role> > > <ejb-relationship-role-name>Evalform-has-EvalformQuestions</ejb-relationship-r > ole-name> > <multiplicity>One</multiplicity> > > <relationship-role-source><ejb-name>EvalformEJB</ejb-name></relationship-role- > source> > > <cmr-field> > <cmr-field-name>evalformquestions</cmr-field-name> > <cmr-field-type>java.util.Collection</cmr-field-type> > </cmr-field> > > </ejb-relationship-role> > > <ejb-relationship-role> > > <ejb-relationship-role-name>EvalformQuestions-belong-to-Evalform</ejb-relation > ship-role-name> > <multiplicity>Many</multiplicity> > <cascade-delete/> > > <relationship-role-source><ejb-name>EvalformQuestionEJB</ejb-name></relationsh > ip-role-source> > > <cmr-field> > <cmr-field-name>evalform</cmr-field-name> > </cmr-field> > > </ejb-relationship-role> > > </ejb-relation> > </relationships> > So again, there is no J2EE way to map fields to the database, each vendor has their own proprietary descriptor which relates to their persistence engine. I can tell you how jboss does it... Secondly, the default behavior is usually to let the container create the table, hence there is no need to map it. Unfortunately the container will use cracked database naming conventions so most of the time you will end up overriding it. Anyhow, hopefully this points you in the right direction. Sorry if I'm latent...I'm home this week and then I go off traveling again. -andy > Any help is appreciated. > > Thanks, Hugh > > > > _______________________________________________ > Juglist mailing list > [EMAIL PROTECTED] > http://trijug.org/mailman/listinfo/juglist_trijug.org > -- Andrew C. Oliver http://www.superlinksoftware.com/poi.jsp Custom enhancements and Commercial Implementation for Jakarta POI http://jakarta.apache.org/poi For Java and Excel, Got POI? The views expressed in this email are those of the author and are almost definitely not shared by the Apache Software Foundation, its board or its general membership. In fact they probably most definitively disagree with everything espoused in the above email. _______________________________________________ Juglist mailing list [EMAIL PROTECTED] http://trijug.org/mailman/listinfo/juglist_trijug.org
