Issue Details (XML | Word | Printable)

Key: JDBC-308
Type: Bug Bug
Status: Closed Closed
Resolution: Fixed
Priority: Major Major
Assignee: Mark Rotteveel
Reporter: Mark Rotteveel
Votes: 0
Watchers: 0
Operations

If you were logged in you would be able to see more operations.
Jaybird JCA/JDBC Driver

Change metadata queries to always return VARCHAR for strings

Created: 27/Apr/13 08:58 AM   Updated: 11/May/13 03:13 PM
Component/s: JDBC driver
Affects Version/s: Jaybird 2.1.6, Jaybird 2.2, Jaybird 2.2.1, Jaybird 2.2.2
Fix Version/s: Jaybird 2.2.3, Jaybird 3.0

Time Tracking:
Issue & Sub-Tasks
Issue Only
Not Specified

Sub-Tasks  All   Open   

 Description  « Hide
Change metadata queries to always return VARCHAR for strings. Some columns in the metadata are currently declared as CHAR instead of VARCHAR, this can cause problems, see http://youtrack.jetbrains.com/issue/IDEA-100786 for an example.

The weird thing is that when checking the metadata with a simple program, the returned string is of the actual length and not of the declared CHAR(31) length

 All   Comments   Work Log   Change History   Version Control   Subversion Commits      Sort Order: Ascending order - Click to sort in descending order
Mark Rotteveel added a comment - 27/Apr/13 04:11 PM
Changed all queries to use VARCHARs, I am leaving this open for now to see if I can find the cause for the difference in behaviour described in the IntelliJ IDEA ticket.

Mark Rotteveel added a comment - 08/May/13 02:18 PM
As described in the ticket with Jetbrains, Jaybird would only trim the strings for metadata ResultSets if the getString() method was called, IntelliJ only calls getString() for Types.VARCHAR, but the columnType was Types.CHAR so getObject() was called and the string wasn't trimmed.

I am considering a solution where I replace the current metadata boolean in ResultSet with using a separate ResultSet subclass for metadata and/or using a StringField subclass/wrapper for metadata that will take care of trimming. This might also make for a 'prettier' solution than all those CAST(... AS VARCHAR(31)) in a large number of queries (and it might increase forward compatibility if identifiers can become larger in future versions).

Mark Rotteveel added a comment - 08/May/13 03:42 PM
Created 'subtask' for a better solution. I will do some additional testing in IntelliJ before closing this ticket.