fix: sort result set by sql type value in metadata typeinfo

[zemian]

fixes #716

I don't see a good way to sort the type from backend query, so I provide a solution that sort the result after the query. Let me know if this is good for you or not.

[codecov-io]

Codecov Report

Merging #910 into master will decrease coverage by 0.01%.
The diff coverage is 66.66%.

@@             Coverage Diff              @@
##             master     #910      +/-   ##
============================================
- Coverage     65.85%   65.83%   -0.02%     
+ Complexity     3546     3545       -1     
============================================
  Files           166      166              
  Lines         15230    15236       +6     
  Branches       2470     2471       +1     
============================================
+ Hits          10029    10031       +2     
- Misses         4022     4026       +4     
  Partials       1179     1179

[vlsi]

Would you please perform parseInt/decode stuff outside of Comparator to avoid repeated decode/parse in the sort loop?

[zemian]

Hi @vlsi, The decode part is needed in the loop because we need the byte[1] "sqlType" as input byte. Moving it outside means I have to create new list of byte array and associate the origingal sqlType int value as one element. And again to remove the int sqlType as final result after the sorting for return value. Can you please confirm is that what you like to see?

[GuntherRademacher]

This does not completely fix #716, because it does not honor the second criterion given in the spec (see my comment).

[davecramer]

@GuntherRademacher so exactly what are the orderings then ? This seems overly pedantic to me

[GuntherRademacher]

Call it pedantic if you want. The ordering constraints are (listed here):

They are ordered by DATA_TYPE and then by how closely the data type maps to the corresponding JDBC SQL type.

The proposed fix ignores the second criterion, which is important, as it provides the ranking information that cannot be derived otherwise. Compared to that, the first criterion is trivial, as it can be restored from the result itself.

I stumbled on this while writing code to find the best fit for mapping JDBC types to vendor-specific type names, for different databases. AFAICS Oracle, MySQL, and Derby are doing it right. A corresponding SQL Server bug is described here.

[davecramer]

The challenge I envisioned was how to deal with custom types. Most databases are not extensible and do not have "create type" That being said fixing the existing types should not be that onerous. Care to provide a pull request ? Dave Cramer

…

On 5 January 2018 at 04:56, Gunther Rademacher ***@***.***> wrote: Call it pedantic if you want. The ordering constraints are (listed here <https://docs.oracle.com/javase/8/docs/api/java/sql/DatabaseMetaData.html#getTypeInfo--> ): They are ordered by DATA_TYPE and then by how closely the data type maps to the corresponding JDBC SQL type. The proposed fix ignores the second criterion, which is important, as it provides the ranking information that cannot be derived otherwise. Compared to that, the first criterion is trivial, as it can be restored from the result itself. I stumbled on this while writing code to find the best fit for mapping JDBC types to vendor-specific type names, for different databases. AFAICS Oracle, MySQL, and Derby are doing it right. A corresponding SQL Server bug is described here <https://connect.microsoft.com/SQLServer/feedbackdetail/view/526890/jdbc-driver-bug-java-sql-databasemetadata-gettypeinfo> . — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#910 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAYz9jT_DeL_dEa0J292TZLEAD8qbdZ-ks5tHfHQgaJpZM4Ouix_> .

[yan-hic]

Any update on this ?

Can a rank (set with CASE WHEN... THEN) not be used to order by sql.Type first, then by 'prefered' typname e.g. 12-VARCHAR before 12-NAME

[davecramer]

fixed in #1506