On Tue, Nov 29, 2011 at 6:09 AM, Justin Deoliveira <[email protected]>wrote:

> +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.
>

I'm not sure about the usage of the dialect. Let me try to elaborate:
- the dialect takes care or something that is database specific, but always
equal as long as the db is the same
- these init and release commands are likely to be related to the database
type (but not necesssarily), what
  makes them vary is the particular instance. For example, I might have one
database and two Oracle stores,
  one hitting a schema that contains the public data which does not need
the scripts, and another hitting some
  sensitive data that needs the impersonation and accounting scripts

As for having a new dialect callback, if a dialect pops up that needs it I
see no problem in adding it.

Regarding the wrapper vs no wrapper, I thought about the wrapper because
anybody is free to call
Connection.close() wherever they want, a wrapper would ensure that the
closing down stament
is executed.

Now, theoretically JDBCDataStore provides a closeSafe(connection) method
that could be used
as the central closing point where the session closing script could be
executed, but implementations
are not using it uniformly, a search with find and grep shows the following
results (just a sampler,
I'm not listing them all):

./jdbc-db2/src/main/java/org/geotools/data/db2/DB2SQLDialect.java:
   try {if (con!=null) con.close();} catch (SQLException ex1) {};
./jdbc-spatialite/src/main/java/org/geotools/data/spatialite/SpatiaLiteDialect.java:
               st.close();
./jdbc-teradata/src/main/java/org/geotools/data/teradata/TeradataDialect.java:
           st.close();
./jdbc-teradata/src/main/java/org/geotools/data/teradata/TeradataPrimaryKeyFinder.java:
           st.close();

Since we cannot rely on implementors to always remember to call
closeSafe(cx) I think it's better
to use a connection wrapper instead.


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

So we would have a default implementation taking the two factory parameters
with the sql scripts
(which would be part of the base factory class) and then have the
JDBCDataStore have a
getLifecycleListeners() returning a live collection that the caller can use
to customize it?

I could also go without the factory parameters, but then I'd have to roll
something custom in the GeoServer
configuration panels (like the sql views, so it would be code percolating
down into the ResourcePool)
since the actual requirement I have is to be able to  configure those two
scripts from the GeoServer GUI
(without any fork or custom code).

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

Reply via email to