[
https://issues.apache.org/jira/browse/ARROW-10492?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Liya Fan updated ARROW-10492:
-----------------------------
Description:
According to the current implementation of JDBC adapter, the conversion between
SQL types and Arrow types is hard-coded. This will cause some problems in
practice:
# The appropriate conversion may vary for different databases. For example,
for SQL Server, type {{real}} corresponds to 4 byte floating point values
([https://docs.microsoft.com/en-us/sql/t-sql/data-types/float-and-real-transact-sql?view=sql-server-ver15),]
whereas for SQLite, \{{real}} corresponds to 8 byte floating point values
([https://www.sqlitetutorial.net/sqlite-data-types/).] If the maping is not
right, some extra conversion would happen, which can impact performance
severely.
# Our current implementation determines the type conversion solely based on
the type ID. However, the appropriate conversion may also depend some other
information, like precision and scale. For example, for {{FLOAT( n )}}, it
should correspond to 4 byte floating point values, if n <= 24, otherwise, it
should correspond to 8 byte floating point values.
To address the problems, we should allow users to customize the conversion
between SQL and Arrow types.
was:
According to the current implementation of JDBC adapter, the conversion between
SQL types and Arrow types is hard-coded. This will cause some problems in
practice:
# The appropriate conversion may vary for different databases. For example,
for SQL Server, type {{real}} corresponds to 4 byte floating point values
([https://docs.microsoft.com/en-us/sql/t-sql/data-types/float-and-real-transact-sql?view=sql-server-ver15),]
whereas for SQLite, \{{real}} corresponds to 8 byte floating point values
([https://www.sqlitetutorial.net/sqlite-data-types/).] If the maping is not
right, some extra conversion would happen, which can impact performance
severely.
# Our current implementation determines the type conversion solely based on
the type ID. However, the appropriate conversion may also depend some other
information, like precision and scale. For example, for {{FLOAT(n)}}, it should
correspond to 4 byte floating point values, if n <= 24, otherwise, it should
correspond to 8 byte floating point values.
To address the problems, we should allow users to customize the conversion
between SQL and Arrow types.
> [Java][JDBC] Allow users to config the mapping between SQL types and Arrow
> types
> --------------------------------------------------------------------------------
>
> Key: ARROW-10492
> URL: https://issues.apache.org/jira/browse/ARROW-10492
> Project: Apache Arrow
> Issue Type: Improvement
> Components: Java
> Reporter: Liya Fan
> Assignee: Liya Fan
> Priority: Major
>
> According to the current implementation of JDBC adapter, the conversion
> between SQL types and Arrow types is hard-coded. This will cause some
> problems in practice:
> # The appropriate conversion may vary for different databases. For example,
> for SQL Server, type {{real}} corresponds to 4 byte floating point values
> ([https://docs.microsoft.com/en-us/sql/t-sql/data-types/float-and-real-transact-sql?view=sql-server-ver15),]
> whereas for SQLite, \{{real}} corresponds to 8 byte floating point values
> ([https://www.sqlitetutorial.net/sqlite-data-types/).] If the maping is not
> right, some extra conversion would happen, which can impact performance
> severely.
> # Our current implementation determines the type conversion solely based on
> the type ID. However, the appropriate conversion may also depend some other
> information, like precision and scale. For example, for {{FLOAT( n )}}, it
> should correspond to 4 byte floating point values, if n <= 24, otherwise, it
> should correspond to 8 byte floating point values.
> To address the problems, we should allow users to customize the conversion
> between SQL and Arrow types.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
