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
--
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]
