Fork me on GitHub
#datomic
<
2017-02-23
>
alex-glv10:02:53

Hello, datomic-ers!

alex-glv10:02:34

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!

pesterhazy10:02:45

yeah that's a common pattern but I don't think there's a consensus answer

pesterhazy10:02:00

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)

pesterhazy10:02:18

- 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

pesterhazy10:02:43

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

val_waeselynck10:02:14

(will answer it when I have better explored all the options)

alex-glv10:02:24

Didn’t realise it wasn’t very trivial! Will read up. @pesterhazy didn’t know about transactor fns, thanks.

pesterhazy10:02:12

@val_waeselynck could you make a gist out of that? Slack is so forgetful

pesterhazy10:02:45

if you don't wrap this in a transactor fn, it can lead to race conditions though, no?

robert-stuttaford10:02:48

this works with any values, but assumes you’re providing ids for refs

pesterhazy10:02:11

which is okay IMO in many circumstances but not all

val_waeselynck10:02:39

@pesterhazy race conditions don't matter much with "reset" semantics

val_waeselynck11:02:19

oh well I see what you mean

pesterhazy11:02:01

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

pesterhazy11:02:46

something like that anyway...

val_waeselynck11:02:04

yeah totally, what I mean is when you implement reset semantics you usually expect that users won't access the resource concurrently 🙂

pesterhazy11:02:07

when you add/remove tags to a product, that may not matter really

alex-glv11:02:24

actually atomic retract and add seems even better, more network calls but oh well

val_waeselynck11:02:03

@alex-glv yeah if you're architecture is compatible with that, it's better to do it this way.

alex-glv11:02:41

awesome, thanks!

rauh11:02:24

@alex-glv Here is another version:

jdkealy22:02:40

is it possible to save a hashmap in datomic ?

devth22:02:25

if you serialize it

devth22:02:52

or if all the keys in the map already existed in the schema

jdkealy22:02:54

so save it as text ?

devth22:02:10

yeah, (pr-str your-map)

jdkealy22:02:14

and what if all the keys in the map existed in the schema

jdkealy22:02:26

would it have to be a component ?

devth22:02:34

then you could transact it as-is

devth22:02:02

component only applies if it's nested, but even then i think it'd be optional

devth22:02:47

(i'm also curious if there are ideas for better ways of storing arbitrary data structures)

jdkealy22:02:58

my data looks like :user/permissions {:can_edit_galleries {:global? true}, :can_create_galleries {:photo_credit "jdkealy"}}

devth22:02:27

if your structure is well-known ahead of time i'd represent it with a schema

jdkealy22:02:54

what i have been doing is mapping that and transforming into :user/permissions [{:permission/type :can_edit_galleries, :permission/is_global? true}]

jdkealy22:02:27

right yeah that makes sense... for all its failings, i did enjoy this feature of mongo

jdkealy22:02:08

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

devth22:02:42

i assume you've already read Nested maps in transactions in http://docs.datomic.com/transactions.html

devth22:02:11

do the work upfront to define the schema, then you can transact deeply nested maps