db-torque-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Thomas Fischer <fisc...@seitenbau.net>
Subject How to remove village [was: Re: Release Torque-4.0-alpha1 soon? & set of supported databases]
Date Thu, 30 Sep 2010 04:20:37 GMT
> >> 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
> > 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
        return BookPeer.populateObjects(
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
        List<Book> result = new ArrayList<Book>();
        while (resultSet.next)
        return result;

   // Mapper can be a static inner class of Peer class but this is no
   // 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;

// 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 ?


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

View raw message