From: "Dan Bachelder" <[EMAIL PROTECTED]>
> The compile problem... Maybe what needs to happen is to add the key to your new
>user... do the init to create the auto
generated classes... Implement the getUserId method, THEN add the FK to your other
tables... and reinit.... just a
thought....
I do not think this will work because the RDF classes expecting the getUserId() method
in BaseNewappUserImpl, rather
than NewappUserImpl. If it does work, then it is cetrainly counter-intuitive and
difficult to implement. Ultimately I
think this should have a fairly straightforward solution - it is after all supposedly
designed with this in mind (isn't
it?)
> As to how to implement other functionality.. I had trouble using other column in
>TURBINE_USER so what I did was the
following..
>
> public void setSomeAttribute(Object obj)
> {
> setPerm("someAttribute", obj);
> }
>
> public Object getSomeAttribute()
> {
> return (Object)getPerm("someAttribute");
> }
>
> what get/set perm does is serialize data to the OBJECTDATA column of the
>TURBINE_USER...
I'm pretty sure that is what it does, although I haven't used this feature myself.
Strike that, I have tried it and it
does work (I just tried it for my Title attribute).
> Can someone who knows confim or deny these facts?
I now know and confirm it.
> I would also like to see what using the actual columns looks like in code...
>
> I thought I saw somewhere that turbine user was using set/get perm for several
>fields (i.e. email, confirm_status)
even though there are columns for these attributes... I might be making that up
though...
I came across this code myself today in org.apache.turbine.om.security.TurbineUser and
thought it very odd as the data
is definitely stored in the available columns. It ties in to
org.apache.turbine.services.security.db.DBUserManager. It
seems that turbine allows for the user data to be stored in whatever medium you like
as configured by
services.SecurityService.user.manager in TR.props. The idea being that you can pull
this data out of an LDAP directory
or whatever. This is what makes me uncomfortable about the solution I currently use
(simply moving all of the turbine
tables into my application schema, generating TurbineUser and TurbineUserPeer classes
as if it were a standard
application table and retrieving records also as if they are standard application
tables). I also recall seeing a post
recently that indicated that this is why the TurbineUser does not implement
getUserId() - something about there being no
equivalent key when LDAP is used (in which case what should we be using as foreign
keys into TURBINE_USER?).
A few minutes of investigation has revealed that DBUserManager calls back into
TurbineUserPeer.buildCriteria() which
moves from Perm to criteria the columns it knows about and then writes the remaining
Perm to Objectdata. Given that
using an alias in the application schema does not generate anything new in terms of
TurbineUser/TurbineUserPeer, this
means that the only way to add additional attributes to TurbineUser is to use Perm
(and thus there is no point adding
columns to TURBINE_USER in turbine-schema.xml ... given the current design that is.)
While it is excellent that turbine supports the ability to add attributes to
TURBINE_USER with little effort (if you
don't care for the convenience getter/setter methods you can just use set/getPerm()),
it would be great to provide a way
to actually get the data into real columns so that it is available to other
applications that you might want to grant
access to the database.
That said, this could simplify what needs to go into the HOWTO for the moment - i.e.
unless you are going to also extend
DBUserManager, you should only use Perm to store additional attributes in TurbineUser.
Cheers,
Scott
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
