> -----Original Message-----
> From: Jon Stevens [mailto:[EMAIL PROTECTED]]
> Sent: Friday, September 07, 2001 2:02 PM
> To: jetspeed-dev
> Subject: Re: XML Database schema for DatabasePsmlManager
> Implementation
>
>
> on 9/7/01 1:22 PM, "David Sean Taylor" <[EMAIL PROTECTED]> wrote:
>
> > Its a one-to-many relationship. One user can have multiple profiles.
> > I believe that we don't want to extend the TURBINE_USER
> table, we need to
> > create a new table JETSPEED_USER_PROFILE,
> > which is related to the TURBINE_USER table on the primary key of
> > TURBINE_USER.
>
> Correct.
>
> > Perhaps there is another way to do this in Torque?
>
> Of course there is a way to do that in Torque.
Yes I know that! I said *another way* - what I meant was "Is there a
different way to represent 1-many relationships in Torque?"
Sorry for the confusion.
The only way I know of how to do that is exactly how Atul did it - with a
foreign key declaration in the child and no modification to the parent.
>
> > Looking at the link above, I believe Atul has the foreign
> key declarations
> > correct.
> > How is this done differently in Scarab?
>
> Look at it. If you are going to extend the TURBINE_USER
> table, then there is
> more work that needs to be done in the XML file to define things.
>
Why are we discussing extending the TURBINE_USER table?
This is a 1-many relationship, and AFAIK, Torque does not require you to
modify the the parent table to represent 1-many.
Anyway, I looked at Scarab's schema: scarab_schema.xml. Hope that's the
right one.
For future reference, I am interested in extending the TURBINE_USER schema.
Are all of the XML tags and attributes available in Turbine 2.2b1?
(baseClass, basePeer, javaName..)
Could you please explain this 'Dummy table' concept, and if it is available
in 2.2b1?
It looks very useful to some of our users.
<!--
Dummy table for where the USER_ID lives. In most cases, this will be a
foreign table outside of the scope of Scarab itself. For example, if you
are
using Scarab with Turbine, then this will be defined as TURBINE_USER.
For
use in other systems, you will want to define this to be the name of
your
own USER table and update the FK references in this file to point at the
new
name. Then, all you need to do is regenerate the OR code to use the new
table name.
-->
<table name="SCARAB_USER" javaName="ScarabUserImpl" alias="TurbineUser"
baseClass="org.apache.fulcrum.security.impl.db.entity.TurbineUser"
basePeer="org.apache.fulcrum.security.impl.db.entity.TurbineUserPeer">
<!--
Unique identifier.
-->
<column name="USER_ID" primaryKey="true" required="true"
type="INTEGER"/>
</table>
> > to store profiles for roles
>
> I don't think that is a good idea. Roles are associated with
> Users and Users
> are associated with Profiles. If you want to know all of the
> profiles for a
> given role, you should look at your Users to get that information.
>
Don't know if I follow that one.
So if I create a profile for a user, and that user has a given role, then
any other user who has that role would also be granted access to that user's
profile?
My intent in my original profile proposal was that any user who is granted a
given role is also granted access to the profiles for that given role. The
use-case was to share profiles(psml) by role -- i.e. psml pages for all
accountants.
> > To store profiles for groups.
>
> You do realize that a "group" is not a group of users, but is really a
> Project. It is badly named in Turbine (we have a proposal to
> fix it), but
> group == project.
>
I do realize it, because I have followed this exact same conversation on the
turbine user list a few times.
As we know, It would help if the table wasn't called TURBINE_GROUP ;)
This is obviously confusing. How many times have you had to explain it.
> >> Do you understand what a Group and what a Role/Permission is?
> >
> > We have the concept of groups in Jetspeed, and we are using
> the TURBINE_GROU
> > P table to store the groups.
> > In the Turbine model, there is the USER_GROUP_ROLE table
> which holds the
> > relationship that a user is in a group under a given role.
>
> NOOOOOOOOOOOO!!!!!!!!!! That is not correct.
>
> A User is in a Project under a given role. It isn't a group
> of users it is
> users in a project.
>
Just replace 'group' with 'project' and you've said the same thing as I have
it.
When you rename TURBINE_USER_GROUP_ROLE to TURBINE_USER_PROJECT_ROLE, will
you change anything else, will the relationships stay the same?
The main problem is with the semantics of group, which can be confusing if
you think that a Turbine group works like a Unix group, which it does not.
Thanks for all the pointers with Torque. Im very impressed with the progress
it has made in a short amount of time.
-david
> > Permissions are defined on a per role basic, defined in the
> > TURBINE_ROLE_PERMISSION table.
> > I haven't checked recently, but Ive heard that the GROUP
> table will be
> > renamed in the next version of Turbine.
>
> Correct.
>
> -jon
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
