Comments inline .. > > Dain Sundstrom wrote: > > >>Finally, we are on the same page ..not even a blue moon ... > >> > > > > About time :) > > > > > >>Yup this is a suggestion. I agree 100% we need to avoid using > >>jbosscmp-jdbc.xml. > >> > >> > >>Ultimately at the database level for each table there has to > >>be a unique > >> column name(s) that acts as a foreign key for the > relation. It also > >>can only participate in 1 relation. > >> > > > > What? Did you really mean that a table can only participate in 1 > > relationship? > > > > Not table column.
Ok so we agree a table can partivipate in more then one relationship. :) > > > >>For a many to many relationship with a mapping table could be > >>a problem > >>if the field name on both sides of the relationship were the > >>same. But I > >>would see this as an exception not the rule. > >> > >>For self joins you would have to do like you do in the EJBQL > >>and prefix > >>the column with the table name. Not a bad idea for all relations so > >> > >>select uuid from CDTrack where composer=? > >> > >>would be > >> > >>select c.uuid from CDTrack as c where c.composer=? > >> > > > > agreed. > > > > > > The column names are constructed to make the code easier to > write. There > > are a lot of cases you are forgetting. Here is a short list: > > > > Many side does not have an accessor, so no name to use. > > For a unidirection relationship you still have to specify the > other side > of the entiry bean that is the key. Really no different than > if you did > define it. > > > > One side has a complex pk. > > > One side uses a DVC for a pk. > > One side has a complex pk which uses a DVC. > > > Does not matter what naming convention you use you still have > to map the > columns in one table to another. So if you had a pk that was columns > a,b,c and the other side had a pk that was columns d,e,f I'm > assuming > that the SQL would generate a=d and b=e and c=f. Still no > naming conflicts. > > As well these are all complex cases and the to get there you would > already be using jbosscmp-jdbc.xml. If we have to put in > extra stuff for > the relation no big deal. > > > > > > > > So what rules do you propose for the fk case. For relation > tables, you have > > the additional problem of name collision between the > entities. It is very > > common to have all entities to use a pk named id or oid. > This is not a high > > priority for me, so what system do you propose? > > > > Well for a relation table I would use id,left_id,right_id and use > left_id in one table and right_id in another. (Just as Monson-Haefel > does in his book, 2.0 edition) > > > > What this boils down to though is how we expect users to name the > columns for there relationships. In the spirit EJB most of > the examples > I have seen assume that the PK is one unqiue database column. > Currently > there is no relationship between the Class field name and the > database > column. You must always specify the database column that is > used for the > relationship. For 90% of the cases and certainly for all of > the examples > I have seen you must use a JBOSS'ism in order to get relations to > work. To me this is just wrong. What really makes my the hair on the > back of my neck stand up is "The column names are constructed to make > the code easier to write". Big red light flashing, what we want is > easier to use ... isn't it? Ok, you are not getting it. Although JBossCMP does not generate the column names you would like, the system still runs. Is that correct? (i.e., this is still a suggestion) Ok now that we agree on that. How would you like the column names generated? Be very very specific and take into consideraton the above problems. As for my comment "easy to code," that is perfectly valid, as we are shooting for CMP 2.0 compliance. CMP 2.0 is a huge spec, so everything can not be "perfect" in the first pass. Some of the implementation details get implemnted the easy way. There have to be priorities. -dain _______________________________________________ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
