Experimental JDBC driver - Mailing list pgsql-hackers
From | Radosław Smogura |
---|---|
Subject | Experimental JDBC driver |
Date | |
Msg-id | 201011211949.28650.rsmogura@softperience.eu Whole thread Raw |
List | pgsql-hackers |
Hello, I last time added some features to JDBC driver meking in some way experimental driver, it could be quite usefull, but if it's possible I would like to ask for some reviews and tests. Maybe some ideas from this will be handly. Beacause the chageset is huge, I don't give patch set, but only URL where You can find sources and compiled binary http://www.rsmogura.net/pgsql/ (drivers are called pgjdbc_exp). Below is some info about changes, in TODO and TO_THINK is set of free ideas about this. === JDBC 4 Exceptions === 1. Driver can throw JDBC 4 exceptions. 2. The PSQLException is now interface, to keep as far as possible backward compatibility, read TO_THINK 3. TODO: In many static methods still exists PgSqlExceptionFactory.getDefault() this should be removed. 4. TODO: Add functionality to allow user to choose between throwin PSQL*Exceptions, or plain SQL*Exception. 5. TODO: Check if decision block about exception type is "fully" proper and there is no missign states, eventualy try to decide to throw Trnasient / Non Transient exceptions. 6. Currently we throw only Non Transient exception, as any error in server only allows to commit or rollback transaction, non future data read or update is possible. 7. TO_THINK: Change PSQLException to interface should make no differences when client application will be fully rebuilded, but if we have some 3rd party binary library its execution can be break (different VM opcode for calling methods). Because we have exception factory we can revoke PSQLException to class, create PSQLExceptionInterface and add additional connection parameter useOldException default true - if true then PSQLException will be thrown on error, false SQLException implementing PSQLExceptionInterface. === Binary Read and Write === Thanks to Mikko for some concepts from his patch (especialy about integer/float dates). 1.Few basic data types has been written (with server types) - read: bool, double, int, short, decimal, varchar, text; date, timestamp (with / without time zone) - write: int, decimal, date, timestamp - casting from server type to Java type is currently supported for few classes and types, need to check this step by step with JDBC spec - dates / times are limited to integer dates server, currently 2.The reader / writer is configured by connection basis with factories so if in future PostgreSQL will change the binary representation only the appropriate reader / writer implementation will change. 3. TODO: Use simillar to binary factory machanism to read / write character protocol. 4. TODO: Add binary modes for PGType classes. 5. TODO: Coopy all statics converters form PGType to factory, and mark methods as deprecated (statics disallow to use custom exception factories). 5a. Subtask create casting facility extracting PGTypes cast methods to this facility, connect it with current if..else trees in ResultSet.get() 6. TODO: Plugability model to internal reading and writing other server types in binary / text mode. 7. Add support for UUID Java class and server type. 8. TODO: Binary reader always return byte[], think about directly writting to stream (less GC overhead). 9.Hack JDK MutuableInteger, less GC overhead and more preformance when parsing DECIMAL. 10. TODO: Make additional test about timestamps (dates, etc.) with / without time zone when server is in different timezone then driver, and what will hapen on TZ change in client. Subject to ask on pg-hackers. 11. TO_THINK: It's good point to think about changing OID to JDBC RowId, just sugar for sugar. 12. No describe or lazy decision to read given value as binary or character. 13. If you would like to test binary for all JUnit test call ant -DbinaryTransfer=true === Other changes === 1. setStatementTimeout - uses Java Timer. It's not fully "secure", as timer will abort statement when statement is executing, long Java processing, or some sub statements can break this soultion. === JDBC 4.1 === 1. build.xml changes, and basic implementation (with UnsupportedOperaionException) of some JDBC interfaces to use JDK 7 JDBC 4.1 Kind regards, Radek
pgsql-hackers by date: