On 14.09.2004 20:20:52 Bruce Snyder wrote:
> ...
> The cast to java.sql.Connection is explained above. Castor has
> always had plans to connected to data sources other than relational
> databases. By allowing this method call to return a java.lang.Object,
> we're allowing other types of connections to be returned.
OK, thanks for the detailed explanation.
So at least the (DatabaseImpl)-type cast can be avoided by
exposing getConnection() in the Database interface.
This makes things at least a bit more comfortable. :)
> I've been pondering this myself over the last month or so. Especially
> in just the last couple of days. There are many applications that
> need access to the JDBC connection simply to set parameters on it
> (e.g. batching, holdability, read-only, transaction isolation
> (especially this one!), etc.). The conclusion I've come to is that
> we should expose such parameters via method calls. This brings up
> another issue, however. We can't place JDBC-specific method calls
> on the Database interface. Because of this, I've been thinking about
> creating a new interface model like so:
I can show you my typical needs for session intializations:
Statement stmt = conn.createStatement();
try {
stmt.execute("set role ROLE_XXX identified by PASSWORD");
stmt.execute("alter session set nls_language = GERMAN");
stmt.execute("alter session set nls_territory = GERMANY");
stmt.execute("alter session set nls_numeric_characters = ',.'");
} catch(...
This just requires the ability to execute some SQL statements.
Would this also be possible with the method calls, you are thinking about?
Regards,
Martin
-----------------------------------------------------------
If you wish to unsubscribe from this mailing, send mail to
[EMAIL PROTECTED] with a subject of:
unsubscribe castor-dev
