This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2016-07-19
Channels
- # admin-announcements (2)
- # aws-lambda (3)
- # beginners (66)
- # boot (61)
- # cider (1)
- # cljs-dev (17)
- # clojure (100)
- # clojure-austin (4)
- # clojure-brasil (1)
- # clojure-canada (8)
- # clojure-quebec (6)
- # clojure-russia (48)
- # clojure-sg (6)
- # clojure-spec (37)
- # clojure-uk (61)
- # clojure-ukraine (2)
- # clojurescript (80)
- # core-async (13)
- # cursive (20)
- # datascript (37)
- # datomic (2)
- # defnpodcast (4)
- # emacs (5)
- # funcool (3)
- # hoplon (11)
- # jobs (7)
- # juxt (26)
- # lein-figwheel (48)
- # leiningen (3)
- # luminus (3)
- # om (34)
- # om-next (5)
- # onyx (5)
- # protorepl (6)
- # re-frame (10)
- # reagent (9)
- # rethinkdb (16)
- # ring-swagger (5)
- # spacemacs (14)
- # specter (54)
- # untangled (36)
- # vim (75)
- # yada (1)
@jonathanj why not use a file based one? then instead of having a totally fresh one each time you can down migrate and up migrate, thus testing your down migrators too
i do that here (wtih h2, but it used to use sqlite) https://github.com/oliyh/slacky/blob/master/src/slacky/db.clj#L61
Contrary to the vast knowledge of Stack Overflow that’s not actually giving it a name.
Well because I want to just build the file up from nothing each time without having to worry about what state I did or did not remember to reset.
@oliy: I think that a new temporary file or your method is probably the best choice, thanks for the code sample.
@oliy: You do make a good point about testing the down migrators too, I hadn’t thought of that aspect of it.
I’m just concerned that tests might pass even if everything didn’t go successfully and that some piece of database state is left lying around causing false negatives in my tests.
I thought an in-memory database would be the easiest way to actually do this but it was only after the weird errors that I realised the database is being recreated multiple times per test because the connection is not retained and reused.
there's possibly a way to give joplin a db connection instead of just a url - i can't remember if that ever got implemented. then you never relinquish it while you migrate
Looking through the joplin.jdbc.database
source I couldn’t see anything that would not try to construct a db-spec from a URL.
https://github.com/juxt/joplin/blob/master/joplin.jdbc/src/joplin/jdbc/database.clj#L25
I was trying to merge a connection and the (:db target)
map but it didn’t produce any useful results and I’m not quite sure why since I don’t really understand all these different db-spec forms.
any thoughts about spec in the context of juxt librairies (since you use schema quite heavily) ?
Yes, yada will most likely move towards it but probably after 1.9 is released