Clojurians Log v2

nil IS a value from Fulcro’s perspective. You are literally saying “this value is nil”…which means it should overwrite in the db

NOT missing

If the server has no opinion of the value of a prop, then it should not return the key. By including the key the server is making an assertion that IT KNOWS the value to be nil, and is therefore not “missing”…it’s nil

But also if the client ASKED for it and the server doesn’t include it, the opinion is that the value was asked for and not received, and therefore should be removed

See the merge documentation in the book. This was very carefully designed to do the “best” it could do with information provided in a distributed system sense.

Yeah what you are saying is consistent with what I would expect as well, but what I get is that when the value of a key is nil the nil value is replaced by this ::not-found

in the final db?

that should be swept

mark-missing does that, and then a final sweep stage removes the keys.

normalization can cause overwrites as it progresses, so that’s why it is in stages

In the network response the value is nil but then in the app db it's gone

so it's actually the step that saves to app db that is losing the value

query is: [:dialogue.session/id ... :dialogue.session/evaluation {:dialogue.session/messages (comp/get-query DialogueMessage)}] and for DialogueMessage: [:dialogue.message/id :dialogue.message/role :dialogue.message/topic-id :dialogue.message/created-at :dialogue.message/text :dialogue.message/image-urls]

but isn’t that what you expect?

value is nil means the server has no value

Think over time: time 1 - you had a value time 2 - you don’t have the vlue (but you query for it) At time 2 my code is evaluating the following cases: • You asked for it • It didn’t arrive • I need to make sure that the value in the app db is no longer there • So, I dissoc the key I see this as “safe” because if the UI queries for the prop, it’ll be nil, so there’s no reason to store nil in the db.

In the api response it's nil

In fulcro inspect db it's gone:

in the defsc component it's ::not-found

That makes no sense to me

That would mean it's in db->tree... Are you using premerge?

@yenda1 did you get to the bottom of this? I'm running into the same thing. The response from the server is nil but in my component it shows up as :com.fulcrologic.fulcro.algorithms.merge/not-found. I am using pre-merge in the parent component and a Pathom placeholder like :>/stuff to spread an entity out across a few defsc's.

but the value is not missing, the value is nil , the server did return the value nil for that key. And the issue is that instead of being nil in the component, the value is then ::fulcro-merge/not-found In pathom when you return nil for a key it means the value was found and is nil, pathom stops searching for the value. not-found would be ::pco/unknown-value and pathom will keep trying other resolvers (if there is any)

Ah. I see. I’m not sure why not-found isn’t stripped by the post processing internally. I really don’t have time to diagnose that at the moment, but I would agree that the m/not-found keys should not be ending up in your client db.

You’re using straight vanilla df/load, network middleware, etc.?

They don't end up in the client db they end up in the components that query for it

props = Query(db)

so the MUST be in the db…or are you saying this is transient behavior

where you see them flash that value during normalization?

(like a render happens in the middle of the normalization/mark/sweep process)

data_fetch.cljc line 143 is the load processing. It marks missing, then processed the merge in a single swap, and the merge inside of that does the sweep. It should not be possible to see transient problems there (js is single-threaded…the merge/sweep happens in a single swap)

No we ended up checking for the value :com.fulcrologic.fulcro.algorithms.merge/not-found as a workaround because we ran out of time

This issue and how to deal with missing entities are the 2 dark passengers in our project, they occasionally resurface as the root cause of bugs

Thanks. I went with the workaround too because I couldn't figure it out within the time box.