Use Texen-1.0 for the generator
Hi, I'd like to warn you that we will release (we already voted, tagged, rolled and deployed it) Texen-1.0 shortly, which is a standalone version of the Texen tool on which the Torque generator is based. I know that you are in the process of releasing torque-3.3 and I want to urge you to base it not on the embedded (org.apache.velocity.texen) version but on the standalone (org.apache.texen). This is a 100% identical (except for the package names) code base but we will deprecate and remove the texen and anakia tools from the main velocity jar in the future. (Steps off his soap box) Thanks for listening. :-) Best regards Henning -- Henning P. Schmiedehausen -- [EMAIL PROTECTED] | J2EE, Linux, |gls 91054 Buckenhof, Germany -- +49 9131 506540 | Apache person |eau Open Source Consulting, Development, Design| Velocity - Turbine guy |rwc |m k INTERMETA - Gesellschaft fuer Mehrwertdienste mbH - RG Fuerth, HRB 7350 |a s Sitz der Gesellschaft: Buckenhof. Geschaeftsfuehrer: Henning Schmiedehausen |n Save the cheerleader. Save the world. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Torque 4.0 plan
Thomas Vandahl [EMAIL PROTECTED] writes: Another piece of advice that I learned from a project that I'm involved with: Don't. Decide on *one* build, embrace it wholeheartedly and ditch everything else. Else you will get project built with foo jars, project built with bar jars and project built with baz jars. Each behaves a bit differently. Maintenance nightmare. Don't go there. :-) Best regards Henning Henning P. Schmiedehausen wrote: I'd *strongly* suggest thinking about the maven support. Maven changed from 1 to 2 completely (different POMs, different program name, different properties, different plugins, different docs) so people moving from m1 to m2 had to throw all their configs (project.xml, maven.xml, properties) away and rework them (most of the time from scratch). I'd volunteer to keep the m1 build alive for this very reason. Thomas F. and I were talking about this already. Bye, Thomas. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Henning P. Schmiedehausen -- [EMAIL PROTECTED] | J2EE, Linux, 91054 Buckenhof, Germany -- +49 9131 506540 | Apache person Open Source Consulting, Development, Design | Velocity - Turbine guy Save the cheerleader. Save the world. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Torque 4.0 plan
Joe Carter [EMAIL PROTECTED] writes: Is there any chance we can make the Peer classes non-static? Currently it's hard/impossible to override/extend these without making generator changes. Perhaps have some form of central registry to hold these classes so that they can be globally looked up but also replaced/extended if desired. At that point you will need sort of a context object like all the other O/R mappers have. :-) The other suggestions are all very good - especially removing village. Definitely. Best regards Henning -- Henning P. Schmiedehausen -- [EMAIL PROTECTED] | J2EE, Linux, 91054 Buckenhof, Germany -- +49 9131 506540 | Apache person Open Source Consulting, Development, Design | Velocity - Turbine guy Save the cheerleader. Save the world. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Torque 4.0 plan
Greg Monroe [EMAIL PROTECTED] writes: - Switch to Maven 2 as build system. Maven 2 has much better multiproject support than Maven 1, so building will be easier. My +0 for Maven 2 is based on the little bit I dug into it for the add-on stuff. It seemed to add a lot of complication and extra more effort to do thing outside the Maven 2 norm that was fairly easy in 1. IMHO, build systems should take a minimum of time away from your development time, not become a subproject of it's own. I'd *strongly* suggest thinking about the maven support. Maven changed from 1 to 2 completely (different POMs, different program name, different properties, different plugins, different docs) so people moving from m1 to m2 had to throw all their configs (project.xml, maven.xml, properties) away and rework them (most of the time from scratch). And the projects relying on m1 suddently find out that people no longer have the 'old' maven installed and complain about not being able to build the project. There is no guarantee that moving from m2 to m3 will not be the same thing. There *is* a simple solution: Provide basic project building with ant. ant stood the test of time quite nicely. Keep the maven (m1, m2) build optional but build your release archives with ant. Best regards Henning -- Henning P. Schmiedehausen -- [EMAIL PROTECTED] | J2EE, Linux, 91054 Buckenhof, Germany -- +49 9131 506540 | Apache person Open Source Consulting, Development, Design | Velocity - Turbine guy Save the cheerleader. Save the world. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Torque 4.0 plan
Thomas Vandahl [EMAIL PROTECTED] writes: Greg Monroe wrote: Additionally, the generated record objects could make use of this new base class to support things like isNull() on primitives. We could also use this to track modified and unmodified column values, which would be very useful (e.g. updating tables without primary keys). I'd throw primitives away completely. There is no advantage in keeping them. Especially with JDK 1.5. You lose all the J2EE 1.4 people. J2EE will be (in the real world) on JDK 1.4 for a long time. There are tools like Retroweaver but throwing primitive support out is IMHO too early. Hibernate did and people still complain about it. Best regards Henning -- Henning P. Schmiedehausen -- [EMAIL PROTECTED] | J2EE, Linux, 91054 Buckenhof, Germany -- +49 9131 506540 | Apache person Open Source Consulting, Development, Design | Velocity - Turbine guy Save the cheerleader. Save the world. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Torque 4.0 plan
Joe Carter [EMAIL PROTECTED] writes: Personally I'd just have the singleton and ditch the static wrapper completely, however I recognise that having the wrapper would keep is closer to what exists already, so I'm not overly concerned. A method to get the singleton would make sense to match the set and would allow you to get an extended version of the back-end should that be available. If you think about a singleton, please separate the singleton class and the implementation class (don't have the static getInstance() method and a possible private C'tor in the implementation). If you separate these, it is possible for projects using e.g. Spring to manage the classes through the framework. Even better, google for 'evil singleton' and read the first few links... Best regards Henning -- Henning P. Schmiedehausen -- [EMAIL PROTECTED] | J2EE, Linux, 91054 Buckenhof, Germany -- +49 9131 506540 | Apache person Open Source Consulting, Development, Design | Velocity - Turbine guy Save the cheerleader. Save the world. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: New Torque Add-ons SF.Net project
Scott Eade [EMAIL PROTECTED] writes: Greg Monroe wrote: Well the SF project is listed as Apache 2.0, but just like the Maven-plugin project, any SF.net approved Open source license will do (all the common modern day one...). IMO it would be a mistake to go with anything other than ASL 2.0. But let's not start that discussion here :-) I would actually look for my DB PMC hat, dust it off and -1 any move away from ASL 2.0. I was AWOL for a while. Is there any special reason (license wise, because that is the only one I can think of) why these add-ons went to sf.net? Opening a sandbox for that kind of stuff in DB should be easy and with the labs.apache.org now in place, that might be a good place, too. Best regards Henning -- Henning P. Schmiedehausen -- [EMAIL PROTECTED] | J2EE, Linux, 91054 Buckenhof, Germany -- +49 9131 506540 | Apache person Open Source Consulting, Development, Design | Velocity - Turbine guy Save the cheerleader. Save the world. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [Vote] Release Torque 3.2-RC3 as Torque 3.2
Thomas Fischer [EMAIL PROTECTED] writes: [ Just repeating my vote on the PMC list for the public records] [X] +1 Yes, release Torque 3.2-rc3 as Torque 3.2 [ ] 0 I do not care [ ] -1 No, 3.2-rc3 is not ready to be released (Please give reasons) Good work, Thomas! Best regards Henning -- Dipl.-Inf. (Univ.) Henning P. Schmiedehausen INTERMETA GmbH [EMAIL PROTECTED]+49 9131 50 654 0 http://www.intermeta.de/ RedHat Certified Engineer -- Jakarta Turbine Development -- hero for hire Linux, Java, perl, Solaris -- Consulting, Training, Development 4 - 8 - 15 - 16 - 23 - 42 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] release Torque 3.2-rc3 now
Thomas Fischer [EMAIL PROTECTED] writes: Should Torque 3.2-rc3 be created from the current svn trunk ? [X] +1 Yes [ ] 0 I don't care [ ] No (please give reasons) Best regards Henning -- Dipl.-Inf. (Univ.) Henning P. Schmiedehausen INTERMETA GmbH [EMAIL PROTECTED]+49 9131 50 654 0 http://www.intermeta.de/ RedHat Certified Engineer -- Jakarta Turbine Development -- hero for hire Linux, Java, perl, Solaris -- Consulting, Training, Development 4 - 8 - 15 - 16 - 23 - 42 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: SVN Error
Charles-Alexandre Sabourdin [EMAIL PROTECTED] writes:
Hello,
I tried to download the svn of torque in order to see if I could add some
patch I would need (the schema in the sql) for instance, but when I try to
get the svn I retrieve errors.
--
{Réf http://db.apache.org/torque/subversion.html}
$ svn checkout https://svn.apache.org/repos/asf/db/torque/trunks torque
This is wrong. You are not a committer and you are not able to check
out the https:// repo. Please use http://. If this is put somewhere in
the docs, this is a docs error.
Best regards
Henning
--
Dipl.-Inf. (Univ.) Henning P. Schmiedehausen INTERMETA GmbH
[EMAIL PROTECTED]+49 9131 50 654 0 http://www.intermeta.de/
RedHat Certified Engineer -- Jakarta Turbine Development -- hero for hire
Linux, Java, perl, Solaris -- Consulting, Training, Development
4 - 8 - 15 - 16 - 23 - 42
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: 3.2-RC2 not being the final release candidate ?
Thomas Fischer [EMAIL PROTECTED] writes: After the discussion in TRQS322, it seems to me that Torque 3.2-RC2 is not suitable as the final release, so I will start development towards 3.2-rc3. If anyone wants a formal vote about it, please shout now. I'd very much like to see a 3.2-RC which does work with Turbine 2.3.2 as expected. While backwards compatibility between 3.1.x and 3.2 is not a really hard issue, the nature of the compile the database name into the class behaviour of Torque would make a general purpose usage of torque generated classes difficult. As I wrote you in private mail, voting is only necessary if the result should go into www.apache.org/dist (because the Apache bylaws require it). If you put the RC into cvs.apache.org/dist (which is the location intended for snapshots, RCs and the like), we don't need a formal vote (and have quicker turnaround times). I'd also suggest that you look on using maven dist:deploy and maven jar:deply to send the binary and source distributions to the repository. These commands also generate the necessary MD5 and SHA1 checksums For Turbine 2.3.2 I've configured two repos in project.properties and uncommented the one to use (non-released for snapshots/RCs, apache for release) manually. A non-voted release need not to be GPG-signed. Best regards Henning -- Dipl.-Inf. (Univ.) Henning P. Schmiedehausen INTERMETA GmbH [EMAIL PROTECTED]+49 9131 50 654 0 http://www.intermeta.de/ RedHat Certified Engineer -- Jakarta Turbine Development -- hero for hire Linux, Java, perl, Solaris -- Consulting, Training, Development 4 - 8 - 15 - 16 - 23 - 42 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Proposal for Automatic text escaping and overflow checking
Greg Monroe [EMAIL PROTECTED] writes:
No. Torque is an O/R layer, not an input value checking device. If you
need this kind of checks, do it in your Controller.
Best regards
Henning
--_=_NextPart_001_01C5C5F8.3391B1D6
Content-Type: text/plain;
charset=us-ascii
Content-Transfer-Encoding: quoted-printable
I've often thought that it would be nice if Torque would automatically
handle buffer=20
overflow checking and SQL text escaping. These are two of the biggest
gotcha=20
in application vunerablities and take a lot of time coding against (if
you remember=20
to do it).
I was looking at the code and think I have found a relatively easy way
to handle this=20
for most of Torque. But before I start causing unseen problems, I
thought I'd run=20
it by everyone for any gotchas.
First, it appears that all the common save methods end up going thru the
BasePeer
method, insertOrUpdateRecord. Here is where the objects are converted
into=20
Village values prior to be saved. It seems like the section with:
if ( obj instanceof String ) {
}
is the place to do this.
Checking for length problems is easy using the MapBuilder.vm template
mod I just=20
submitted. With this, the columnMap will have the size to check against
the String
length. If it's too long, the codue would throw a TorqueException (
Should there
be a TorqueException subclass like TorqueFieldOverflowException to
indicate this=20
specific error?)
Making sure that the string being saved has been escaped is a little
harder. This
is because the current version of quoteAndEscapeText is non-repeatable.
E.g.,
if you call it twice, you double quote things. There is a lot of
existing code out there
that calls this prior to doing a save. =20
So, in order for, the new automatic escaping to work and not change the
data value,=20
the quoteAndEscapeText method needs to be re-written so it's repeatable.
Not a=20
big deal, just some pickie checking of the last or next characters
before something=20
is changed. Once that's done, unescaped text will be automatically
escaped and=20
pre-escaped text will just be passed thru.
So, that's it. Seems simple enough. Have I missed any gotchas or
other issues=20
that need to be considered?
TIA
Greg
Greg Monroe[EMAIL PROTECTED](919)680-5050
CIS Solutions Team Lead
Duke Corporate Education, Inc.
333 Liggett St.
Durham, NC 27701
Duke CE Privacy Statement
Please be advised that this e-mail and any files transmitted with it are =
confidential communication or may otherwise be privileged or =
confidential and are intended solely for the individual or entity to =
whom they are addressed. If you are not the intended recipient you may =
not rely on the contents of this email or any attachments, and we ask =
that you please not read, copy or retransmit this communication, but =
reply to the sender and destroy the email, its contents, and all copies =
thereof immediately. Any unauthorized dissemination, distribution or =
copying of this communication is strictly prohibited.
--_=_NextPart_001_01C5C5F8.3391B1D6--
--
Dipl.-Inf. (Univ.) Henning P. Schmiedehausen INTERMETA GmbH
[EMAIL PROTECTED]+49 9131 50 654 0 http://www.intermeta.de/
RedHat Certified Engineer -- Jakarta Turbine Development -- hero for hire
Linux, Java, perl, Solaris -- Consulting, Training, Development
4 - 8 - 15 - 16 - 23 - 42
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Discussion: Change torque JDBCTransformTask to not use xerces
This is a proposal for a post-rc2, pre-rc3 change! I've seen that Thomas is ramping up the rc2 release and I don't want to interfere with this (and his well-deserved vacation :-) ). However, I'd like to give Thomas a chance to throw in a word or two before he leaves. :-) If you compile the torque-generator from the trunk using JDK 1.4 and comment out the JDK 1.4 included xerces and xml-api dependencies, you will notice that the generator no longer compiles. The reason for this is the JDBCTransformTask which uses the org.apache.xerces.dom.DocumentImpl and a number of other, internal classes directly (though DocumentImpl e.g. contains the notice Usage of this class is not supported. It may be altered or removed at any time. (see http://xml.apache.org/xerces2-j/javadocs/xerces2/org/apache/xerces/dom/DocumentImpl.html)) When using JDK 1.3, this does hurt only a little bit; because this JDK release does not contain javax.xml or org.w3c.dom packages, you will have to include xerces and xml-apis anyway. But on JDK 1.4, you get about a Megabyte of dependencies that are actually not used at all except for this lone task. Which is not even a correct use case. :-) I therefore would like to rewrite the current JDBCTransformTask using some other XML writing library. jdom (150k) or dom4j (300k) come to mind. It shouldn't be too hard and putting some unit tests on top will help here. Opinions? Best regards Henning -- Dipl.-Inf. (Univ.) Henning P. Schmiedehausen INTERMETA GmbH [EMAIL PROTECTED]+49 9131 50 654 0 http://www.intermeta.de/ RedHat Certified Engineer -- Jakarta Turbine Development -- hero for hire Linux, Java, perl, Solaris -- Consulting, Training, Development 4 - 8 - 15 - 16 - 23 - 42 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: 3.2-RC2 in the next few days ?
Thomas Fischer [EMAIL PROTECTED] writes: Hi, Does anyone object to push out RC2 in the next few days ? The other option is doing it in three weeks as afterwards, I am on vacation for two weeks. +1 Do it now. So we have two weeks to hammer on it and find bugs. :-) I am currently aware of the following open issues: JCS. Obviously, the new release wont be in as it is not available. Does it have so much improvements justifying to wait for it ? Release RC2 with the current JCS version. Hopefully, 1.3 will be out when you are back. Alternatively you can fetch 1.2.6.5 (most current built?) from http://cvs.apache.org/viewcvs.cgi/jakarta-turbine-jcs/tempbuild/, test with that one and lobby Aaron to push it to ibiblio. The LargeSelect limit/offset issue. The developers who have raised a voice are of the opinion that a javadoc statement should suffice, at least for the moment. This would be in. A real solution would have to wait. We've lived with that for so long; no need to hurry/delay here. There was a bug report about functions in offsets to the dev list about two weeks ago. It seems to be an enhancement rather than a bug to me. I have not looked at it, but I will do so before pushing RC2. Else document as open, may be fixed in RC3/final. +1 for building an RC! Best regards Henning -- Dipl.-Inf. (Univ.) Henning P. Schmiedehausen INTERMETA GmbH [EMAIL PROTECTED]+49 9131 50 654 0 http://www.intermeta.de/ RedHat Certified Engineer -- Jakarta Turbine Development -- hero for hire Linux, Java, perl, Solaris -- Consulting, Training, Development 4 - 8 - 15 - 16 - 23 - 42 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: 3.2-RC2 in the next few days ?
Thomas Vandahl [EMAIL PROTECTED] writes:
-protected static String MANAGED_CLASS = ${package}.${interfaceName};
+protected final static String MANAGED_CLASS =
${package}.${interfaceName};
static final please. Does protected static final make sense?
Best regards
Henning
--
Dipl.-Inf. (Univ.) Henning P. Schmiedehausen INTERMETA GmbH
[EMAIL PROTECTED]+49 9131 50 654 0 http://www.intermeta.de/
RedHat Certified Engineer -- Jakarta Turbine Development -- hero for hire
Linux, Java, perl, Solaris -- Consulting, Training, Development
4 - 8 - 15 - 16 - 23 - 42
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Torque test (ex runtimetest)
Thomas Vandahl [EMAIL PROTECTED] writes: Also: Henning and I are pushing for a JCS release so we can update the version used for Torque 3.2. God bless you. It is about time. :-) We might want to build a jar from the current trunk and check whether Torque actually still runs with the most recent JCS code. Best regards Henning -- Dipl.-Inf. (Univ.) Henning P. Schmiedehausen INTERMETA GmbH [EMAIL PROTECTED]+49 9131 50 654 0 http://www.intermeta.de/ RedHat Certified Engineer -- Jakarta Turbine Development -- hero for hire Linux, Java, perl, Solaris -- Consulting, Training, Development 4 - 8 - 15 - 16 - 23 - 42 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: svn commit: r279830 - /db/torque/test/trunk/profile/henning/
[EMAIL PROTECTED] writes: Author: tfischer Date: Fri Sep 9 10:37:33 2005 New Revision: 279830 URL: http://svn.apache.org/viewcvs?rev=279830view=rev Log: Copied the setting of Henning's profile Henning, I am afraid the postgresql driver needs to be in the maven repository. Please check the version. Also, I have taken over all the generator settings from your old profile, even if they are the default settings. Hope that is ok. maven.jar.override = on maven.jar.postgresql = /usr/share/java/postgresql.jar should IMHO work. Best regards Henning -- Dipl.-Inf. (Univ.) Henning P. Schmiedehausen INTERMETA GmbH [EMAIL PROTECTED]+49 9131 50 654 0 http://www.intermeta.de/ RedHat Certified Engineer -- Jakarta Turbine Development -- hero for hire Linux, Java, perl, Solaris -- Consulting, Training, Development 4 - 8 - 15 - 16 - 23 - 42 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: svn commit: r278825 - in /db/torque/test: ./ trunk/ trunk/maven-test-plugin/
[EMAIL PROTECTED] writes: db/torque/test/trunk/maven-test-plugin/ (with props) -1 on maven-test-plugin. We are not testing maven. We are testing Torque. + goal name=torque:run-test -1 on the name space overlap between your plugin and the torque-plugin. This will not only create confusion, knowing a bit about the mes^Wstate of maven, I'm pretty sure that sooner or later a name space separation will be enforced and then either one or the other plugin breaks. +attainGoal name=torque:test:test/ -1 on xxx:yyy:zzz. Same as above. Sooner or later, maven will enforce the plugin:goal rule and then double ':' will probably break. +/project \ No newline at end of file Bad. Personally, I'm -0 on the whole plugin idea. For just running the runtime test, I will afterwards have to drag around a plugin not used for anything else in my maven installation. Not really ideal. Regards Henning -- Dipl.-Inf. (Univ.) Henning P. Schmiedehausen INTERMETA GmbH [EMAIL PROTECTED]+49 9131 50 654 0 http://www.intermeta.de/ RedHat Certified Engineer -- Jakarta Turbine Development -- hero for hire Linux, Java, perl, Solaris -- Consulting, Training, Development 4 - 8 - 15 - 16 - 23 - 42 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: svn commit: r278825 - in /db/torque/test: ./ trunk/ trunk/maven-test-plugin/
Thomas Fischer [EMAIL PROTECTED] writes: I tried several things and this was the best I could come up with till now. The problem with the old runtimetest were the following: - one had to build the generator and the templates separately if one changed something there. Really annoying if you run the test 10 times. - it was testing the ant version of the generator and not the maven-plugin. - it had problems with the junit task definition. - it was not a runtimetest, but instead it was testing the whole of torque, and therefore should not be in the runtime part of the project. The new test has none of these problems, and the new problem with the installed plugin can be solved. So in my own personal private opinion, it is much better than the old test. Full stop. However, it is also not the ideal solution from my point of view. What I would have liked best would be a test project which could be run like any other torque project. The problems were the following: - The main problem is that I did not find a possibility to read a profile file during (not before!!!) maven execution and passing the parameters to the torque maven plugin. Maybe I did not look hard enough, will look again this evening if one can do tricks with maven:set. - in the runtimetest, one can switch the idmethod from the profile. This was done using ant filters while copying the file. To retain this feature, one has to copy the schema files. If one does not want to retain this feature, one could use some tables with the idbroker and some normal ones. Then one could leave out the copying stuff and the project would look more like a normal Torque project. A strong point for retaining the idmethod switching feature is that some database adapters (firebird, at least) do not support the idmethod=native, so the part of the test using idmethod native would not run at all. Maybe one wants to have two runs in every test, one with idmethod=native and one with idmethod=idbroker, but no idea how to do this in an elegant way. It's ok. If you see real benefits and it does not put a burden on a maven installation, go ahead. As I said, I'm not really a fan of the solution (-0) but I don't object it. Getting some docs on how to use this would be good, though. Regards Henning -- Dipl.-Inf. (Univ.) Henning P. Schmiedehausen INTERMETA GmbH [EMAIL PROTECTED]+49 9131 50 654 0 http://www.intermeta.de/ RedHat Certified Engineer -- Jakarta Turbine Development -- hero for hire Linux, Java, perl, Solaris -- Consulting, Training, Development 4 - 8 - 15 - 16 - 23 - 42 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
maven-xdoc-plugin 1.9.2
This has just hit ibiblio. It should now be possible to build the current trunk site again. Regards Henning -- Dipl.-Inf. (Univ.) Henning P. Schmiedehausen INTERMETA GmbH [EMAIL PROTECTED]+49 9131 50 654 0 http://www.intermeta.de/ RedHat Certified Engineer -- Jakarta Turbine Development -- hero for hire Linux, Java, perl, Solaris -- Consulting, Training, Development 4 - 8 - 15 - 16 - 23 - 42 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Torque does not build
Thomas Vandahl [EMAIL PROTECTED] writes: S*it, did I put this in? Sorry, slipped somehow by. The problem here is: - maven-xdoc-plugin 1.8 is not good enough to build the site - maven-xdoc-plugin 1.9 and 1.9.1 are broken and don't build the sites correctly. - maven-xdoc-plugin 1.9.2 (which might be released in a short while after I put some of my frustration into http://mail-archives.apache.org/mod_mbox/maven-dev/200508.mbox/[EMAIL PROTECTED] and the following thread) You can get the snapshot plugin from cvs.apache.org: % maven plugin:download -DgroupId=maven -DartifactId=maven-xdoc-plugin \ -Dversion=1.9.2-SNAPSHOT \ -Dmaven.repo.remote=http://cvs.apache.org/repository/ but you must then change the version of 1.9.2 to 1.9.2-SNAPSHOT and might end up running the first site build with the -Dmaven.repo.remote anyway, because the new and improved 1.9.2 plugin insists on downloading another bazillion unreleased jars. Did anyone in the back of the audience just said maven sucks? ;-) Regards Henning -- Dipl.-Inf. (Univ.) Henning P. Schmiedehausen INTERMETA GmbH [EMAIL PROTECTED]+49 9131 50 654 0 http://www.intermeta.de/ RedHat Certified Engineer -- Jakarta Turbine Development -- hero for hire Linux, Java, perl, Solaris -- Consulting, Training, Development 4 - 8 - 15 - 16 - 23 - 42 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Torque does not build
Henning P. Schmiedehausen [EMAIL PROTECTED] writes: - maven-xdoc-plugin 1.9.2 (which might be released in a short while after I put some of my frustration into http://mail-archives.apache.org/mod_mbox/maven-dev/200508.mbox/[EMAIL PROTECTED] and the following thread) This BTW also spawned http://henning.schmiedehausen.org/wingnut-diaries/archives/18 ;-) Regards Henning -- Dipl.-Inf. (Univ.) Henning P. Schmiedehausen INTERMETA GmbH [EMAIL PROTECTED]+49 9131 50 654 0 http://www.intermeta.de/ RedHat Certified Engineer -- Jakarta Turbine Development -- hero for hire Linux, Java, perl, Solaris -- Consulting, Training, Development 4 - 8 - 15 - 16 - 23 - 42 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Coding conventions
Thomas Fischer [EMAIL PROTECTED] writes: Hm. Actually, I don't really understand this vote. We should've had some discussion first. :-) First my vote: [X] +1 Torque code should be written according to the Turbine code conventions. The problem is, that the Turbine Coding standard are at best a loosely defined collection of do's and don't's (at http://jakarta.apache.org/turbine/common/code-standards.html) with a (broken) checkstyle definition in maven-checkstyle-plugin. It is (IMHO) just a document that describes how some (one?) of the original Turbine people write code. It has a number of glaring ambiguities (like the if (foo) and if ( foo ) ) convention. The attached .emacs file makes it even worse. If you reformat a buffer with this style, the result will not confirm to the style described. :-) Also, it is almost impossible to configure Jalopy to format code just like this emacs style. And eclipse again formats different. However, I strongly advise _against_ reformatting the source code into another format. Not because I'm clinging to the current style. But because I've learned (the hard way), that reformatting source code is almost always a bad idea. This like indenting (4 spaces? 8 spaces? tabs?), brace positions and everything else are a matter of personal taste. Every developer does it differently. And having two developers using a different coding style working on the same file will let real changes drown in a sea of indent and brace position changes. Having a coding style is better than having none. But changing a code style is even worse than having no coding style. What I would _love_ to have (even some people will cry out in horror) is a subversion pre-commit hook on the server, which takes .java files and reformats them to a coding style set on the server. And reject a checkin if a file has only formatting changes unless they still exist after reformatting. This would make sure, that only correctly formatted code will hit the repository. And it would allow developers to cling to their own style and first thing after a checkout is to reformat the project according to their personal tastes. If you really care about code style, then you should take a peek at the following things (IMHO): - Code Conventions for the Java(TM) Programming Language. http://java.sun.com/docs/codeconv/html/CodeConvTOC.doc.html This is a surprisingly stable document (last revision is from '99) describing how to format code. I have some problems with it (Tabs vs. Spaces is one) but it is a good guide how a style guide _can_ look like and it is a great foundation to build upon. - The Elements of Java Style -- ISBN 0-521-77768-2 If you don't own this booklet, try to steal it somewhere. If you want to write professional Java code and don't know this book, you did something wrong. I hate their control statement indentation (I do believe, BSD style is more readable), but that is personal. They hate hard tabs too, which is good. - The output of checkstyle, pmd and findbugs. As we are using a maven build, we get all three of them for free. While (especially Findbugs) sometimes point to false warnings, most of the time the damned tools are right (The current Torque code still contains about fifteen 'tab' characters in the runtime alone). My final advice is to apply some reason. Is it really necessary to reformat a file you're working on? The LKM people basically say if you work on foo.c, try to keep the indentation as closely as possible to the original style of the code. If it's KR, keep KR, if it's BSD, keep BSD. Regards Henning -- Dipl.-Inf. (Univ.) Henning P. Schmiedehausen INTERMETA GmbH [EMAIL PROTECTED]+49 9131 50 654 0 http://www.intermeta.de/ RedHat Certified Engineer -- Jakarta Turbine Development -- hero for hire Linux, Java, perl, Solaris -- Consulting, Training, Development 4 - 8 - 15 - 16 - 23 - 42 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: svn commit: r240328 - in /db/torque:
[EMAIL PROTECTED] writes: Made the generated beans serializable. Also added a testcase to the runtimetest which checks that. I'm not sure that this is a good idea without having a switch to be able to turn it on/off. With the beans suddently be serializable, you buy a whole wealth of possible problems with e.g. beans ending up in Servlet container sessions that in turn get serialized at restart time. Adding this in a RC is IMHO a bad thing, either. This is 3.3 stuff (because it could break existing code in a new and exciting way...). Regards Henning -- Dipl.-Inf. (Univ.) Henning P. Schmiedehausen INTERMETA GmbH [EMAIL PROTECTED]+49 9131 50 654 0 http://www.intermeta.de/ RedHat Certified Engineer -- Jakarta Turbine Development -- hero for hire Linux, Java, perl, Solaris -- Consulting, Training, Development 4 - 8 - 15 - 16 - 23 - 42 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
SVN reorganisation complete, new site deployed
Hi, the reorganisation of the torque svn into different parts for the various torque elements is now complete. I also updated the various sites and redeployed them. If you have noticed the new 'logo' on the top right corner: I couldn't stand the old white on blue any longer. If you have a better idea for a logo or simply want to update or change this one: in the 'site' module there is a src/gimp directory which contains the gimp sources for this logo. Regards Henning -- Dipl.-Inf. (Univ.) Henning P. Schmiedehausen INTERMETA GmbH [EMAIL PROTECTED]+49 9131 50 654 0 http://www.intermeta.de/ RedHat Certified Engineer -- Jakarta Turbine Development -- hero for hire Linux, Java, perl, Solaris -- Consulting, Training, Development 4 - 8 - 15 - 16 - 23 - 42 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Torque Subversion Repo Reorganization complete
Thomas Fischer [EMAIL PROTECTED] writes: Henning, I have been able to run the build and the runtimetest against postgres, mysql and the part that runs against hsqldb against hsqldb from the trunks directory. I have not been able to build the different parts of Cool. the project from their respective trunk. It complains about having to define currentVersion in the POM, si this should be eeasy to fix. Will look into it tomorrow. Are you sure that you went into part/trunk ? This is exactly the error mesage that you get when you just do 'cd part'. I tried all the modules one more time and they build fine. I would also like to look into some details (like running the dist target from the various places) at some time, but this can also happen when the stuff is live. Ok. Only thing we need still to think about is the runtimetest. Running it on a directory which is pulled out of svn:externals is not optimal, because one needs to commit changes before one can pull them out again. So one cannot check if a change broke something before commiting. The optimal solution would be to have two possibilities to run the runtimetest: 1) run it against the version installed in the local repository (fast version) Doesn't really help you because RTT tests all parts of Torque: Generator, Templates and Runtime 2) do a reactor build of all projects in their respective trunks, install them to the local repository, and then proceed with 1) This implies that all the trunks must be checked out, so you are back to square #1. The reactor is not exactly clever. It just runs all project.xml files in sub-directories. To be honest: Only developers will run the runtime test and only the ones who are in the know. It took me 1 year and a hint from Martin to find out about the runtime test. To me, the current solution is fine. If you want to work on Torque, you will check out the trunks anyway. The main trees are more interesting to keep the code organized and for browsing by users. Regards Henning -- Dipl.-Inf. (Univ.) Henning P. Schmiedehausen INTERMETA GmbH [EMAIL PROTECTED]+49 9131 50 654 0 http://www.intermeta.de/ RedHat Certified Engineer -- Jakarta Turbine Development -- hero for hire Linux, Java, perl, Solaris -- Consulting, Training, Development 4 - 8 - 15 - 16 - 23 - 42 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Torque Site Skeleton
As soon as the rsyncs are run, you can take a sneak peek at a torque envelope site design at http://db.apache.org/torque/site/ Basically, we move a front page, the download and status pages and links to all released and current parts into this site. Discussion and help wanted. Regards Henning -- Dipl.-Inf. (Univ.) Henning P. Schmiedehausen INTERMETA GmbH [EMAIL PROTECTED]+49 9131 50 654 0 http://www.intermeta.de/ RedHat Certified Engineer -- Jakarta Turbine Development -- hero for hire Linux, Java, perl, Solaris -- Consulting, Training, Development 4 - 8 - 15 - 16 - 23 - 42 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Torque Subversion Repo Reorganization complete
Hi, as you may have noticed, there have been a lot of changes yesterday by Thomas and me. The reason for this is the establishment of the new subversion structure for testing in branches/vn-reorganisation-branch. It relies heavily on the svn:externals feature of Subversion which helps to pull common directories into different trees. features are: - different repositories for runtime, generator, maven-plugin and templates - no more build.path hacks, clean generation of the dist-src and dist-bin archives - reactor build for all parts of Torque If you want to test it out, you can check out each module separately at http://svn.apache.org/repos/asf/db/torque/branches/svn-reorganisation-branch/runtime/trunk http://svn.apache.org/repos/asf/db/torque/branches/svn-reorganisation-branch/generator/trunk http://svn.apache.org/repos/asf/db/torque/branches/svn-reorganisation-branch/maven-plugin/trunk http://svn.apache.org/repos/asf/db/torque/branches/svn-reorganisation-branch/templates/trunk or (and this is the recommended way) by checking out all modules simulateously at http://svn.apache.org/repos/asf/db/torque/branches/svn-reorganisation-branch/trunks/ In this directory, you can run the following goals: build -- starts a reactor build of runtime, generator, templates and maven-plugin install -- installs the jars and the plugin into your local maven repository doc -- generates the sites for all modules in the target/docs directories If you want to run the runtime test, you must check out the 'trunks' tree because it depends on the relations between runtime, generator and templates. Pleast test this repository structure (at least checkout the 'trunks' tree and run maven build in the root and report success/failure). This tree structure will go live later this week and the sooner we can iron out any problems, the better. I'm aware that the svn urls in the various POMs does not point to the branches/... locations. This is intentional. Regards Henning -- Dipl.-Inf. (Univ.) Henning P. Schmiedehausen INTERMETA GmbH [EMAIL PROTECTED]+49 9131 50 654 0 http://www.intermeta.de/ RedHat Certified Engineer -- Jakarta Turbine Development -- hero for hire Linux, Java, perl, Solaris -- Consulting, Training, Development 4 - 8 - 15 - 16 - 23 - 42 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Torque Subversion Repo Reorganization complete
Henning P. Schmiedehausen [EMAIL PROTECTED] writes: subversion structure for testing in branches/vn-reorganisation-branch. grmbl. branches/svn-reorganisation-branch Time for bed Henning -- Dipl.-Inf. (Univ.) Henning P. Schmiedehausen INTERMETA GmbH [EMAIL PROTECTED]+49 9131 50 654 0 http://www.intermeta.de/ RedHat Certified Engineer -- Jakarta Turbine Development -- hero for hire Linux, Java, perl, Solaris -- Consulting, Training, Development 4 - 8 - 15 - 16 - 23 - 42 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: svn commit: r230657 -
Thomas Fischer [EMAIL PROTECTED] writes: The _reason_ why it fails is clear to me. I still consider it a bug, though. :-) It works when you don't skip the test plugin because the test plugin pulls the junit.jar in. Regards Henning Hi Henning, On Sun, 7 Aug 2005, Henning P. Schmiedehausen wrote: bad news: It still fails (though in a new and exciting way) if you run the tests like this: % maven -Dmaven.test.skip=true -Dtorque.testProfile=profile/henning.profile runtime:test [...] BUILD FAILED File.. /home/henning/scratch/torque-svn/db-torque/maven.xml Element... ant Line.. 130 Column 29 Could not create task or type of type: junit. Ant could not find the task or a class this task relies upon. This is common and has a number of causes; the usual solutions are to read the manual pages then download and install needed JAR files, or fix the build file: [...] The runtime test seems to rely on maven to create the junit tasks for ant. So when you skip the tests, the junit task is not defined and the runtime test fails. It should run independently from the maven driven unit tests. This is a problem with the classpath maven sets in the maven shell script and the ant classloaders. Read http://ant.apache.org/faq.html#delegating-classloader and look at the -classpath definition in the java command in the maven shell script. To resolve the issue, you can either edit the maven shell script to include junit.jar in the classpath, or you can copy junit-3.8.1.jar into the $MAVEN_HOME/lib/endorsed directory. Don't ask me why it works if you do not set -Dmaven.test.skip=true Of course this could also be a problem with the ant installation from jpackage. I know that Stefan Bodewig almost gets a fit every time I mention ant and jpackage or ant and Redhat. ;-) This is not the problem. I have installed ant from scratch and can reproduce the problem. Thomas - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Dipl.-Inf. (Univ.) Henning P. Schmiedehausen INTERMETA GmbH [EMAIL PROTECTED]+49 9131 50 654 0 http://www.intermeta.de/ RedHat Certified Engineer -- Jakarta Turbine Development -- hero for hire Linux, Java, perl, Solaris -- Consulting, Training, Development 4 - 8 - 15 - 16 - 23 - 42 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Subversion reorganisation?
Thomas Fischer [EMAIL PROTECTED] writes: Hi, this looks very good to me. Excluding subpackages in the source directory causes lots of problems in the build. But, being not so That's what I thought. :-) experienced in subversion and maven, I have some stupid questions - would the runtime, generator, templates and the maven-plugin be independent projects in the maven sense (i.e. would the project-base.xml be removed and not be replaced) ? Yes they would. However, the files would not be removed. All files common to the three parts would be moved into the common module. In the sub projects, you add a subversion property to the tree which is svn:externals common https://svn.apache.org/repos/asf/db/torque/common/ this will pull the common directory automatically into the three sub projects. Inside of these, you will just refer common/project-base.xml as you did currently with project-base.xml, ../../project-base.xml and so on. The module will be the same for all three projects and still have its own tree in subversion. - Instead of having different trunks for the runtime, generator etc it would also be possible to have one trunk, and runtime, generator etc as subdirectories. It seems to me that different trunks is better for keeping things decoupled, but one cannot have relative paths between the different parts of the projects any more. Or is this what the trunks directory is for ? Yes. I got this idea from the jakarta/commons tree. Inside of trunks, there will be svn:external references for all sub projects, so if you check out the trunks directory, you will get trunks/runtime --- same as runtime/trunk trunks/generator--- same as generator/trunk trunks/templates--- same as templates/trunk and inside of this trunks could also be e.g. a global maven.xml file which does a reactor build of all three projects. Regards Henning -- Dipl.-Inf. (Univ.) Henning P. Schmiedehausen INTERMETA GmbH [EMAIL PROTECTED]+49 9131 50 654 0 http://www.intermeta.de/ RedHat Certified Engineer -- Jakarta Turbine Development -- hero for hire Linux, Java, perl, Solaris -- Consulting, Training, Development 4 - 8 - 15 - 16 - 23 - 42 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [patch] MySQL SQL generation fix
David Sean Taylor [EMAIL PROTECTED] writes: When we upgraded to Torque version 3.2-rc1, Torque incorrectly generating MySQL statements for MEDIUMTEXT as COLUMN_VALUE MEDIUMTEXTNOT NULL, Right. This is a bug. src/generator/src/java/org/apache/torque/engine/database/model/Column.java 27 Jun 2005 21:34:10 - 1.29 +++ src/generator/src/java/org/apache/torque/engine/database/model/Column.java 5 Aug 2005 06:42:27 - Please move to the subversion repository in the future. While your patch fixes a symptom, it does not cure the deeper, underlying problems of getSqlString() which is sort of a let's juggle with spaces somehow method. I just checked in a fix that should repair all problems with that method for good. If you do work with MySQL; it would be nice to have a domain test class for MySQL like we have for other databases. This would help us spot such errors faster. Best regards Henning -- Dipl.-Inf. (Univ.) Henning P. Schmiedehausen INTERMETA GmbH [EMAIL PROTECTED]+49 9131 50 654 0 http://www.intermeta.de/ RedHat Certified Engineer -- Jakarta Turbine Development -- hero for hire Linux, Java, perl, Solaris -- Consulting, Training, Development 4 - 8 - 15 - 16 - 23 - 42 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: svn commit: r230657 -
[EMAIL PROTECTED] writes: Author: tfischer Date: Sun Aug 7 03:11:44 2005 New Revision: 230657 [...] good news: This patch fixes the runtime test. bad news: It still fails (though in a new and exciting way) if you run the tests like this: % maven -Dmaven.test.skip=true -Dtorque.testProfile=profile/henning.profile runtime:test [...] BUILD FAILED File.. /home/henning/scratch/torque-svn/db-torque/maven.xml Element... ant Line.. 130 Column 29 Could not create task or type of type: junit. Ant could not find the task or a class this task relies upon. This is common and has a number of causes; the usual solutions are to read the manual pages then download and install needed JAR files, or fix the build file: [...] The runtime test seems to rely on maven to create the junit tasks for ant. So when you skip the tests, the junit task is not defined and the runtime test fails. It should run independently from the maven driven unit tests. Of course this could also be a problem with the ant installation from jpackage. I know that Stefan Bodewig almost gets a fit every time I mention ant and jpackage or ant and Redhat. ;-) Regards Henning -- Dipl.-Inf. (Univ.) Henning P. Schmiedehausen INTERMETA GmbH [EMAIL PROTECTED]+49 9131 50 654 0 http://www.intermeta.de/ RedHat Certified Engineer -- Jakarta Turbine Development -- hero for hire Linux, Java, perl, Solaris -- Consulting, Training, Development 4 - 8 - 15 - 16 - 23 - 42 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[RESULT][VOTE] Move the Torque Bugtracker to JIRA
Result of the vote: +1 Henning Schmiedehausen (binding) Scott Eade (binding) (I just took this as sort of +1 vote, if it was just a general opinion and not a vote, please correct me) [EMAIL PROTECTED] (non-binding) (Folks, please give a real name. I'd like to check whether you are a committer, a PMC member or just a reader of the list) 0 Thomas Fischer (binding) Only two binding +1 votes means that the vote has not passed and Torque will not move to JIRA. Due to the fact that Scarab is currently down, this means that we now have no bug tracker at all. I'd like to encourage the people that spoke up in this thread (Thomas, Jorge) to get in contact with the ASF infrastructure team ([EMAIL PROTECTED]) and sort out the Scarab issues and maybe volunteer as Scarab maintainers. Regards Henning -- Dipl.-Inf. (Univ.) Henning P. Schmiedehausen INTERMETA GmbH [EMAIL PROTECTED]+49 9131 50 654 0 http://www.intermeta.de/ RedHat Certified Engineer -- Jakarta Turbine Development -- hero for hire Linux, Java, perl, Solaris -- Consulting, Training, Development 4 - 8 - 15 - 16 - 23 - 42 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Subversion reorganisation?
Hi, now that we are on subversion, this offers us the opportunity to finall decouple the development of the various parts of Torque. I'd propose that we reorganize the SCM to reflect this: db/ torque/ runtime/- trunk trunk/ tags/ branches/ generator/ - trunk/src/generator trunk/ tags/ branches/ templates/ - trunk/src/generator/src/templates trunk/ tags/ branches/ plugin/ - trunk/src/maven-plugin trunk/ tags/ branches/ common/ - stuff that all the parts use, can be pulled in the projects using svn:external site/ A wrapper site like the db-site or turbine site to allow us havingmultiple release versions and common information in one place trunks/ A checkout directory like the jakarta-commons has with trunks-proper The idea is to remove all the build tricks from the current tree and allow us to decouple the building of e.g. the generator and the runtime. With the generator being able to build other templates (like OJB) it is IMHO a good thing to be able to cut revisions independently from the runtime. Opinions? Regards Henning -- Dipl.-Inf. (Univ.) Henning P. Schmiedehausen INTERMETA GmbH [EMAIL PROTECTED]+49 9131 50 654 0 http://www.intermeta.de/ RedHat Certified Engineer -- Jakarta Turbine Development -- hero for hire Linux, Java, perl, Solaris -- Consulting, Training, Development 4 - 8 - 15 - 16 - 23 - 42 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Subversion now active
Hi, the Torque repo is now available at http://svn.apache.org/repos/asf/db/torque/ Regards Henning -- Dipl.-Inf. (Univ.) Henning P. Schmiedehausen INTERMETA GmbH [EMAIL PROTECTED]+49 9131 50 654 0 http://www.intermeta.de/ RedHat Certified Engineer -- Jakarta Turbine Development -- hero for hire Linux, Java, perl, Solaris -- Consulting, Training, Development 4 - 8 - 15 - 16 - 23 - 42 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Torque sites redeployed with Subversion
Hi, I just redeployed the sites for runtime, generator, maven-plugin and templates from the Subversion repository. All links inside the site should now point to the new repository. Please check. Regards Henning -- Dipl.-Inf. (Univ.) Henning P. Schmiedehausen INTERMETA GmbH [EMAIL PROTECTED]+49 9131 50 654 0 http://www.intermeta.de/ RedHat Certified Engineer -- Jakarta Turbine Development -- hero for hire Linux, Java, perl, Solaris -- Consulting, Training, Development 4 - 8 - 15 - 16 - 23 - 42 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Current trunk fails runtime tests
:185) at org.apache.commons.jelly.impl.TagScript.run(TagScript.java:279) at org.apache.commons.jelly.impl.ScriptBlock.run(ScriptBlock.java:135) at org.apache.maven.jelly.tags.werkz.MavenGoalTag.runBodyTag(MavenGoalTag.java:79) at org.apache.maven.jelly.tags.werkz.MavenGoalTag$MavenGoalAction.performAction(MavenGoalTag.java:110) at com.werken.werkz.Goal.fire(Goal.java:639) at com.werken.werkz.Goal.attain(Goal.java:575) at org.apache.maven.plugin.PluginManager.attainGoals(PluginManager.java:671) at org.apache.maven.MavenSession.attainGoals(MavenSession.java:263) at org.apache.maven.cli.App.doMain(App.java:488) at org.apache.maven.cli.App.main(App.java:1239) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:324) at com.werken.forehead.Forehead.run(Forehead.java:551) at com.werken.forehead.Forehead.main(Forehead.java:581) Final Memory: 24M/43M Total time: 2 minutes 39 seconds Finished at: Fri Aug 05 12:01:54 CEST 2005 I noticed that the rttest does not copy the torque-gen-templates jar into the rttest/lib directory. Is this intentional? Best Regards Henning -- Dipl.-Inf. (Univ.) Henning P. Schmiedehausen INTERMETA GmbH [EMAIL PROTECTED]+49 9131 50 654 0 http://www.intermeta.de/ RedHat Certified Engineer -- Jakarta Turbine Development -- hero for hire Linux, Java, perl, Solaris -- Consulting, Training, Development 4 - 8 - 15 - 16 - 23 - 42 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Move the Torque Bugtracker to JIRA
Henning P. Schmiedehausen [EMAIL PROTECTED] writes: [X] +1 - Yes! Let's go JIRA [ ] 0 - I don't care [ ] -1 - No (Please give a justification) -- Dipl.-Inf. (Univ.) Henning P. Schmiedehausen INTERMETA GmbH [EMAIL PROTECTED]+49 9131 50 654 0 http://www.intermeta.de/ RedHat Certified Engineer -- Jakarta Turbine Development -- hero for hire Linux, Java, perl, Solaris -- Consulting, Training, Development 4 - 8 - 15 - 16 - 23 - 42 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Move the Torque Bugtracker to JIRA
Thomas Fischer [EMAIL PROTECTED] writes: 0 - Not sure what to do I am not convinced we should move away from Scarab, because Scarab is one of the few Open Source Projects known to me which uses Torque internally, and I do think that we should support it by using it. That wouldn't be a real reason for me. It also uses Turbine and still the Turbine bugtracker will go. On the other hand, if moving away from Scarab would reduce work load to the ASF admins, this is a very good reason to do so. Henning, did you ask infrastructure how they feel about this ? Henri (Yandell) said so and I know that Scarab maintenance sometimes lagged not just weeks but months. The admins are quite busy and they are very much more familiar with Bugzilla and/or JIRA. Also, what is problematic about using Scarab is that one needs an account just to read the bug reports, but I am not sure whether this can be configured or not, so not sure whether this qualifies as a reason to move away from scarab. Scarab is IMHO a general PITA. Sorry for my french. Regards Henning -- Dipl.-Inf. (Univ.) Henning P. Schmiedehausen INTERMETA GmbH [EMAIL PROTECTED]+49 9131 50 654 0 http://www.intermeta.de/ RedHat Certified Engineer -- Jakarta Turbine Development -- hero for hire Linux, Java, perl, Solaris -- Consulting, Training, Development 4 - 8 - 15 - 16 - 23 - 42 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: jdk 1.3 support in torque generator
Thomas Fischer [EMAIL PROTECTED] writes: Hi, I am unsure about whether we should still support jdk 1.3.x in the generator. If we would drop it, we could also drop the dependencies on jndi.jar and jdbc.jar, which are awful as they cannot be obtained from ibiblio, but have to be downloaded from sun, unpacked, renamed and put into the right directory in the maven local repository in order to run the maven plugin. For JDK 1.4 and later, this is not necessary any more because the jars are already contained in the jdk. Basically I'm -0 on this. While I don't really care for 1.3 backwards compatibility (I do see your point), I know that there are lots of projects stuck on 1.3 for various reasons. Personally I would have no qualms if we require 1.4 for building torque (make sure that you set 1.3 compatibility in the build.properties) and state in the docs that torque will still run on 1.3 (+JNDI + JDBC). I would like to comment out the dependency on jndi and jdbc in the generator's project xml and put a note 1) in the project xml itself and 2) on the generator homepage to uncomment the dependecies if one uses jdk 1.3. This would imply that people using jdk 1.3 would have to build the generator from source. +1 for that. Note that the runtime should still support JDK 1.3 out of the box (However, I am not sure about it because I did not try it lately) Don't think so. I'm pretty sure that you need jdbc.jar for some data sources and definitely jndi for the JNDI based DS. I will not crash and burn immediately though. Regards Henning -- Dipl.-Inf. (Univ.) Henning P. Schmiedehausen INTERMETA GmbH [EMAIL PROTECTED]+49 9131 50 654 0 http://www.intermeta.de/ RedHat Certified Engineer -- Jakarta Turbine Development -- hero for hire Linux, Java, perl, Solaris -- Consulting, Training, Development 4 - 8 - 15 - 16 - 23 - 42 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: silent db hit for associated objects
Thomas Fischer [EMAIL PROTECTED] writes: Hi, If one has an association between objects by foreign key, (e.g. book - author association in the tutorial), Torque generates methods to get the associated objects (e.g. Book.getAuthor() and Author.getBooks()). If the associated object has not yet been retrieved, these methods silently ask the database for the objects, using a new connection from the database pool. This is not at all what one wants if one wants to use transactions in an application, because one wants to do all reads in the same transaction. I therefore plan to do the following 1) add a method getXXX(boolean silentDbFetch), which only hits the database silently if silentDbFetch is set to true. If set to false and the associated object(s) have not been retrieved yet, null is returned, even though there might be associated objects in the database. -0 The classes are already too overloaded IMHO. 2 ) add a method getXXX(connection) for the n-1 direction, whcih uses the provided connection if a db hit is necessary (in the book example, this would be book.getAuthor(connection) (author.getBooks() was already present) +0; this is better, but still not really good. The question is: Does it hurt? The database hit is read-only, so a rollback would only be necessary if you have some trigger in the database which does writing changes on a read-access. In the worst case you will get stale data, but personally I would always recommend to run with torque.objectIsCaching = false anyway. 3) add a generator property torque.silentDbFetch, which is true by default. If set to false, the getXXX() methods without arguments will not access the db silently, but return null if the associated objects has not been read yet. Also, the method does not throw a Torque exception any more (which is the main reason why using these methods is more convenient than getXXX(boolean silentDbFetch) with silentDbFetch set to false). That sounds like the best way to go. Regards Henning -- Dipl.-Inf. (Univ.) Henning P. Schmiedehausen INTERMETA GmbH [EMAIL PROTECTED]+49 9131 50 654 0 http://www.intermeta.de/ RedHat Certified Engineer -- Jakarta Turbine Development -- hero for hire Linux, Java, perl, Solaris -- Consulting, Training, Development 4 - 8 - 15 - 16 - 23 - 42 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: jdk 1.3 support in torque generator
Henning P. Schmiedehausen [EMAIL PROTECTED] writes: sources and definitely jndi for the JNDI based DS. I will not crash ^ It and burn immediately though. -- Dipl.-Inf. (Univ.) Henning P. Schmiedehausen INTERMETA GmbH [EMAIL PROTECTED]+49 9131 50 654 0 http://www.intermeta.de/ RedHat Certified Engineer -- Jakarta Turbine Development -- hero for hire Linux, Java, perl, Solaris -- Consulting, Training, Development 4 - 8 - 15 - 16 - 23 - 42 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: initial values
Mickey Mokotov [EMAIL PROTECTED] writes: actually it does. However, it involves XML. :-) After you built your schema, you run the torque:datadtd task. This will create a simple DTD for your schema. According to this DTD; you can then create an XML file which contains your data. This can be loaded into the database by running the torque:datasql task. An example: On Turbine, we have turbine-security-schema which contains the following table: --- cut --- table name=TURBINE_USER idMethod=idbroker column name=USER_ID required=true primaryKey=true type=INTEGER/ column name=LOGIN_NAME required=true size=64 type=VARCHAR javaName=UserName/ column name=PASSWORD_VALUE required=true size=16 type=VARCHAR javaName=Password/ column name=FIRST_NAME required=true size=64 type=VARCHAR/ column name=LAST_NAME required=true size=64 type=VARCHAR/ column name=EMAIL size=64 type=VARCHAR/ column name=CONFIRM_VALUE size=16 type=VARCHAR javaName=Confirmed/ column name=MODIFIED type=TIMESTAMP size=0/ column name=CREATED type=TIMESTAMP size=0 javaName=CreateDate/ column name=LAST_LOGIN type=TIMESTAMP size=0/ column name=OBJECTDATA type=VARBINARY/ unique unique-column name=LOGIN_NAME/ /unique /table --- cut --- running torque:datadtd creates turbine-security-data.dtd !ELEMENT dataset ( TurbineUser| [...] )* !ATTLIST dataset name CDATA #REQUIRED !ELEMENT TurbineUser EMPTY !ATTLIST TurbineUser UserId CDATA #REQUIRED UserName CDATA #REQUIRED Password CDATA #REQUIRED FirstName CDATA #REQUIRED LastName CDATA #REQUIRED Email CDATA #IMPLIED Confirmed CDATA #IMPLIED Modified CDATA #IMPLIED CreateDate CDATA #IMPLIED LastLogin CDATA #IMPLIED Objectdata CDATA #IMPLIED [...] --- cut --- According to this DTD, you can now create turbine-security-data.xml --- cut --- ?xml version=1.0 encoding=ISO-8859-1 standalone=no ? !DOCTYPE dataset SYSTEM file://turbine-security-data.dtd [...] dataset name=all TurbineUser UserId=1 UserName=admin Password=password FirstName= LastName=Admin/ TurbineUser UserId=2 UserName=user Password=password FirstName= LastName=User/ [...] --- cut --- this turbine-security-data.xml file will create a data SQL file when you run the torque:datasql and it will be inserted on torque:insert-sql. I do use this with great success in a number of projects (I do load a country table with defaults BTW. ;-) ) Regards Henning --=_NextPart_000_000B_01C587CF.C7353460 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Hi guys, =20 Q: I want to fill tables with initial values (for example, one might = want to have a Country table, and than have this table filled with all the countries). Does torque schema support adding values for tables?=20 I'm asking since I'd rather avoid having a 'db-creation-script', rather = I'd like to keep the schema.xml on cvs and generate the db-creation-script whenever I need. =20 --=20 http://www.fetchbook.info/ www.FetchBook.Info Find the lowest price - Compare more then a hundred book stores in a = click. =20 --=_NextPart_000_000B_01C587CF.C7353460-- -- Dipl.-Inf. (Univ.) Henning P. Schmiedehausen INTERMETA GmbH [EMAIL PROTECTED]+49 9131 50 654 0 http://www.intermeta.de/ RedHat Certified Engineer -- Jakarta Turbine Development -- hero for hire Linux, Java, perl, Solaris -- Consulting, Training, Development 4 - 8 - 15 - 16 - 23 - 42 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Torque 3.2-rc1 is released
Thomas Fischer [EMAIL PROTECTED] writes: Thanks for the really hard work! Regards Henning The Torque development team is pleased to announce that Torque-3.2-rc1 is released and ready for download. We would like to thank all contributors, bug reporters and other people who have contributed in one way or another to prepare the release candidate. The most prominent changes are: - Added database schema support, both in the generator and in the runtime - Added support for outer joins - Added support for creation of simple java beans from persistent objects - The old deprecated connection pool is removed (only dbcp is supported out of the box) - Some smaller changes were made in the database.dtd - The build-torque ant file for the generator is contained again in the generator release - The generator is now divided into a template jar (torque-gen-templates.jar) and the rest (torque-gen.jar) You can obtain the Torque 3.2-rc1 generator, runtime and maven-plugin from our download page http://db.apache.org/torque/download.html or from the ibiblio maven repository http://ibiblio.org/maven/torque/ Please refer to the Changes report http://db.apache.org/torque/changes-report.html for a full list of changes and fixed bugs. If you discover any bugs in the release candidate or feel that there are _SMALL_ things missing for the final release, please open an issue in the issue tracker http://issues.apache.org/scarab/issues If you have not done so before, create an account and request the role of observer in the modules torque source or torque documentation, depending of the nature of your bug. Ater being granted that role (should happen automatically as far as I know), enter your bug. Make sure you attach all files before you click finish. If you have any questions, please feel free to ask at the Torque users mailing list. The Torque development team. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Dipl.-Inf. (Univ.) Henning P. Schmiedehausen INTERMETA GmbH [EMAIL PROTECTED]+49 9131 50 654 0 http://www.intermeta.de/ RedHat Certified Engineer -- Jakarta Turbine Development -- hero for hire Linux, Java, perl, Solaris -- Consulting, Training, Development 4 - 8 - 15 - 16 - 23 - 42 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Subversion migration
Hi, now that the repository problems which stopped migration @ ApacheCon have been shaken out and Thomas has made the 3.2-rc1 release, it might be a good moment to get the migration finally underway. I have already made a cvs2svn test conversion and will open an issue with infra shortly about this. My idea is, that we will build 3.2-rc2 from subversion, shake down the links for documentation and everything else and then build 3.2 from the subversion repository. Opinions? Regards Henning -- Dipl.-Inf. (Univ.) Henning P. Schmiedehausen INTERMETA GmbH [EMAIL PROTECTED]+49 9131 50 654 0 http://www.intermeta.de/ RedHat Certified Engineer -- Jakarta Turbine Development -- hero for hire Linux, Java, perl, Solaris -- Consulting, Training, Development 4 - 8 - 15 - 16 - 23 - 42 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Subversion migration
Thomas Fischer [EMAIL PROTECTED] writes: Hi Henning, sounds good to me. Can I help you with anything ? Hi, I did a cvs2svn dump (you can get it from people.apache.org) and notified infrastructure, so all we can do now is just sit tight and wait for them to load the test repo. Once this is done, we should try out if everything works as we expect it and if yes, tell them to go live. Regards Henning Thomas On Mon, 25 Jul 2005, Henning P. Schmiedehausen wrote: Hi, now that the repository problems which stopped migration @ ApacheCon have been shaken out and Thomas has made the 3.2-rc1 release, it might be a good moment to get the migration finally underway. I have already made a cvs2svn test conversion and will open an issue with infra shortly about this. My idea is, that we will build 3.2-rc2 from subversion, shake down the links for documentation and everything else and then build 3.2 from the subversion repository. Opinions? Regards Henning -- Dipl.-Inf. (Univ.) Henning P. Schmiedehausen INTERMETA GmbH [EMAIL PROTECTED]+49 9131 50 654 0 http://www.intermeta.de/ RedHat Certified Engineer -- Jakarta Turbine Development -- hero for hire Linux, Java, perl, Solaris -- Consulting, Training, Development 4 - 8 - 15 - 16 - 23 - 42 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Dipl.-Inf. (Univ.) Henning P. Schmiedehausen INTERMETA GmbH [EMAIL PROTECTED]+49 9131 50 654 0 http://www.intermeta.de/ RedHat Certified Engineer -- Jakarta Turbine Development -- hero for hire Linux, Java, perl, Solaris -- Consulting, Training, Development 4 - 8 - 15 - 16 - 23 - 42 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Torque SVN conversion at ApacheCon EU Hackathon?
Hi, we did vote about this some time ago and had great agreement; Thomas and I will be at AC and there are all of the infrastructure people around (we simply assimilate Erik... ;-). I did plan to do this but I don't want to interfere with Thomas' release. But right after the release would be a really nice moment to do the SVN conversion. Regards Henning -- Dipl.-Inf. (Univ.) Henning P. Schmiedehausen INTERMETA GmbH [EMAIL PROTECTED]+49 9131 50 654 0 http://www.intermeta.de/ RedHat Certified Engineer -- Jakarta Turbine Development -- hero for hire Linux, Java, perl, Solaris -- Consulting, Training, Development Now you can start with implementation and integration and do the requirements later. -- Prof. Dr. Dr. h.c. Manfred Broy about the new german federal software development standard V-Model XT (found at http://de.biz.yahoo.com/050207/299/4en0t.html) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: accuracy of TIME columns
Thomas Fischer [EMAIL PROTECTED] writes: Hi, I am currently checking a bug report (http://nagoya.apache.org/scarab/issues/id/TRQS263). I am investigating the accuracy of TIME columns. The problem is that saving a TIME value and retrieving it again from an Oracle DB only has day accuracy, not second accuracy as one would expect from the SQL type TIME. Sounds like the mapping of the TIME type in db.props is wrong. And from db-torque-TORQUE_3_1_BRANCH/src/generator/src/templates/sql/base/oracle/db.props: --- cut --- DATE = DATE TIME = DATE TIMESTAMP = DATE --- cut --- the reason for this is clear. All TIME types are mapped to DATE, which _has_ only day resolution. No magic here. :-) While stepping through the code, I have come to the conclusion that this problem might not be a oracle problem, but might also occur in other databases. To check this, I have just committed a test case to CVS branch TORQUE_3_1_BRANCH. Can anyone whoe does _NOT_ use oracle please check this out and run the runtime-tests? At some point, there should be output like This is even easier: src/generator/src/templates/sql/base/axion/db.props:TIME = time src/generator/src/templates/sql/base/cloudscape/db.props:TIME = TIME src/generator/src/templates/sql/base/db2400/db.props:TIME = TIME src/generator/src/templates/sql/base/db2/db.props:TIME = TIME src/generator/src/templates/sql/base/hypersonic/db.props:TIME = time src/generator/src/templates/sql/base/interbase/db.props:TIME = src/generator/src/templates/sql/base/msaccess/db.props:TIME = time src/generator/src/templates/sql/base/mssql/db.props:TIME = DATETIME src/generator/src/templates/sql/base/mysql/db.props:TIME = TIME src/generator/src/templates/sql/base/oracle/db.props:TIME = DATE src/generator/src/templates/sql/base/postgresql/db.props:TIME = time src/generator/src/templates/sql/base/sapdb/db.props:TIME = TIME src/generator/src/templates/sql/base/sybase/db.props:TIME = TIMESTAMP = all but Oracle should work. Why does the Oracle mapping has TIME = DATE? I don't know. Regards Henning -- Dipl.-Inf. (Univ.) Henning P. Schmiedehausen INTERMETA GmbH [EMAIL PROTECTED]+49 9131 50 654 0 http://www.intermeta.de/ RedHat Certified Engineer -- Jakarta Turbine Development -- hero for hire Linux, Java, perl, Solaris -- Consulting, Training, Development What is more important to you... [ ] Product Security or [ ] Quality of Sales and Marketing Support -- actual question from a Microsoft customer survey - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: accuracy of TIME columns
Thomas Fischer [EMAIL PROTECTED] writes: Well, I didn't want to bother non-Oracle people with oracle details. So the thing is that Oracle's DATE format has seconds accuracy, and there is no Heh, we're wresting with a database layer. We should talk about the implementation details... :-) TIME type. So the DB should be able to save and retrieve even DATE fields with seconds precision, no problem there. Ah, the joy of standards... [...] So looking into Torque and Village code, it seems to me that for TIME colums, Torque uses a java.util.Date object. Then, village looks at the type of the object, says well, it's java.util.Date, lets format it with day accuracy, and the insert is done with day accuracy. But if this is the case, all other DBs should have the same problem, and as I do not have an easy possibility to check that, It would be very helpful if someone did that for me. So do you think it is a village problem? I've posted a (cleaned) snapshot of village a while ago, which is nice for debugging in Eclipse. Maybe you want to check whether there is a bug inside this. Regards Henning -- Dipl.-Inf. (Univ.) Henning P. Schmiedehausen INTERMETA GmbH [EMAIL PROTECTED]+49 9131 50 654 0 http://www.intermeta.de/ RedHat Certified Engineer -- Jakarta Turbine Development -- hero for hire Linux, Java, perl, Solaris -- Consulting, Training, Development What is more important to you... [ ] Product Security or [ ] Quality of Sales and Marketing Support -- actual question from a Microsoft customer survey - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: initialisation process: registration of Map builders
Thomas Fischer [EMAIL PROTECTED] writes: 4) modify the Peer classes such that the static initializer of any Peer class loads every other Peer class, e.g. by putting in class.forName(...) calls in the static initializer. This makes the Torque startup with large schematas as sluggish as the Hibernate startup. Acceptable for start once, run a long time application like server side java, inacceptable for e.g. command line tools. Using Hibernate here is a main PITA. If you really think of putting Class.forName() somewhere, please make it _one_ method in e.g. the mapbuilder and let all the peers call this method. I don't want to have a list of n Class.forName() statements duplicated in every Peer. Regards Henning -- Dipl.-Inf. (Univ.) Henning P. Schmiedehausen INTERMETA GmbH [EMAIL PROTECTED]+49 9131 50 654 0 http://www.intermeta.de/ RedHat Certified Engineer -- Jakarta Turbine Development -- hero for hire Linux, Java, perl, Solaris -- Consulting, Training, Development What is more important to you... [ ] Product Security or [ ] Quality of Sales and Marketing Support -- actual question from a Microsoft customer survey - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
CfV: Move to Subversion [Was Re: repository (CVS/subversion ?) organisation]
Thomas Fischer [EMAIL PROTECTED] writes: Hi. it seems that nobody really cares about whether the repository should be moved to subversion or not. So Henning, I would suggest you launch a vote and then do it. [...] Henning, do you think the clean-up is done more easily once the repository is moved, or is there no difference ? I have no idea, as I did not work with subversion before. _MUCH_ easier in subversion. svn move trunk branches/torque-3.2-DEAD svn copy branches/torque-3.1 trunk done. Vote: Shall we move the DB Torque repository to Subversion? === Advantages: - Re-Organization of the HEAD and Branches would be much easier - Decoupling of the Generator, maven plugin and runtime would be possible, allowing us to develop the code independently and with different speeds - Most of the quirks from CVS are gone (global Revision numbers, easy tagging cheap copies...) Disadvantages: - IDE code needs to be Subversion aware (at least Eclipse has the very good subclipse plugin from tigris.org) - Our maven build might (no, _will) lose some information such as the developer-activity or changelog plugins because they don't support Subversion yet. +1 [ ] Do it, the advantages outweigh the disadvantages 0 [ ] I don't care -1 [ ] Don't it, the disadvantages outweigh the advantages I can do the move between chrismas and new years eve (depending on the right people being present @ #asfinfra). Vote open till Dec 23th, 12:00 MET. Regards Henning -- Dipl.-Inf. (Univ.) Henning P. Schmiedehausen INTERMETA GmbH [EMAIL PROTECTED]+49 9131 50 654 0 http://www.intermeta.de/ RedHat Certified Engineer -- Jakarta Turbine Development -- hero for hire Linux, Java, perl, Solaris -- Consulting, Training, Development What is more important to you... [ ] Product Security or [ ] Quality of Sales and Marketing Support -- actual question from a Microsoft customer survey - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [SOURCE] Issue #TRQS256 had user association modified
[EMAIL PROTECTED] writes: Henning: Thx for the feedback! (even though bedside manners doesn't seem to be your strong point... I'm quite busy ATM and write short comments that might sound harsh. I know, this is not intended to be harsh, just to the point. If you felt offended, I apologize. However, this is a development list and code critisism is intended to improve the code quality, not to put people down. remember I just want to contribute a bit back to the community with a feature that I think is useful) We all are grateful for contributions. But that does not mean, that every patch gets applied without discussion. IMHO there is no reason to add another number of convenience methods to an already bloated class. These methods can well be inside a helper class (CountHelper e.g.) Uh, do we really want to bloat up the Peer classes any further? What sense in putting this into BasePeer? Ok, where would you put it? o.a.t.utils.CountHelper e.g. [...] Why are you doing all the shebang in count(Criteria, Connection, columnName, distinct) ? Am I missing something? In order to issue the 'count' call the criteria is modified. So in order to restitute it in the original form, we are resetting the columns and the 'order by columns' in the original states. With this, the called doesn't need to keep a copy of his original object. Is there a need to keep state? AFAIK none of the other methods keep the state of the Criteria. IMHO, just run the count and be done with it. Put a notice on top of the Methods that the state of Criteria is destroyed. You should be able to get the deliminator from buildQuery()? Why use the doSelect() anyway? Why not use the primitives to build the SQL string and send it to the DB? Why not? Because doSelect() is expensive as hell. It runs through all the Village hoops just to return (in the end) a single integer value. I'd expect to run a simple Criteria parser + straight SQL to run 10-20 times faster. However, this probably won't be visible compared to the DB time for the select anyway. :-) Regards Henning -- Dipl.-Inf. (Univ.) Henning P. Schmiedehausen INTERMETA GmbH [EMAIL PROTECTED]+49 9131 50 654 0 http://www.intermeta.de/ RedHat Certified Engineer -- Jakarta Turbine Development -- hero for hire Linux, Java, perl, Solaris -- Consulting, Training, Development What is more important to you... [ ] Product Security or [ ] Quality of Sales and Marketing Support -- actual question from a Microsoft customer survey - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: cvs commit: db-torque/src/java/org/apache/torque/util Criteria.java
[EMAIL PROTECTED] writes:
tfischer2004/12/13 09:35:28
Modified:src/java/org/apache/torque/util Tag: TORQUE_3_1_BRANCH
Criteria.java
Log:
Changed getJoins() to public access
No reason why it should not be public (all the other getters are)
I didn't want to expose the Join objects outside the util package to
the end user. If you open up this method, you lock in the object
signature (which ATM is an Arraylist(3) and should be replaced with a
thinner Join bean) because you expose the contents to the
public. Changing this would later be a nasty surprise to the users.
Do you actually need this or is this a well, this seems to be a good
idea patch?
Regards
Henning
Revision ChangesPath
No revision
No revision
1.42.2.6 +2 -2 db-torque/src/java/org/apache/torque/util/Criteria.java
Index: Criteria.java
===
RCS file: /home/cvs/db-torque/src/java/org/apache/torque/util/Criteria.java,v
retrieving revision 1.42.2.5
retrieving revision 1.42.2.6
diff -u -r1.42.2.5 -r1.42.2.6
--- Criteria.java1 Dec 2004 15:03:39 - 1.42.2.5
+++ Criteria.java13 Dec 2004 17:35:28 - 1.42.2.6
@@ -1346,7 +1346,7 @@
* @return a List which contains objects of type Join,
* or null if the criteria dies not contains any joins
*/
-List getJoins()
+public List getJoins()
{
return joins;
}
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
Dipl.-Inf. (Univ.) Henning P. Schmiedehausen INTERMETA GmbH
[EMAIL PROTECTED]+49 9131 50 654 0 http://www.intermeta.de/
RedHat Certified Engineer -- Jakarta Turbine Development -- hero for hire
Linux, Java, perl, Solaris -- Consulting, Training, Development
What is more important to you...
[ ] Product Security
or [ ] Quality of Sales and Marketing Support
-- actual question from a Microsoft customer survey
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: cvs commit: db-torque/src/java/org/apache/torque/util Criteria.java
Thomas Fischer [EMAIL PROTECTED] writes: [...] Are you content with this ? Basically, I just wanted to heads up that I did give the missing public some thought and it was not just an omission. Personally, I feel that for some of this code, we are reaching EOL in the development cycle. So I don't really care for (in-)visibility of the methods. Regards Henning -- Dipl.-Inf. (Univ.) Henning P. Schmiedehausen INTERMETA GmbH [EMAIL PROTECTED]+49 9131 50 654 0 http://www.intermeta.de/ RedHat Certified Engineer -- Jakarta Turbine Development -- hero for hire Linux, Java, perl, Solaris -- Consulting, Training, Development What is more important to you... [ ] Product Security or [ ] Quality of Sales and Marketing Support -- actual question from a Microsoft customer survey - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [SOURCE] Issue #TRQS256 had user association modified
thomas fischer [EMAIL PROTECTED] writes: You can view the issue detail at the following URL: http://nagoya.apache.org/scarab/issues/id/TRQS256 Type Enhancement Issue ID TRQS256 (count methods addition to the BasePeer class) Uh, do we really want to bloat up the Peer classes any further? What sense in putting this into BasePeer? We have constants for ASC (SqlEnum.ASC), please use these. (why entries[1].compareTo()? What is bad with equals()?) Why are you doing all the shebang in count(Criteria, Connection, columnName, distinct) ? Am I missing something? You should be able to get the deliminator from buildQuery()? Why use the doSelect() anyway? Why not use the primitives to build the SQL string and send it to the DB? If you build strings like this: c.addSelectColumn( COUNT(+ (distinct?DISTINCT :) +columnName +) ); please use a StringBuffer() All in all, I'm -0 on this patch. I don't really see the benefit to have it around in the BasePeer and it seems to complicated to me. As this is a static method anyway, why not move it into another helper class? Regards Henning -- Dipl.-Inf. (Univ.) Henning P. Schmiedehausen INTERMETA GmbH [EMAIL PROTECTED]+49 9131 50 654 0 http://www.intermeta.de/ RedHat Certified Engineer -- Jakarta Turbine Development -- hero for hire Linux, Java, perl, Solaris -- Consulting, Training, Development What is more important to you... [ ] Product Security or [ ] Quality of Sales and Marketing Support -- actual question from a Microsoft customer survey - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: provide a central place for parsing column names in SQLBuilder
Thomas Fischer [EMAIL PROTECTED] writes: Henning, I just checked out your changes and they pass the runtime test on Oracle 9.2 ;-) Nice. I expect this to fail on DBs which don't support schemas like MySQL (?) (my MySQL is a bit rusty, 3.x didn't have them). I am also very glad that all the initialisation procedures in the DB adapters have been simplified, and that the parsing of the tablenames now Yep, that was a nice side effect. happens at a central place (though there are still a lot of methods for this, but this is certainly to be blamed on me, not you. Perhaps I can remedy this at some point.) There is a lot of work to be done. The parsing of the column names is shady at best. However, it does work and does not break the current state which is important IMHO. I felt a bit uneasy about putting default schema suppurt directly into the Torque object at my first impression. But then, e.g. in Oracle there is a It is in the DatasourceFactories. Torque is just the static facade. I'm open to better ideas. default schema for each database user, so what harm ist there to have a default schema per database in torque ? Some DBs will choke on the schema, I'm sure. I was concerned about backwards compatibility. So if you don't set the schema, it will not be visible. As for dynamically changing the schema name, well, if you need it... I am glad that I don't (Torque is a Singleton, so if you change it at one place, it gets changed in all the other places without warning. Even the thought makes me shudder). Yes. As I said, I didn't check in the whole patch. Internally for us here, schemaName is a part of the Criteria and the Torque.getSchema() is just the fallback. However, this brings _massive_ changes in the generator, the internal structure of the runtime and everything else (up to the method signatures for Criteria. Not 3.1 material at all). We e.g. have a bean called TableType which is a dbName/schemaName/tableName triple and controls the column name generation. Just out of curiosity : have you tried what happens if one puts schemaname.tablename as tablename into schema.xml ? That might also be interesting for some people. No. Testers welcome. More comments below Henning P. Schmiedehausen [EMAIL PROTECTED] schrieb am 13.12.2004 18:17:13: I just forced my Schema patch onto an unsuspecting public. :-) Please review; this patch does what I need for Torque which might not exactly be what everyone wants. In a nutshell: I have an application that uses a database schema for storing application state. Now this application is required to be multi-state. For convenience, we just use multiple schemas with the same table structure and let the user select the schema for the required application state. This is less than perfect, because one datasource currently cannot access different schemas (e.g. for different users). I am not sure what you want to do here. I thought that with your patch, one can either add the Schema name to the tablename when doing a select and then have full control over what schema to use with what table, or one can use the defaults. This makes perfect sense for me. What more could one want ? Ok, it would be nice if I could thell the Criteria object use this schema for this table/alias, and another schema for another, but this can be added later. However, without any per-database-session state object around in Torque, this is currently pretty hard to do (that is the part that I did _not_ check into the CVS...) I do not know about hibernate sessions, but assigning a schema to e.g. a connection would not make sense to me. For me, the location of tables is rather static, and only in extraordinary circumstances should be changed on runtime. In my example above, assigning a schema to a criteria would still be a per-criteria operation, and this is the scope which would make sense for me. Nearly everything (except transactions) in Torque is done on a per-Criteria-Basis, which I do not consider a disadvantage. If somebody has several criteria presets, he/she can build a factory for it, no need to store them in a session. I am under the slight impression that I did not grab what you meant, though. The fact that there is no state object like e.g. the Hibernate Session object really starts to hurt here... Please test. This passes the unit and runtime tests with PostgreSQL but I'm very keen on hearing other success / failure stories. Do you think that it makes sense to create runtime testcases for the extended functionality ? I am not sure whether every database supports schemata, but it would certainly help to have some testcases ready, even if one has to enable them by hand in some way. Definitely! Regards Henning -- Dipl.-Inf. (Univ.) Henning P. Schmiedehausen INTERMETA GmbH [EMAIL PROTECTED]+49 9131 50 654 0 http://www.intermeta.de/ RedHat Certified Engineer -- Jakarta Turbine Development -- hero for hire Linux
Re: provide a central place for parsing column names in SQLBuilder
Thomas Fischer [EMAIL PROTECTED] writes:
Hi,
In the org.apache.torque.util.SQLBuilder class (recently taken out of
BasePeer), there is a lot of code which parses column names in lots of
places. I would like to go ahead and see if the existing code can be
simplified by creating an internal class in SQLBuilder which represents a
database (pseudo)column, does the parsing and takes care of things like
aliases. I am not sure whether this works out, as there might be subtle
differences in the parsing of raw column names e.g. between the FROM part
and the ORDER BY part of the query, but I'd like to give it a try.
Ah, coincidence strikes again. Part of my reworks was to get the code
in shape to do exactly that. So yes, this is where I will work right
now.
While doing this, I would also like to check whether static schema support
can be easily built in. My fist step would be to allow tablenames which
contain a dot (like SCHEMANAME.TABLENAME). This would mean to replace the
splitting between tablename and columnname, which at the moment looks at
the first dot in the column name (rawColumnName.indexOf('.')), by splitting
at the last dot (rawColumnName.lastIndexOf('.'))
By the way, is the fully qualified column name
SCHEMANAME.TABLENAME.COLUMNNAME in all Db's or are there exceptions ?
And this is the reason why I need this. Even worse, I do need to
switch the schema name on the fly.
Do you already have code?
Regards
Henning
--
Dipl.-Inf. (Univ.) Henning P. Schmiedehausen INTERMETA GmbH
[EMAIL PROTECTED]+49 9131 50 654 0 http://www.intermeta.de/
RedHat Certified Engineer -- Jakarta Turbine Development -- hero for hire
Linux, Java, perl, Solaris -- Consulting, Training, Development
What is more important to you...
[ ] Product Security
or [ ] Quality of Sales and Marketing Support
-- actual question from a Microsoft customer survey
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: provide a central place for parsing column names in SQLBuilder
Thomas Fischer [EMAIL PROTECTED] writes:
yes, I have some code in an internal branch. I will not commit all of
it to the 3.1 branch, because some of my logic requires rewriting of
the templates. I will commit the parts that are usable without template
changes.
Regards
Henning
Hi Henning,
I do not have code yet. I have just done a quick survey to see whether
there are any big obstacles, but I did not find any. I just wanted to make
sure the work is done only once. So if you already have code, just tell me
and go ahead.
Thomas
Henning P. Schmiedehausen [EMAIL PROTECTED] schrieb am 10.12.2004
12:57:47:
Thomas Fischer [EMAIL PROTECTED] writes:
Hi,
In the org.apache.torque.util.SQLBuilder class (recently taken out of
BasePeer), there is a lot of code which parses column names in lots of
places. I would like to go ahead and see if the existing code can be
simplified by creating an internal class in SQLBuilder which represents
a
database (pseudo)column, does the parsing and takes care of things like
aliases. I am not sure whether this works out, as there might be subtle
differences in the parsing of raw column names e.g. between the FROM
part
and the ORDER BY part of the query, but I'd like to give it a try.
Ah, coincidence strikes again. Part of my reworks was to get the code
in shape to do exactly that. So yes, this is where I will work right
now.
While doing this, I would also like to check whether static schema
support
can be easily built in. My fist step would be to allow tablenames which
contain a dot (like SCHEMANAME.TABLENAME). This would mean to replace
the
splitting between tablename and columnname, which at the moment looks at
the first dot in the column name (rawColumnName.indexOf('.')), by
splitting
at the last dot (rawColumnName.lastIndexOf('.'))
By the way, is the fully qualified column name
SCHEMANAME.TABLENAME.COLUMNNAME in all Db's or are there exceptions ?
And this is the reason why I need this. Even worse, I do need to
switch the schema name on the fly.
Do you already have code?
Regards
Henning
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
Dipl.-Inf. (Univ.) Henning P. Schmiedehausen INTERMETA GmbH
[EMAIL PROTECTED]+49 9131 50 654 0 http://www.intermeta.de/
RedHat Certified Engineer -- Jakarta Turbine Development -- hero for hire
Linux, Java, perl, Solaris -- Consulting, Training, Development
What is more important to you...
[ ] Product Security
or [ ] Quality of Sales and Marketing Support
-- actual question from a Microsoft customer survey
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [J2] Vote: Torque schema generation problems - how to proceed?
Ate Douma [EMAIL PROTECTED] writes: Henning P. Schmiedehausen wrote: Chris Custine [EMAIL PROTECTED] writes: I think you may want to consider these items in the context of fixing the total nightmare of using torque-gen with Postgres as well. I have posted several times about the hoops I jump through to get JS2 and Postgres to work together, and your suggestions look like a good opportunity to fix those problems with torque-gen and Postgres. To be clear, no single project is at fault (Postgres, Torque, or JS2), but some minor bad choices in each are making Postgres support really crappy right now in JS2. The Torque people right over there at [EMAIL PROTECTED] would be really happy to know what you consider total nightmare. (Personally I'm running a PostgreSQL based Project using sequences as ID generators with ~4000 tables in 52 schemas inside a database quite successful. All tables are generated an maintained by Torque and accessed through Torque and Hibernate). (Folks, if you have trouble with Torque and/or improvements or wishes, LET US KNOW!). Not many Torque people scan the lists of arbitrary project. Just come over to torque-dev or torque-user and tell us. We are not only willing to listen, we are even willing to act and improve our code to cater the needs of our users. That's what a project is all about. Henning, thanks for the response and for scanning our list. Seems we aren't just an arbitrary project to you at least ;-) I scan jetspeed-* because it is built on Turbine (at least 1.5) and I still would like to find time (or someone that pays for it. ;-) ) to work more with Jetspeed. In my initial message, http://nagoya.apache.org/eyebrowse/ReadMsg?listId=22msgNo=19387, I described a few problems we are encountering with Torque right now. Just read it. As far as I can see, Torque really shines where its Pear support is needed (like in Jetspeed-1). But, for our Jetspeed-2 requirements which mainly concern mapping an abstract schema definition and inserting initial configuration data, the current torque generator features are not really sufficient, nor flexible enough. Yes. The static peers and the fixed connection of table - object really hurts (an example: In one of my projects I have a lot of tables that all have the same structure but describe different things. I'd really love to define the mapping between object and table only once and then just say table a maps to class foo. table b maps to class foo. table c maps to class foo. I ended up with having all classes that descibe a, b and c implement the same interface and just work through the interfaces. After reviewing the generator and its templates I found the following lacking or missing: - separate generation and/or suppression of drop table statements Yep. the drops should be turn-off-able using a property. They are not. - order of drop, create table statements causing conflicting result for different database: - for hsql a detail table must be generated (thus dropped) before the parent table otherwise a fk constraint violation is thrown - for mysql (also with innoDB) the foreign keys are generated inline and thus changing the order doesn't help: we need to drop the child table (or constraints) by hand, something Torque doesn't help us with This is difficult to achieve IMHO because the sequence of the tables is controlled by the Control.vm template and does not vary for the different databases. It _should_ be possible to suppress foreign key checking temporarily thus allowing arbitrary creation sequences with some databases but I am no real wizard here. This needs more input from other developers / users. - no support (as far as I could tell) for generating schema update scripts Yes. Torque is all or nothing. - no direct execution of ddl/data sql from xml, only through first written out scripts. For execution at runtime from a portal/servlet application this isn't blocking but not exactly what I really would like. Correct. The whole generator has been designed as an additional wart^W^Waddition to ant. It definitely needs refactoring and personally I want to look into dropping the whole Velocity templating/Texen shebang. Texen has given us nothing but headaches starting with logging and error reporting and ending up with gobbling up memory like mad... Personally, I believe an XSLT solution would be nicer but I sorely lack time to do any work on this ATM. Hibernate e.g. has a better solution by generating the creation SQL directly at run-time. We still shine at the source code generation for the classes/peers though. - data xml to sql translation is very limited. We at least need proper date and timestamp (in configurable format) value transformation support, as well as support for proper BIT mapping (an issue with PostgreSQL which seems to have been reported several times on the Torque list). Furthermore, I'd like to be able to use variables
Re: [J2] Vote: Torque schema generation problems - how to proceed?
activity - It depends on a number of snapshot jars - it has no release yet. - it is also (like torque-gen) missing any object types outside the database/table/column scope (sequence, view..) which are necessary to model your database fully. Hibernate is better here. Personally, I wouldn't hold my breath for this. It definitely needs work (e.g. there is no MySQL 3/4.0/4.1 distinction, same problem as torque-gen) just as torque-gen. But, my time is limited and I really would like to keep my primary focus on Jetspeed-2 features, not get lost in DB configuration problems. So I'm not convinced (yet), certainly not after your frankly given response on the current state of Torque, we should wait and see. I don't know about the deeper issues aside from the few mails in this thread. It all boils down to how deeply is J2 entwined with Torque. If your answer is not much, trying something like OJB might prove to be the better way. Moving from torque-gen to commons-sql looks more like a sideway move to new problems to me. My impression right now is that we have a much closer match with commons-sql already and that our near future needs (schema updates, direct ddl/sql execution) will prove that even more so. As I said above: JMMV. Regards Henning -- Dipl.-Inf. (Univ.) Henning P. Schmiedehausen INTERMETA GmbH [EMAIL PROTECTED]+49 9131 50 654 0 http://www.intermeta.de/ RedHat Certified Engineer -- Jakarta Turbine Development -- hero for hire Linux, Java, perl, Solaris -- Consulting, Training, Development What is more important to you... [ ] Product Security or [ ] Quality of Sales and Marketing Support -- actual question from a Microsoft customer survey - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [J2] Vote: Torque schema generation problems - how to proceed?
Silvio Godenzi [EMAIL PROTECTED] writes: Hi, dropping everything in reverse order than it was created should avoid referential integrity violations. But what is the creation sequence? This might be different for different databases (consider inline foreign key generation to outside). BTW: I posted this already in march 2002 Average UseNet memory is three months. :-) Regards Henning -- Dipl.-Inf. (Univ.) Henning P. Schmiedehausen INTERMETA GmbH [EMAIL PROTECTED]+49 9131 50 654 0 http://www.intermeta.de/ RedHat Certified Engineer -- Jakarta Turbine Development -- hero for hire Linux, Java, perl, Solaris -- Consulting, Training, Development What is more important to you... [ ] Product Security or [ ] Quality of Sales and Marketing Support -- actual question from a Microsoft customer survey - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: issue TRQS221 (invalid SQL for PostgreSQL bool columns)
T E Schmitz [EMAIL PROTECTED] writes: Hello, I apalogize in advance for writing to the dev list about this - I somehow couldn't find how to add a comment to the issue. I had a brief look at v 3.1.1 and noticed that DBPostgres.getBooleanString() still returns 0/1 rather than FALSE/TRUE. What puzzles me is: don't the other PostgreSQL users have the same problem as me?! (Henning, you are using psql too, aren't you?) Yep. I use column name=LOCKED required=true type=BIT javaName=Locked/ and this works fine for me. I use PostgreSQL 7.3.4 though. Small Testcase against 3.1.1 / 3_1_BRANCH would be great Regards Henning -- Dipl.-Inf. (Univ.) Henning P. Schmiedehausen INTERMETA GmbH [EMAIL PROTECTED]+49 9131 50 654 0 http://www.intermeta.de/ RedHat Certified Engineer -- Jakarta Turbine Development -- hero for hire Linux, Java, perl, Solaris -- Consulting, Training, Development What is more important to you... [ ] Product Security or [ ] Quality of Sales and Marketing Support -- actual question from a Microsoft customer survey - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: torque.idbroker.cleverquantity=false doesn't work
Jinsong Hu [EMAIL PROTECTED] writes: --=_NextPart_000_0005_01C4D467.C25B4D60 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable I notice in 3.1 and 3.1.1 , if I set = torque.idbroker.cleverquantity=3Dfalse, the quantity column in the ID_TABLE still increases. Is this a bug, has = that been fixed ? Jinsong Hu cleverquantity just means, that Torque does not access the DB for each required ID but pulls batches from the DB. Maybe idbroker.prefetch is what you are looking for. Regards Henning -- Dipl.-Inf. (Univ.) Henning P. Schmiedehausen INTERMETA GmbH [EMAIL PROTECTED]+49 9131 50 654 0 http://www.intermeta.de/ RedHat Certified Engineer -- Jakarta Turbine Development -- hero for hire Linux, Java, perl, Solaris -- Consulting, Training, Development What is more important to you... [ ] Product Security or [ ] Quality of Sales and Marketing Support -- actual question from a Microsoft customer survey - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Village dependency
Lach, Thierry [EMAIL PROTECTED] writes: If there is no further work being done on Village, perhaps it could be moved into apache db (db-commons perhaps?) or incorporated directly into torque so that people don't have to keep passing around patches for it in order to use Torque on different databases? You are welcome to try and get the people behind share.whichever.com to donate the code to the ASF. I was not able to pull this off. Regards Henning -Original Message- From: Thomas Fischer [mailto:[EMAIL PROTECTED] Sent: Friday, November 12, 2004 3:34 AM To: [EMAIL PROTECTED] Cc: Apache Torque Developers List Subject: Re: Village dependency Hi, it seems that village is not developed any more, so the current version from their CVS is fine. The correct jar can also be found in the binary distribution of torque. Thomas Vidas Simkus [EMAIL PROTECTED] schrieb am 12.11.2004 01:44:20: In reference to this: http://db.apache.org/torque/dependencies.html It states that Torque requires '2.0-dev-20030825', yet there's no reference to that particular version anywhere on the Village site. I checked out the latest version for their CVS...and the build.xml has '2.0-dev' as the version property. Is this the correct version of Village to use? Thanks -- My favorite animal is steak. -Fran Lebowitz - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] This message and any attachments contain information, which may be confidential or privileged. If you are not the intended recipient, please refrain from any disclosure, copying, distribution or use of this information. Please be aware that such actions are prohibited. If you have received this transmission in error, kindly notify us by calling 1-800-262-4723 or e-mail to [EMAIL PROTECTED] We appreciate your cooperation. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Dipl.-Inf. (Univ.) Henning P. Schmiedehausen INTERMETA GmbH [EMAIL PROTECTED]+49 9131 50 654 0 http://www.intermeta.de/ RedHat Certified Engineer -- Jakarta Turbine Development -- hero for hire Linux, Java, perl, Solaris -- Consulting, Training, Development What is more important to you... [ ] Product Security or [ ] Quality of Sales and Marketing Support -- actual question from a Microsoft customer survey - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Village dependency
Vidas Simkus [EMAIL PROTECTED] writes: In reference to this: http://db.apache.org/torque/dependencies.html It states that Torque requires '2.0-dev-20030825', yet there's no reference to that particular version anywhere on the Village site. I checked out the latest version for their CVS...and the build.xml has '2.0-dev' as the version property. Is this the correct version of Village to use? Ok folks, I will teel you the whole and dirty truth... :-) I tried to get the Village code donated to the ASF by whichever.com who developed the code. However, as far as I can see, this this will not happen. However, the code _is_ released under BSD license. So it will be possible to simply fork off it. While I consider it impolite without an explicit permission from the original author, I see no other chance to keep the base of Torque stable and add the various bug fixes that are floating around applied _and_ get a release from this. While many people (including the authors) do consider Village ready and there is no work going on on the Village code, there are some issues with database specific stuff (like the Oracle patches). This cannot happen under an ASF umbrella (so I don't expect to get org.apache.village which I really would have prefered) but it might happen under another name. In fact, I do have the village code base reorganized and building with maven right here; I cleaned up some of the PMD and findbugs issues (just minor stuff) and added a few unit tests with hsqldb (taking the TestMySQL class apart) here at the ApacheCon Hackathlon. I will just dump a source tarball at my home page @ apache as soon as I get a better network connection here at Apachecon. As Torque is probably the biggest generic Village user, we can discuss work on @ torque-dev. Feel free to send me patches to Village that you would like to see applied (diff -u please and a short description). Regards Henning -- Dipl.-Inf. (Univ.) Henning P. Schmiedehausen INTERMETA GmbH [EMAIL PROTECTED]+49 9131 50 654 0 http://www.intermeta.de/ RedHat Certified Engineer -- Jakarta Turbine Development -- hero for hire Linux, Java, perl, Solaris -- Consulting, Training, Development What is more important to you... [ ] Product Security or [ ] Quality of Sales and Marketing Support -- actual question from a Microsoft customer survey - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Village snapshot
Grab my Village Snapshot from http://www.apache.org/~henning/village-20041114.tar.gz Regards Henning -- Dipl.-Inf. (Univ.) Henning P. Schmiedehausen INTERMETA GmbH [EMAIL PROTECTED]+49 9131 50 654 0 http://www.intermeta.de/ RedHat Certified Engineer -- Jakarta Turbine Development -- hero for hire Linux, Java, perl, Solaris -- Consulting, Training, Development What is more important to you... [ ] Product Security or [ ] Quality of Sales and Marketing Support -- actual question from a Microsoft customer survey - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [SOURCE] Issue #TRQS242 - torque-3.1.1-src.tar.gz misses project-base.xml
Stefan Broetz [EMAIL PROTECTED] writes: Ok, I think I will have to reroll the distribution archives. Sorry about this. Regards Henning You can view the issue detail at the following URL: http://nagoya.apache.org/scarab/issues/id/TRQS242 Type Defect Issue ID TRQS242 (torque-3.1.1-src.tar.gz misses project-base.xml) Reported by Stefan Broetz stefanb ([EMAIL PROTECTED]) New issue details: - Summary set to torque-3.1.1-src.tar.gz misses... Status set to New Description set to The source distribution archiv... Priority set to High Issue created - This message is automatically generated by the Scarab issue tracking system. For more information: http://scarab.tigris.org/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Dipl.-Inf. (Univ.) Henning P. Schmiedehausen INTERMETA GmbH [EMAIL PROTECTED]+49 9131 50 654 0 http://www.intermeta.de/ RedHat Certified Engineer -- Jakarta Turbine Development -- hero for hire Linux, Java, perl, Solaris -- Consulting, Training, Development What is more important to you... [ ] Product Security or [ ] Quality of Sales and Marketing Support -- actual question from a Microsoft customer survey - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Torque Source archives rebuilt
Hi, as Stefan found out, it was not possible to build Torque from the -src archives on www.apache.org. The reason for this is the interdependency between the three parts of Torque (generator, runtime, maven-plugin) and the project-base.xml file which is not understood by the maven dist target (and renders this at least for source archives pretty useless). Due to this interdependency, it does not make much sense to pack the generator and the maven-plugin separately. I simply packed up the whole tree for the TORQUE_3_1_1 tag into an archive, signed it and uploaded it. And added a Notice to the directory and soft-links for the generator and maven-plugin jar. This will actually get better with SVN; we could define a common module there and pull it into the various elements with svn:external. Regards Henning -- Dipl.-Inf. (Univ.) Henning P. Schmiedehausen INTERMETA GmbH [EMAIL PROTECTED]+49 9131 50 654 0 http://www.intermeta.de/ RedHat Certified Engineer -- Jakarta Turbine Development -- hero for hire Linux, Java, perl, Solaris -- Consulting, Training, Development What is more important to you... [ ] Product Security or [ ] Quality of Sales and Marketing Support -- actual question from a Microsoft customer survey - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Torque Binary archives rebuilt
Hi, some users have noticed that the lib dependencies are missing from the torque und torque-gen archives were missing. I hereby promise not to use the maven dist-tools ever again for rolling distributions. I rerolled the torque-gen and torque archives with the lib dependencies. Please note that the JNDI and JDBC archives are still missing because we are not allowed to distribute these jars from apache.org sites. Sorry for the inconvenience Henning -- Dipl.-Inf. (Univ.) Henning P. Schmiedehausen INTERMETA GmbH [EMAIL PROTECTED]+49 9131 50 654 0 http://www.intermeta.de/ RedHat Certified Engineer -- Jakarta Turbine Development -- hero for hire Linux, Java, perl, Solaris -- Consulting, Training, Development What is more important to you... [ ] Product Security or [ ] Quality of Sales and Marketing Support -- actual question from a Microsoft customer survey - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[CfV] Thomas Fischer as a committer
Hi, I'd like to propose Thomas Fischer [EMAIL PROTECTED] as a committer for the DB Torque project. Thomas has demonstrated that he understands the Torque code and wants to contribute to the project. This is what he wrote about himself: --- cut --- I was born in 1972 in Bamberg, Germany. After school I studied physics, where I gained some experience in C++ programming, and finished my PhD in 2003. Since then, I work for a company called Seitenbau, which is located in Konstanz, Germany, and have learnt my java lessions there. Seitenbau specializes in Content Management Systems and building Web-based applications. In my spare time, I like to sail, windsurf, hike, and snowboard, depending on the season. --- cut --- [ ] +1 Yes, Thomas should become a committer [ ] 0 I don't care. [ ] -1 No. Regards Henning -- Dipl.-Inf. (Univ.) Henning P. Schmiedehausen INTERMETA GmbH [EMAIL PROTECTED]+49 9131 50 654 0 http://www.intermeta.de/ RedHat Certified Engineer -- Jakarta Turbine Development -- hero for hire Linux, Java, perl, Solaris -- Consulting, Training, Development Fighting for one's political stand is an honorable action, but re- fusing to acknowledge that there might be weaknesses in one's position - in order to identify them so that they can be remedied - is a large enough problem with the Open Source movement that it deserves to be on this list of the top five problems. -- Michelle Levesque, Fundamental Issues with Open Source Software Development - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [CfV] Thomas Fischer as a committer
Henning P. Schmiedehausen [EMAIL PROTECTED] writes: [X] +1 Yes, Thomas should become a committer ...obviously. :-) -- Dipl.-Inf. (Univ.) Henning P. Schmiedehausen INTERMETA GmbH [EMAIL PROTECTED]+49 9131 50 654 0 http://www.intermeta.de/ RedHat Certified Engineer -- Jakarta Turbine Development -- hero for hire Linux, Java, perl, Solaris -- Consulting, Training, Development Fighting for one's political stand is an honorable action, but re- fusing to acknowledge that there might be weaknesses in one's position - in order to identify them so that they can be remedied - is a large enough problem with the Open Source movement that it deserves to be on this list of the top five problems. -- Michelle Levesque, Fundamental Issues with Open Source Software Development - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Did http://db.apache.org/torque/dtd/database_3_0_1.dtd vanish?!
Kevin A. Burton [EMAIL PROTECTED] writes: There was some re-organization on the torque site and they were temporarily misplaced. All should be well again. Regards Henning [torque-sql] Parsing file: 'id-table-schema.xml' [torque-sql] ERROR 16:19:56,578 DTDResolver:160 Couldn't read DTD specified in XML schema: [torque-sql] java.io.FileNotFoundException: http://db.apache.org/torque/dtd/database_3_0_1.dtd [torque-sql]at sun.net.www.protocol.http.HttpURLConnection.getInputStream(HttpURLConnection.java:789) [torque-sql]at java.net.URL.openStream(URL.java:913) [torque-sql]at org.apache.torque.engine.database.transform.DTDResolver.getInputSource(DTDResolver.java:156) [torque-sql]at org.apache.torque.engine.database.transform.DTDResolver.resolveEntity(DTDResolver.java:141) [torque-sql]at org.apache.torque.engine.database.transform.XmlToAppData.resolveEntity(XmlTo I can't build my Torque :-/ Kevin -- Use Rojo (RSS/Atom aggregator). Visit http://rojo.com. Ask me for an invite! Also see irc.freenode.net #rojo if you want to chat. Rojo is Hiring! - http://www.rojonetworks.com/JobsAtRojo.html If you're interested in RSS, Weblogs, Social Networking, etc... then you should work for Rojo! If you recommend someone and we hire them you'll get a free iPod! Kevin A. Burton, Location - San Francisco, CA AIM/YIM - sfburtonator, Web - http://peerfear.org/ GPG fingerprint: 5FB2 F3E2 760E 70A8 6174 D393 E84D 8D04 99F1 4412 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Dipl.-Inf. (Univ.) Henning P. Schmiedehausen INTERMETA GmbH [EMAIL PROTECTED]+49 9131 50 654 0 http://www.intermeta.de/ RedHat Certified Engineer -- Jakarta Turbine Development -- hero for hire Linux, Java, perl, Solaris -- Consulting, Training, Development Fighting for one's political stand is an honorable action, but re- fusing to acknowledge that there might be weaknesses in one's position - in order to identify them so that they can be remedied - is a large enough problem with the Open Source movement that it deserves to be on this list of the top five problems. -- Michelle Levesque, Fundamental Issues with Open Source Software Development - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Moving Torque to SVN
Hi, are there any big objections in moving the Torque Code base to SVN? I would propose the following SVN structure: Runtime (torque.jar) /db/torque/runtime/trunk TORQUE_3_1_BRANCH /tags TORQUE_3_1 TORQUE_3_1_1 ... (other release tags from CVS) /branches TORQUE_3_2_BRANCH TORQUE_3_1_HENNING ... (other branches tags from CVS) Generator (torque-gen.jar) /generator/trunk /tags /branches Tags and Branches as above Maven-Plugin (maven-torque-plugin.jar) /maven-plugin/trunk /tags /branches Tags and Branches as above Site (torque Umbrella Site) /maven-plugin/trunk Reason for this structure: The generator is already uses for different projects like OJB. Other uses are thinkable and decoupling the runtime and generator would allow different release cycles. Same goes for the Maven plugin. A site module has been discussed and it should take all the common for all branches pages like download.xml. It should also help to structure the Torque site better. As the current active development branch is the 3.1 branch, it would be sensible to move this branch onto the Trunk and keep the (inactive) 3.2 development branch as a Branch directory. Going from CVS to SVN is not really hard. I did this with my projects about six months ago and I would never ever go back to CVS again. SVN integration for most development environments (Eclipse, emacs, ... :-) ) is available. Opinions? Regards Henning -- Dipl.-Inf. (Univ.) Henning P. Schmiedehausen INTERMETA GmbH [EMAIL PROTECTED]+49 9131 50 654 0 http://www.intermeta.de/ RedHat Certified Engineer -- Jakarta Turbine Development -- hero for hire Linux, Java, perl, Solaris -- Consulting, Training, Development What is more important to you... [ ] Product Security or [ ] Quality of Sales and Marketing Support -- actual question from a Microsoft customer survey - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Moving Torque to SVN
Henning P. Schmiedehausen [EMAIL PROTECTED] writes: Site (torque Umbrella Site) /maven-plugin/trunk /site/trunk obviously. Cut'n'paste error... Regards Henning -- Dipl.-Inf. (Univ.) Henning P. Schmiedehausen INTERMETA GmbH [EMAIL PROTECTED]+49 9131 50 654 0 http://www.intermeta.de/ RedHat Certified Engineer -- Jakarta Turbine Development -- hero for hire Linux, Java, perl, Solaris -- Consulting, Training, Development What is more important to you... [ ] Product Security or [ ] Quality of Sales and Marketing Support -- actual question from a Microsoft customer survey - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Nightly snapshots for Torque
As there didn't seem to be any nightly snapshots for Torque, I took the liberty and set up a Nighty snapshots run for Torque just as I did for Turbine. These are located under http://cvs.apache.org/dist/db/torque/nightly/ for the torque-3.1 and torque-3.2 trees. These snapshots are only built when the source repository changes. Regards Henning -- Dipl.-Inf. (Univ.) Henning P. Schmiedehausen INTERMETA GmbH [EMAIL PROTECTED]+49 9131 50 654 0 http://www.intermeta.de/ RedHat Certified Engineer -- Jakarta Turbine Development -- hero for hire Linux, Java, perl, Solaris -- Consulting, Training, Development Fighting for one's political stand is an honorable action, but re- fusing to acknowledge that there might be weaknesses in one's position - in order to identify them so that they can be remedied - is a large enough problem with the Open Source movement that it deserves to be on this list of the top five problems. -- Michelle Levesque, Fundamental Issues with Open Source Software Development - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Patch TQRS219
Thomas Fischer [EMAIL PROTECTED] writes: Everything that clears up the logic in the BasePeer is a good thing. It would be nice if we get some unit test that check the behaviour before and after to make sure that the patch does not break anything. The TORQUE_3_1_HENNING branch is intended to be a full speed ahead and damn the torpedoes branch which does not look for backward compatibility. I intended to merge parts of it that have proven to work fine back into 3.2 or 3.1.x. As far as I understand, the Join patch just extends the functionality of the Per. Or are there any incompatible changes in it? Regards Henning Hi, It seems that I cannot post a comment to the ticket, so my comment goes here. I do not see this patch in the 3.1.1 release, because there exists no documentation at the moment and because the patch would have to be adjusted to the changes in BasePeer which have been applied to CVS since the patch. At the moment, it seems that after the 3.1.1 release is out, I will have time to rework the patch and write some documentation. Henning, I just wonder whether you agree with the appoach I have taken in BasePeer, which is to split the method createQuery() and createPreparedStatement() into several methods, i.e. processJoins()..., processModifiers()... , and whether that collides with anything you have done in your 3_1_HENNING-Branch. Thomas - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Dipl.-Inf. (Univ.) Henning P. Schmiedehausen INTERMETA GmbH [EMAIL PROTECTED]+49 9131 50 654 0 http://www.intermeta.de/ RedHat Certified Engineer -- Jakarta Turbine Development -- hero for hire Linux, Java, perl, Solaris -- Consulting, Training, Development Fighting for one's political stand is an honorable action, but re- fusing to acknowledge that there might be weaknesses in one's position - in order to identify them so that they can be remedied - is a large enough problem with the Open Source movement that it deserves to be on this list of the top five problems. -- Michelle Levesque, Fundamental Issues with Open Source Software Development - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
New Issues
Heh, you have been a few busy little bees. Eight new issues while I was not looking. ;-) That suits me right for announcing a release schedule. :-) I will look into all of these before CfV; I definitely will try to fix the binary compare issue (unless Scott has already beaten me to it) and consider the others. The JNDI caching code will 99,9% surely be in it; Thomas sent me a nice patch with documentation. Stay tuned, I will try to get this stuff done today. Regards Henning -- Dipl.-Inf. (Univ.) Henning P. Schmiedehausen INTERMETA GmbH [EMAIL PROTECTED]+49 9131 50 654 0 http://www.intermeta.de/ RedHat Certified Engineer -- Jakarta Turbine Development -- hero for hire Linux, Java, perl, Solaris -- Consulting, Training, Development Fighting for one's political stand is an honorable action, but re- fusing to acknowledge that there might be weaknesses in one's position - in order to identify them so that they can be remedied - is a large enough problem with the Open Source movement that it deserves to be on this list of the top five problems. -- Michelle Levesque, Fundamental Issues with Open Source Software Development - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: cvs commit: db-torque/xdocs changes.xml
[EMAIL PROTECTED] writes: action type=update dev=seade TRQS235 Generated code contains Javadoc error sentence is different /action +action type=update dev=seade + TRQS236 Generated code contains Javadoc error @param tags incorrect. +/action /release Hi Scott, if you use the 'issue=' attribute, maven will even create a link for the issue to be tracked. Regards Henning -- Dipl.-Inf. (Univ.) Henning P. Schmiedehausen INTERMETA GmbH [EMAIL PROTECTED]+49 9131 50 654 0 http://www.intermeta.de/ RedHat Certified Engineer -- Jakarta Turbine Development -- hero for hire Linux, Java, perl, Solaris -- Consulting, Training, Development Fighting for one's political stand is an honorable action, but re- fusing to acknowledge that there might be weaknesses in one's position - in order to identify them so that they can be remedied - is a large enough problem with the Open Source movement that it deserves to be on this list of the top five problems. -- Michelle Levesque, Fundamental Issues with Open Source Software Development - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[VOTE] CfV: Torque 3.1.1 release
This is the Call for Votes [CfV] for the release of version 3.1.1 of DB Torque including the DB Torque Generator and the Maven plugin for Torque. [ ] +1 Yes [ ] 0 I don't care [ ] -1 No I will collect votes until Monday 25th 0:00 (MEST) and will act as release manager. The rules on http://db.apache.org/decisions.html apply for this CfV; I'd especially like to encourage our contributors to participate in the CfV (so Scott and I will not decide this alone... ;-)) Regards Henning -- Dipl.-Inf. (Univ.) Henning P. Schmiedehausen INTERMETA GmbH [EMAIL PROTECTED]+49 9131 50 654 0 http://www.intermeta.de/ RedHat Certified Engineer -- Jakarta Turbine Development -- hero for hire Linux, Java, perl, Solaris -- Consulting, Training, Development Fighting for one's political stand is an honorable action, but re- fusing to acknowledge that there might be weaknesses in one's position - in order to identify them so that they can be remedied - is a large enough problem with the Open Source movement that it deserves to be on this list of the top five problems. -- Michelle Levesque, Fundamental Issues with Open Source Software Development - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] CfV: Torque 3.1.1 release
Henning P. Schmiedehausen [EMAIL PROTECTED] writes: [X] +1 Yes -- Dipl.-Inf. (Univ.) Henning P. Schmiedehausen INTERMETA GmbH [EMAIL PROTECTED]+49 9131 50 654 0 http://www.intermeta.de/ RedHat Certified Engineer -- Jakarta Turbine Development -- hero for hire Linux, Java, perl, Solaris -- Consulting, Training, Development Fighting for one's political stand is an honorable action, but re- fusing to acknowledge that there might be weaknesses in one's position - in order to identify them so that they can be remedied - is a large enough problem with the Open Source movement that it deserves to be on this list of the top five problems. -- Michelle Levesque, Fundamental Issues with Open Source Software Development - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Proposed release schedule for Torque 3.1.1
Hi, how about the following release schedule: - accept last minute fixes up to tuesday, 19th October - CfV for 3.1.1 release on wednesday, 20th October - when CfV succesful: 3.1.1 release on 27th October I'd volunteer as release manager (I need some practice ;-) ) Regards Henning -- Dipl.-Inf. (Univ.) Henning P. Schmiedehausen INTERMETA GmbH [EMAIL PROTECTED]+49 9131 50 654 0 http://www.intermeta.de/ RedHat Certified Engineer -- Jakarta Turbine Development -- hero for hire Linux, Java, perl, Solaris -- Consulting, Training, Development Fighting for one's political stand is an honorable action, but re- fusing to acknowledge that there might be weaknesses in one's position - in order to identify them so that they can be remedied - is a large enough problem with the Open Source movement that it deserves to be on this list of the top five problems. -- Michelle Levesque, Fundamental Issues with Open Source Software Development - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: JndiDataSourceFactory
Thomas Vandahl [EMAIL PROTECTED] writes: John McNally wrote: The reason it is not cached is that the DataSource/JNDI concept allows an adminstration application to change the DataSource that is bound to a name and an application using that name would automatically start using a different pool of connections. I see. Problem is, that the lookups slow down the application quite badly. Is there anything else one could do? Use a cache that times out. If you implement a cache that will defer lookups for 30 seconds or so (configureable!), then you will get the behaviour that John described after the timeout but still get the performance gains from having a cache. There is an implementation of such a time-out cache in the Turbine code base. Regards Henning -- Dipl.-Inf. (Univ.) Henning P. Schmiedehausen INTERMETA GmbH [EMAIL PROTECTED]+49 9131 50 654 0 http://www.intermeta.de/ RedHat Certified Engineer -- Jakarta Turbine Development -- hero for hire Linux, Java, perl, Solaris -- Consulting, Training, Development Fighting for one's political stand is an honorable action, but re- fusing to acknowledge that there might be weaknesses in one's position - in order to identify them so that they can be remedied - is a large enough problem with the Open Source movement that it deserves to be on this list of the top five problems. -- Michelle Levesque, Fundamental Issues with Open Source Software Development - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: PostgreSQL ID generation
('tablename_colname_seq') NOT NULL
);
according to http://www.postgresql.org/docs/7.3/static/datatype.html#DATATYPE-SERIAL)
when using sequence, we should also create the sequence in the SQL.
What is left is to find out what native should really be. IMHO it
should be equivalent sequence because auto_increment creates
implicit object in the database outside user control. This is the patch
that I've put on the list.
There is also a note with SERIAL:
--- cut --- http://www.postgresql.org/docs/7.3/static/datatype.html#DATATYPE-SERIAL
--- cut ---
Note: Prior to PostgreSQL 7.3, serial implied UNIQUE. This is no
longer automatic. If you wish a serial column to be UNIQUE or a
PRIMARY KEY it must now be specified, just as with any other data
type.
--- cut --- http://www.postgresql.org/docs/7.3/static/datatype.html#DATATYPE-SERIAL
--- cut ---
so we might need to build a switch for pre-7.3 PostgreSQL databases.
Regards
Henning
--
Dipl.-Inf. (Univ.) Henning P. Schmiedehausen INTERMETA GmbH
[EMAIL PROTECTED]+49 9131 50 654 0 http://www.intermeta.de/
RedHat Certified Engineer -- Jakarta Turbine Development -- hero for hire
Linux, Java, perl, Solaris -- Consulting, Training, Development
Fighting for one's political stand is an honorable action, but re-
fusing to acknowledge that there might be weaknesses in one's
position - in order to identify them so that they can be remedied -
is a large enough problem with the Open Source movement that it
deserves to be on this list of the top five problems.
-- Michelle Levesque, Fundamental Issues with
Open Source Software Development
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Findbugs Patch for 3.1.1
Scott Eade [EMAIL PROTECTED] writes: I will apply this for 3.1.1, but it would have been easier if you had provided a patch against cvs rather than against your version that includes the boolean getter patch that I don't see going in as part of 3.1.1 (3.1.2-dev is more acceptable I think). I assume there will be some corresponding changes to ObjectWithManager.vm (I know you don't use it, but some do). Whoops, sorry. Shall I redo it against 3.1.1-HEAD? Regads Henning -- Dipl.-Inf. (Univ.) Henning P. Schmiedehausen INTERMETA GmbH [EMAIL PROTECTED]+49 9131 50 654 0 http://www.intermeta.de/ RedHat Certified Engineer -- Jakarta Turbine Development -- hero for hire Linux, Java, perl, Solaris -- Consulting, Training, Development Fighting for one's political stand is an honorable action, but re- fusing to acknowledge that there might be weaknesses in one's position - in order to identify them so that they can be remedied - is a large enough problem with the Open Source movement that it deserves to be on this list of the top five problems. -- Michelle Levesque, Fundamental Issues with Open Source Software Development - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Findbugs Patch for 3.1.1
Scott Eade [EMAIL PROTECTED] writes: -// Set the correct dbName if it has not been overridden -// criteria.getDbName will return the same object if not set to -// another value so == check is okay and faster [...] Is the removed comment not true? Yes. Cut'n'paste eagerness. It should be on top of the factored out method. Regards Henning -- Dipl.-Inf. (Univ.) Henning P. Schmiedehausen INTERMETA GmbH [EMAIL PROTECTED]+49 9131 50 654 0 http://www.intermeta.de/ RedHat Certified Engineer -- Jakarta Turbine Development -- hero for hire Linux, Java, perl, Solaris -- Consulting, Training, Development Fighting for one's political stand is an honorable action, but re- fusing to acknowledge that there might be weaknesses in one's position - in order to identify them so that they can be remedied - is a large enough problem with the Open Source movement that it deserves to be on this list of the top five problems. -- Michelle Levesque, Fundamental Issues with Open Source Software Development - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Deployment to repository [was [SOURCE] Issue #TRQS217 modified]
Scott Eade [EMAIL PROTECTED] writes: Excellent. cannot deploy the plugin because of a permission problem. It seems that the directory /x1/www/www.apache.org/dist/java-repository/torque/plugins doesn't have group write access and hence I cannot write the jar file §()=!§ Maven. :-) Done. -bash-2.05b$ pwd /x1/www/www.apache.org/dist/java-repository/torque/plugins -bash-2.05b$ ls -lad . drwxrwxr-x 2 henning apcvs 512 Aug 22 17:42 . [...] BTW: I recall a while back you expressing some caution about using site:deploy / site:sshdeploy - is this caution still warranted or are you happier with these now that maven 1.0 has been released? maven-1.0 is an improvement beyond the betas that I cannot start to put in words. The work done on the tree beyond b10 is tremendous and personally I consider it stable (though not quirk-free but no software really is). I did deploy the various Turbine sites with maven site:deploy and had no problems. Only gotcha might be directory permission problems. Regards Henning -- Dipl.-Inf. (Univ.) Henning P. Schmiedehausen INTERMETA GmbH [EMAIL PROTECTED]+49 9131 50 654 0 http://www.intermeta.de/ RedHat Certified Engineer -- Jakarta Turbine Development -- hero for hire Linux, Java, perl, Solaris -- Consulting, Training, Development Fighting for one's political stand is an honorable action, but re- fusing to acknowledge that there might be weaknesses in one's position - in order to identify them so that they can be remedied - is a large enough problem with the Open Source movement that it deserves to be on this list of the top five problems. -- Michelle Levesque, Fundamental Issues with Open Source Software Development - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Findbugs Patch for 3.1.1
($fk in $table.ForeignKeys)
@@ -1418,7 +1317,7 @@
#if (!$joinClassName.equals($excludeClassName))
#set ( $new_index = $index + 1 )
-${joinClassName}Peer.addSelectColumns(c);
+${joinClassName}Peer.addSelectColumns(criteria);
int offset$new_index = offset$index + ${joinClassName}Peer.numColumns;
#set ( $index = $new_index )
#end
@@ -1428,42 +1327,28 @@
#set ( $cup=$col.Name.toUpperCase() )
#if($col.isBooleanInt())
// check for conversion from boolean to int
-if (c.containsKey($cup))
+if (criteria.containsKey($cup))
{
-Object possibleBoolean = c.get($cup);
+Object possibleBoolean = criteria.get($cup);
if (possibleBoolean instanceof Boolean)
{
-if (((Boolean) possibleBoolean).booleanValue())
-{
-c.add($cup, 1);
-}
-else
-{
-c.add($cup, 0);
-}
+criteria.add($cup, (((Boolean) possibleBoolean).booleanValue() ? 1 :
0);
}
}
#elseif ($col.isBooleanChar())
// check for conversion from boolean to Y/N
-if ( c.containsKey($cup) )
+if ( criteria.containsKey($cup) )
{
-Object possibleBoolean = c.get($cup);
+Object possibleBoolean = criteria.get($cup);
if (possibleBoolean instanceof Boolean)
{
-if (((Boolean) possibleBoolean).booleanValue())
-{
-c.add($cup, Y);
-}
-else
-{
-c.add($cup, N);
-}
+criteria.add($cup, (((Boolean) possibleBoolean).booleanValue() ? Y
: N);
}
}
#end
#end
-List rows = BasePeer.doSelect(c);
+List rows = BasePeer.doSelect(criteria);
List results = new ArrayList();
for (int i = 0; i rows.size(); i++)
@@ -1534,13 +1419,13 @@
break;
}
}
+#if ($objectIsCaching)
if (newObject)
{
-#if ($objectIsCaching)
obj${index}.init${collThisTable}();
obj${index}.add${collThisTableMs}(obj1);
-#end
}
+#end
#end
#end
#end
@@ -1569,4 +1454,15 @@
return Torque.getDatabaseMap(DATABASE_NAME).getTable(TABLE_NAME);
}
#end ## ends if (!$table.isAlias())
+
+ private static void setDbName(Criteria crit)
+ {
+if (crit != null crit.getDbName() != null)
+{
+ if (crit.getDbName().equals(Torque.getDefaultDB()))
+ {
+crit.setDbName(DATABASE_NAME);
+ }
+}
+ }
}
--
Dipl.-Inf. (Univ.) Henning P. Schmiedehausen INTERMETA GmbH
[EMAIL PROTECTED]+49 9131 50 654 0 http://www.intermeta.de/
RedHat Certified Engineer -- Jakarta Turbine Development -- hero for hire
Linux, Java, perl, Solaris -- Consulting, Training, Development
Fighting for one's political stand is an honorable action, but re-
fusing to acknowledge that there might be weaknesses in one's
position - in order to identify them so that they can be remedied -
is a large enough problem with the Open Source movement that it
deserves to be on this list of the top five problems.
-- Michelle Levesque, Fundamental Issues with
Open Source Software Development
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [PATCH TORQUE-3.1.1] Name Boolean/boolan getters correctly for
Scott Eade [EMAIL PROTECTED] writes: Henning, I like what this patch does, but I have a couple of concerns. Firstly I [Was busy for a while, so I answer just now ] think the fact that this would result in Torque 3.1.1 generating different method names to Torque 3.1 (at least for boolean columns) is not something users would be expecting. Secondly, from the perspective True. I fell into a gotcha with another application [1], which uses the regular bean classes for object parsing and that expected isxxx methods for the binary columns. This is a Catch-22 situation. The current code generator does it wrong. However, users are used to this and work around it. If we never change it, there will be no improvement. of a Turbine user, have/will the mapper methods in ParameterParser, et al, been/be updated? I know that my Turbine applications would fail if Nope. I wasn't even thinking about this and I don't think that this is an issue, mainly because the setProperties() method calls the _setters_ and they don't change. Or do you map _from_ a bean to a ParameterParser (strange idea, I never tried to do this). this patch is applied and I regenerate my om. IMHO it would be more appropriate to introduce such a change in Torque 3.2. A more acceptable alternative would be if the generated code provides both the current get methods (perhaps marking them as deprecated) and the new is methods. It would be nice to know that the Turbine ParameterParser was Don't do this! I tried it in my business classes and funnily enough, there is software which chokes if it finds a boolean getsomething method and a boolean issomething method. I don't know whether this is a regular behaviour or a plain bug but in my case, I had to work around it. going to sync up with this change in some future release. If the Turbine parser relies on getter and setter methods being called getxxx and setxxx, it will be in for more nasty surprises. IIRC, ParameterParser calls getWriteMethod() and getReadMethod() on a PropertyDescriptor, so I see no problem here. A few additional minor points: 1. I have highlighted a change below that I think you may like to reverse (an erroneous replace I think). Yes. That was a mistake. 2. I have also highlighted an instance where you introduce an space character after method names in the generated code (I only highlighted one of these but there are more). While the generated code is not all that attractive there is no reason to make it worse. This was highlighted to me by comparing changes to the generated code after applying your patch - it results in a whole bunch of changes that are just the introduction of a space. Did I? It might be a search-and-replace mistake, adding a to the replace string. No particular reason except sloppiness. :-) 3. The Object.vm changes need to be replicated for ObjectWithManager.vm Yes. However, I don't use this so I didn't want to break a class that I don't use and don't know exactly how it works. I agree with your analysis and I admit, that I feel a little uneasy about dropping a method name change in the middle of a minor release. However, I have the following points: - Existing classes won't break. The code is generated at compile time, classes that have been generated won't break by this change. When recompiling source throws compilation errors, they can easily be fixed. There is no binary replacement problem like e.g. getList/getVector in commons-configuration or the commons-lang disaster. - Properly written Software that uses the PropertyDescriptor and getGetterMethod and getSetterMethod won't break. - Some poorly written software, that chokes on boolean getxxx will work. Disadvantage is, that business logic extending the BaseClasses which might contain an boolean getFoo method to override the method in the base class, must be adjusted. There is no way around it, yes. I still want to lobby for this patch. If it won't make 3.1.1, we could apply it immediately after the release and then use 3.1.2-dev to check out if there are major user complaints. Regards Henning [1] To name the culprit: commons-betwixt and addDefaults / in the XML description. -- Dipl.-Inf. (Univ.) Henning P. Schmiedehausen INTERMETA GmbH [EMAIL PROTECTED]+49 9131 50 654 0 http://www.intermeta.de/ RedHat Certified Engineer -- Jakarta Turbine Development -- hero for hire Linux, Java, perl, Solaris -- Consulting, Training, Development Fighting for one's political stand is an honorable action, but re- fusing to acknowledge that there might be weaknesses in one's position - in order to identify them so that they can be remedied - is a large enough problem with the Open Source movement that it deserves to be on this list of the top five problems. -- Michelle Levesque, Fundamental Issues with Open Source Software Development
Re: [SOURCE] Issue #TRQS217 modified
Scott Eade [EMAIL PROTECTED] writes: Reason: This will be sorted out real soo now with the release of Torque 3.1.1. Scott, if you want to, you can use the maven jar:deploy goal to put a snapshot or a release onto the www.apache.org repository. From there, it is mirrored onto ibiblio. No more could you please upload xxx from yyy asking on the maven lists. Yeah! For the plugin, it is maven plugin:repository-deploy (noone would have expected it to have the same name as the deploy target in the jar plugin. ;-) ). One cause for concern that I have is the fact that we have two development branches and only one SNAPSHOT version. You can't decide for yourself, if versionSNAPSHOT/version will pull a 3.1 or a 3.2 snapshot from ibiblio. Ah well, I said time and again on the maven lists, that the whole SNAPSHOT concept was a bad idea, but no one wanted to listen... Regards Henning -- Dipl.-Inf. (Univ.) Henning P. Schmiedehausen INTERMETA GmbH [EMAIL PROTECTED]+49 9131 50 654 0 http://www.intermeta.de/ RedHat Certified Engineer -- Jakarta Turbine Development -- hero for hire Linux, Java, perl, Solaris -- Consulting, Training, Development Fighting for one's political stand is an honorable action, but re- fusing to acknowledge that there might be weaknesses in one's position - in order to identify them so that they can be remedied - is a large enough problem with the Open Source movement that it deserves to be on this list of the top five problems. -- Michelle Levesque, Fundamental Issues with Open Source Software Development - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: cvs commit: db-torque/profile mysql.profile postgres.profile
[EMAIL PROTECTED] writes:
-torque.testDatabaseJar = ${maven.repo.local}/mm.mysql/jars/mm.mysql-2.0.13-bin.jar
+torque.testDatabaseJar = ${maven.repo.local}/mm.mysql/jars/mm.mysql-2.0.14-bin.jar
We should update this at some point.
The official release is called
mysql-connector-java-2.0.14-bin.jar and should be put into
${maven.repo.local}/mysql/jars/mysql-connector-java-2.0.14-bin.jar
(http://dev.mysql.com/downloads/connector/j/2.0.html)
The latest release is mysql-connector-java-3.0.14-production-bin.jar
${maven.repo.local}/mysql/jars/mysql-connector-java-3.0.14-production-bin.jar
(http://dev.mysql.com/downloads/connector/j/3.0.html)
I hate the fscking renaming of the jars on ibiblio. If they insist on
collecting everything in the Java world, they should at least try to
get it right.
-torque.testDatabaseJar =
${maven.repo.local}/postgresql/jars/postgresql-7.3-jdbc2.jar
+torque.testDatabaseJar =
${maven.repo.local}/postgresql/jars/postgresql-7.3-jdbc3.jar
same here. The official jars are called
pg74.215.jdbc3.jar for PostgreSQL 7.4
pg73jdbc3.jar for PostgreSQL 7.3.x
available from http://jdbc.postgresql.org/download.html
Yes, their naming sucks. And with PostgreSQL changing their policy
regarding auto-commit lately [1], you should make very, very
sure, that you get the right driver for your PostgreSQL version.
Regards
Henning
[1] Basically they turn it always on and let the database sort it
out... ...along comes something like Hibernate; insisting on
auto-commit=off. Boom!
--
Dipl.-Inf. (Univ.) Henning P. Schmiedehausen INTERMETA GmbH
[EMAIL PROTECTED]+49 9131 50 654 0 http://www.intermeta.de/
RedHat Certified Engineer -- Jakarta Turbine Development -- hero for hire
Linux, Java, perl, Solaris -- Consulting, Training, Development
Fighting for one's political stand is an honorable action, but re-
fusing to acknowledge that there might be weaknesses in one's
position - in order to identify them so that they can be remedied -
is a large enough problem with the Open Source movement that it
deserves to be on this list of the top five problems.
-- Michelle Levesque, Fundamental Issues with
Open Source Software Development
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
The dreaded BIT and PostgreSQL
Hi,
the following situation. I have a table definition for a postgres
database that has the following column definition:
[...]
column name=PROJEKTDATEN_LOCKED required=true type=BIT javaName=Locked/
[...]
When building a Criteria for the PROJEKTDATEN table (e.g. deleting)
then a criteria is built that contains a PROJEKTDATEN.PROJEKTDATEN_LOCKED = something
For PostgreSQL, the something must be true or false.
But Torque generates 1 and 0 (true == 1, false == 0). Which leads
to cannot convert between boolean and integer, you need an explict
cast from the database.
The choice of 0 and 1 is useful if the underlying column is not a
real boolean column but an integer column (which is the choice with
databases that don't have a real boolean type).
The real solution would be if Torque looks at the column map and
generated true and false for boolean columns and 0/1 for integer or
other types. However, Torque isn't that clever.
If you apply the following patch to the 3.1 branch, then some
operations with criterias (most prominent: doDelete(objecttype obj)
in the generated peers) will work with boolean column. But this breaks
the behaviour where adding a false to a criteria put a 0 into an
integer column and a true puts a 1. So this is a breaking change.
Personally, I'd very much prefer applying this patch to Torque (3.2
and 3.1) because IMHO it fixes a bug.
Discussion wanted.
Regards
Henning
Index: src/java/org/apache/torque/adapter/DBPostgres.java
===
RCS file: /home/cvs/db-torque/src/java/org/apache/torque/adapter/DBPostgres.java,v
retrieving revision 1.16
diff -u -b -r1.16 DBPostgres.java
--- src/java/org/apache/torque/adapter/DBPostgres.java 25 Aug 2003 21:56:10 -
1.16
+++ src/java/org/apache/torque/adapter/DBPostgres.java 3 Nov 2003 16:35:41 -
@@ -180,6 +180,6 @@
*/
public String getBooleanString(Boolean b)
{
-return (b == null) ? 0 : (Boolean.TRUE.equals(b) ? 1 : 0);
+return (b == null) ? false : (Boolean.TRUE.equals(b) ? true : false);
}
}
Index: src/test/org/apache/torque/util/CriteriaTest.java
===
RCS file: /home/cvs/db-torque/src/test/org/apache/torque/util/CriteriaTest.java,v
retrieving revision 1.20
diff -u -b -r1.20 CriteriaTest.java
--- src/test/org/apache/torque/util/CriteriaTest.java 18 Jul 2003 20:11:48 -
1.20
+++ src/test/org/apache/torque/util/CriteriaTest.java 3 Nov 2003 16:35:41 -
@@ -313,7 +313,7 @@
fail(Exception thrown in DBFactory);
}
-assertEquals(TABLE.COLUMN=1, cc.toString());
+assertEquals(TABLE.COLUMN=true, cc.toString());
}
/**
--
Dipl.-Inf. (Univ.) Henning P. Schmiedehausen INTERMETA GmbH
[EMAIL PROTECTED]+49 9131 50 654 0 http://www.intermeta.de/
Java, perl, Solaris, Linux, xSP Consulting, Web Services
freelance consultant -- Jakarta Turbine Development -- hero for hire
Dominate!! Dominate!! Eat your young and aggregate! I have grotty silicon!
-- AOL CD when played backwards (User Friendly - 200-10-15)
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [vote] some breaking changes
Martin Poeschl [EMAIL PROTECTED] writes: * remove support for stratum interfaces as turbine is the only user of the interfaces and you can use the avalon component service since turbine 2.3 +1 * always use classpath to load templates i never used the template path since torque supports loading the templates via classpath ... if people have to extend the templates, they should build their own jar ... +0 Loading from files is nice for debugging (you don't need a full jar cycle). * remove support for old properties (without torque prefix) +1 * change version number to 4.0 Don't care much. :-) Unless I get my stuff in, then I'm +1 Regards Henning -- Dipl.-Inf. (Univ.) Henning P. Schmiedehausen INTERMETA GmbH [EMAIL PROTECTED]+49 9131 50 654 0 http://www.intermeta.de/ Java, perl, Solaris, Linux, xSP Consulting, Web Services freelance consultant -- Jakarta Turbine Development -- hero for hire Dominate!! Dominate!! Eat your young and aggregate! I have grotty silicon! -- AOL CD when played backwards (User Friendly - 200-10-15) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Location of generated sql files
Scott Eade [EMAIL PROTECTED] writes: It seems to me that the sql files generated by torque:create-db and torque:sql are now placed in target/classes/sql rather than the previously used location of target/sql. Is there a property I can't see that allows this to be configured? Putting sql under classes is a PITA as it means I have to take specific action to exclude these files from any jar files that are produced. probably yet-another maven problem. Simply set torque.sql.dir in your project properties to be the directory where you want to have your SQL. I've given up relying on maven for this long ago. Regards Henning -- Dipl.-Inf. (Univ.) Henning P. Schmiedehausen INTERMETA GmbH [EMAIL PROTECTED]+49 9131 50 654 0 http://www.intermeta.de/ Java, perl, Solaris, Linux, xSP Consulting, Web Services freelance consultant -- Jakarta Turbine Development -- hero for hire Dominate!! Dominate!! Eat your young and aggregate! I have grotty silicon! -- AOL CD when played backwards (User Friendly - 200-10-15) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Torque: Hard coding of database name in *BasePeer and *MapBuilder java files.
Zigs Torque [EMAIL PROTECTED] writes: No, you don't. You have the data source names hard coded in your peers. The actual database is controlled by the DB URI, that you specify in your torque.properties. Regards Henning Hi All, Whoever solve my problem, I would really appreciate. Im using TORQUE 3.0 , and we have database name hard coded when we run torque to generate beans .. hard coding in *BasePeer.java and *MapBuilder.java files Is this issue already bean addressed or any alternatives to get away from this hard coding , so that we can have database name reading from some property or xml file directly run time. Thanks a lot, appreciate any help. -zt __ Do you Yahoo!? Yahoo! SiteBuilder - Free, easy-to-use web site design software http://sitebuilder.yahoo.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Dipl.-Inf. (Univ.) Henning P. Schmiedehausen INTERMETA GmbH [EMAIL PROTECTED]+49 9131 50 654 0 http://www.intermeta.de/ Java, perl, Solaris, Linux, xSP Consulting, Web Services freelance consultant -- Jakarta Turbine Development -- hero for hire Dominate!! Dominate!! Eat your young and aggregate! I have grotty silicon! -- AOL CD when played backwards (User Friendly - 200-10-15) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: cvs commit: db-torque/src/java/org/apache/torque/util BasePeer.java Transaction.java
Daniel Rall [EMAIL PROTECTED] writes:
-1 on this change.
I'd prefer to get the contract changed so that null is a legal value.
We discussed this in length, it would've been nice if you had read the
archives before simply changing this to an exception
Regards
Henning
[EMAIL PROTECTED] writes:
...
1.9 +18 -9 db-torque/src/java/org/apache/torque/util/Transaction.java
Index: Transaction.java
===
RCS file: /home/cvs/db-torque/src/java/org/apache/torque/util/Transaction.java,v
retrieving revision 1.8
retrieving revision 1.9
diff -u -r1.8 -r1.9
--- Transaction.java 18 May 2003 12:27:24 - 1.8
+++ Transaction.java 3 Aug 2003 17:41:04 - 1.9
@@ -182,7 +182,7 @@
{
if (con == null)
{
-log.error(Connection object was null.
+throw new TorqueException(Connection object was null.
+ This could be due to a misconfiguration of the
+ DataSourceFactory. Check the logs and Torque.properties
+ to better determine the cause.);
IllegalArgumentException might make more sense here.
--
Daniel Rall
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
Dipl.-Inf. (Univ.) Henning P. Schmiedehausen INTERMETA GmbH
[EMAIL PROTECTED]+49 9131 50 654 0 http://www.intermeta.de/
Java, perl, Solaris, Linux, xSP Consulting, Web Services
freelance consultant -- Jakarta Turbine Development -- hero for hire
Dominate!! Dominate!! Eat your young and aggregate! I have grotty silicon!
-- AOL CD when played backwards (User Friendly - 200-10-15)
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: A bug in org.apache.torque.engine.database.model.Database.java
[EMAIL PROTECTED] writes:
This has been fixed in the current CVS HEAD.
Regards
Henning
--=_alternative 0080690386256D78_=
Content-Type: text/plain; charset=us-ascii
Line 464 to 470 is as follows:
if (foreign == null)
{
System.out.println(ERROR!! Attempt to set
foreign
+ key to nonexistent column,
+ foreign.getName() + , in table,
+ foreignTable.getName() + !);
}
If the condition is ever true, foreign.getName() would give you a
NullPointerException.
Peng
--=_alternative 0080690386256D78_=--
--
Dipl.-Inf. (Univ.) Henning P. Schmiedehausen INTERMETA GmbH
[EMAIL PROTECTED]+49 9131 50 654 0 http://www.intermeta.de/
Java, perl, Solaris, Linux, xSP Consulting, Web Services
freelance consultant -- Jakarta Turbine Development -- hero for hire
You are being far too rational for this discussion.
--- Scott Robert Ladd in [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: cvs commit: db-torque/src/java/org/apache/torque/util BasePeer.java Transaction.java
[EMAIL PROTECTED] writes: Modified:src/java/org/apache/torque/util Tag: TORQUE_3_0_BRANCH BasePeer.java Transaction.java * src/java/org/apache/torque/util/BasePeer.java - replace null Connection checks wrapping Transaction.rollback with Transaction.safeRollback. * src/java/org/apache/torque/util/Transaction.java - rollback method changed to throw TorqueException instead of NPE when Connection is null. safeRollback method changed to log null Connection at debug level, since it is a normal event. Lowered other exception logging to warn level since safeRollback should not be called if a failed rollback is considered a serious error. Thanks a lot. I like to rollback code much better this way. Regards Henning -- Dipl.-Inf. (Univ.) Henning P. Schmiedehausen INTERMETA GmbH [EMAIL PROTECTED]+49 9131 50 654 0 http://www.intermeta.de/ Java, perl, Solaris, Linux, xSP Consulting, Web Services freelance consultant -- Jakarta Turbine Development -- hero for hire You are being far too rational for this discussion. --- Scott Robert Ladd in [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Problem with SQL load task - ideas?
Hi, I have the following problem: I have a table (PostgreSQL). This table has multiple colums, one is a CLOB (PostgreSQL text) column. This column should get a text which is generated by another application. The problem is, that this text might look like this: foo bar This bugger is --- that thick. baz bla point 1 point 2 point 3 Which means, that I can contain multiple whitespaces and/or line feeds. This is find in our source represenatation which is generated by an XML transformation tool. I get stuff like this: table description=. lots of stuff This XML file should be fed to the torque:insert-sql task to be put in the database. However, the Torque task uses Texen, which in turn uses Velocity, which gobbles up excessive whitespace. Duh! There goes my text formatting and/or linefeeds. Can I turn this excessive whitespace gobbling off? If yes, how? If not, is Texen still the right tool for us, because it simply changes the value of database columns to be inserted? Regards Henning -- Dipl.-Inf. (Univ.) Henning P. Schmiedehausen INTERMETA GmbH [EMAIL PROTECTED]+49 9131 50 654 0 http://www.intermeta.de/ Java, perl, Solaris, Linux, xSP Consulting, Web Services freelance consultant -- Jakarta Turbine Development -- hero for hire You are being far too rational for this discussion. --- Scott Robert Ladd in [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Modify Transaction.rollback to ignore a null connection [was Re:
John McNally [EMAIL PROTECTED] writes:
ATM, passing null into the Transaction does
--- cut ---
if (con == null)
{
throw new NullPointerException(Connection object was null.
+ This could be due to a misconfiguration of the
+ DataSourceFactory. Check the logs and Torque.properties
+ to better determine the cause.);
}
--- cut ---
Which is equally bad. By putting if(con != null) checks around all
calls to commit, you simply work around this problem. IMHO, the whole
connection object was null, throw a NPE business is a wrong way.
If getting a null connection object is bad, then let commit() throw a
meaningful exception.
If getting a null connection object is possible, then let commit() work
on a null con and not return an error.
If the behaviour should be decideable, add a safeCommit() method to
the Transaction and use this in your error cases. But adding a bunch
of if (con != null) statements just to hide the problem with the
commit method, is IMNSVHO a hack.
Sorry, you are going to need to point me to the documentation that shows
why null checks are a bad idea or a hack. Without them the code was
hiding root cause of many errors.
Because you plaster over the real problem. If you need null checks, add
public static void safeCommit(Connection con) throws TorqueException
{
if (con != null)
{
commit(con);
}
}
to the Transaction and do _ONE_ check. And replace all the checks with
calls to safeCommit(Connection con). Document that safeCommit() is
intended to be used in error cases where the con object can be legally
null.
To quote Elements of Java Style: Write code once and only once..
You think modifying Transaction.rollback to ignore a null connection is
a good one. I don't see how that could be a good thing, at least now an
Not rollback. commit.
Regards
Henning
--
Dipl.-Inf. (Univ.) Henning P. Schmiedehausen INTERMETA GmbH
[EMAIL PROTECTED]+49 9131 50 654 0 http://www.intermeta.de/
Java, perl, Solaris, Linux, xSP Consulting, Web Services
freelance consultant -- Jakarta Turbine Development -- hero for hire
You are being far too rational for this discussion.
--- Scott Robert Ladd in [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
