@anmonteiro I think I have hit a bug in om server side denormalization. Could you confirm that I am not mistaken? I’ll log an issue as soon as I know it’s not my brain that has a bug. https://gist.github.com/stevebuik/665511e028295f422ce21f2596b77c3a

@steveb8n: looks like a bug, but I don't have access to a computer right now to try it out

ok thanks. I’ll create an issue. thanks for the verification. It’s not urgent for me, I can work around it

Does it work in ClojureScript?

haven’t tried in cljs. will do that and will update the issue

@steveb8n: awesome, thanks. I'll take a look later

@anmonteiro same in cljs. I have updated the gist and issue. https://github.com/omcljs/om/issues/802

@steveb8n thanks, looking into it now

@steveb8n https://github.com/omcljs/om/pull/803

Good morning! If I’m performing a mutation followed by a read in a transaction (against my server) and the mutation stores something in datomic, is there a way to shuttle the new db value along to the next (in this case, read) parser method? Looking at the implementation of the parser step function, there doesn’t seem to be any accumulation of results visible to each mutate/read parser method.

specifically, I’m using pedestal and my only option right now is to acquire a new DB value, which is suboptimal bc concurrency + consistency + independent read impls that can be composed in various ways. 😄

@solussd so this is on the server right?

right

since you call the parser directly in your server handler with the mutation, you can add a key to env which represents the DB value

let’s say it’s an atom or a volatile. Whenever you perform the mutation, you can swap! that key with the db-after and have it available in the read

but env is closed over by the step function- not accumulating values as the reduction progresses

ah

@solussd wouldn’t that work?

yes, it would, though it feels a little hacky.

It does feel a little hacky 🙂

I've used a similar solution for handling dependent mutations on the remote, it's worked well

but then, I can’t think of a reasonable way to merge mutation action fn results at each step

I don’t even know that would be desirable

right

it would be good for your use case, but maybe not for others where you want to perform mutations in “isolation"

Maybe it would make sense for the parser to carry both the state reference and the immutable state value in the env, and then use the return value of the action as the new state value for the next key

I've always thought it was odd to have to deref the state in a read anyhow

Oh, I see, does the parser currently collect the actions before running any of them?

@peeja I don’t think so, it runs them as it sees them

Ah, then that could work, right?

yeah, but at what cost?

then mutations and reads wouldn’t really have the same “interface” (in reads the state wouldn’t be an atom)

that has been a goal since the beginning

Right, I'm saying they both get both

OK so then what for?

you can get one by derefing the other

Everyone gets the connection/atom, as well as the current value

You can't, though, not in datomic

oh you’re speaking about the server

Getting the latest db from the connection isn't necessarily the same as the db you got from your last transaction

Yeah, it's only necessary on the server, but only because JS is single-threaded

but it makes sense for both, I think

Yeah I get it, I was confusing things

I can see how that would be useful

but: it’s possible to solve in userland and would probably introduce Datomic-specific code

not something you can reuse if you’re talking to other DBs

I've always thought that derefing the state for each key felt weird, and that you should only really deref it at the start, in the case of all-reads

Shouldn't be Datomic-specific

If you expect the result of the action to be the new state value, that works in any system

no that’s not right

(You still need to define how you get the value from the state reference at the beginning, but that seems doable)

there can be no result from an action

?

you can do a mutation for side-effects only

and what’s the “app state” in the server?

in Datomic I can see it could be a database

The db value

Right, it doesn't necessarily exist

but if you’re using other DBs, you’ve only got a connection

but you don't need to do it this way

It would be backwards compatible with the current way

I'm saying it would be nice for Om to take advantage of immutable DB values when you have them, such as in Datomic, and with either the default DB format or Datascript

@dnolen should be OK to merge these in, no? https://github.com/omcljs/om/pull/790 https://github.com/omcljs/om/pull/788

just minor refactoring & an added invariant

@anmonteiro yes will get to those later

cool