Fork me on GitHub
#datomic
<
2016-11-25
>
robert-stuttaford06:11:01

@zane, why isn’t it performant? i can also think of a way to combine d/datom scans of eavt + vaet for an e, looking for the highest t

jonpither11:11:58

How does the Memcached setup work - can peers have their own memcached instances that would become warmed up to their needs, or is it a secondary level distributed cache that all peers would use the same way?

mitchelkuijpers12:11:49

Are there any people here who have some experience with saving money values in datomic? I am leaning towards bigint and then simply saving dollar values

karol.adamiec13:11:42

@mitchelkuijpers i went with using long/bigint and saving cents. Then for display just divide by 100 and attach currency symbol.

mitchelkuijpers13:11:16

Yeah that was also my plan, Not sure is a long is alway big enough that is the reason I am leaning towards bigint

karol.adamiec13:11:03

but i did what i did because of javascript compatibility. I would use decimal otherwise

robert-stuttaford13:11:41

@jonpither memcached as you need it. we connect everything to one cluster right now, but eventually backend webservers would have their own vs end-user webservers

robert-stuttaford13:11:14

advantage of one is that transactor pushes live index into the one it’s connected to

jonpither13:11:24

ok - let's say you did that, does the transactor still need to be aware of all the various memcacheds out there?

robert-stuttaford13:11:26

which turns memcached into the primary datastore and ddb the near-line backup 🙂

robert-stuttaford13:11:40

i know you can only give txor one. i presume that any other url given to a peer but not txor would essentially be a private 2nd tier for all who share it. e.g. @stuarthalloway mentioned having a memcached on his computer for a production transactor (so remote repl queries are faster)

jonpither14:11:34

so you can give a peer a memcached and not tell the transactor?

robert-stuttaford14:11:31

yes. you can give different memcached to different peers

robert-stuttaford14:11:21

transactor uses it as its own 2nd-tier cache (for the queries it does) and also writes live-index segments there. all other peers will use which ever they connect to as 2nd-tier cache. if it’s the same one for everyone, you obviously get leverage

jonpither14:11:06

cool - thanks

pesterhazy16:11:47

I'm working with a cardinality many ref. Does anyone have a transaction fn at hand that replaces all current refs with a new set?

karol.adamiec16:11:15

@pesterhazy haha, i had the same days ago

karol.adamiec16:11:29

in general i turned away from that solution

karol.adamiec16:11:58

and i do a built in fn for that :db.fn/retractEntity

karol.adamiec16:11:11

the function i tried to use before had issues ;/ but here it is:

;;DB function that allows to replace collection with a new (or empty ) colection
    {:db/id #db/id [:db.part/user]
     :db/ident :assertWithRetracts
     :db/fn #db/fn {:lang "clojure"
                :params [db e a vs]
                :code "(vals (into (into {} (map (comp #(vector % [:db/retract e a %]) first) (datomic.api/q [:find '?v :where [e a '?v]] db))) (into {} (map #(vector % [:db/add e a %]) vs))))"}}

karol.adamiec16:11:32

credit to google groups user….

marshall16:11:38

@jonpither you can give the transactor multiple memcached instances and it will push segments to all of them

pesterhazy16:11:28

my use case is I want to re-create all dependent entities and remove old ones in a single tx

pesterhazy16:11:59

ideally the caller shouldn't need to know the entids of the dependent entities

pesterhazy16:11:09

but obv not sure that this is the right approach

karol.adamiec16:11:11

if you mark dependants as isComponent they will be retracted

pesterhazy16:11:30

well I don't want to delete the original entity, only update it!

karol.adamiec16:11:32

well, i compromised on that 🙂. the origianl entity in my use case is not linked to anything other than owner, so it is ok for me

karol.adamiec16:11:03

try the fn i pasted, it works if you pass ID . I had problems with it working with tempids or lookup refs

pesterhazy16:11:28

@rauh, that looks great

pesterhazy16:11:12

code looks a bit scary

pesterhazy16:11:53

@rauh, could you give an example of how to use it?

pesterhazy16:11:07

the negative numbers in the gist refer to tempids?

pesterhazy16:11:51

and why do you have to supply a tempid and actual id for each value?

pesterhazy16:11:07

here's a simpler version:

(defn replace-refs [db e attr vs]
  (->> e
       (d/q [:find '[?v ...] :in '$ '?e :where ['?e attr '?v]] db)
       (map (fn [v] [:db/retract e attr v]))
       (concat (map (fn [v] [:db/add e attr v]) vs))))

rauh17:11:26

@pesterhazy There is an example in the doc string and just right afterwards is another one as a #_ comment

rauh17:11:41

Which you can run on the db (it will return you the transaction generated by the fn)

rauh17:11:06

If you already have all entities in your db, then you can nil the tempids, they won't be touched

rauh17:11:48

But it's flexible enough that you can add new entities at the same time.

jonpither17:11:48

managed to crash DT on a load-test - Exception: java.lang.OutOfMemoryError thrown from the UncaughtExceptionHandler in thread "hornetq-expiry-reaper-thread"

pesterhazy17:11:15

@rauh, thanks for the explanation

rauh18:11:48

@pesterhazy I've seen the simpler version of this too but decided to go with my own one. It'll properly work even if you specify idents, lookup-refs or entity ids. It'll also work when you :db/add an already existing entity (the above version would fail). And in addition if you add some new entity (with a tempid) you can ref that in the same transaction and assert it. It'll just work. With the simpler version you'd have to transact twice, making your transaction history less transparent on what happened. I did just simplify my gist a little bit.