This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
- # admin-announcements (22)
- # beginners (15)
- # boot (38)
- # cider (16)
- # clojure (68)
- # clojure-android (1)
- # clojure-berlin (27)
- # clojure-japan (7)
- # clojure-nl (7)
- # clojure-poland (2)
- # clojure-russia (164)
- # clojure-uk (2)
- # clojurescript (321)
- # datomic (42)
- # editors (45)
- # events (4)
- # indycljs (2)
- # jobs (7)
- # ldnclj (7)
- # liberator (4)
- # off-topic (29)
- # om (5)
- # onyx (8)
- # re-frame (6)
- # reagent (44)
- # slack-help (9)
Do people using Datomic in Clojure projects usually run a separate Datomic instance for development or do you use an in-process version?
bin/maven-install script (and maybe others) don’t have a
#!/bin/sh — maybe a good idea to add it?
If you upgrade Datomic moving a db from old to new is done by backup & restore basically?
several times they've changed the format of what's in storage and done that via code in the transactor, which means no backup/restore
one thing to note for the memory db is that it’s sufficient for testing ACI but not D aspects of Datomic's ACID semantics. I.e., it has no log, which underlies durability in Datomic.
so you’ll need e.g. local dev storage if you have any testing around Log API, excise, etc.
Regarding a question I asked a few days ago about schema declaration: What do you think of using transaction functions to make declaring schema attributes less tedious? Here's a POC: https://gist.github.com/vvvvalvalval/fe16f475b1656f28d4b8
the use case is a matter of opinion I’ll stay out of but re: making it a transaction function, in general I would avoid tx functions in cases where you don’t need transaction-time access to the database value.
@val_waeselynck less “going wrong” and more about best fit. Data munging (producing a schema attr map from defaults/terse names) makes sense to me as library/API code. Transaction functions (the occasional dorky illustrative example aside) are really about enabling logic at transaction time that ensures valid transitions between state a la ACID isolation (using serialized writes as the mechanism), i.e. adding/subtracting from a balance.
there are use cases for validation or helper functions that make sense as tx functions, b/c they would require transaction-time access to the db value
you can run into issues by over-relying on transaction functions, mainly perf issues since tx function logic is performed in serial, a few commonly used tx functions w/non trivial perf characteristics can tank the throughput of a system
The thing is, in this case, the code has 2 purposes: being processed by the database (data) and being a reference for the application developer (which makes it a big deal to reduce noise)
@val_waeselynck @bkamphaus I'd utter some things about the suitability of abstracting away schema as well. Whilst the default definition is relatively verbose, it's easy to understand for the most part. I'd worry about losing that by moving to a more terse syntax.
As for the fact that it does not use transaction-time access to the database, I don't really see it as a problem. The documentation itself says other uses for database functions may yet be found. http://docs.datomic.com/database-functions.html
Also, depends on your app, but I think in most apps schema changes are relatively rare, and so making them easier isn't a good economic tradeoff (at least for the apps I've worked on)
@tcrayford: maybe if you have a very good memory but I often find myself consulting my schema declarations quite often e.g to remember attribute names.
@bkamphaus: I do note your point about not mixing library code with data though
val: a dev-time dev/user.clj fn that prints out all your schema should save you some time
@robert-stuttaford: before cursive, I had a keybinding that "autocompleted" schema attributes (easy to wire up with ido-mode or similar)
definitely agree with keeping schema simple: data. dsls are nice for writing it, but that’s about it. you lose when you stop keeping it as data. we use .edns with plain datomic schema defs
Mmmh still can't think of a situation where this goes wrong. I think I'll be dumbly stubborn and tell you what happens when it gets ugly.
@robert-stuttaford: do you have an example of such helper? would you mind posting the code?
Something like this should work for grabbing schema, we have a java example as well: https://github.com/Datomic/datomic-java-examples/blob/master/src/PrintSchema.java
(let [db (d/db conn)] (clojure.pprint/pprint (map #(->> % (d/entity db) d/touch) (d/q '[:find [?a ...] :where [_ :db.install/attribute ?a]] db))))