Hi Scott, and everybody,
more than a year ago you wrote the message below.
(There has been no reply to your message.)
What I need to do is building a security framework for customers to inherit
their rights (roles,permissions) to sub-customers. I have app-tables that
hold reseller-specific security data. This is supposed to be kind of
extension of the basic turbine security framework. (I can't explain the
whole thing, it's rather complex.)
Anyway, I need to reference various turbine security tables.
So I wonder if you have figured out a solution for the problem that you
outlined in your message.
I was thinking about aliasing all the tables (like for extending the user)
but I'd like to make sure there isn't any better/easer solution before.
TIA.
Marc
* From: Scott Eade
* Subject: torque schema - joins to turbine tables
* Date: Tue, 03 Jul 2001 12:21:39 -0700
In my application database schema a number of my tables
include foreign-key references to TURBINE_USERS and
TURBINE_GROUPS. To make this work I currently
redefine these tables at the bottom of my application
database schema (a cut and paste from turbine-schema.xml).
With this set up the two tables mentioned are generated twice
and I end up with two sets of peer classes - not a very tidy
solution, but it works.
I'm wondering if there is a better way of achieving the same
result. In database.dtd I notice a number of table element
attributes that may actually provide what I need, but I am
unsure of the combination of attributes to use.
Here is the definition of the table element from database.dtd:
<!ELEMENT table (column+,(foreign-key|index|unique|id-method-parameter)*)>
<!ATTLIST table
name CDATA #REQUIRED
javaName CDATA #IMPLIED
idMethod (idbroker|autoincrement|sequence|none|null) "null"
skipSql (true|false) "false"
abstract (true|false) "false"
baseClass CDATA #IMPLIED
basePeer CDATA #IMPLIED
alias CDATA #IMPLIED
>
I was thinking that skipSql might be part of the answer,
however I remembered that my currently generated
BaseTurbineUser class has a whole bunch of get methods
that join back to my application tables. I am now thinking
that I may be better off keeping the duplicate table definitions
but providing baseClass and basePeer attributes presumably
so that the application classes extent the classes generated by
turbine-schema.
Am I thinking along the right lines or have I got it all wrong?
I am assuming that linking from application tables to
turbine tables is a common requirement and that database.dtd
and torque allow for this.
Thanks,
Scott
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
