Jason van Zyl wrote:
> Did we agree that all the address information was
> going to be leaving the TURBINE_USER table? Rafal,
> I see several columns missing from the your MySQL
> schema, did you just leave the address info out?
I thought we were discussing this eariler...
Anyway here is my proposal:
<proposal>
Default schema of TURBINE_USER table contains the minimal
subset of user information that is useful to the widest
range of applications possible.
The following fields are included:
first name
last name
email address
If application needs to process more information about
an user the following actions can be performed
1) The application may define custom keys for User.getPerm/
setPerm methods, and uses those methods for accesing
user information. Consult User interface for key values
that are reserved for use by Turbine.
2) Application may extend TurbineUser class to provide
accessor methods for the custom user attributes.
This class can be configured by usabe by UserManager
(services.TurbineSecurityService.user.class=...)
and then applicaton may cast the result of RunData.getUser()
call to this class to use the accessor methods
3) If searching capability is desired upon the values
of certain custom user attributes, the fields for storing
these attributes may be appended to the TURBINE_USER
table schema. This action may be performed by DB adminstrator
by issuing a sequence of SQL statemets
ALTER TABLE TURBINE_USER ADD name type
The names of the fields must be identical to the keys
used in getPerm/serPerm methods, and the field types must
be compatibe to Java types of the corresponding attributes.
After adding these fields to the DB they may be used for
building Criteria objects to be used with UserManager.getUsers()
method.
No other actions need to be taken by application creator/deployer
than those described above to provide the described functionality.
Everything else is handled behind the scenes by DBUserManger and
TurbineUserPeer classes.
</proposal>
I feel that putting inconsistent set of user attributes that will
be too broad for one applications and too narrow for others into
the default turbine database is not a good idea.
Another thought about it is that since we have JNDI and a wrapper
service for it, why not use X.500 directory for processing user
information in applications that really need it?
I'm waiting for votes.
Non-commiter comments are also wellcome!
Rafal
--
Rafal Krzewski
Senior Internet Developer
mailto:[EMAIL PROTECTED]
+48 22 8534830 http://e-point.pl
------------------------------------------------------------
To subscribe: [EMAIL PROTECTED]
To unsubscribe: [EMAIL PROTECTED]
Search: <http://www.mail-archive.com/turbine%40list.working-dogs.com/>
Problems?: [EMAIL PROTECTED]
