Open
Conversation
|
This seems like a useful feature would be nice to see it merged or comments as to what's wrong with the current PR. |
Member
|
Instead of adding new function to the dsl for each configuration option, I would like to see a solution that allows passing arbitrary options to clojure.java.jdbc. |
|
Thoughts on what this would look like? Maybe a function |
Member
|
Yeah, I was also thinking of something like this: (with-options {:fetch-size 100 :max-rows 1000}
(select users)) |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Added functionality to set and pass through two JDBC options (:fetch-size and :max-rows) to clojure.java.jdbc's prepare-statement.
Fetch size is important because large queries to a remote server are intolerably slow with the default fetch size of 10.
Max rows is important because the only simple way Korma currently provides to limit the number of rows returned is the (limit) function, which relies on SQL LIMIT, which is not supported by Oracle. The only workaround my group was able to find was to run our original query as a subselect, then call (where (raw (str "rownum <= " X))), but this has the problem of not automatically calling any transforms defined for entities in the subselect. Being able to call (select users (max-rows X)) solves this.
Some usage examples, with performance for one of the large tables my group uses:
user=> (defdb b (korma.db/oracle {...}}))
{:pool …}
user=> (defentity ent (table ...))
'user/ent
user=> (count (time (select ent (fields :name))))
"Elapsed time: 14443.238 msecs"
17178
user=> (count (time (select ent (fields :name))))
"Elapsed time: 14247.032 msecs"
17178
user=> (count (time (select ent (fields :name))))
"Elapsed time: 14024.118 msecs"
17178
user=> (count (time (select ent (fields :name) (fetch-size 100))))
"Elapsed time: 1812.418 msecs"
17178
user=> (count (time (select ent (fields :name) (fetch-size 1000))))
"Elapsed time: 353.63 msecs"
17178
user=> (count (time (select ent (fields :name) (max-rows 100))))
"Elapsed time: 160.334 msecs"
100
user=> (count (time (select ent (fields :name) (limit 100)))) ;;Oracle doesn't support LIMIT.
Failure to execute query with SQL:
SELECT “TABLE_NAME.”NAME" FROM “TABLE_NAME” LIMIT 100 :: []
SQLSyntaxErrorException:
Message: ORA-00933: SQL command not properly ended
SQLState: 42000
Error Code: 933
SQLSyntaxErrorException ORA-00933: SQL command not properly ended
oracle.jdbc.driver.T4CTTIoer.processError (T4CTTIoer.java:445)