Fork me on GitHub
#datomic
<
2015-10-12
>
aan13:10:19

Does anyone know if it’s possible to save queries across sessions in the datomic console?

martinklepsch13:10:20

Just got a :backup/claim-failed error when trying to backup — it seems that the backup mechanism thought the backup location is being used by another system or so. Couldn’t find anything googling so asking here: how does datomic check if a backup storage is already in use?

java.lang.IllegalArgumentException: :backup/claim-failed Backup storage already used by solglas-1862a281-5d82-4fd1-97dc-10b7fa084e9e

Ben Kamphaus14:10:46

@martinklepsch: That message indicates that the backup URI where you’re trying to backup to is already being used to backup a different database.

martinklepsch14:10:29

@bkamphaus: yeah that’s what I understood too but how does Datomic know? Or what did I do that it doesn’t know anymore? simple_smile

Ben Kamphaus14:10:58

i.e. you backed up “accounts” to that URI (file location, s3 location), so you can’t backup “dossiers” to it.

Ben Kamphaus14:10:23

Well, it knows the exact detail it puts there — "solglas-1862a281-5d82-4fd1-97dc-10b7fa084e9e” is the id of the db backed up there.

Ben Kamphaus14:10:15

if you want to overwrite with something different and don’t want to keep the other data, you can just use s3/file system to delete the backup, or if you’re not sure of course archive/backup the current backup folder first.

sdegutis14:10:04

When making test databases for use in tests, is it efficient to create a new one for each test and let the system GC them after they're unused (str "datomic:mem://fake-db-" (java.util.UUID/randomUUID))?

Ben Kamphaus14:10:23

@sdegutis: if the tests don’t encounter behavior that introduces garbage that doesn’t get removed (restoring over an old db with a branching t, index failures, that sort of thing), probably. If you’re really worried, have all test dbs hit the same storage table/bucket/keyspace with the txor and periodically blow it away and recreate. There are users doing this as part of their testing, actually (delete and re-init keyspace/table).

sdegutis14:10:35

@bkamphaus: That's what I was doing before, but I wanted to unify my test/live code, which meant removing the initial (d/delete-database uri) line.

peterbak15:10:15

Thinking of using Datomic as a backing store for a web app hosted on AWS (probably on top of DynamoDB). Can anybody share any gotchas from an operational perspective? Did you end up creating custom admin dashboards to make sense of the data stored in Datomic, or is console sufficient? etc etc. Thanks!

Ben Kamphaus16:10:29

@sdegutis: I’m not sure I follow - do you delete at the end now, or in some batch delete? You will still have to call delete to get the database recovered by gc. Also the initial delete call would be spurious if starting from a new keyspace/table/bucket each time? Or is that i.e. what you mean you had to drop to match live?

sdegutis16:10:19

@bkamphaus: Our current tests use a function that re-uses the same memory-based databased URI but call delete-database before the tests run (followed immediately by create-database), in order to clear any state from previous tests.

sdegutis16:10:00

@bkamphaus: But other than that one call to delete-database, the code for handling our in-memory test database and a live database was identical, thanks to how Datomic was designed.

sdegutis16:10:43

@bkamphaus: So my solution is to remove the call to delete-database, leave the call to create-database (which is a no-op if the db already exists), and change the function that produces a test-database's URI so that instead of returning a single one, it returns a new one every time.

sdegutis16:10:27

@bkamphaus: It works fine, I just worry about memory consumption and whether Datomic knows to GC them properly when I'm done with them, so that I don't have to manually release them when the each test is done with the temporary in-memory database.