You are viewing a plain text version of this content. The canonical link for it is here.
Posted to torque-dev@db.apache.org by Thomas Fischer <fi...@seitenbau.net> on 2010/09/30 06:20:37 UTC
How to remove village [was: Re: Release Torque-4.0-alpha1 soon? & set of
supported databases]
> >> Greg suggested to use the map
> >> classes for the metadata which sounds quite reasonable.
> >
> > I'd rather not do it. We have all the information for processing data
in a
> > typesafe manner, so why do we want to have a class in the middle which
> > stores information as a Object with no type information at all ? But
> > perhaps I should make a suggestion of what solution is in my mind. But
> > before that, we should decide whether this should happen before an
alpha1
> > release or after.
>
> No additional object is needed. The map classes can tell for each and
> every selected column what the actual type of the column is. So we
> actually already *have* the metadata information and we don't need to
> query the database for that.
I was never suggesting to query the database for type information (or so I
hope). But I'd rather generate conversion mappers from the schema than
determine the types on runtime from the Map classes.
Currently we have the following conversion for query result
ResultSet -> List of array of Village objects -> List of Torque objects.
For this we generate the code
// BaseBookPeer.java
public static List<Book> doSelect(Criteria criteria) throws
TorqueException
{
return BookPeer.populateObjects(
BookPeer.doSelectVillageRecords(criteria));
}
This would not change with the method you suggest.
I'd aim for the following (no intermediate objects):
ResultSet -> List of Torque objects.
And this could work as follows (error handling, closing stuff, correcting
Booleans, Join support etc omitted):
// BaseBookPeer.java
public static List<Book> doSelect(Criteria criteria, Connection con)
throws TorqueException
{
return BookPeer.selectAndConvert(criteria, new BookRecordMapper
(0)), con);
}
// maybe can go to BasePeer
public static List<Book> selectAndConvert(Criteria criteria,
Mapper<Book> mapper, Connection con)
{
Query query = createQuery(criteria);
ResultSet resultSet = con.createStatement().executeQuery
(query.toString());
List<Book> result = new ArrayList<Book>();
while (resultSet.next)
{
result.add(BookMapper.map(resultSet));
}
return result;
}
// Mapper can be a static inner class of Peer class but this is no
requirement
// it would also be generated from the schema information
public static class BookMapper implements Mapper<Book>
{
public Book map(ResultSet resultSet)
{
Book book = BookPeer.getOmClass().newInstance();
setId(book, resultSet);
....
return book;
}
protected void setId(Book book, ResultSet resultSet)
{
Integer id = resultSet.getInt(1);
if (resultSet.wasNull())
{
id = null;
}
book.setId(id);
}
....
}
// Mapper.java
public interface Mapper<T>
{
T map(ResultSet resultSet);
}
> >> This would
> >> however require some changes in the runtime.
Same as the mapping solution outlined above. To remove village, the runtime
must be touched. No way around it.
> >> Anybody having a strong
> >> feeling against the integration of the few village-classes into the
> > runtime?
> >
> > Yes, see above.
>
> A couple of advantages:
> - No additional dependency for some 10 classes
> - No cross-dependency between libraries
> - Easier removal at a later stage.
> - Direct access to table map data
>
> Still -1 ?
>
> Bye, Thomas.
I'd prefer the simpler solution above. I'd even volunteer to implement
it :-).
Do you see any advantages of the metadata approach a compared to the mapper
approach outlined above ?
Thomas
---------------------------------------------------------------------
To unsubscribe, e-mail: torque-dev-unsubscribe@db.apache.org
For additional commands, e-mail: torque-dev-help@db.apache.org
Re: How to remove village [was: Re: Release Torque-4.0-alpha1 soon? & set
of supported databases]
Posted by Thomas Fischer <fi...@seitenbau.net>.
--------------------------------------------------------------------
Dr. Thomas Fischer
Software-Entwicklung
Tel. +49 (0) 7531 36598-22
Fax +49 (0) 7531 36598-11
E-Mail fischer@seitenbau.com
SEITENBAU GmbH
Seilerstraße 7
D-78467 Konstanz
http://www.seitenbau.com
Amtsgericht Freiburg HRB 381528
USt-IdNr.: DE 1905 525 50
Geschäftsführer:
Florian Leinberger | Sebastian Roller | Rainer Henze | Jan Bauer | Stefan
Eichenhofer
Thomas Vandahl <tv...@apache.org> schrieb am 30.09.2010 21:50:47:
> Von:
>
> Thomas Vandahl <tv...@apache.org>
>
> An:
>
> Apache Torque Developers List <to...@db.apache.org>
>
> Datum:
>
> 30.09.2010 21:50
>
> Betreff:
>
> Re: How to remove village [was: Re: Release Torque-4.0-alpha1 soon?
> & set of supported databases]
>
> On 30.09.10 06:20, Thomas Fischer wrote:
> > // maybe can go to BasePeer
> > public static List<Book> selectAndConvert(Criteria criteria,
> > Mapper<Book> mapper, Connection con)
> > {
> > Query query = createQuery(criteria);
> > ResultSet resultSet = con.createStatement().executeQuery
> > (query.toString());
> > List<Book> result = new ArrayList<Book>();
> > while (resultSet.next)
> > {
> > result.add(BookMapper.map(resultSet));
> > }
> > return result;
> > }
>
> I understand. I tried to do something similar with commons-dbutils once.
> Worked like a charm.
Yes it's the commons-dbutils approach.
> Problem is, that this only covers the SELECT case.
> I found it very difficult to apply the equivalent concept to the
> INSERT/UPDATE case.
But for what does one need village for updating? For insert/update, one
needs to create a prepared statement containing all columns (should not bee
too difficult) and add all the values as parameters (using plain objects).
If I recall correctly, village does create the prepared statement and does
the filling in, but this could also be generated (perhaps in the mapper
class). One can even leave out building the criteria IMHO. I will have a go
at it.
> > Do you see any advantages of the metadata approach a compared to the
mapper
> > approach outlined above ?
>
> Easier transition. Do something simple but useful for 3.3.1, keep the
> big bang for later. ;-)
Ah ok. I have no stock in 3.3.1, you can do whatever you want there (well
not really, but within very wide limits)
Thomas
---------------------------------------------------------------------
To unsubscribe, e-mail: torque-dev-unsubscribe@db.apache.org
For additional commands, e-mail: torque-dev-help@db.apache.org
Re: How to remove village [was: Re: Release Torque-4.0-alpha1 soon?
& set of supported databases]
Posted by Thomas Vandahl <tv...@apache.org>.
On 30.09.10 06:20, Thomas Fischer wrote:
> // maybe can go to BasePeer
> public static List<Book> selectAndConvert(Criteria criteria,
> Mapper<Book> mapper, Connection con)
> {
> Query query = createQuery(criteria);
> ResultSet resultSet = con.createStatement().executeQuery
> (query.toString());
> List<Book> result = new ArrayList<Book>();
> while (resultSet.next)
> {
> result.add(BookMapper.map(resultSet));
> }
> return result;
> }
I understand. I tried to do something similar with commons-dbutils once.
Worked like a charm. Problem is, that this only covers the SELECT case.
I found it very difficult to apply the equivalent concept to the
INSERT/UPDATE case.
> Do you see any advantages of the metadata approach a compared to the mapper
> approach outlined above ?
Easier transition. Do something simple but useful for 3.3.1, keep the
big bang for later. ;-)
Bye, Thomas.
---------------------------------------------------------------------
To unsubscribe, e-mail: torque-dev-unsubscribe@db.apache.org
For additional commands, e-mail: torque-dev-help@db.apache.org