This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
- # admin-announcements (25)
- # beginners (21)
- # boot (487)
- # cider (8)
- # clara (2)
- # cljsrn (35)
- # clojure (44)
- # clojure-austin (6)
- # clojure-russia (211)
- # clojure-uk (25)
- # clojurescript (225)
- # core-matrix (1)
- # data-science (3)
- # datomic (23)
- # events (1)
- # hoplon (9)
- # immutant (14)
- # jobs (1)
- # jobs-discuss (5)
- # ldnclj (3)
- # lein-figwheel (2)
- # off-topic (2)
- # om (65)
- # onyx (65)
- # parinfer (3)
- # pedestal (4)
- # proton (1)
- # protorepl (1)
- # re-frame (16)
- # reagent (3)
- # ring-swagger (1)
- # specter (11)
- # untangled (1)
- # yada (8)
is there a good way to remove an entity’s components and assign new ones in the same transaction?
@wei I wrote a transaction fn which retracts the target entities except for a whitelist of lookup refs, and I use that in combination with the specs that add or update the "replacing" entitires
does datomic support connecting to a SQL store without using SSL? It seems like its passing ssl=<something> even if I leave ‘sql-driver-params’ blank or some innocuous
well, luckily postgres also has ‘sslmode=disable’, so I’ve fixed this with setting “sql-driver-params=sslmode=disable"
When setting up datomic with memcached. Is it preferable to have multiple nodes in the cluster?
This sounds like Datomic 101 but how do I add a child entity that relates back to a parent entity? For example a University has many Classes. I can add the university and the classes in a single transaction but I can’t add a single new Class to the existing classes. I’ve tried googling and looking through the Datomic docs but hit a wall. What’s the idiomatic way to do this?
@jamespw: If you're looking to add a class that belongs to a university, you need to get the university's entity from the database. You probably added classes to your university originally using something like
[:db/id (d/tempid :db.part/user) :class/university #db/id[:db.part/user -1]]. If your university is an existing entity
university-entity, you would add a class to it with
[:db/id (d/tempid :db.part/user) :class/university university-entity].
correct me if I am wrong, but if you have an unique attribute on the university, you can also use that right?
When I created the classes in the initial transaction I used the :university/classes relation and had a vector of classes, as I have a cardinality many ref type for :university/classes
so you can query datomic to find the entity id of each university, then use that entity id to add more classes
I have not used datomic very much, but if I recall correctly, if you have a unique attribute on a university like maybe
:university/name and you had already transacted a university named "Foo" if you do another transaction that contains something like
[#db/id[-1] :university/name "Foo"] the tempid will be resolved to the entity id of the already existing university with the name "Foo"
Is there a ‘belongs to’ association that’s auto created when I add the one to many ref? I can find the university name but when I try and add a new Class it just overwrites the existing one
@jamespw can you provide a code example of how how you’re trying to add a new class? If you’re working with entities for each, one mistake you might be making is retrieving a class entity and overwriting its attributes, rather than transacting a new class entity.
@bkamphaus: it’s very convenient to transact the schema and create the database every time my server process (re)starts. i’ve heard this is not best practice. do you agree? if so what are the specific bad things that will happen if you do this?
(d/create-database datomic-uri) (let [conn (d/connect datomic-uri)] @(d/transact conn schema))
@jdubie: I think it makes the most sense to use something like the approach in conformity - https://github.com/rkneufeld/conformity - where you ensure that schema (and entites, w/e) specified in e.g. an edn file are in the database in the form you specify, but don’t submit spurious transactions.
The create call is pretty much harmless. Additional schema transactions will generate empty transactions (i.e., if nothing to be done, won’t add any datoms apart from the transaction datom itself), so they're not completely idempotent.