search

exasol / exasol-virtual-schema

Virtual Schema from Exasol to Exasol
MIT License
1 stars 2 forks source link

Use getEXAType() to determin Exasol-specific types #60

Closed redcatbear closed 2 years ago

redcatbear commented 2 years ago

Situation

Exasol has uncommon types like INTERVAL, HASHTYPE and GEOMETERY. While types are like that are not unheard of in other products, they are rare. For compatibility with 3rd party products, the JDBC driver's getType() method reports them as either VARCHAR or CHAR. This is a problem in the Exasol Virtual Schema though, because you really want the exact original types in a connection between two Exasol clusters.

Luckily the driver has a non-standard getEXAType() method that reports the original type.

Back reference: SUPPORT-27418

Breaking Change

While this fixes a long lasting problem, it is still a breaking change, so we need to write that into the release letter and increase the major version. Same for RLS when we propagate this.

Acceptance Criteria

  1. Metadata reader determines original column types for all columns.
AnastasiiaSergienko commented 2 years ago

We figured out that getEXAType is not implemented correctly in the driver. This is going to be fixed in 7.1.4. But now it's not possible to use it for a fix. (SPOT-13565) We can use getColumnTypeName() instead and check if the name equals to HASHTYPE

AnastasiiaSergienko commented 2 years ago

Another problem with the HASHTYPE: I can't get the correct byte size of the column via the JDBC driver. In my test, I create a table with a single column HASHTYPE (16 BYTE). I insert a value 550e8400-e29b-11d4-a716-446655440000 which I got from our website examples (https://docs.exasol.com/sql_references/data_types/datatypedetails.htm). And I'm trying to get the information about the column via the JDBC driver. I can get the type name from ResultSetMetaData class, getColumnTypeName method. But I can't get the correct byte size. getPrecision() returns 32. getScale() returns 0.

redcatbear commented 2 years ago

Closed via #60.