This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2017-02-23
Channels
- # aws-lambda (1)
- # beginners (11)
- # boot (456)
- # cider (3)
- # cljsrn (7)
- # clojure (340)
- # clojure-berlin (6)
- # clojure-dev (207)
- # clojure-germany (12)
- # clojure-greece (3)
- # clojure-italy (3)
- # clojure-russia (12)
- # clojure-spec (42)
- # clojure-uk (29)
- # clojured (7)
- # clojurescript (125)
- # datascript (1)
- # datomic (47)
- # defnpodcast (4)
- # emacs (30)
- # events (7)
- # hoplon (13)
- # instaparse (64)
- # jobs (13)
- # jobs-discuss (1)
- # lein-figwheel (1)
- # leiningen (10)
- # luminus (1)
- # lumo (14)
- # off-topic (10)
- # om (16)
- # om-next (3)
- # onyx (1)
- # pedestal (3)
- # protorepl (5)
- # re-frame (17)
- # reagent (66)
- # ring (1)
- # ring-swagger (13)
- # spacemacs (12)
- # specter (4)
- # untangled (272)
- # vim (4)
- # yada (24)
@marshall just wanted to make sure you'd seen this question: https://groups.google.com/forum/#!topic/datomic/d74excL8JaI
I have a question. Fooling around with Datomic tx-es and trying to translate SQLish concepts.. I have a :job/tasks , that is cardinality - many, references to “task” entity. When my front-end updates, I want to completely wipe current references and update with new ones. (if I just transact new references they add up, instead of replace). Any suggestion how to do it? I tried :db/retract, but don’t want to remove existing references knowing what they are, basically, I don’t care. Thanks!
yeah that's a common pattern but I don't think there's a consensus answer
things you can do: - remember previous values and retract them (easy, may lead to race conditions) - create a transactor fn that replaces all values for a cardinality/many attribute atomically (safer)
- store the set of tasks in a separate entity (task-set) and store a ref to the task-set in a the job, then simply replace the ref and recreate a taskset every time
if you go with 2 (seems cleanest), you'll need to do a diff as you can't retract and add the same fact in a single transaction
@alex-glv related: http://stackoverflow.com/questions/42112557/datomic-schema-for-a-to-many-relationship-with-a-reset-operation
(will answer it when I have better explored all the options)
Didn’t realise it wasn’t very trivial! Will read up. @pesterhazy didn’t know about transactor fns, thanks.
@val_waeselynck could you make a gist out of that? Slack is so forgetful
@pesterhazy sure https://gist.github.com/vvvvalvalval/4f1736fab9b4ab0e3e03b805ad35a78c
@val_waeselynck @pesterhazy i took a simpler approach
if you don't wrap this in a transactor fn, it can lead to race conditions though, no?
this works with any values, but assumes you’re providing ids for refs
which is okay IMO in many circumstances but not all
@pesterhazy race conditions don't matter much with "reset" semantics
oh well I see what you mean
alright
user A could set jobs to 1 2
and user B could set it to 3 4
, but it could end up 1 2 3
something like that anyway...
yeah totally, what I mean is when you implement reset semantics you usually expect that users won't access the resource concurrently 🙂
when you add/remove tags to a product, that may not matter really
@alex-glv yeah if you're architecture is compatible with that, it's better to do it this way.
(i'm also curious if there are ideas for better ways of storing arbitrary data structures)
my data looks like :user/permissions {:can_edit_galleries {:global? true}, :can_create_galleries {:photo_credit "jdkealy"}}
what i have been doing is mapping that and transforming into :user/permissions [{:permission/type :can_edit_galleries, :permission/is_global? true}]
right yeah that makes sense... for all its failings, i did enjoy this feature of mongo
up until now.... i had been saving permissions as keywords in cardinality many, and now client needs metadata on the permissions, so i gotta make them refs... the nested refs are starting to make my head spin
i assume you've already read Nested maps in transactions
in http://docs.datomic.com/transactions.html