Fork me on GitHub
#datomic
<
2017-12-27
>
gcast18:12:53

Does anyone know how datomic handles repeated :db/add transactions on an attribute that is cardinality one.

favila18:12:36

it automatically :db/retracts what is there

favila18:12:03

but you can't :db/add twice in the same transaction, that will produce a datom conflict

gcast19:12:00

gotcha. See thats what I thought too, but then I did a index query for datoms with that attribute that had been retracted (using .added) and it found nothing

favila19:12:53

unless you use a history db, datoms will never see any retractions

favila19:12:32

normal (non-history) dbs only contain assertions

gcast19:12:42

ok got it. thank you

timgilbert19:12:48

Say, are the datomic client libraries available on clojars or anywhere? Trying to write a little open-source datomic utility and I’m not sure what I should tell users about what to do about the libraries

timgilbert20:12:50

I suppose I’ll just instruct them to use bin/maven-install from the datomic distribution, that seems simple enough

favila20:12:58

I always make datomic a :provided dependency

favila20:12:11

(this only works for libraries though)

favila20:12:34

you can include datomic as a maven dependency

favila20:12:04

instructions are at the top of your datomic account page: https://my.datomic.com/account

favila20:12:14

but you obviously can't share that key

sova20:12:50

Hi I was wondering something. How do I commit to datomic elements with cardinality many?

sova20:12:00

iterate over them and commit them one by one? o.o

sova20:12:13

maybe this is where my procedural software brain still doesn't grok FP

sova21:12:12

in my case users can provide a comma separated list of tags, i want to commit them all to the same "blurb" entity in the db. but a commit I can only do one element right? i want to commit many independent tags (with contributing user id) as cardinality many so I can keep track of who submitted which tag (and award verification/participation points)

sova21:12:58

hopefully my question makes sense. i am still kinda puzzled by how to resolve temporary IDs if I were to do a commit for the blurb contents and stuff and then subsequent commit for tag/val and tag/author and tag/blurb

favila21:12:33

Your transaction can do arbitrary things, there is no "one element" restriction

sova22:12:39

that is a simple statement and helps.

sova22:12:45

more study required on my part

sova23:12:58

does that mean i can transact a vector and search against the set? that's what i want to do essentially

val_waeselynck04:12:24

@ it would probably be easier for us to help if you gave us a sample schema and expected query results :)