Clojurians Log v2

@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

or - give it a name, jdbc:sqlite::memory:my-test and i think that will work too

Contrary to the vast knowledge of Stack Overflow that’s not actually giving it a name.

That’s using an on disk file that is ./:memory:my-test.

(I found this out the hard way.)

yes

is there a reason you don't want to do that?

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.

you could give it a random name each time then

i agree you don't want ambiguity in your 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

I couldn’t find out how.

Looking through the joplin.jdbc.database source I couldn’t see anything that would not try to construct a db-spec from a URL.

I think ragtime supports this though.

https://github.com/juxt/joplin/blob/master/joplin.jdbc/src/joplin/jdbc/database.clj#L25

i guess for now you'll need to try one of the other approaches, or PRs welcome 🙂

Where can I learn about these jdbc db-spec maps?

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.

probably clojure.java.jdbc

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