"Quinton McCombs" <[EMAIL PROTECTED]> writes:
>That is correct.
>It might be more clear to think about this from the torque end. When
>Torque.getConnection() is called to get a database connection, I need to
>know what the current user is. I have no reference to RunData, the
>HttpRequest, or anything else that I could use to get back to the user.
>My only real option here is to call a static method that can return the
>current user.
Well, IMHO the answer is (unfortunately) simple: This is not possible. =:-(
The user to connect to the database is static in the Torque
properties. What you would need is a completely new Pool structure
which keeps user/database connection pairs pooled and hands out the
connections according to a requested user. This is mainly Torque
scope, not Turbine scope. Turbine simply relies on Torque to provide
the persistence. We could pass the Turbine user into Torque but Torque
doesn't use it ATM.
Regards
Henning
>The call to Torque.getConnection, the execution of the session
>validation, and the execution of any action or screen class applicable
>to producing the returned page will always execute in the same thread.
>Using a static attribute that is an instance of ThreadLocal will allow
>each thread to have its own copy of the data stored in the ThreadLocal
>instance. This allows a call to a static method to get the current user
>to work.
>At least, I think this should work. I haven't tried it yet.
>More on the design -
> I am going to modify Torque so that you can register a listener
>class of sorts. Basically, you will set a property in Torque.properties
>with the class name of your listener class. If the listener is
>configured, Torque will execute the appropriate method on the listener
>class passing in the connection object. It will then return the
>connection object.
> This type of functionality could be useful in other
>circumstances as well. Perhaps Torque could be configured in the future
>to implement data filtering based upon some arbitrary criteria.
>Consider a simple human resources app where depending on the user
>(manager, hr person, employee), the data returned from the database on
>queries was automatically filtered by Torque.... This type of
>functionality is often embedded into the application where it is often
>duplicated in a few places. It is also very easy to forget to implement
>the data filtering (depending, of course, on how you designed you
>application). This type of approach could greatly simplify things.
> The real drive behind why I am doing this is that I am trying to
>use Oracle's Virtual Private Database technology. When each user logs
>in, I will call a stored procedure passing in an identifier for the user
>(user_id) and other data that will be used to restict data access. Each
>time I obtain a pooled connection, I call another stored proc passing in
>only the user_id. This gives Oracle enough information to dynamically
>rewrite queries as they are executed adding more filters into the where
>clause. This same idea is also supposed to apply to iserts, updates,
>and deletes.
>> -----Original Message-----
>> From: Jeffrey D. Brekke [mailto:[EMAIL PROTECTED]
>> Sent: Friday, February 28, 2003 9:15 AM
>> To: Turbine Users List
>> Subject: Re: Passing TurbineUser info to the database
>>
>>
>>
>> I'll take a stab at this question...
>>
>> Each request could be on a different thread, therfore each
>> request must set the user for the thread. The login action
>> would only be called once at login, but the session validator
>> is called on each request?
>>
>> "Eric Emminger <[EMAIL PROTECTED]> writes:
>>
>> > Quinton
>> >
>> > > I have need to pass the username of the person logged into my
>> > > application to the database. The only way that I can see
>> to really
>> > > accomplish this is to call a stored procedure immediately after
>> > > obtaining a pooled connection and calling it again when the
>> > > connection is released to clear the name.
>> >
>> > This may be a naive response, but could you just do this in
>> the Login
>> > action?
>> >
>> > Eric
>> >
>> >
>> >
>> ---------------------------------------------------------------------
>> > To unsubscribe, e-mail: [EMAIL PROTECTED]
>> > For additional commands, e-mail:
>> [EMAIL PROTECTED]
>>
>> --
>> =====================================================================
>> Jeffrey D. Brekke [EMAIL PROTECTED]
>> Wisconsin, USA [EMAIL PROTECTED]
>> [EMAIL PROTECTED]
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: [EMAIL PROTECTED]
>> For additional commands, e-mail: [EMAIL PROTECTED]
>>
>>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: [EMAIL PROTECTED]
>For additional commands, e-mail: [EMAIL PROTECTED]
--
Dipl.-Inf. (Univ.) Henning P. Schmiedehausen INTERMETA GmbH
[EMAIL PROTECTED] +49 9131 50 654 0 http://www.intermeta.de/
Java, perl, Solaris, Linux, xSP Consulting, Web Services
freelance consultant -- Jakarta Turbine Development -- hero for hire
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
