This one time, at band camp, Martin Fuchs said:
MF>while looking through in Castor's source code the following question
MF>hit me one more time: Why is it made so difficult to retrieve the
MF>underlying JDBC connections from Castor?
MF>
MF>Yes, I saw the warning "Only for internal / advanced use !" in
DatabaseImplgetConnection().
MF>But some applications need access to the JDBC connection for example
MF>to set some DB parameters at session initialization.
MF>
MF>I see everywhere this construct:
MF>
MF>Database db = jdo.getDatabase();
MF>db.begin();
MF>Connection conn = (Connection) ((DatabaseImpl)db).getConnection();
MF>
MF>A bit complicated just to get a connection object, if you ask me.
MF>
MF>First: Why is the cast to DatabaseImpl necessary?
MF>Well, it's needed because getConnection() is only present in DatabaseImpl,
MF>not in the Database interface. What about declaring it in the Database
MF>interface, perhaps with ajusted name getJdbcConnection() and
MF>the return type java.sql.Connection ?
MF>Any other derived database implementation could just return null,
MF>if it doesn't use a JDBC connection. Well - will there ever be a database
MF>implementation in Java, which doesn't use JDBC? I doubt.
I'm not sure why the getConnection() method is not exposed in the
Database interface. Proabably just an oversight more than anything.
I have no problem exposing this method via the Database interface
but the name cannot change and here's why. All connections in Castor
are not always of type java.sql.Connection. There have always been
plans to make Castor support LDAP persistence. Currently it only
supports querying and marshalling the results to XML. I'm about to
start to work on adding LDAP persistence to Castor to leaving the
getConnection() method signature the way it is currently designed
is important.
MF>Second: Why is the cast to Connection necessary?
MF>DatabaseImpl.getConnection() simply calls TransactionContextImpl.getConnection(),
MF>which in any case returns a JDBC Connection object. Is there the
MF>possibility to return any another type?
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.
MF>I would propose to change the return type of the getConnection() functions
MF>from Object to java.sql.Connection.
I disagree here and have explained the reaasons for this above.
MF>What do you think?
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:
+------------+
| DataSource |
+------------+
#
|
+------------+------------+
| |
+----------------------+ +----------------+
| RelationalDataSource | | LdapDataSource |
+----------------------+ +----------------+
. .
/_\ /_\
| |
| |
+--------------------------+ +--------------------+
| RelationalDataSourceImpl | | LdapDataSourceImpl |
+--------------------------+ +--------------------+
For a description of this ASCII UML, please see the following doc:
http://c2.com/cgi/wiki?UmlAsciiArt
In the diagram above, the DataSource interface would replace the
current Database interface. The second layer allows any additional
DataSource type to be added (JCA connectors to AS/400, etc.). The
third layer is a replacemet for the current DatabaseImpl.
Bear in mind that changes this significant would not go into the
TRUNK. We'd need to create a 1_0 or 2_0 branch for it. With the big
changes we're thinking about, we need to leave the TRUNK alone and
only do minor changes and bugs fixes.
Bruce
-- perl -e 'print unpack("u30","<0G)[EMAIL
PROTECTED]&5R\"F9E<G)E=\$\!F<FEI+F-O;0\`\`");'
The Castor Project
http://www.castor.org/
Apache Geronimo
http://incubator.apache.org/projects/geronimo.html
-----------------------------------------------------------
If you wish to unsubscribe from this mailing, send mail to
[EMAIL PROTECTED] with a subject of:
unsubscribe castor-dev
