Yes, I have noticed the same behavior in 2.0 CMP style beans. What I have been doing is simply alerting orion-ejb-jar.xml, and changing one of the tables into another one. So, instead of 2 tables, there is actually 1 table. I am not sure, if this is working correctly during transaction, in other words, I think orion still keeps two separate relationships in memory until a commit is done. So GroupBean.add(user), will not find "group" in the "user" entity until a commit and update to the relational table. This is somewhat frustrating and I am hoping will get fixed with the next release of Orion (not clear when that will happen since we have not seen any updates for over 9 months now!).
-AP_ -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of George Mardale Sent: Wednesday, October 03, 2001 5:49 AM To: Orion-Interest Subject: Re: Design strategy Hello Daniel, What I said about those 2 tables, was strictly Orion-related. You are right, in designing relational databases, a n-m relationship will be normalized by introducing 1 (one) table and two 1-n relationships between the existing 2 tables (Group, User) and the new one (let's say GroupUser). Thus, we will avoid redundancy. In Orion, as far as I know, if I use something like this: public class GroupBean .... { ... List users; ... } public class UserBean... { ... List groups; .... } to simulate a *-* relationship, Orion will create, by OR mapping, a table for my first 1-* relationship Group->User (let's say the table is named Group_users) and another table for my other 1-* relationship User->Group (let's say the table is named Users_group). Of course, these 2 tables (Group_users and Users_group) are identical, but I think Orion will not know that these two 1-n relationships represent in fact one n-m relationship. Please be advised that his is only my supposition about Orion. I don't know if I'm right about this one but I'll be glad if someone can clarify this issue for me. I was trying to find out for some days, how Orion handles *-* relationships, but I wasn't lucky to find something useful. best regards, George. ----- Original Message ----- From: "Daniel Lopez" <[EMAIL PROTECTED]> To: "Orion-Interest" <[EMAIL PROTECTED]> Sent: Tuesday, October 02, 2001 5:04 PM Subject: Re: Design strategy > Hi George, > > I don't know about EJB, as we don't use them, but having an extra table to > represent an n-m relationship is a well stablished technique when designing > relational databases. AFAIK there's no other way to do that while providing > db-enforced consistency and avoiding redundancy. You represent a logical n-m > relationship, you create a new table that implements two real 1-n relationships, > thus creating one extra table. I don't see where you get two extra tables per > relationship from. > regards, > D. > > George Mardale wrote: > > > Hello Owen, > > > > Thank you for your kind response. Yesterday, while waiting for a response on > > the Orion mailing list, we thought of a design somehow close to yours. We > > thought that using 3 different tables (ClassRoles, GroupRoles, UserRoles) > > was a good ideea. > > > > But today, we came up with a solution that we thought would benefit of > > Orion's powerful features. Thanks to Alex Paransky who helped us a lot, we > > tried to redesign the system, using OR mapping. So, we designed something > > like this: > > > > public class GroupBean implements EntityBean > > { > > ... > > List users; //1..* relationship with UserBean > > } > > > > public class UserBean implements EntityBean > > { > > .... > > List groups; //1..* relationship with GroupBean > > } > > > > Practically, we broke every *..* relationship (in this case Group(*) - > > User(*)) into two 1..* relationships. And so on, for every relationship that > > we have: > > Class(1) - Group(*) > > User(*) - Role(*) > > Group(*) - Role(*) > > Class(*) - Role(*) > > > > As far as I know, Orion will create an additional table in the database that > > will store the relationship. For example, for users attribute in GroupBean, > > it will create a new table Group_users, besides the existing Group and User > > tables. Practically, for every *-* relationship will have 2 more tables in > > the database. Is that correct? > > > > What I want to know is if this design is correct. Are there any drawbacks > > that would make this system work unproperly (may be some OR mapping > > problems)? > > > > Tkanks, > > George. > > > > ----- Original Message ----- > > From: "Owen Fellows" <[EMAIL PROTECTED]> > > To: "Orion-Interest" <[EMAIL PROTECTED]> > > Sent: Tuesday, October 02, 2001 10:58 AM > > Subject: RE: Design strategy > > > > > Hello, > > > > > > We have done a similar thing were we don't know the type of class assign > > the > > > role except at runtime. > > > > > > The solution we used was to have an Object Type table (contain Class, > > Group, > > > User). > > > Then created a interface which was Roleable (i.e. this class can have a > > role > > > assigned). > > > In the database you can store each assignment in a different table > > > (ClassRoles, GroupRoles, UserRoles), > > > or have a generic table that stores Roleable_id, Role_id and > > Object_type_id. > > > > > > This does have drawbacks e.g. the Database does not have enforced > > > consistence as the Roleable_id is not a foreign key on any one table. It > > > may also be slower to retrieve the Roles for a particular (Class, Group, > > > User) as you will have to lookup it object type and then its roles. (You > > > could always cache object types as there will not be that many). > > > > > > I'm sure you can implement a Bean with the above functionality (we haven't > > > used beans for this so I can help there). > > > > > > Hope this is of some help. > > > > > > Owen > > > > > > -----Original Message----- > > > From: [EMAIL PROTECTED] > > > [mailto:[EMAIL PROTECTED]]On Behalf Of George Mardale > > > Sent: 02 October 2001 06:06 > > > To: Orion-Interest > > > Subject: RE: Design strategy > > > > > > > > > Hello Alex, > > > > > > Thank you for your prompt response. Your suggestions are excellent. > > > > > > You're right, the analysis is not correct. I tried to reduce the problem > > to > > > a > > > simple example. To avoid complexity, I just limited the relationships to > > > 1..*. > > > Maybe the example is not the best, but I only wanted to know if I could > > > model > > > the "Abstract being" bean in Orion. > > > > > > There are still 2 issues we are unclear about: > > > 1. what are the advantages of dumping entity Class? (Class has specific > > > fields > > > that Group does not have) > > > 2. could you please detail the best way to implement a *-* relationship > > in > > > Orion? > > > > > > Thanks, > > > George. > > > > > > > >
