This is a note on the ongoing 1.2 DataNode refactoring. Currently we
have way too many special cases of JDBC interaction. The logic to
determine query execution strategies is spread over DbAdapter and
DataNode code. There are ugly workarounds like
"DbAdapter.shouldRunBatchQuery(..)" all over the place. As we add new
conditions (say conditional autogenerated column values), things become
even worse.
So I was thinking for a while how to reorganize this code. What I came
up with is org.objectstyle.cayenne.access.jdbc.SQLAction - a generic
stateless strategy for query execution. It has a single method:
public void performAction(Connection connection, Query query,
OperationObserver observer)
throws SQLException, Exception;
So now DataNode will take care of obtaining a connection and wrapping
operation in a transaction, but everything else will be done inside the
SQLAction. Choosing an appropriate SQLAction will be done using some
sort of configurable rules that can be changed by DbAdapter or manually
in runtime.
What's in CVS:
--------------
Currently I extracted DataNode code in a set of SQLActions (see
tomorrow's nightly build), but the decision-making part is still mostly
unchanged (though I was already able to streamline OracleAdapter). I'll
work on the rules part later. Any ideas are welcomed.
Custom DbAdapters:
------------------
This effort affects custom DbAdapters if you provide a subclass of a
DataNode with your adapter (and/or override "shouldRunBatchQuery"), so
at this point it shouldn't affect most adapters, but this is still work
in progress.
Andrus
This archive was generated by hypermail 2.0.0 : Sun Dec 12 2004 - 23:47:05 EST