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:[EMAIL PROTECTED], mailto:[EMAIL PROTECTED]
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 <[EMAIL PROTECTED]> 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 [EMAIL PROTECTED]
