search

synchronoss / cpo-api

Class Persistence Object (CPO) Application Programming Interface (API).
GNU Lesser General Public License v2.1
3 stars 3 forks source link

Add in support for the latest JDBC Types #7

Closed berryware closed 4 years ago

berryware commented 10 years ago

We need to add in support for the following getters and setters: AsciiStream BinaryStream CharacterStream NCharacterStream NClob NString RowId SqlXml

Some of these have their own JavaTypes some reuse existing. This will require using CpoUtil to override the default jdbc type for the java type. E.g. String -> VARCHAR, overide would be String -> NVarchar

Some of the setters have overloaded methods. Will need to look into being able to use them. This will most likely need to be a separate enhancement

berryware commented 8 years ago

Here's where I am at with this.

I added in NClob, RowId and SqlXml as they have their own java classes so it is not an issue.

JDBC Types NCHAR, LONGNVARCHAR, and NVARCHAR should use the setNString and getNString methods on PreparedStatement, CallableStatement, and ResultSet. CPO will never call these methods because the lookup is based on the java class of the object being passed in not the Jdbc Type. So if the attribute is a String is will always call setString and getString.

CPO has always assumed that the Driver will do the right conversion or error out appropriately. So if someone passes a string to a column that is a DECIMAL, CPO will call set string for that column index and let the driver deal with it. If a driver does not do the conversion of String to NString then a user will want to force the use of the setNString or getNString which CPO does not support.

The solution of this is to tie the getters and setters to the JDBC Type and use them. The question is: Do I only allow JDBC TYPE mapped getters and setters or do I try to match them first and then fall through to the Java Type mapped getters and setters?

The last problem is with the streams. There is no way to tell when to use ascii stream, binary stream, or character stream. Right now only binary and character are supported. I would need to create custom JDBC Types to get the right methods called.

berryware commented 4 years ago

Closing. Was looking at this the wrong way. It is not about having access to all the getters and setters, but making sure that the datatypes get converted properly to the types in the database. All the national character set methods are already supported using the getString counterparts. The JDBC spec states the proper conversion will be made. Character stream and BinaryStream is supported. Ascii stream is a special case of a bytestream that is sending only bytes from the ascii code pages, so in general it is better to use the character stream as it will handle the proper translation of the utf-8 java characters to that of the database.