Re: [JDBC] [PATCHES] Ant configuration
* "Dave Cramer" <[EMAIL PROTECTED]> wrote: | | | There seems to be enough interested parties to support both build tools. | For the folks that want a Makefile, they can support it. If someone | wants to support the build.xml file, then we should encourage it. I | suspect that one of them will become obsolete on it's own. I think that would be the best as well for time being. Don't remove ant support as that is very useful for the people working on the JDBC code, and add standard make files for building the system. Make itself is not designed to work with a language like Java, so you need third party tools to handle dependencies. Gunnar -- Gunnar Rønning - [EMAIL PROTECTED] Senior Consultant, Polygnosis AS, http://www.polygnosis.com/ ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [JDBC] Does PG's JDBC support prepared statements at all?
On Sat, Oct 20, 2001 at 11:14:22PM -, Dr. Evil wrote: > > There is a bunch of documentation for prepared statements in PG's > JDBC, it seems that the only thing prepared statements do is throw > exceptions. > > Here's some code I'm trying: > > String newvalue = "This is a new value"; > int accountnumber = 54; > String qstring = "UPDATE foo SET message = '?' WHERE number = ?"; > PreparedStatement st = db.prepareStatement(qstring); > st.setString(1, newvalue); > st.setInt(2, accountnumber); > st.execute(); > st.clearParameters(); > st.close(); > > and I always get a Parameter index out of range error, which seems > impossible. Any idea what's going on? You shouldn't quote the ? for the string. By calling the setString() method, it will add the quotes for you. So I guess what is happening is that the preparedstatement parser ignores quoted question marks and just finds 1 variable, when you call setstring on 1 it sets the number= part, and then when you call setInt(2) you are getting the index out of range. The proper qstring should be: "UPDATE foo SET message = ? WHERE number = ?" Cheers, Tom. -- Thomas O'Dowd. - Nooping - http://nooper.com [EMAIL PROTECTED] - Testing - http://nooper.co.jp/labs ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
[JDBC] PreparedStatement parameters question
I have a table like this:
CREATE TABLE foo { number INT, name VARCHAR(100), email VARCHAR(100));
and I am trying to do this with a prepared statement:
PreparedStatement st = db.prepareStatement("UPDATE foo SET ? = '?' " +
"WHERE number = ?");
Whenever I use this I get a "Parameter index out of range" error.
I am assuming that what this means is that I can't use a ? as a column
name, but it can only be used as a parameter. Am I correct in this?
The main reason I want to use PreparedStatement in this case is for
safety. Should I basically do it like this:
PreparedStatement st = db.prepareStatement("UPDATE foo SET " + colname
+ "= '?' WHERE number = ?");
Is that the only way to do this?
Thanks
---(end of broadcast)---
TIP 2: you can get off all lists at once with the unregister command
(send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])
[JDBC] Does PG's JDBC support prepared statements at all?
There is a bunch of documentation for prepared statements in PG's JDBC, it seems that the only thing prepared statements do is throw exceptions. Here's some code I'm trying: String newvalue = "This is a new value"; int accountnumber = 54; String qstring = "UPDATE foo SET message = '?' WHERE number = ?"; PreparedStatement st = db.prepareStatement(qstring); st.setString(1, newvalue); st.setInt(2, accountnumber); st.execute(); st.clearParameters(); st.close(); and I always get a Parameter index out of range error, which seems impossible. Any idea what's going on? ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [JDBC] [PATCHES] Ant configuration
Dave Cramer writes: > The one issue I have with a non ant based build system is that it > makes it difficult to build the driver on a windows machine. That is a valid concern that we're going to have to think about before we move to another method. > What problems does ant present? * Ant needs to be installed. Of course this is not that much of a problem because you can simply install it. However, in automated build environments this might not be so easy, so people are just going to opt to leave out the JDBC driver. I'm sure we can use the Makefile to install the ant jar. * Ant doesn't provide an exit status; you have to watch the build to see if it works. This is unacceptable. Hmmm... I will look into this * Ant is buggy. We've had numerous reports of people having trouble with it for no apparent reason. I can also confirm from my own experience that numerous things don't seem to work the way they should work. I find this a little hard to believe given the number of projects which use ant as a primary build tool. jarkarta.apache.org for instance * In numerous attempts I have failed to convince Ant to place the built files in a tree different from the source tree. This really makes it a pain to build for multiple architectures (in Java, architecture = different jdk). I think this can be overcome. I have had no problems with this. * Ant doesn't support gcj last I checked. This is a real tragedy because gcj is the only free(tm) Java compiler available that seems to have a real future. Ant doesn't support Kaffe very well, btw. There are a number of free compilers, sun's is free, ibm's is free * The Ant language is not nearly as powerful as the stuff you can do in Makefiles. No comment I am Make challenged, but Ant is pretty comprehensive... * Ant is, well, different. I have personally spent a lot of effort to make all parts of PostgreSQL build the same way. Every new language has to reinvent configuration and build management: Perl MakeMaker -- total junk, Python distutils -- no thanks, Tcl -- well, at least they had the right idea. Ant -- one more thing to go wrong. Currently, everything you want to switch and change about the build of PostgreSQL you communicate to the configure script. How do you change the Java compiler? Good question -- not even the Ant manual can answer that because it depends on your particular distribution. Change the $JAVA_HOME environment variable AFAIK The problem is that Ant is a completely new and different tool that we have to deal with, but it doesn't actually solve a problem that hasn't been solved already. Well, this is a little philosophical, but my current focus is java, and ant is the de-facto standard for building java programs, so I guess I'm biased towards it. One thing it does solve is the ability to resolve inter-dependancies automatically. I have had builds which can only be built by ant, or by building the entire source tree at once. This is one feature which is usefull. As for a solution. My opinion is that we should support both. There seems to be enough interested parties to support both build tools. For the folks that want a Makefile, they can support it. If someone wants to support the build.xml file, then we should encourage it. I suspect that one of them will become obsolete on it's own. Dave ---(end of broadcast)--- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
[JDBC] Ant installation (and other) issues!
Hi all, I have been listening to the discussions about Ant and the build system. I think that the discussion is missing a point, which I will try to make here :-) 1. Standard The Ant build system is making its way to be a "de facto" standard for building java applications as it is built for the purpose. 2. Integration In the apache cocoon project, the ant build system jar is shipped along with the distribution and does not require a separate installation of Ant on the target system. The Ant shell script is customized so that the JAVA_HOME environment is the only parameter to set. In the case of postgreSQL driver this could be done by invoking the "pgcustom" ant build from the gnu configure/make when configuring with the "--with-java" parameter. 3. Platforms I´m sure everyone agrees that providing a working java compiler should be out of scope for the build system. Since the ant jar is shipped along, with its own build scripts (.bat and .sh) the build of the driver need not to differ for the platform used. 4. Other things not particulary related to the build The build script should, IMHO, NOT replace good implementation and structured design of the driver packages. A little note on the server and the driver as a substitute for Oracle. Everytime a get a chance, I spread the word of this wonderful database and people wonder "why not MySQL?" I tell them to look a the benchmarking test made by different users, to look at the SQL 9x compliance and to realize the size of the devel community for pgsql and the jdbc driver. As the postgis project evolves with its spatially enabling extension to the driver, the driver´s compliance to the API compared to commercial dmses will be IMHO one of the success factors for providing a rock solid open source alternative. I Can´t help it, I Just love this Server AND Driver. Thanx for listening :-) Per-Olof Norén Stockholm
Re: FW: Re: [JDBC] [PATCHES] Ant configuration
* Peter Eisentraut <[EMAIL PROTECTED]> wrote: | | > compile the JDBC driver via ant if Java and ant are installed. (Or, rather, I | > should be able to) | | You can also install GNU make on Windows. This is how we used to build or apps on Windows before Ant, but we portability issues with respect to scripts invoked from make is a PITA, IMHO ;-) Seriously would installing GNU Make be enough, or would you need to install Cygwin and other packages as well ? Has anybody tested this ? I suspect that something like that would not work painless. -- Gunnar Rønning - [EMAIL PROTECTED] Senior Consultant, Polygnosis AS, http://www.polygnosis.com/ ---(end of broadcast)--- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [JDBC] [PATCHES] Ant configuration
* Peter Eisentraut <[EMAIL PROTECTED]> wrote: | | * Ant needs to be installed. Of course this is not that much of a | problem because you can simply install it. However, in automated build | environments this might not be so easy, so people are just going to opt to | leave out the JDBC driver. This can be solved by including the ant binaries. | * Ant doesn't provide an exit status; you have to watch the build to see | if it works. This is unacceptable. Hmm. Anybody with a solution here ? | | * In numerous attempts I have failed to convince Ant to place the built | files in a tree different from the source tree. This really makes it a | pain to build for multiple architectures (in Java, architecture = | different jdk). Is that what you want ? | | * Ant doesn't support gcj last I checked. This is a real tragedy because | gcj is the only free(tm) Java compiler available that seems to have a real | future. Ant doesn't support Kaffe very well, btw. It does support it now according to the documentation. I think open source jikes has a better future as a compiler, but it is not free in the GNU sense. | * The Ant language is not nearly as powerful as the stuff you can do in | Makefiles. Well, make doesn't solve the build problems for Java. Ant is made to remedy the problems with make and create and easier to use build tool for Java apps. The adoption rate of Ant suggests that the developers have been doing something right ;-) | | * Ant is, well, different. I have personally spent a lot of effort to | make all parts of PostgreSQL build the same way. Every new language has | to reinvent configuration and build management: Perl MakeMaker -- total | junk, Python distutils -- no thanks, Tcl -- well, at least they had the | right idea. Ant -- one more thing to go wrong. Currently, everything you | want to switch and change about the build of PostgreSQL you communicate to | the configure script. How do you change the Java compiler? Good question | -- not even the Ant manual can answer that because it depends on your | particular distribution. >From the Ant manual : It is possible to use different compilers. This can be selected with the "build.compiler" property. | | The problem is that Ant is a completely new and different tool that we | have to deal with, but it doesn't actually solve a problem that hasn't | been solved already. It solves some of the problems with make and it runs easily on platforms like Windows and Mac. When Ant 2.0 comes it will be a even more general task/build system as it will allow for scheduling ala cron as well. But that is off-topic ;-) -- Gunnar Rønning - [EMAIL PROTECTED] Senior Consultant, Polygnosis AS, http://www.polygnosis.com/ ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: FW: Re: [JDBC] [PATCHES] Ant configuration
Ned Wolpert writes: > 3) Java is system independant, and the JDBC driver is a client piece. I should > be able to compile the JDBC driver outside of PostgreSQL server if I wanted to, > right? Example, I can't compile PostgreSQL on windozes 95. But I could > compile the JDBC driver via ant if Java and ant are installed. (Or, rather, I > should be able to) You can also install GNU make on Windows. -- Peter Eisentraut [EMAIL PROTECTED] http://funkturm.homeip.net/~peter ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])
Re: [JDBC] Whatever ... JDBC build patch
Gunnar Rønning writes: > How do distributors that need to build all driver types proceed ? I haven't seen one yet, but theoretically they should configure several different build trees from one source tree. Of course, this doesn't work with Ant, but it's trivial with GNU make. -- Peter Eisentraut [EMAIL PROTECTED] http://funkturm.homeip.net/~peter ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [JDBC] [PATCHES] Ant configuration
Dave Cramer writes: > The one issue I have with a non ant based build system is that it makes > it difficult to build the driver on a windows machine. That is a valid concern that we're going to have to think about before we move to another method. > What problems does ant present? * Ant needs to be installed. Of course this is not that much of a problem because you can simply install it. However, in automated build environments this might not be so easy, so people are just going to opt to leave out the JDBC driver. * Ant doesn't provide an exit status; you have to watch the build to see if it works. This is unacceptable. * Ant is buggy. We've had numerous reports of people having trouble with it for no apparent reason. I can also confirm from my own experience that numerous things don't seem to work the way they should work. * In numerous attempts I have failed to convince Ant to place the built files in a tree different from the source tree. This really makes it a pain to build for multiple architectures (in Java, architecture = different jdk). * Ant doesn't support gcj last I checked. This is a real tragedy because gcj is the only free(tm) Java compiler available that seems to have a real future. Ant doesn't support Kaffe very well, btw. * The Ant language is not nearly as powerful as the stuff you can do in Makefiles. * Ant is, well, different. I have personally spent a lot of effort to make all parts of PostgreSQL build the same way. Every new language has to reinvent configuration and build management: Perl MakeMaker -- total junk, Python distutils -- no thanks, Tcl -- well, at least they had the right idea. Ant -- one more thing to go wrong. Currently, everything you want to switch and change about the build of PostgreSQL you communicate to the configure script. How do you change the Java compiler? Good question -- not even the Ant manual can answer that because it depends on your particular distribution. The problem is that Ant is a completely new and different tool that we have to deal with, but it doesn't actually solve a problem that hasn't been solved already. -- Peter Eisentraut [EMAIL PROTECTED] http://funkturm.homeip.net/~peter ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
