Thread: OID-problem: metadata: use of TableGen O/R-mapper
I'm having a problem with TableGen, an O/R-mapper, while trying to use it with PostgreSQL thru JDBC. There's a metadata-related call that throws an exception indicating that the OID for the table in question was not found. A little online research led me to a site (can't cite it right now) on which there is some mention of a bug in the PostgreSQL-JDBC driver having something to do with the datatype of OID: some mismatch, apparently, between PostgreSQL's type for OID vs. the type the driver is expecting (pointer vs. INTEGER ?). My next step is to get the latest (dev-build?) of the driver. However, I'm worried that that driver will be unstable as regards other functionality. Any advice regarding this issue would be much appreciated. Thank you, Larry LeFever
Yes, there can be some problems getting the oid, jakarta's turbine project has the same problem. As far as instability goes, we generally fix more than we break, so I would say go for it, but of course test the code. Dave On Wed, 2002-11-06 at 18:09, Larry LeFever wrote: > I'm having a problem with TableGen, an O/R-mapper, > while trying to use it with PostgreSQL thru JDBC. > > There's a metadata-related call that throws an > exception indicating that the OID for the table in > question was not found. > > A little online research led me to a site (can't > cite it right now) on which there is some mention > of a bug in the PostgreSQL-JDBC driver having > something to do with the datatype of OID: some > mismatch, apparently, between PostgreSQL's type > for OID vs. the type the driver is expecting > (pointer vs. INTEGER ?). > > My next step is to get the latest (dev-build?) of > the driver. However, I'm worried that that driver > will be unstable as regards other functionality. > > Any advice regarding this issue would be much > appreciated. > > Thank you, > > Larry LeFever > > > ---------------------------(end of broadcast)--------------------------- > TIP 4: Don't 'kill -9' the postmaster -- Dave Cramer <Dave@micro-automation.net>
I'm using an O/R-Mapper called TableGen. I had, just recently, a problem with it having to do with OID's. I solved that problem by starting to use the 7.3 beta 3 JDBC-driver. I didn't realize until just today that the latest stable version of the driver seems to have a problem with TIMESTAMP (or do I have a configuration-problem?). As indicated below, my Test doesn't work with the latest stable driver, but it does work with 7.3 beta 3. I'm reluctant to use third-party beta-code on the current project; it handles "other people's money" and financial accounts. Do I have a config-problem? Is there an option to postmaster for setting the default TIMESTAMP format? I have yet to search for such, but I wanted to get this email out ASAP. I'm under a (as always, tight) deadline. Any assistance with this matter would be much appreciated. BTW, if this project could count on really speedy bug-fix responses from postgres-developers (or specifically from postgres JDBC-driver developers), perhaps use of 7.3 beta 3 in our production version would be worth the risk -- though that would ultimately not be for me to say. Thank you, Larry LeFever (NOTE: "<proprietary-omitted>", below, is the result of a search/replace i did, to conceal the name of a project not yet to be revealed to the public; i.e., there's no problem with the paths that expression appears in below) [lefever@dataman_local dbtables]$ javac Test.java [lefever@dataman_local dbtables]$ java Test INSERTing one Client Showing all Clients Exception in thread "main" Bad Timestamp Format at 23 in 2002-11-14 14:11:14.163727-05 at org.postgresql.jdbc2.ResultSet.getTimestamp(ResultSet.java:517) at org.postgresql.jdbc2.ResultSet.getTimestamp(ResultSet.java:675) at com.<proprietary-omitted>.db.dao.Client.getFromResultSet(Client.java:422) at com.<proprietary-omitted>.db.dao.Client.retrieveAll(Client.java:699) at Test.showAllClients(Test.java:68) at Test.main(Test.java:17) [lefever@dataman_local dbtables]$ echo $CLASSPATH /usr/java/j2sdk1.4.1/lib/postgresql.jar:/usr/java/j2sdk1.4.1/lib/DDConnectionBroker.jar:/home/users/lefever/tablegen-1.8:/home/users/lefever/tablegen-1.8/classes:/home/users/lefever/tablegen-1.8/dbtables:/home/server/pSrvr/<proprietary-omitted>1.0/classes [lefever@dataman_local dbtables]$ ls $JAVA_HOME/lib DDConnectionBroker.jar htmlconverter.jar log4j-1.2.6.jar pg73b3jdbc2.jar tools.jar dt.jar ir.idl orb.idl postgresql.jar [lefever@dataman_local dbtables]$ export CLASSPATH=$JAVA_HOME/lib/pg73b3jdbc2.jar:$CLASSPATH [lefever@dataman_local dbtables]$ echo $CLASSPATH /usr/java/j2sdk1.4.1/lib/pg73b3jdbc2.jar:/usr/java/j2sdk1.4.1/lib/postgresql.jar:/usr/java/j2sdk1.4.1/lib/DDConnectionBroker.jar:/home/users/lefever/tablegen-1.8:/home/users/lefever/tablegen-1.8/classes:/home/users/lefever/tablegen-1.8/dbtables:/home/server/pSrvr/<proprietary-omitted>1.0/classes [lefever@dataman_local dbtables]$ java Test INSERTing one Client Showing all Clients 0 | llefever0 | myPassword | Larry | LeFever | INSERTing a second Client Showing all Clients 0 | llefever0 | myPassword | Larry | LeFever | 1 | llefever1 | myPassword | Larry | LeFever | [lefever@dataman_local dbtables]$
Larry, Larry LeFever wrote: > > I didn't realize until just today that the latest stable version of the driver > seems to have a problem with TIMESTAMP (or do I have a > configuration-problem?). > The problem is that the 7.2 driver has a bug with understanding the extra precision in the seconds. In 7.1 the database only really supported 9.99 for precision, but 7.2 can support upto 9.999999. One way to work around this problem is to create your columns with less precision. So instead of: create table foo (col_a timestamp) use: create table foo (col_a timestamp(2)) - where two is two decimal digits of precision > > I'm reluctant to use third-party beta-code on the current project; it handles > "other people's money" and financial accounts. > I understand your reluctance, but 7.3 goes RC1 today. And I personally feel that the 7.3 driver is better than the 7.2 version. And I am currently running it on one production system. (Of course as a maintainer of the driver I probably should be using in it production before anyone else :-) > BTW, if this project could count on really speedy bug-fix responses from > postgres-developers (or specifically from postgres JDBC-driver developers), > perhaps use of 7.3 beta 3 in our production version would be worth the risk -- > though that would ultimately not be for me to say. If you go the 7.3 route, use something more current thant beta3. There have been some fixes since beta3, one of which is very important. I will try to get RC1 builds posted to the website over the weekend, else you can build from CVS. thanks, --Barry
Larry, As co-maintainer I second Barry's suggestion. I certainly am aware of many more bugs that were fixed than we have possibly created. I also routinely use beta drivers in production. Dave On Fri, 2002-11-15 at 13:36, Barry Lind wrote: > Larry, > > Larry LeFever wrote: > > > > I didn't realize until just today that the latest stable version of the driver > > seems to have a problem with TIMESTAMP (or do I have a > > configuration-problem?). > > > > The problem is that the 7.2 driver has a bug with understanding the > extra precision in the seconds. In 7.1 the database only really > supported 9.99 for precision, but 7.2 can support upto 9.999999. One > way to work around this problem is to create your columns with less > precision. So instead of: > create table foo (col_a timestamp) > use: > create table foo (col_a timestamp(2)) - where two is two decimal digits > of precision > > > > > I'm reluctant to use third-party beta-code on the current project; it handles > > "other people's money" and financial accounts. > > > > I understand your reluctance, but 7.3 goes RC1 today. And I personally > feel that the 7.3 driver is better than the 7.2 version. And I am > currently running it on one production system. (Of course as a > maintainer of the driver I probably should be using in it production > before anyone else :-) > > > BTW, if this project could count on really speedy bug-fix responses from > > postgres-developers (or specifically from postgres JDBC-driver developers), > > perhaps use of 7.3 beta 3 in our production version would be worth the risk -- > > though that would ultimately not be for me to say. > > If you go the 7.3 route, use something more current thant beta3. There > have been some fixes since beta3, one of which is very important. I > will try to get RC1 builds posted to the website over the weekend, else > you can build from CVS. > > thanks, > --Barry > > > > > ---------------------------(end of broadcast)--------------------------- > TIP 1: subscribe and unsubscribe commands go to majordomo@postgresql.org -- Dave Cramer <Dave@micro-automation.net>
Thanks much for your respective responses. The relevant decision-maker(s) on my end will presumably consider your feedback and tell me how they want me to handle this issue. This morning, the precision-issue occurred to me. I proceeded to develop a solution involving "substring": "substring(current_timestamp, 0, 20)" that seemed to truncate so as to leave off the entire fractional part of the timestamp, which I believed is the issue. Something similar is done in the DAO-base-class used by TableGen, but only for Oracle. You seem to be saying something slightly different: namely, that there's a degree of precision (in terms of fractions of a second) that the stable driver does support, instead of not supporting any fractional part. Do I understand this correctly? Also, is there any problem with putting CURRENT_TIMESTAMP into a timestamp(2) field? That seems to be a case of a kind of "cast required, lest loss of precision" issue. Not so? If so, would my substring approach be preferred (or required)? The CURRENT_TIMESTAMP, in this case, is being used in a trigger (for INSERT and UPDATE timestamping). Larry LeFever Dave Cramer wrote: > Larry, > > As co-maintainer I second Barry's suggestion. I certainly am aware of > many more bugs that were fixed than we have possibly created. I also > routinely use beta drivers in production. > > Dave > On Fri, 2002-11-15 at 13:36, Barry Lind wrote: > > Larry, > > > > Larry LeFever wrote: > > > > > > I didn't realize until just today that the latest stable version of the driver > > > seems to have a problem with TIMESTAMP (or do I have a > > > configuration-problem?). > > > > > > > The problem is that the 7.2 driver has a bug with understanding the > > extra precision in the seconds. In 7.1 the database only really > > supported 9.99 for precision, but 7.2 can support upto 9.999999. One > > way to work around this problem is to create your columns with less > > precision. So instead of: > > create table foo (col_a timestamp) > > use: > > create table foo (col_a timestamp(2)) - where two is two decimal digits > > of precision > > > > > > > > I'm reluctant to use third-party beta-code on the current project; it handles > > > "other people's money" and financial accounts. > > > > > > > I understand your reluctance, but 7.3 goes RC1 today. And I personally > > feel that the 7.3 driver is better than the 7.2 version. And I am > > currently running it on one production system. (Of course as a > > maintainer of the driver I probably should be using in it production > > before anyone else :-) > > > > > BTW, if this project could count on really speedy bug-fix responses from > > > postgres-developers (or specifically from postgres JDBC-driver developers), > > > perhaps use of 7.3 beta 3 in our production version would be worth the risk -- > > > though that would ultimately not be for me to say. > > > > If you go the 7.3 route, use something more current thant beta3. There > > have been some fixes since beta3, one of which is very important. I > > will try to get RC1 builds posted to the website over the weekend, else > > you can build from CVS. > > > > thanks, > > --Barry > > > > > > > > > > ---------------------------(end of broadcast)--------------------------- > > TIP 1: subscribe and unsubscribe commands go to majordomo@postgresql.org > -- > Dave Cramer <Dave@micro-automation.net>