Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Support for literal serialization #552

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

Support for literal serialization #552

timowest opened this issue Nov 15, 2013 · 4 comments
Assignees
Milestone

Comments

@timowest
Copy link
Member

@timowest 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
Copy link

@thackel 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
Copy link
Member Author

@timowest 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
Copy link

@BuBuaBu 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
Copy link
Member Author

@timowest 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
Labels
None yet
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
3 participants