[
https://issues.apache.org/jira/browse/DERBY-3849?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12650138#action_12650138
]
Kristian Waagan commented on DERBY-3849:
----------------------------------------
Well, it is implemented for empty property sets ;)
You are right regarding supporting arbitrary properties, but my impression
after reading the JavaDoc is that this is not the way this mechanism is
intended to be used. The driver is supposed to return a list of supported
properties when DatabaseMetaData.getClientInfoProperties is called. What should
we return for arbitrary properties?
Providing a reasonable set of properties for free-from use is trivial though,
and I don't think there are any technical difficulties stopping us from doing
what you propose.
It is not clear to me whether these properties should be persisted or not, but
since they are associated with a connection I don't immediately see why they
should be persisted beyond the life-time of a connection. The application
programmer can do this if required, either by writing a trigger or extracting
the information from the JDBC driver in the application.
I guess what I'm really asking, is if storing the properties in the connection
object is okay?
I have never used this feature before, so please correct me if I'm wrong!
> Session data
> ------------
>
> Key: DERBY-3849
> URL: https://issues.apache.org/jira/browse/DERBY-3849
> Project: Derby
> Issue Type: New Feature
> Components: Services
> Environment: N/A
> Reporter: Antonio Sánchez
> Priority: Minor
>
> Being able of storing session data the same way a Java application does with
> HttpSession.
> Some applications might require this feature or could take advantage of it
> in order to fulfill its requirement more easily.
> Next I will describe an example scenario but there might be many others that
> would benefit of this feature:
> "A client/server (java-swing/derby) application that requires connecting to
> derby always using the same database user; the application users are stored
> in a an application table, e.g., APPUSERS. The application also requires
> auditing the activity of the connection via 'triggers' but having the current
> application user the 'owner' or 'responsible' of the database connection.
> The problem is that there is no way of tracking the application user
> corresponding to a database connection. For instance: given this scenario, if
> we have application users 'foouser' and 'baruser' and the connecting database
> user 'derbyconnect' , CURRENT_USER will return always 'derbyconnect' for
> both 'foouser' and 'baruser' connections. Althouht it is true that we could
> create a table where application connections are managed, at the time of the
> audit triggers run there won't be a way of relating the running physical
> connection (derby connection user) with the logical one (application user).
> Having the chance of storing data for a physical connection (session) would
> make it work, just by storing the application user in the session and
> retrieving it when needed in the triggers. Otherwise the application would be
> forced to perform an extra request in order to carry out the audit operation
> passing the application user as an argument, which would make worse both
> performance and application design."
> I am not an expert neither on derby nor in databases and maybe derby already
> provides the way of fulfilling this without the need of developing a new
> feature; if that it is the case I would appreciate if someone could let me
> know. But it there is no way, then I think this one would be a great feature
> for application developers using derby in scenarios like the one described
> above.
> Thanks.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
