Support for literal serialization #552

Closed
timowest opened this Issue Nov 15, 2013 · 4 comments

Comments

Projects
None yet
3 participants
@timowest
Member

timowest commented Nov 15, 2013

Support for literal serialization into the final query or statement. This means that literals such as numbers, strings and chars are not handled via prepared statement parameters, but serialized directly into the query or statement.

Supported using SQL 92 standard and JDBC escape syntax (Derby).

Enable via:

  • configuration.setUseLiterals(true) - for configuration level setting
  • query.setUseLiterals(true) - for query level setting
@thackel

This comment has been minimized.

Show comment
Hide comment
@thackel

thackel Nov 15, 2013

Why is this desirable? So you have to care about escaping etc instead of the JDBC driver.
I can't imagine a use case....

thackel commented Nov 15, 2013

Why is this desirable? So you have to care about escaping etc instead of the JDBC driver.
I can't imagine a use case....

@timowest

This comment has been minimized.

Show comment
Hide comment
@timowest

timowest Nov 15, 2013

Member

We have a customer that requests this feature. It won't be the default, but can be enabled if literal serialization is desired. This feature is also useful for cases where Querydsl acts as the SQL query builder.

The specific reason is that for some databases (e.g. Teradata and Virtuoso) usage of literals helps in the query optimization.

Member

timowest commented Nov 15, 2013

We have a customer that requests this feature. It won't be the default, but can be enabled if literal serialization is desired. This feature is also useful for cases where Querydsl acts as the SQL query builder.

The specific reason is that for some databases (e.g. Teradata and Virtuoso) usage of literals helps in the query optimization.

@ghost ghost assigned timowest Nov 18, 2013

@BuBuaBu

This comment has been minimized.

Show comment
Hide comment
@BuBuaBu

BuBuaBu Nov 18, 2013

Using literals instead of prepared statement is also useful on Oracle.
On Oracle, the execution plan is computed with the query string. So if there are some bind parameters, there are not yet known. Then, the optimizer have to guess the type of bind parameters, and some times it's not possible. The execution plan will be affected and could be not optimal.

One workaround, to still use bind parameter, is to explicitly cast it to the correct datatype.

BuBuaBu commented Nov 18, 2013

Using literals instead of prepared statement is also useful on Oracle.
On Oracle, the execution plan is computed with the query string. So if there are some bind parameters, there are not yet known. Then, the optimizer have to guess the type of bind parameters, and some times it's not possible. The execution plan will be affected and could be not optimal.

One workaround, to still use bind parameter, is to explicitly cast it to the correct datatype.

timowest added a commit that referenced this issue Nov 19, 2013

timowest added a commit that referenced this issue Nov 19, 2013

timowest added a commit that referenced this issue Nov 19, 2013

@timowest

This comment has been minimized.

Show comment
Hide comment
@timowest

timowest Dec 22, 2013

Member

Released in 3.3.0

Member

timowest commented Dec 22, 2013

Released in 3.3.0

@timowest timowest closed this Dec 22, 2013

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment