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 Fabio Insaccanebbia <fi...@gmail.com> on 2005/04/25 19:39:48 UTC
Torque and Village
Hi everybody,
I've tried to make a patch and solve a couple of Torque problems with Oracle Integration (DATE and BLOB management) and it turned out that they are dependent on some Village choices (*). I tried to write some patch but unfortunately there's no way to contribute them back because Village project is no longer mantained.
I read on the mailing list that this issue has been already raised and the last news were that someone was trying to "fork" it. There has been some progress in this task? Have somebody contacted the author to hear if he would allow us to contribute patches by putting the code on a read-write cvs?
I mean: it is not necessary to ask to donate the code to Apache Foundation. It would be sufficient to put the code on a developer site who could host it and allow developers to contribute back patches. Otherwise the only other options are:
- forking (into the Torque project?)
- replacing it with another DB Layer (any proposal?)
- write a Torque DB Layer (could it mimic Village API? and use the original Village jar to have a "compatibility layer"?)
Any feedback?
Thanks,
Fabio
(*) they aren't Village "bugs". They would work if every RDBMS in the world fully respected ANSI SQL specifications and the JDBC drivers would be fully compliant... unfortunately, that's not the case :-(
--
Fabio Insaccanebbia
INSAC.COM
e-mail: finsaccanebbia@insac.com - URL: http://www.insac.com
<http://www.insac.com/>
---------------------------------------------------------------------
To unsubscribe, e-mail: torque-dev-unsubscribe@db.apache.org
For additional commands, e-mail: torque-dev-help@db.apache.org
Re: Torque and Village
Posted by Thomas Dudziak <to...@gmail.com>.
> 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
Btw, there is also DbUtils over in commons which does things that
DdlUtils won't do, e.g. simple statements (select/update/delete etc.)
concerning data in the model (whereas DdlUtils concerns itself
primarily with the Database Model itself).
> 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 :-(.
IMO the database model used by DdlUtils is so simple that it should be
usable by Torque as well ?
> 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.
One thing that is probably quite useful to Torque users is the ability
to alter a schema (without losing data) ?!
> 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.
John McNally asked for it when requesting the mailing list creation,
but it seems it is not in place yet. There is a infrastructure issue
for it: http://issues.apache.org/jira/browse/INFRA-314
Tom
Re: Torque and Village
Posted by Thomas Fischer <fi...@seitenbau.net>.
I also think that it is a good idea to create an interface, the reasons for
it have already been summarized by Fabio and Martin.
The following is my personal opinion about how to deal with (the removal
of) village, if someone else has a better solution, I'll be happy to accept
it.
In my personal there already exists an interface which satisfies almoast
all needs of Torque - the jdbc interface. I'll try to explain that a bit:
For processing selects, village uses an object called Value, which can do
conversions between java types and sql types. The functionality most used
in Torque is that a Value can hold any sql type that might come along, and
the user can convert it to the appropriate java type later. For this, it
needs to be supplied with the sql type, whis is obtained by village by
querying the sql metadata of a select statement.
This behaviour might be useful for other db layers, but in case of Torque,
the Torque runtime already knows which java type is needed, there is no
need to query the metadata. Instead it causes problems, see e.g.
http://issues.apache.org/scarab/issues/id/TRQS285.
To me, the most satisfactory solution would be to dispose of the Value
object altogether, and work with jdbc ResultSets on the query side. This is
not as easy at it seems, as some parts of Torque rely heavily on the value
concept (for example the IdGenerator interface)
For performing inserts/updates, village has got two functions :
1) create the sql for a prepared statement for the insert/update
2) fill the prepared statement with the appropriate values
We would need to define an interface for 1) Then e.g. ddlutils could be
used for that. The interface for 2) could be the jdbc PreparedStatement.
Maybe some wrapper around the PreparedStatement interface must be written
in order to deal with the LOB issues in oracle.
But this kind of solution is certainly not compatible with the village api.
So the idea of a gradual refactoring seems intriguing at first, but will be
lost work if the final solutions should be something as I have sketched
above.
Again, this is just my personal opinion, but it seems to me that some
careful thinking is needed before one rushes off and creates an interface.
If someone has another suggestion for an interface, I'll be glad to hear
it. I will support any sensible way to deal with the village problems.
Thomas
Martin Kalén <mk...@apache.org> schrieb am 02.05.2005 11:29:56:
> Fabio Insaccanebbia wrote:
> > suggestion: what about a "pluggable" dblayer for Torques?
>
> +1 I think this idea is brilliant!
>
> > We could design the API that Torque needs, create a Village Adapter
(for
> > compatibility with the past) a DdlUtils based db layer and, if we need
a
> > "custom - made" dblayer, we can write our own (or we can find a
> > new/better in the Open Source space).
> >
> > So we can start with Village (putting our patches in the "Adapter"
layer
> > if we really want to) [short time effort], then start an effort to
write
> > the DdlUtils based db layer [medium time effort] and see what happens
> > next.. [long time effort... Torque's own dblayer... only if necessary].
>
> That's IMHO a perfect approach since:
>
> *) work can start immediately
>
> *) it will be crystal clear exactly how Torque is dependent on Village
>
> *) no more "get the patched Village here"; as you say, the patches
> can be maintained in the Torque adapter layer
> (Torque+Village=only 2 code repositories instead of current 3)
>
> *) making this work for Village in the existing code will prepare for
> DdlUtils "plug-in" later
>
> > Obviously the difficult thing would be to create an API that makes
> > simple to create adapters both for Village and DdlUtils (thus without
> > complex hierarchy, with the minimum API objects number).
>
> Since this API is 100% internal there will be lots of room for
refactoring
> later. Starting with Village will be a good first try, trying to plug in
> DdlUtils later -- with some additional API refactorings if needed -- will
> make the DB layer API even better (as will be the case for each new
> added product).
>
> > P.S.: I'm just talking about the functions currently covered in Torque
> > by Village.
> > Torque and DdlUtils can concentrate efforts also in other "use cases"
> > probably without having to add an Adapter...
>
> Agree fully. There is nothing wrong with having both a pluggable DB layer
> adapter for DdlUtils and some other direct compile-time depdencies on
> different areas of the same package.
>
> If you guys decide that this is the way to go, I would be happy to
> help you with any code I can contribute with!
>
> Regards,
> Martin
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: torque-dev-unsubscribe@db.apache.org
> For additional commands, e-mail: torque-dev-help@db.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: torque-dev-unsubscribe@db.apache.org
For additional commands, e-mail: torque-dev-help@db.apache.org
Re: Torque and Village
Posted by Martin Kalén <mk...@apache.org>.
Fabio Insaccanebbia wrote:
> suggestion: what about a "pluggable" dblayer for Torques?
+1 I think this idea is brilliant!
> We could design the API that Torque needs, create a Village Adapter (for
> compatibility with the past) a DdlUtils based db layer and, if we need a
> "custom - made" dblayer, we can write our own (or we can find a
> new/better in the Open Source space).
>
> So we can start with Village (putting our patches in the "Adapter" layer
> if we really want to) [short time effort], then start an effort to write
> the DdlUtils based db layer [medium time effort] and see what happens
> next.. [long time effort... Torque's own dblayer... only if necessary].
That's IMHO a perfect approach since:
*) work can start immediately
*) it will be crystal clear exactly how Torque is dependent on Village
*) no more "get the patched Village here"; as you say, the patches
can be maintained in the Torque adapter layer
(Torque+Village=only 2 code repositories instead of current 3)
*) making this work for Village in the existing code will prepare for
DdlUtils "plug-in" later
> Obviously the difficult thing would be to create an API that makes
> simple to create adapters both for Village and DdlUtils (thus without
> complex hierarchy, with the minimum API objects number).
Since this API is 100% internal there will be lots of room for refactoring
later. Starting with Village will be a good first try, trying to plug in
DdlUtils later -- with some additional API refactorings if needed -- will
make the DB layer API even better (as will be the case for each new
added product).
> P.S.: I'm just talking about the functions currently covered in Torque
> by Village.
> Torque and DdlUtils can concentrate efforts also in other "use cases"
> probably without having to add an Adapter...
Agree fully. There is nothing wrong with having both a pluggable DB layer
adapter for DdlUtils and some other direct compile-time depdencies on
different areas of the same package.
If you guys decide that this is the way to go, I would be happy to
help you with any code I can contribute with!
Regards,
Martin
---------------------------------------------------------------------
To unsubscribe, e-mail: torque-dev-unsubscribe@db.apache.org
For additional commands, e-mail: torque-dev-help@db.apache.org
Re: Torque and Village
Posted by Fabio Insaccanebbia <fi...@gmail.com>.
suggestion: what about a "pluggable" dblayer for Torques?
We could design the API that Torque needs, create a Village Adapter (for
compatibility with the past) a DdlUtils based db layer and, if we need a
"custom - made" dblayer, we can write our own (or we can find a
new/better in the Open Source space).
So we can start with Village (putting our patches in the "Adapter" layer
if we really want to) [short time effort], then start an effort to write
the DdlUtils based db layer [medium time effort] and see what happens
next.. [long time effort... Torque's own dblayer... only if necessary].
Obviously the difficult thing would be to create an API that makes simple
to create adapters both for Village and DdlUtils (thus without complex hierarchy,
with the minimum API objects number).
Bye,
Fabio
P.S.: I'm just talking about the functions currently covered in Torque by Village.
Torque and DdlUtils can concentrate efforts also in other "use cases" probably without
having to add an Adapter...
Thomas Fischer wrote:
>
>
>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.
>
> Thomas
>
>
>Thomas Dudziak <to...@gmail.com> schrieb am 26.04.2005 14:12:24:
>
>
>
>>>To prevent duplicate development efforts, also note that the project
>>>previously known as "Jakarta Commons SQL" has graduated from the
>>>
>>>
>Jakarta
>
>
>>>Commons sandbox into a fully-fledged Apache DB-project "DdlUtils" [1]
>>>with it's own website and mailinglists [2]
>>>(last migration steps are still in progress, some "dust" still in the
>>>
>>>
>air).
>
>
>>>Tom Dudziak has more info about this and can probably tell more about
>>>if there is some overlapping Village / DdlUtils functionality
>>>(which I believe).
>>>
>>>If that is the case, I would suggest Torque developers to come join
>>>the new DdlUtils project to help create a well-maintained and active
>>>developer base (instead of breathing air into the "corpse" of Village).
>>>
>>>Disclaimer: I think that this might be a Good Thing (TM) for Torque,
>>>but it might turn out that DdlUtils have nothing at all in common
>>>with Village (Tom?) -- in which case you can just ignore this post. :-)
>>>
>>>
>>I fully agree and AFAIK the possible synergy effect was one of the
>>reasons that the vote on the DB PMC regarding the move was
>>unanimously.
>>Also that's why the major point on my short-term to-do list is the
>>stabilization of DdlUtils including Unit tests for the individual
>>databases (in which it currently is somewhat lacking) and enhance the
>>doc, in order to release a 1.0 in the near future.
>>IMO it's probably useful to create a Wiki page for DdlUtils on which
>>to sketch these todos, so I'll create one.
>>
>>Btw, John McNally already gave these Torque developers commit rights
>>to DdlUtils :
>>
>>seade,henning,tfischer
>>
>>(as he wrote on the PMC).
>>
>>Tom
>>
>>---------------------------------------------------------------------
>>To unsubscribe, e-mail: torque-dev-unsubscribe@db.apache.org
>>For additional commands, e-mail: torque-dev-help@db.apache.org
>>
>>
>>
>
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: torque-dev-unsubscribe@db.apache.org
>For additional commands, e-mail: torque-dev-help@db.apache.org
>
>
>
>
--
Fabio Insaccanebbia
INSAC.COM
e-mail: finsaccanebbia@insac.com - URL: http://www.insac.com
<http://www.insac.com/>
Re: Torque and Village
Posted by Fabio Insaccanebbia <fi...@gmail.com>.
suggestion: what about a "pluggable" dblayer for Torques?
We could design the API that Torque needs, create a Village Adapter (for
compatibility with the past) a DdlUtils based db layer and, if we need a
"custom - made" dblayer, we can write our own (or we can find a
new/better in the Open Source space).
So we can start with Village (putting our patches in the "Adapter" layer
if we really want to) [short time effort], then start an effort to write
the DdlUtils based db layer [medium time effort] and see what happens
next.. [long time effort... Torque's own dblayer... only if necessary].
Obviously the difficult thing would be to create an API that makes simple
to create adapters both for Village and DdlUtils (thus without complex hierarchy,
with the minimum API objects number).
Bye,
Fabio
P.S.: I'm just talking about the functions currently covered in Torque by Village.
Torque and DdlUtils can concentrate efforts also in other "use cases" probably without
having to add an Adapter...
Thomas Fischer wrote:
>
>
>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.
>
> Thomas
>
>
>Thomas Dudziak <to...@gmail.com> schrieb am 26.04.2005 14:12:24:
>
>
>
>>>To prevent duplicate development efforts, also note that the project
>>>previously known as "Jakarta Commons SQL" has graduated from the
>>>
>>>
>Jakarta
>
>
>>>Commons sandbox into a fully-fledged Apache DB-project "DdlUtils" [1]
>>>with it's own website and mailinglists [2]
>>>(last migration steps are still in progress, some "dust" still in the
>>>
>>>
>air).
>
>
>>>Tom Dudziak has more info about this and can probably tell more about
>>>if there is some overlapping Village / DdlUtils functionality
>>>(which I believe).
>>>
>>>If that is the case, I would suggest Torque developers to come join
>>>the new DdlUtils project to help create a well-maintained and active
>>>developer base (instead of breathing air into the "corpse" of Village).
>>>
>>>Disclaimer: I think that this might be a Good Thing (TM) for Torque,
>>>but it might turn out that DdlUtils have nothing at all in common
>>>with Village (Tom?) -- in which case you can just ignore this post. :-)
>>>
>>>
>>I fully agree and AFAIK the possible synergy effect was one of the
>>reasons that the vote on the DB PMC regarding the move was
>>unanimously.
>>Also that's why the major point on my short-term to-do list is the
>>stabilization of DdlUtils including Unit tests for the individual
>>databases (in which it currently is somewhat lacking) and enhance the
>>doc, in order to release a 1.0 in the near future.
>>IMO it's probably useful to create a Wiki page for DdlUtils on which
>>to sketch these todos, so I'll create one.
>>
>>Btw, John McNally already gave these Torque developers commit rights
>>to DdlUtils :
>>
>>seade,henning,tfischer
>>
>>(as he wrote on the PMC).
>>
>>Tom
>>
>>---------------------------------------------------------------------
>>To unsubscribe, e-mail: torque-dev-unsubscribe@db.apache.org
>>For additional commands, e-mail: torque-dev-help@db.apache.org
>>
>>
>>
>
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: torque-dev-unsubscribe@db.apache.org
>For additional commands, e-mail: torque-dev-help@db.apache.org
>
>
>
>
--
Fabio Insaccanebbia
INSAC.COM
e-mail: finsaccanebbia@insac.com - URL: http://www.insac.com
<http://www.insac.com/>
---------------------------------------------------------------------
To unsubscribe, e-mail: torque-dev-unsubscribe@db.apache.org
For additional commands, e-mail: torque-dev-help@db.apache.org
Re: Torque and Village
Posted by Thomas Fischer <fi...@seitenbau.net>.
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 <fi...@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
Re: Torque and Village
Posted by Thomas Fischer <fi...@seitenbau.net>.
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.
Thomas
Thomas Dudziak <to...@gmail.com> schrieb am 26.04.2005 14:12:24:
> > To prevent duplicate development efforts, also note that the project
> > previously known as "Jakarta Commons SQL" has graduated from the
Jakarta
> > Commons sandbox into a fully-fledged Apache DB-project "DdlUtils" [1]
> > with it's own website and mailinglists [2]
> > (last migration steps are still in progress, some "dust" still in the
air).
> >
> > Tom Dudziak has more info about this and can probably tell more about
> > if there is some overlapping Village / DdlUtils functionality
> > (which I believe).
> >
> > If that is the case, I would suggest Torque developers to come join
> > the new DdlUtils project to help create a well-maintained and active
> > developer base (instead of breathing air into the "corpse" of Village).
> >
> > Disclaimer: I think that this might be a Good Thing (TM) for Torque,
> > but it might turn out that DdlUtils have nothing at all in common
> > with Village (Tom?) -- in which case you can just ignore this post. :-)
>
> I fully agree and AFAIK the possible synergy effect was one of the
> reasons that the vote on the DB PMC regarding the move was
> unanimously.
> Also that's why the major point on my short-term to-do list is the
> stabilization of DdlUtils including Unit tests for the individual
> databases (in which it currently is somewhat lacking) and enhance the
> doc, in order to release a 1.0 in the near future.
> IMO it's probably useful to create a Wiki page for DdlUtils on which
> to sketch these todos, so I'll create one.
>
> Btw, John McNally already gave these Torque developers commit rights
> to DdlUtils :
>
> seade,henning,tfischer
>
> (as he wrote on the PMC).
>
> Tom
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: torque-dev-unsubscribe@db.apache.org
> For additional commands, e-mail: torque-dev-help@db.apache.org
>
Re: Torque and Village
Posted by Thomas Fischer <fi...@seitenbau.net>.
Tom, Martin,
Thanks for the information. I'll have a look at DdlUtils and write up what
possible synergies exist in my opinion. I'd appreciate it if other Torque
developers would do the same in order to get more than one opinion.
Thomas
Thomas Dudziak <to...@gmail.com> schrieb am 26.04.2005 14:12:24:
> > To prevent duplicate development efforts, also note that the project
> > previously known as "Jakarta Commons SQL" has graduated from the
Jakarta
> > Commons sandbox into a fully-fledged Apache DB-project "DdlUtils" [1]
> > with it's own website and mailinglists [2]
> > (last migration steps are still in progress, some "dust" still in the
air).
> >
> > Tom Dudziak has more info about this and can probably tell more about
> > if there is some overlapping Village / DdlUtils functionality
> > (which I believe).
> >
> > If that is the case, I would suggest Torque developers to come join
> > the new DdlUtils project to help create a well-maintained and active
> > developer base (instead of breathing air into the "corpse" of Village).
> >
> > Disclaimer: I think that this might be a Good Thing (TM) for Torque,
> > but it might turn out that DdlUtils have nothing at all in common
> > with Village (Tom?) -- in which case you can just ignore this post. :-)
>
> I fully agree and AFAIK the possible synergy effect was one of the
> reasons that the vote on the DB PMC regarding the move was
> unanimously.
> Also that's why the major point on my short-term to-do list is the
> stabilization of DdlUtils including Unit tests for the individual
> databases (in which it currently is somewhat lacking) and enhance the
> doc, in order to release a 1.0 in the near future.
> IMO it's probably useful to create a Wiki page for DdlUtils on which
> to sketch these todos, so I'll create one.
>
> Btw, John McNally already gave these Torque developers commit rights
> to DdlUtils :
>
> seade,henning,tfischer
>
> (as he wrote on the PMC).
>
> Tom
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: torque-dev-unsubscribe@db.apache.org
> For additional commands, e-mail: torque-dev-help@db.apache.org
>
Re: Torque and Village
Posted by Thomas Fischer <fi...@seitenbau.net>.
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.
Thomas
Thomas Dudziak <to...@gmail.com> schrieb am 26.04.2005 14:12:24:
> > To prevent duplicate development efforts, also note that the project
> > previously known as "Jakarta Commons SQL" has graduated from the
Jakarta
> > Commons sandbox into a fully-fledged Apache DB-project "DdlUtils" [1]
> > with it's own website and mailinglists [2]
> > (last migration steps are still in progress, some "dust" still in the
air).
> >
> > Tom Dudziak has more info about this and can probably tell more about
> > if there is some overlapping Village / DdlUtils functionality
> > (which I believe).
> >
> > If that is the case, I would suggest Torque developers to come join
> > the new DdlUtils project to help create a well-maintained and active
> > developer base (instead of breathing air into the "corpse" of Village).
> >
> > Disclaimer: I think that this might be a Good Thing (TM) for Torque,
> > but it might turn out that DdlUtils have nothing at all in common
> > with Village (Tom?) -- in which case you can just ignore this post. :-)
>
> I fully agree and AFAIK the possible synergy effect was one of the
> reasons that the vote on the DB PMC regarding the move was
> unanimously.
> Also that's why the major point on my short-term to-do list is the
> stabilization of DdlUtils including Unit tests for the individual
> databases (in which it currently is somewhat lacking) and enhance the
> doc, in order to release a 1.0 in the near future.
> IMO it's probably useful to create a Wiki page for DdlUtils on which
> to sketch these todos, so I'll create one.
>
> Btw, John McNally already gave these Torque developers commit rights
> to DdlUtils :
>
> seade,henning,tfischer
>
> (as he wrote on the PMC).
>
> Tom
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: torque-dev-unsubscribe@db.apache.org
> For additional commands, e-mail: torque-dev-help@db.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: torque-dev-unsubscribe@db.apache.org
For additional commands, e-mail: torque-dev-help@db.apache.org
Re: Torque and Village
Posted by Thomas Fischer <fi...@seitenbau.net>.
Tom, Martin,
Thanks for the information. I'll have a look at DdlUtils and write up what
possible synergies exist in my opinion. I'd appreciate it if other Torque
developers would do the same in order to get more than one opinion.
Thomas
Thomas Dudziak <to...@gmail.com> schrieb am 26.04.2005 14:12:24:
> > To prevent duplicate development efforts, also note that the project
> > previously known as "Jakarta Commons SQL" has graduated from the
Jakarta
> > Commons sandbox into a fully-fledged Apache DB-project "DdlUtils" [1]
> > with it's own website and mailinglists [2]
> > (last migration steps are still in progress, some "dust" still in the
air).
> >
> > Tom Dudziak has more info about this and can probably tell more about
> > if there is some overlapping Village / DdlUtils functionality
> > (which I believe).
> >
> > If that is the case, I would suggest Torque developers to come join
> > the new DdlUtils project to help create a well-maintained and active
> > developer base (instead of breathing air into the "corpse" of Village).
> >
> > Disclaimer: I think that this might be a Good Thing (TM) for Torque,
> > but it might turn out that DdlUtils have nothing at all in common
> > with Village (Tom?) -- in which case you can just ignore this post. :-)
>
> I fully agree and AFAIK the possible synergy effect was one of the
> reasons that the vote on the DB PMC regarding the move was
> unanimously.
> Also that's why the major point on my short-term to-do list is the
> stabilization of DdlUtils including Unit tests for the individual
> databases (in which it currently is somewhat lacking) and enhance the
> doc, in order to release a 1.0 in the near future.
> IMO it's probably useful to create a Wiki page for DdlUtils on which
> to sketch these todos, so I'll create one.
>
> Btw, John McNally already gave these Torque developers commit rights
> to DdlUtils :
>
> seade,henning,tfischer
>
> (as he wrote on the PMC).
>
> Tom
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: torque-dev-unsubscribe@db.apache.org
> For additional commands, e-mail: torque-dev-help@db.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: torque-dev-unsubscribe@db.apache.org
For additional commands, e-mail: torque-dev-help@db.apache.org
Re: Torque and Village
Posted by Thomas Dudziak <to...@gmail.com>.
> To prevent duplicate development efforts, also note that the project
> previously known as "Jakarta Commons SQL" has graduated from the Jakarta
> Commons sandbox into a fully-fledged Apache DB-project "DdlUtils" [1]
> with it's own website and mailinglists [2]
> (last migration steps are still in progress, some "dust" still in the air).
>
> Tom Dudziak has more info about this and can probably tell more about
> if there is some overlapping Village / DdlUtils functionality
> (which I believe).
>
> If that is the case, I would suggest Torque developers to come join
> the new DdlUtils project to help create a well-maintained and active
> developer base (instead of breathing air into the "corpse" of Village).
>
> Disclaimer: I think that this might be a Good Thing (TM) for Torque,
> but it might turn out that DdlUtils have nothing at all in common
> with Village (Tom?) -- in which case you can just ignore this post. :-)
I fully agree and AFAIK the possible synergy effect was one of the
reasons that the vote on the DB PMC regarding the move was
unanimously.
Also that's why the major point on my short-term to-do list is the
stabilization of DdlUtils including Unit tests for the individual
databases (in which it currently is somewhat lacking) and enhance the
doc, in order to release a 1.0 in the near future.
IMO it's probably useful to create a Wiki page for DdlUtils on which
to sketch these todos, so I'll create one.
Btw, John McNally already gave these Torque developers commit rights
to DdlUtils :
seade,henning,tfischer
(as he wrote on the PMC).
Tom
Re: Torque and Village
Posted by Thomas Dudziak <to...@gmail.com>.
> To prevent duplicate development efforts, also note that the project
> previously known as "Jakarta Commons SQL" has graduated from the Jakarta
> Commons sandbox into a fully-fledged Apache DB-project "DdlUtils" [1]
> with it's own website and mailinglists [2]
> (last migration steps are still in progress, some "dust" still in the air).
>
> Tom Dudziak has more info about this and can probably tell more about
> if there is some overlapping Village / DdlUtils functionality
> (which I believe).
>
> If that is the case, I would suggest Torque developers to come join
> the new DdlUtils project to help create a well-maintained and active
> developer base (instead of breathing air into the "corpse" of Village).
>
> Disclaimer: I think that this might be a Good Thing (TM) for Torque,
> but it might turn out that DdlUtils have nothing at all in common
> with Village (Tom?) -- in which case you can just ignore this post. :-)
I fully agree and AFAIK the possible synergy effect was one of the
reasons that the vote on the DB PMC regarding the move was
unanimously.
Also that's why the major point on my short-term to-do list is the
stabilization of DdlUtils including Unit tests for the individual
databases (in which it currently is somewhat lacking) and enhance the
doc, in order to release a 1.0 in the near future.
IMO it's probably useful to create a Wiki page for DdlUtils on which
to sketch these todos, so I'll create one.
Btw, John McNally already gave these Torque developers commit rights
to DdlUtils :
seade,henning,tfischer
(as he wrote on the PMC).
Tom
---------------------------------------------------------------------
To unsubscribe, e-mail: torque-dev-unsubscribe@db.apache.org
For additional commands, e-mail: torque-dev-help@db.apache.org
Re: Torque and Village
Posted by Martin Kalén <mk...@apache.org>.
To prevent duplicate development efforts, also note that the project
previously known as "Jakarta Commons SQL" has graduated from the Jakarta
Commons sandbox into a fully-fledged Apache DB-project "DdlUtils" [1]
with it's own website and mailinglists [2]
(last migration steps are still in progress, some "dust" still in the air).
Tom Dudziak has more info about this and can probably tell more about
if there is some overlapping Village / DdlUtils functionality
(which I believe).
If that is the case, I would suggest Torque developers to come join
the new DdlUtils project to help create a well-maintained and active
developer base (instead of breathing air into the "corpse" of Village).
Disclaimer: I think that this might be a Good Thing (TM) for Torque,
but it might turn out that DdlUtils have nothing at all in common
with Village (Tom?) -- in which case you can just ignore this post. :-)
The following developers are on the initial committer-list of DdlUtils:
tomdz,mkalen,thma,brj,arminw,brianm,mattbaird,rsfeir
Regards,
Martin
[1] http://db.apache.org/ddlutils/
[2] mailto:ddlutils-dev-subscribe@db.apache.org, mailto:ddlutils-user-subscribe@db.apache.org
Thomas Fischer wrote:
>
> Hi,
>
> In my personal opinion, forking village would be a good short-term solution
> (because currently Torque as not got the manpower to rewrite the DB
> Access). It would alleviate the problem that at the moment, there is no
> central place to collect village patches. Therefore, I would support such a
> step.
>
> In the long term, however, I believe that village should not be used in
> Torque anymore, but that the code should be rewritten inside Torque. The
> reasons are the following shortcomings of village:
>
> - Village uses jdbc metadata to collect information about the database.
> However, with Torque, this is completely unneccessary as the information
> about the database is already collected in the generated MapBuilders.
>
> - Village does not know about different databases accessed by it. This
> leads to errors like http://issues.apache.org/scarab/issues/id/TRQS285 .
>
> - Village does not log the statements it uses for inserts and updates,
> making debugging difficult.
>
> Thomas
>
> Hendrik Busch <he...@lexisnexis.de> schrieb am 26.04.2005 09:39:12:
>
>
>>Hi!
>>
>>
>>>I've tried to make a patch and solve a couple of Torque problems with
>>>Oracle Integration (DATE and BLOB management) and it turned out that
>>>they are dependent on some Village choices (*). I tried to write some
>>>patch but unfortunately there's no way to contribute them back because
>>>Village project is no longer mantained.
>>
>>Looks like we did the same thing :-). We're currently porting our
>>document management system from MySQL to Oracle and needed to fix some
>>weaknesses in Village, too, mainly LOB-related stuff.
>>
>>
>>>I read on the mailing list that this issue has been already raised and
>>>the last news were that someone was trying to "fork" it. There has been
>
>
>>>some progress in this task? Have somebody contacted the author to hear
>>>if he would allow us to contribute patches by putting the code on a
>>>read-write cvs?
>>
>>I sent an email to jon (at) latchkey.com as we would have liked to
>>contribute our modifications as well. Yet I have received no reply until
>>now (or maybe our company-spam-cop caught that mail due to some reason).
>>
>>The fork seems to be a good idea since many people are still using
>>Village, even without Torque. So if we pull together, maybe we can
>>achieve a reactivation.
>>
>>So long,
>>Hendrik Busch
>>
>>--
>>Mit freundlichen Grüßen / Kind regards
>>
>>Hendrik Busch - Teamleiter LexisNexis Recht Entwicklung
>>
>>LexisNexis Deutschland GmbH
>>http://www.lexisnexis.de
>>Feldstiege 100
>>D-48161 Münster
>>phone +49 (0) 2533-9300-455
>>fax +49 (0) 02533-9300-50
>>hendrik.busch@lexisnexis.de
---------------------------------------------------------------------
To unsubscribe, e-mail: torque-dev-unsubscribe@db.apache.org
For additional commands, e-mail: torque-dev-help@db.apache.org
Re: Torque and Village
Posted by Martin Kalén <mk...@apache.org>.
To prevent duplicate development efforts, also note that the project
previously known as "Jakarta Commons SQL" has graduated from the Jakarta
Commons sandbox into a fully-fledged Apache DB-project "DdlUtils" [1]
with it's own website and mailinglists [2]
(last migration steps are still in progress, some "dust" still in the air).
Tom Dudziak has more info about this and can probably tell more about
if there is some overlapping Village / DdlUtils functionality
(which I believe).
If that is the case, I would suggest Torque developers to come join
the new DdlUtils project to help create a well-maintained and active
developer base (instead of breathing air into the "corpse" of Village).
Disclaimer: I think that this might be a Good Thing (TM) for Torque,
but it might turn out that DdlUtils have nothing at all in common
with Village (Tom?) -- in which case you can just ignore this post. :-)
The following developers are on the initial committer-list of DdlUtils:
tomdz,mkalen,thma,brj,arminw,brianm,mattbaird,rsfeir
Regards,
Martin
[1] http://db.apache.org/ddlutils/
[2] mailto:ddlutils-dev-subscribe@db.apache.org, mailto:ddlutils-user-subscribe@db.apache.org
Thomas Fischer wrote:
>
> Hi,
>
> In my personal opinion, forking village would be a good short-term solution
> (because currently Torque as not got the manpower to rewrite the DB
> Access). It would alleviate the problem that at the moment, there is no
> central place to collect village patches. Therefore, I would support such a
> step.
>
> In the long term, however, I believe that village should not be used in
> Torque anymore, but that the code should be rewritten inside Torque. The
> reasons are the following shortcomings of village:
>
> - Village uses jdbc metadata to collect information about the database.
> However, with Torque, this is completely unneccessary as the information
> about the database is already collected in the generated MapBuilders.
>
> - Village does not know about different databases accessed by it. This
> leads to errors like http://issues.apache.org/scarab/issues/id/TRQS285 .
>
> - Village does not log the statements it uses for inserts and updates,
> making debugging difficult.
>
> Thomas
>
> Hendrik Busch <he...@lexisnexis.de> schrieb am 26.04.2005 09:39:12:
>
>
>>Hi!
>>
>>
>>>I've tried to make a patch and solve a couple of Torque problems with
>>>Oracle Integration (DATE and BLOB management) and it turned out that
>>>they are dependent on some Village choices (*). I tried to write some
>>>patch but unfortunately there's no way to contribute them back because
>>>Village project is no longer mantained.
>>
>>Looks like we did the same thing :-). We're currently porting our
>>document management system from MySQL to Oracle and needed to fix some
>>weaknesses in Village, too, mainly LOB-related stuff.
>>
>>
>>>I read on the mailing list that this issue has been already raised and
>>>the last news were that someone was trying to "fork" it. There has been
>
>
>>>some progress in this task? Have somebody contacted the author to hear
>>>if he would allow us to contribute patches by putting the code on a
>>>read-write cvs?
>>
>>I sent an email to jon (at) latchkey.com as we would have liked to
>>contribute our modifications as well. Yet I have received no reply until
>>now (or maybe our company-spam-cop caught that mail due to some reason).
>>
>>The fork seems to be a good idea since many people are still using
>>Village, even without Torque. So if we pull together, maybe we can
>>achieve a reactivation.
>>
>>So long,
>>Hendrik Busch
>>
>>--
>>Mit freundlichen Grüßen / Kind regards
>>
>>Hendrik Busch - Teamleiter LexisNexis Recht Entwicklung
>>
>>LexisNexis Deutschland GmbH
>>http://www.lexisnexis.de
>>Feldstiege 100
>>D-48161 Münster
>>phone +49 (0) 2533-9300-455
>>fax +49 (0) 02533-9300-50
>>hendrik.busch@lexisnexis.de
Re: Torque and Village
Posted by Thomas Fischer <fi...@seitenbau.net>.
Hi,
In my personal opinion, forking village would be a good short-term solution
(because currently Torque as not got the manpower to rewrite the DB
Access). It would alleviate the problem that at the moment, there is no
central place to collect village patches. Therefore, I would support such a
step.
In the long term, however, I believe that village should not be used in
Torque anymore, but that the code should be rewritten inside Torque. The
reasons are the following shortcomings of village:
- Village uses jdbc metadata to collect information about the database.
However, with Torque, this is completely unneccessary as the information
about the database is already collected in the generated MapBuilders.
- Village does not know about different databases accessed by it. This
leads to errors like http://issues.apache.org/scarab/issues/id/TRQS285 .
- Village does not log the statements it uses for inserts and updates,
making debugging difficult.
Thomas
Hendrik Busch <he...@lexisnexis.de> schrieb am 26.04.2005 09:39:12:
> Hi!
>
> > I've tried to make a patch and solve a couple of Torque problems with
> > Oracle Integration (DATE and BLOB management) and it turned out that
> > they are dependent on some Village choices (*). I tried to write some
> > patch but unfortunately there's no way to contribute them back because
> > Village project is no longer mantained.
>
> Looks like we did the same thing :-). We're currently porting our
> document management system from MySQL to Oracle and needed to fix some
> weaknesses in Village, too, mainly LOB-related stuff.
>
> > I read on the mailing list that this issue has been already raised and
> > the last news were that someone was trying to "fork" it. There has been
> > some progress in this task? Have somebody contacted the author to hear
> > if he would allow us to contribute patches by putting the code on a
> > read-write cvs?
>
> I sent an email to jon (at) latchkey.com as we would have liked to
> contribute our modifications as well. Yet I have received no reply until
> now (or maybe our company-spam-cop caught that mail due to some reason).
>
> The fork seems to be a good idea since many people are still using
> Village, even without Torque. So if we pull together, maybe we can
> achieve a reactivation.
>
> So long,
> Hendrik Busch
>
> --
> Mit freundlichen Grüßen / Kind regards
>
> Hendrik Busch - Teamleiter LexisNexis Recht Entwicklung
>
> LexisNexis Deutschland GmbH
> http://www.lexisnexis.de
> Feldstiege 100
> D-48161 Münster
> phone +49 (0) 2533-9300-455
> fax +49 (0) 02533-9300-50
> hendrik.busch@lexisnexis.de
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: torque-dev-unsubscribe@db.apache.org
> For additional commands, e-mail: torque-dev-help@db.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: torque-dev-unsubscribe@db.apache.org
For additional commands, e-mail: torque-dev-help@db.apache.org
Re: Torque and Village
Posted by Hendrik Busch <he...@lexisnexis.de>.
Hi!
> I've tried to make a patch and solve a couple of Torque problems with
> Oracle Integration (DATE and BLOB management) and it turned out that
> they are dependent on some Village choices (*). I tried to write some
> patch but unfortunately there's no way to contribute them back because
> Village project is no longer mantained.
Looks like we did the same thing :-). We're currently porting our
document management system from MySQL to Oracle and needed to fix some
weaknesses in Village, too, mainly LOB-related stuff.
> I read on the mailing list that this issue has been already raised and
> the last news were that someone was trying to "fork" it. There has been
> some progress in this task? Have somebody contacted the author to hear
> if he would allow us to contribute patches by putting the code on a
> read-write cvs?
I sent an email to jon (at) latchkey.com as we would have liked to
contribute our modifications as well. Yet I have received no reply until
now (or maybe our company-spam-cop caught that mail due to some reason).
The fork seems to be a good idea since many people are still using
Village, even without Torque. So if we pull together, maybe we can
achieve a reactivation.
So long,
Hendrik Busch
--
Mit freundlichen Grüßen / Kind regards
Hendrik Busch - Teamleiter LexisNexis Recht Entwicklung
LexisNexis Deutschland GmbH
http://www.lexisnexis.de
Feldstiege 100
D-48161 Münster
phone +49 (0) 2533-9300-455
fax +49 (0) 02533-9300-50
hendrik.busch@lexisnexis.de
---------------------------------------------------------------------
To unsubscribe, e-mail: torque-dev-unsubscribe@db.apache.org
For additional commands, e-mail: torque-dev-help@db.apache.org