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 (nike.apache.org: local policy)
Subject: created torque 4 branch with village removed
To: Apache Torque Developers List <torque-dev@db.apache.org>
Message-ID: 
 <OF98697049.4339EDBD-ONC12577C9.00771014-C12577C9.007EE878@seitenbau.net>
From: Thomas Fox <Thomas.Fox@seitenbau.net>
Date: Thu, 28 Oct 2010 01:06:09 +0200
MIME-Version: 1.0
Content-type: text/plain; charset=US-ASCII


As you might have noticed, there is a new branch in torque4 which has
village removed. This branch passes the Torque test project for mysql,
postgresql, oracle, derby and mssql, ecept one failuing tests with the
managers which I have not yet looked into.

The functionality which village provided was replaced by the following
strategy:

- The class which converts a result set into a java object is called
recordMapper. It is a new interface in a new package,
org.apache.torque.om.mapper, and has a few generic implementations in the
same package as well as one generated for each table as inner class in the
peer class. so what doSelect does is now construct the query, get the
result set, walk through it and applying the recordMapper to each row to
get the result list.

- The doInsert and doSelect methods convert a new class called
org.apache.torque.util.ColumnValues which is basically a map from column
values to an ew class called org.apache.torque.util.JdbcTypedValues shich
contains a value and a SQL type (ColumnValues additionally contains a table
map). ColumnValues replaces the Criteria used for inserts and updates; this
has become necessary because at least Derby needs the JDBC Types when
setting null values in prepared statements, and we do not want to query the
resultSetMetadata as village did. So what happens for inserts and updates,
the Peers construct a ColumnValues object from tha database object and pass
this to the BasePeer's doInsert and doUpdate methods, which then construct
a prepared statement from the information, insert the given values and
execute the prepared statement.

Of course this has led to quite a few changes in the APIs, in particular
all methods which return village values or village records are gone
(naturally).
The following  methods have changed signature:
- Base.Peer.getIdAsVillageValue in the AutoIncrementIdBroker and the
SequenceIdBroker
- Base.Peer.doInsert (Criteria -> ColumnValues)
- Base.Peer.doUpdate(Criteria -> ColumnValues)
- LargeSelect Constructor now aditiionally need a RecordMapper

The following methods were removed, renamed or moved
- doPsSelect (need to figure out hwether all selects can be done using
prepared statements)
- doSelectVillageRecords is now called doSelect and needs a RecordMapper
and a TableMap as additional inputs.
- BasePeer.getPrimaryKey was moved to TableMap
- BasePeer.executeQuery is now Called doSelect and needs a RecordMapper and
a TableMap as additional inputs.
- BasePeer.getSelectResults is removed without Replacement (one-step
mapping instead of two-step mapping)
- BasePeer.initTableColumns is removed (no village schema any more)
- BasePeer.insertOrUpdateRecord (no recordy any more)
- BasePeer.processTables (was needed for deletes and was handling village
records, not needed any more)
- LargeSelectonstructors which would have retuned a record list are removed
- generated Peer's row2object, populateObject and populateObjects method
(their job is now done by the RecordMappers)
- generated Peer's doSelectVillageRecords (replaced by doSelect methods)
- generated Peers getOmClass(record)
- DataTets's testNullConnection and testPreparedStatements are gone for now
(former needs to be rewritten)
- SqlToAppDataTest was removed (was useless before as Sql2AppData is now
tested in generator)

The return types of some Methods ofSummaryHelper now depend on the database
(but additional methodw were added to fix this across databases)
And finally, the ProcessCallback interface in BasePeer was removed (it was
handling village records)

I tried to keep focus on the remove village task, but while I was at it I
could not resist to do some additional changes
- methods which take a connection as argument now fail when null is given
as an argument. This was discussed to be teh expected behaviour on the dev
list some year ago, and the reason is that if you pass a connnection you
expect to be in a transaction (otherwise you would not bother). if you are
not in a transaction then you want to fail fast because this mioght be
difficult to track otherwise.
- renamed a few template veriables (because the table element now has an
attribute field, the column template attributes should have a different
name)
- db object instances are now created using a constructor

Although this list of changes may seem long, in my opinion most of these
things were not parts of torque which were used outside. As Proof to this
staement, check how few things needed to be changed in the test project.

Of course there are a few things left to do (which I will hopefully tackle
in the next fes weeks):
- check whether to revive the doPsSelect methods or whether all selects can
use prepared statements
- there was come code in doDelete which handled cascading deletes (at leats
theoretically, never saw it working) tris needs to be reimplemented
- Maybe one can clean up LargeSelect from the reflection stuff therein
- the builldCriteria method in generated peers does not make sense anymore
(replaced by buildColumnValues) and should be removed
- the null-failure if a connection is passed as null needs to be consistent
throughout Torque
- rewrite testNullConnection method (check passing a nul connection fails)

I'd appreciate any feedback. Of course my idea is to move this back into
trunk, but I wanted to give everybody opportunity to check this.

And, one last thing, as of my marriage two weeks ago my last name has
changed from Fischer to Fox, so do not be surprised by the new email
address.

    Cheers,

      Thomas


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