This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2017-11-16
Channels
- # aleph (1)
- # aws (1)
- # beginners (23)
- # boot (33)
- # cider (15)
- # cljs-dev (4)
- # clojure (73)
- # clojure-dev (18)
- # clojure-italy (8)
- # clojure-russia (7)
- # clojure-serbia (1)
- # clojure-spec (8)
- # clojure-uk (118)
- # clojure-ukraine (3)
- # clojurescript (34)
- # code-art (1)
- # community-development (24)
- # cursive (21)
- # data-science (3)
- # datomic (72)
- # defnpodcast (1)
- # fulcro (77)
- # graphql (4)
- # hoplon (8)
- # jobs (3)
- # luminus (3)
- # lumo (7)
- # off-topic (3)
- # onyx (17)
- # other-languages (7)
- # pedestal (1)
- # perun (1)
- # protorepl (21)
- # re-frame (91)
- # ring (4)
- # ring-swagger (18)
- # shadow-cljs (22)
- # spacemacs (37)
- # specter (1)
- # sql (23)
- # test-check (4)
- # unrepl (29)
- # utah-clojurians (3)
- # vim (36)
- # yada (10)
Hi, jdbc/get-connection db worked like a charm.
It works on one of my stored procedures but not the other one. Only difference I can see is that the one not working returns a value. We have used java with Spring previously to contact this procedure with SimpleJdbcCall. Could it be that I need to specify that the procedure returns a value? I'm getting error message: Caused by: java.sql.SQLException: ORA-06550: rad 1, kolumn 7: PLS-00221: 'RECEIVE_MESSAGE' is not a procedure or is undefined ORA-06550: rad 1, kolumn 7: PL/SQL: Statement ignored
Cant upload my code snippet for some reason.
@mattias.didriksson java.jdbc
doesn't do much to help you with stored procs so you'll need to use Java interop and whatever the java.sql.*
classes would require. Feel free to add information about what would make life easier to this JIRA issue https://dev.clojure.org/jira/browse/JDBC-48
Sidenote: I totally agree with the sentiment on this ticket about stored procedures. Also, I like this part of the ticket "March 15, 2013: I'll be hacking on this, so patches forthcoming" ...crickets
@gdeer81 Well, you know how it goes with OSS and volunteers... 🙂
If I ever actually used stored procs myself, you can bet this feature would have been added years ago...
...but I don't even have a test case to try it out (and I don't know how cross-platform-DB such a test case would be -- I only use MySQL).
I was thinking about this the other day. Lets say you had a script that would spin up a docker instance for each OS and database vendor and ran the tests for each combination. That test suite might be harder to maintain than the codebase itself
Well, I already have PostgreSQL and Percona 5.7 locally in Docker instances for testing. I also have a Windows XP VM with SQL Server Express on it. I run clojure.java.jdbc
tests against all those plus MySQL 5.5, Apache Derby, SQLite, H2, HSQLDB...
But the real problems come from where the SQL dialect supported by each DB differs. Even something as simple as auto-generated integer PK differs on almost every DB. How to do EXPLAIN (that's in the java.jdbc
test suite).
hrm it's almost like you need a .sqlc
file that has reader conditionals for each database vendor 😆
sorry that's my default response to statements where I know all the words individually but not as a whole
if you're looking for a good time this weekend, fork clojure/clojure and add some feature expressions. Then for symbolic effect, submit a PR. PRs and Jira tickets on this are equally likely to be accepted.