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/26 19:49:15 UTC
Release Torque-4.0-alpha1 soon? & set of supported databases
I am wondering whether we should do a Torque-4.0-alpha1 release in the near
future.
In my opinion, the generator is quite stable ,the templates are also ok,
and the build tool integration seems to be working.
Nothing much has happened to the runtime, so it is not near a 4.0 release.
So this release could show where Torque 4 is heading in terms of generator
and templates, and to give folks an easy opportunity to test and find bugs.
We could release the generator, templates, maven 2 plugin and ant tasks as
4.0-alpha1, and simultaneously do a 3.3.1 release of the runtime and
village.
Of course, this would need a bit of testing and tweaking before releasing,
but do you think it is a good idea in general? I'd volunteer as release
manager.
If we do this, we still need to think about a set of supported databases.
As I have written before, I'd prefer that we only officially support
databases where we test the integration. This would mean to drop the
non-supported platform and adapter implementations.
I am prepared to test mysql, oracle, postgresql, derby (and mssql if I
must), but I will not do more than that (administrating test databases
which I do not use personally frustrates me, and I personally only use
mysql and oracle).
Does anybody think that we should support more databases and do not thest
the integration?
Or is anybody prepared to test the future release candidates against an
other database?
If we do not reach consensus here, I'd suggest to put this to a vote.
Thomas
---------------------------------------------------------------------
To unsubscribe, e-mail: torque-dev-unsubscribe@db.apache.org
For additional commands, e-mail: torque-dev-help@db.apache.org
Re: Release Torque-4.0-alpha1 soon? & set of supported databases
Posted by Thomas Fischer <fi...@seitenbau.net>.
> Scott Eade wrote
> On 28/09/10 4:03 AM, Thomas Vandahl wrote:
> > On 26.09.10 19:49, Thomas Fischer wrote:
> >> Does anybody think that we should support more databases and do not
thest
> >> the integration?
> > Testing on DB2/AS400 would be kind of a hurdle for all of us, I
believe.
> > HSQL would be worth saving, I'd say. I guess as long as we don't do bad
> > things to the SQL, we could deprecate the not listed databases systems
> > for the next release. If some user wants to contribute test results
> > and/or templates, we could remove the deprecation again.
> I support the suggested approach
As said in another e-mail in this thread, this will cause work for
migrating the templates but in my opinion will not help anybody. I'd rather
not migrate every sql templateset.
> and agree that we should if possible
> aim to retain support for HSQL.
ok I'm fine with that.
Thomas
---------------------------------------------------------------------
To unsubscribe, e-mail: torque-dev-unsubscribe@db.apache.org
For additional commands, e-mail: torque-dev-help@db.apache.org
Re: Release Torque-4.0-alpha1 soon? & set of supported databases
Posted by Scott Eade <se...@backstagetech.com.au>.
On 28/09/10 4:03 AM, Thomas Vandahl wrote:
> On 26.09.10 19:49, Thomas Fischer wrote:
>> Does anybody think that we should support more databases and do not thest
>> the integration?
> Testing on DB2/AS400 would be kind of a hurdle for all of us, I believe.
> HSQL would be worth saving, I'd say. I guess as long as we don't do bad
> things to the SQL, we could deprecate the not listed databases systems
> for the next release. If some user wants to contribute test results
> and/or templates, we could remove the deprecation again.
I support the suggested approach and agree that we should if possible
aim to retain support for HSQL.
Scott
---------------------------------------------------------------------
To unsubscribe, e-mail: torque-dev-unsubscribe@db.apache.org
For additional commands, e-mail: torque-dev-help@db.apache.org
Re: Release Torque-4.0-alpha1 soon? & set of supported databases
Posted by Thomas Fischer <fi...@seitenbau.net>.
Thomas Vandahl wrote
>
> On 30.09.10 06:40, Thomas Fischer wrote:
> > From the lack of answers to the qeustion whether or not to release
> > Torque-4.0-alpha1 soon, I conclude that the idea does not have strong
> > support and that we want to have a go at the runtime first.
>
> I'd support the idea of the generator and template release, even without
> the runtime.
Hm I messed that up. While doing the MapBuilder changes I introduced
incompatible changes to the runtime.
So I'm afraid we have to do the runtime first.
Thomas
---------------------------------------------------------------------
To unsubscribe, e-mail: torque-dev-unsubscribe@db.apache.org
For additional commands, e-mail: torque-dev-help@db.apache.org
Re: Release Torque-4.0-alpha1 soon? & set of supported databases
Posted by Thomas Vandahl <tv...@apache.org>.
On 30.09.10 06:40, Thomas Fischer wrote:
> From the lack of answers to the qeustion whether or not to release
> Torque-4.0-alpha1 soon, I conclude that the idea does not have strong
> support and that we want to have a go at the runtime first.
I'd support the idea of the generator and template release, even without
the runtime.
Bye, Thomas.
---------------------------------------------------------------------
To unsubscribe, e-mail: torque-dev-unsubscribe@db.apache.org
For additional commands, e-mail: torque-dev-help@db.apache.org
Re: Release Torque-4.0-alpha1 soon? & set of supported databases
Posted by Thomas Fischer <fi...@seitenbau.net>.
>From the lack of answers to the qeustion whether or not to release
Torque-4.0-alpha1 soon, I conclude that the idea does not have strong
support and that we want to have a go at the runtime first.
Of course, changing the runtime will also change the generated classes and
thus the templates.
How do we organize the rewriting? My fear is that if everybody changes
everything we end up in chaos, so I'd suggest as a minimum that someone who
wants to change something dicusses the change at the dev list first and
starts implementing after that discussion.
Then, maybe we could use the Wiki for an overview of plans people have and
who is doing what.
Also, discussions will come up whether or not functionality is kept or not.
In an ideal world, we would have test cases for all supported
functionality. Well, in our world, we have the test project.... In my
opinion, we should try to add test cases to check more functionality.
As we are at it, any objections against using JUnit 4.x instead of 3.8?
Also, I'd suggest some general cleanup should be done before. E.g. we
vaguely decided (at least no one objected) to drop java 1.4 support. Any
objections against removing the java5 switch from the templates(set to
"true") and using java5 generics to the runtime ?
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
How to remove village [was: Re: Release Torque-4.0-alpha1 soon? & set of
supported databases]
Posted by Thomas Fischer <fi...@seitenbau.net>.
> >> 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: Release Torque-4.0-alpha1 soon? & set of supported databases
Posted by Thomas Vandahl <tv...@apache.org>.
On 27.09.10 22:05, Thomas Fischer wrote:
>> 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.
>> This would
>> however require some changes in the runtime. 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.
---------------------------------------------------------------------
To unsubscribe, e-mail: torque-dev-unsubscribe@db.apache.org
For additional commands, e-mail: torque-dev-help@db.apache.org
Re: Release Torque-4.0-alpha1 soon? & set of supported databases
Posted by Thomas Fischer <fi...@seitenbau.net>.
> > We could release the generator, templates, maven 2 plugin and ant tasks
as
> > 4.0-alpha1, and simultaneously do a 3.3.1 release of the runtime and
> > village.
> > Of course, this would need a bit of testing and tweaking before
releasing,
> > but do you think it is a good idea in general? I'd volunteer as release
> > manager.
>
> If you actually want to do a runtime release, I'd try to have a second
> look into the village/metadata-issue.
Hm, I was thinking of doing a alpha1 release before we have a go at the
runtime.
But if you think we should change the runtime first, we can also do that.
> 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.
> This would
> however require some changes in the runtime. Anybody having a strong
> feeling against the integration of the few village-classes into the
runtime?
Yes, see above.
> > Does anybody think that we should support more databases and do not
thest
> > the integration?
>
> Testing on DB2/AS400 would be kind of a hurdle for all of us, I believe.
> HSQL would be worth saving, I'd say. I guess as long as we don't do bad
> things to the SQL, we could deprecate the not listed databases systems
> for the next release. If some user wants to contribute test results
> and/or templates, we could remove the deprecation again.
Ok, to be honest, the problem is it costs my time to migrate the templates
to the new generator. So I'd rather not migrate templates for DB2/AS400
(although its possible, just check the output against the old output),
because I do not think anybody will ever use it and it will just be a waste
of time (which I do not have plenty at the moment).
Ok, we can do HSQL, it is commonly used, but if somebody else uses any
other database we can provide docs on how to do it and see if somebody
screams. Besides, they can always use Torque 3.3
Thomas
---------------------------------------------------------------------
To unsubscribe, e-mail: torque-dev-unsubscribe@db.apache.org
For additional commands, e-mail: torque-dev-help@db.apache.org
Re: Release Torque-4.0-alpha1 soon? & set of supported databases
Posted by Thomas Vandahl <tv...@apache.org>.
On 26.09.10 19:49, Thomas Fischer wrote:
> We could release the generator, templates, maven 2 plugin and ant tasks as
> 4.0-alpha1, and simultaneously do a 3.3.1 release of the runtime and
> village.
> Of course, this would need a bit of testing and tweaking before releasing,
> but do you think it is a good idea in general? I'd volunteer as release
> manager.
If you actually want to do a runtime release, I'd try to have a second
look into the village/metadata-issue. Greg suggested to use the map
classes for the metadata which sounds quite reasonable. This would
however require some changes in the runtime. Anybody having a strong
feeling against the integration of the few village-classes into the runtime?
> Does anybody think that we should support more databases and do not thest
> the integration?
Testing on DB2/AS400 would be kind of a hurdle for all of us, I believe.
HSQL would be worth saving, I'd say. I guess as long as we don't do bad
things to the SQL, we could deprecate the not listed databases systems
for the next release. If some user wants to contribute test results
and/or templates, we could remove the deprecation again.
Bye, Thomas
---------------------------------------------------------------------
To unsubscribe, e-mail: torque-dev-unsubscribe@db.apache.org
For additional commands, e-mail: torque-dev-help@db.apache.org
Re: Release Torque-4.0-alpha1 soon? & set of supported databases
Posted by Ivano Luberti <lu...@archicoop.it>.
It was not a criticism, I would have done exactly the same thing :-) . I
cannot see myself another way to proceed.
I was just curious to know if someone has an idea of the Torque fan base.
Il 01/10/2010 9.26, Thomas Fischer ha scritto:
>>>> 3) keep the larger possible user base: in this case devs should ask the
>>>> community and then see if the requests for asked dbs are satisfiable
>>>> with the available manpower
>>>>
>>>>
>>> Good idea. I will do that.
>>>
>
>> Do you know how many people are subscribed to the user list?
>>
> No idea, sorry. But contacting the users list is the best that came to my
> mind. In all cases better than nothing.
>
> Thomas
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: torque-dev-unsubscribe@db.apache.org
> For additional commands, e-mail: torque-dev-help@db.apache.org
>
>
>
--
==================================================
dott. Ivano Mario Luberti
Archimede Informatica societa' cooperativa a r. l.
Sede Operativa
Via Gereschi 36 - 56126- Pisa
tel.: +39-050- 580959
tel/fax: +39-050-9711344
web: www.archicoop.it
==================================================
---------------------------------------------------------------------
To unsubscribe, e-mail: torque-dev-unsubscribe@db.apache.org
For additional commands, e-mail: torque-dev-help@db.apache.org
Re: Release Torque-4.0-alpha1 soon? & set of supported databases
Posted by Thomas Fischer <fi...@seitenbau.net>.
>>> 3) keep the larger possible user base: in this case devs should ask the
>>> community and then see if the requests for asked dbs are satisfiable
>>> with the available manpower
>>>
>> Good idea. I will do that.
> Do you know how many people are subscribed to the user list?
No idea, sorry. But contacting the users list is the best that came to my
mind. In all cases better than nothing.
Thomas
---------------------------------------------------------------------
To unsubscribe, e-mail: torque-dev-unsubscribe@db.apache.org
For additional commands, e-mail: torque-dev-help@db.apache.org
Re: Release Torque-4.0-alpha1 soon? & set of supported databases
Posted by Ivano Luberti <lu...@archicoop.it>.
Do you know how many people are subscribed to the user list?
Il 30/09/2010 20.57, Thomas Fischer ha scritto:
> ....
>
>> 3) keep the larger possible user base: in this case devs should ask the
>> community and then see if the requests for asked dbs are satisfiable
>> with the available manpower
>>
> Good idea. I will do that.
>
> Thomas
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: torque-dev-unsubscribe@db.apache.org
> For additional commands, e-mail: torque-dev-help@db.apache.org
>
>
>
--
==================================================
dott. Ivano Mario Luberti
Archimede Informatica societa' cooperativa a r. l.
Sede Operativa
Via Gereschi 36 - 56126- Pisa
tel.: +39-050- 580959
tel/fax: +39-050-9711344
web: www.archicoop.it
==================================================
---------------------------------------------------------------------
To unsubscribe, e-mail: torque-dev-unsubscribe@db.apache.org
For additional commands, e-mail: torque-dev-help@db.apache.org
Re: Release Torque-4.0-alpha1 soon? & set of supported databases
Posted by Thomas Fischer <fi...@seitenbau.net>.
....
> 3) keep the larger possible user base: in this case devs should ask the
> community and then see if the requests for asked dbs are satisfiable
> with the available manpower
Good idea. I will do that.
Thomas
---------------------------------------------------------------------
To unsubscribe, e-mail: torque-dev-unsubscribe@db.apache.org
For additional commands, e-mail: torque-dev-help@db.apache.org
Re: Release Torque-4.0-alpha1 soon? & set of supported databases
Posted by Ivano Luberti <lu...@archicoop.it>.
Since I have not been able to participate in the dev process I will stay
agnostic with respect to an alpha1 release. But.....
Il 26/09/2010 19.49, Thomas Fischer ha scritto:
> If we do this, we still need to think about a set of supported databases.
> As I have written before, I'd prefer that we only officially support
> databases where we test the integration. This would mean to drop the
> non-supported platform and adapter implementations.
> I am prepared to test mysql, oracle, postgresql, derby (and mssql if I
> must), but I will not do more than that (administrating test databases
> which I do not use personally frustrates me, and I personally only use
> mysql and oracle).
>
It depends on what Torque devs aim at:
1) keep the software update for their own use: then the answer is
support only the one that devs want to be supported
2) spread the verb of Torque around the world: then the answer is no,
then the answer is support all the db that devs are operatively able to
test (obtaining a licence, install it, etc etc)
3) keep the larger possible user base: in this case devs should ask the
community and then see if the requests for asked dbs are satisfiable
with the available manpower
For what I have understood of the Torque community, I think that
adopting 1) will not encounter many objections by the community.
--
==================================================
dott. Ivano Mario Luberti
Archimede Informatica societa' cooperativa a r. l.
Sede Operativa
Via Gereschi 36 - 56126- Pisa
tel.: +39-050- 580959
tel/fax: +39-050-9711344
web: www.archicoop.it
==================================================
---------------------------------------------------------------------
To unsubscribe, e-mail: torque-dev-unsubscribe@db.apache.org
For additional commands, e-mail: torque-dev-help@db.apache.org