Why not have User include the getPrimaryKeyXXX() methods, then have the
default or non-db implementations set the login id as the PK?
John McNally
Rafal Krzewski wrote:
>
> Jon Stevens wrote:
>
> > Rafal, the problem with this is that if you are using a relational database
> > in the background, you *will* need to get access to that ID in order to do
> > relationships with other tables. For example, relating a user to a project
> > or an issue_id. Therefore, I think it is an ugly hack to have to cast to a
> > TurbineUser object in order to simply get this ID.
>
> Yes, it's an ugly hack. It should not be done this way.
>
> Just use the login name as the "foreign key" - I put that in quotes
> because
> it is a foreign key but a key that does not come from your app's tables,
> it's a key from the Turbine security service.
>
> Using 8 (or even 16) character string as a key wont eat that much
> memory,
> and it will be still reasonably fast, provided that you put an index on
> the column.
>
> Another solution is to create a table in you app to map login names
> into id-brokered numerical ids. But it's your application's part,
> not Turbine's.
>
> At this moment, Turbine does not depend on existence of a database
> in the system *at all*, unless you use DBSecurityService and the
> Scheduler.
> I wish is stayed this way. I think it only proves the quality of design.
>
> Rafal
>
------------------------------------------------------------
To subscribe: [EMAIL PROTECTED]
To unsubscribe: [EMAIL PROTECTED]
Search: <http://www.mail-archive.com/turbine%40list.working-dogs.com/>
Problems?: [EMAIL PROTECTED]
