datomic 2024-01-11 | Slack Archive

itaied15:01:37

hey all, we are setting up a local and remote (dev and prod) envs for datomic cloud. the local should work with {:server-type :datomic-local} and remote with {:server-type :ion}. we are switching between them using aliases and an env var

:dev     {:extra-deps {com.datomic/local {:mvn/version "1.0.276"}}
            :jvm-opts   ["-Dconfig-path=app/local.config.edn"]}
:prod    {:jvm-opts ["-Dconfig-path=app/prod.config.edn"]}

when we deploy this project using datomic cloud ions, how can we set the alias to use? how can we tell the ions to use the prod alias? do you have any thoughts about this solution? maybe there's a more convenience one?

itaied18:01:48

Or trying a different approach, how can I load a different config to the classpath? I've tried using (ion/push {:repl-cmd "-A:prod"}) but it does nothing...

:paths     ["src" "resources" "config/dev"]
:aliases
 {:prod    {:extra-paths ["config/prod"]}

config/prod doesn't get pushed to the S3 bucket

souenzzo19:01:20

Just use (System/getProperty "config-path" "app/prod.config.edn") So in dev, it will have the jvm-opts in prod, there is no jvm-opts, and it will use the default value

itaied05:01:49

but this way, if a developer forgot to select the "dev" alias, he will be connected to prod. I want prod connection to be explicit and not the default

Albert Dorfman16:01:29

Hey everyone, I'm relatively new to datomic. I'm currently designing a schema, and I'm trying to figure out how to think about normalization vs. query performance. As a simple example, imagine the system I'm modelling looks like this: author -> books -> characters . And in my application I often have to display all of the characters for a given author. My first instinct would be to model this in a way where the :character namespace has a ref back up to the :book namespace, which has a ref back up to the :author namespace. However, if I often need to display all of the characters for a given author, I'll always have to join through books in order to get the characters. I'm not sure if this is something I should be worried about, and whether I should instead model my data in a way where :author has a direct reference to all of its :characters Obviously this example is a bit contrived, but imagine we were working on a slightly larger scale (thousands of books per author, and thousands of characters per book)

cch116:01:14

My first recommendation is to not worry about “joins” in Datomic -they are vastly less expensive than in traditional relational databases. So traversing from author->book->character to get the characters by author is simple and easy using Datalog (for queries) and in the selector syntax (for pull).

Albert Dorfman16:01:02

Got it, thanks! Are there any datomic docs/benchmarks or discussions on this? Would be nice to find something concrete that I could show my team

cch117:01:07

You might find some reassurance in reading design docs around Clojure -there are only ~4 indices (give or take one IIRC) and joins are never going to tradeoff indexing versus performance. Secondly, look at the design of Datomic’s query language, Datalog. Understanding Datalog will go a long way to showing “The Way” for joins in queries and appreciate how absolutely banal they are in Datomic.

Linus Ericsson21:01:31

If this would be a serious performance problem later on, you could keep an in-process-memory index author -> character that keeps itself updated via the transaction log (at least if we are speaking on-prem). I highly doubt that it would be a problem.

Albert Dorfman22:01:24

Got it, thanks for the responses — much appreciated

2024-01-11

Channels