Mailing-List: contact torque-dev-help@db.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Apache Torque Developers List" <torque-dev@db.apache.org>
Received-SPF: pass (hermes.apache.org: local policy)
In-Reply-To: 
 <OF4B01B838.DB025DE8-ONC1256FF0.002BBB4F-C1256FF0.002E512F@seitenbau.net>
Subject: Re: Torque and Village
To: "Apache Torque Developers List" <torque-dev@db.apache.org>
Message-ID: 
 <OF994ED017.FB38D072-ONC1256FF7.001F21A6-C1256FF7.00213D0B@seitenbau.net>
From: Thomas Fischer <fischer@seitenbau.net>
Date: Wed, 4 May 2005 08:03:02 +0200
MIME-Version: 1.0
Content-type: text/plain; charset=US-ASCII


Hi,

I could not resist playing around a bit with the jdbc interface on the
query side (Peer.vm). The only problem I ran into was when I realized that
a jdbc ResultSet needs to be processed by a callback. The following leads
to this:
1) one wants to have a lean doSelect method, which takes a criteria and a
connection and returns a rowset.
2) For this, one needs to create a statement, and execute the statement.
The statement should be closed when the method exits (we do not want to
pass it around, since it is of no further use)
3) according to the jdbc spec, when a statement is closed, the
corresponding resultSet is also closed.
4) after a resultSet is closed, one cannot get any more records from it.
So the resultSet has to be processed before the method exits. My solution
to this would be a callback interface. It would look like this

interface ResultSetReader {
  /**
   * reads the resultSet (and probably stores the results somewhere, though
this is not required)
   * @param resultSet the resultSet to read
   * @param offset how many rows at the beginning should be ignored, or 0
for no offset
   * @param limit how many rows should be processed at most, or -1 for no
limit
   * @param singleRecord if we expect one single row in the resultSet.
   *                  An exception is thrown if this is set to true and
there is not exactly one row in the resultSet
   */
  public void read(ResultSet resultSet, int offset, int limit, boolean
singleRecord) throws TorqueException;
}

The offset/limit/singleRecord parameters exist to be able to cover all
functionality of
BasePeer.executeQuery(
        String queryString,
        int start,
        int numberOfResults,
        boolean singleRecord,
        Connection con)

I did stop at that point, but it certainly looks promising. Mapping between
java types/jdbc types did not pose a problem, there is already the
TypeMap class in the generator where two additional Maps can be generated,
jdbcToJavaMethods and javaConstructors.

    Thomas

Thomas Fischer <fischer@seitenbau.net> schrieb am 27.04.2005 10:25:53:

> Hi,
>
> I have taken a shortish look at DdlUtils and also investigated (not in
much
> detail) what features of village are used by Torque.
> Torque uses the following features of village which are not provided by
> plain JDBC (I hope I did not miss anything):
> - Mapping of sql types to java types when reading from a database
> - constructing the SQL for a PreparedStatement to insert Datasets
> - constructing the SQL for a PreparedStatement to modify Datasets
>
> In my opinion, these features are not very difficult to implement.
> Most (All?) of them are also implemented in DdlUtils. I have not yet
formed
> a personal opinion whether I would favour useing ddlUtils for these Tasks
> over implementing them in Torque.
> On one hand, these things are so fundamental for Torque that one would
like
> to have full control over what happens within Torque. Also, the modelling
> of the database is different for Torque and DdlUtils, which makes
> integration difficult. In fact, Torque has two models, one for the
> generator and one for the runtime :-(.
> On the other hand, there is duplicate programming effort and duplicate
> maintenance. Also, from what I have seen, the use cases for Torque and
> DdlUtils overlap somehow, so that it might be possible to concentrate
> efforts even further. Using a dynamical bean to read from a database
might
> be a useful feature for Torque users, so perhaps one could make it easy
to
> use ddlUtils feature within Torque.
> I have to do further research to forma an opinion.
>
> By the way, are the DdlUtils mailing lists archived somewhere? I Did not
> find them on nagoya, but then, you said there was still some dust in the
> air.
>


---------------------------------------------------------------------
To unsubscribe, e-mail: torque-dev-unsubscribe@db.apache.org
For additional commands, e-mail: torque-dev-help@db.apache.org