Fork me on GitHub
#sql
<
2019-09-19
>
seancorfield01:09:12

@deleted-user Per the Getting Started > Installation section of the docs: In addition, you will need to add dependencies for the JDBC drivers you wish to use for whatever databases you are using. You can see the drivers and versions that next.jdbc is tested against in the project's deps.edn file, but many other JDBC drivers for other databases should also work (e.g., Oracle, Red Shift). 🙂

seancorfield01:09:23

I'll be around for a while in case you have any other questions / issues, so I should be able to help you get up and running quickly.

Tom Fenton09:09:57

Hey all! Can anyone give me some pointers on how to terminate a long-running query on an external event (i.e. not on a timeout)? I'm building a data export tool and I need to be able to cancel a query from a gui event without having to exit the entire application. Running the query in a future and calling future-cancel has gotten me nowhere (returns true but runs to completion anyay)...

Tom Fenton10:09:52

Thanks jumar - good pointers, I didn't think of cancelling the statement since I assumed it was blocked/unresponsive until completion, hence going down the route of killed the associated thread. It looks like I'll have to operate directly on the statement, which means replacing a chunk of clojure.java.jdbc or next.jdbc with interop... Sure I'll figure it out though!

Tom Fenton10:09:36

Disregard that last part... Just realised that PreparedStatement extends Statement

👍 4
seancorfield16:09:26

Interesting. I didn't even realize that was possible at all, but you'd need to organize your code very carefully to make that work.

Tom Fenton09:09:14

I can see the transactions disappear from Activity Monitor in SSMS on command, so it appears to be working perfectly - thanks again @U06BE1L6T!

👍 4
Tom Fenton09:09:17

Implementation-wise - I have three channels (stop, results, output). I execute the prepared statement in a future, but process the results set first to ensure it doesn't return immediately. The output is directed to the results channel. I then have a go alt! which waits for stop-chan (do (.cancel statement) (.rollback conn)) or results-chan, which just passes the result to output-chan. When I click "cancel", the GUI thread puts to stop-chan and cancels the future that is waiting for the result. Feels slightly messy but works as intended - let me know if I've done anything too unwholesome/if you have any suggestions!

jumar09:09:49

Maybe just beaware of potential blocking of (.cancel statement) in a go block? I mean I don't really know how is that implemented but since it has to incur DB call it can block potentially for a long time. If you get many such unlucky cancellations then you can prevent your go blocks from progressing I think

jmayaalv10:09:33

i don’;t think that’s supported by any jdbc driver. never saw it at least.