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.
>
>
