3 ms·
I'm using postgres and clojure for quite a few enterprises and my typical approach is to keep the raw sql files somewhere (resources/sql/) so that I can execute
by dmichulke 11y ago
I'm using postgres and clojure for quite a few enterprises and my typical approach is to keep the raw sql files somewhere (resources/sql/) so that I can execute it via CLI (say psql) as well as from within clojure (by parsing the files and putting them in a JDBC transaction)
From this I derive both the database schema itself as well as implementation details (e.g., check what columns are in a table or see if the current DB schema agrees with the current SQL schema in resources/sql)
For program internal representation I have my own "classes" (hash maps with a few pre/post assertions on key points) and I just use a single db.clj file that needs to be adapted when the SQL representation changes.
I also worked a lot with Java and Hibernate and it just feels verbose to change a simple datatype definition in both the application and the db. In a way, with clojure I get DB / App consistency that I wouldn't get with Java and/or types. I haven't had the chance to use scala, however.
I also worked with MongoDB (when I started with clojure) and I agree, there it is very easy to make mistakes but maybe I would do things now differently if I used it again.
- daxfohl 11y agoYeah I'm using raw JDBC for the same reason; I like knowing the exact SQL that's going to be used and it's nice to be able to freely use non-SQL-standard things that your particular database supports. It's trivial to write a custom wrapper to make things easier, and simple case classes in Scala to represent the DB records make for a single line code change when the DB model changes.