+1 on the idea in general. Quite similar to a use case I had with teradata,
and query banding.
So if I understand correctly... we will see two new jdbc factory
parameters. The first being "pre" connection... and would be executed from
SQLDialect.initializeConnection() (or some wrapper of it)? In order to
execute the "post" sql do we need a new dialect callback method? Rather
than use a wrapper.
An alternative idea might be rather than using factory parameters directly
to come up with a "ConnectionLifecycleListener" interface or something like
that. Would be a bit more general and you could always use that to easily
come up with an implementation that would simply execute sql stored in some
factory parameters. Also would cater to cases where maybe some other stuff
needs to happen pre or post connection event, not just some sql statements
being executed.
Just an idea.
-Justin
On Mon, Nov 28, 2011 at 7:36 AM, Andrea Aime
<[email protected]>wrote:
> Hi,
> in a project we're working on we are facing a intersting request: the
> ability to run
> arbitrary sql commands before a connection is used by the code, and right
> before
> the connection is returned to the pool.
>
> The intent of such request is to allow do some custom environmental
> setup in that
> connection before it is used, in particular to setup impersonation
> (the ability to run
> commands with the credentials of another user) using some in-house grant
> and
> account package (e.g., not the standard impersonation commands).
>
> These sql commands would be parametric, using the usual cql variable
> expansion
> we already see in dynamic symbolizers (that, is, ${cql_expression}).
>
> The code in GeoServer would stick the current user in the "env" map,
> using a reserved
> key that cannot be used in normal request parameters, so that the session
> setup
> code can run the impersonation.
>
> However, being open ended, the code could be used for other purposes, such
> as
> for example switching workspace in oracle workspace manager, or setting
> some
> variables that stored procedure calls could use later, etc etc.
>
> The two commands would be specified as factory parameters. We already have
> an hook to initialize a connection, in order to perform the cleanup
> part we could
> simply use a wrapper that runs the other script when "close" is called.
>
> What do you think?
>
> Cheers
> Andrea
>
> --
> -------------------------------------------------------
> Ing. Andrea Aime
> GeoSolutions S.A.S.
> Tech lead
>
> Via Poggio alle Viti 1187
> 55054 Massarosa (LU)
> Italy
>
> phone: +39 0584 962313
> fax: +39 0584 962313
>
> http://www.geo-solutions.it
> http://geo-solutions.blogspot.com/
> http://www.youtube.com/user/GeoSolutionsIT
> http://www.linkedin.com/in/andreaaime
> http://twitter.com/geowolf
>
> -------------------------------------------------------
>
>
> ------------------------------------------------------------------------------
> All the data continuously generated in your IT infrastructure
> contains a definitive record of customers, application performance,
> security threats, fraudulent activity, and more. Splunk takes this
> data and makes sense of it. IT sense. And common sense.
> http://p.sf.net/sfu/splunk-novd2d
> _______________________________________________
> Geotools-devel mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/geotools-devel
>
--
Justin Deoliveira
OpenGeo - http://opengeo.org
Enterprise support for open source geospatial.
------------------------------------------------------------------------------
All the data continuously generated in your IT infrastructure
contains a definitive record of customers, application performance,
security threats, fraudulent activity, and more. Splunk takes this
data and makes sense of it. IT sense. And common sense.
http://p.sf.net/sfu/splunk-novd2d
_______________________________________________
Geotools-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/geotools-devel
