Clojurians Log v2

is GC run after every merge?

no such thing

i thought there was something that crawls links and deletes data that has no links to it

how do I cleanup normalized data?

Nope, there is no way to not make that buggy.

if I merge data {:id 3 :foo {:id 4}} and it's normalized to {:x {3 ..} :y {4 ..} } and then I merge data {:id 3 :foo nil}

e.g. I have a list of users. I run a filter to show those that start with 'A'. Now my database only has links to a subset...do I clean those just because a "GC" runs?

how do I cleanup :y automatically

Untangled is not involved. It is your database.

ok, this makes me want to not normalize data 😞

so I don't have to deal with this pain

this is a trait of OM in general I understand

There is no free lunch in programming. What is a trait?

if you don't normalize data, then you have other more serious problems.

well there's some logic you have to write that is essentially checking if table is not referenced by any links, and seems like i have to write this over and over again for each situation that arises

like a search engine that loads search results

each search query loads new search results

so you have to cleanup after yourself

which search results are no longer referenced

So just clean the entire table as part of the query logic

in my example, each time the search query changes, I empty the search results table?

that is much simpler and more reliable than an automatic GC that you have to program

I mean, I guess you could write some kind of GC of your own...it is a simple algorithm if you make certain assumptions (e.g. no refs means cleanup, which isn't good enough for all apps, but might be ok for yours).

but unless you're worried about killing a javascript VM with data size, I would not even worry about it.

most apps don't have huge data sets, and js can have a pretty darn large memory footprint.

anyway...if you write GC, just transact on the reconciler once every 15 minutes or something.

"So just clean the entire table as part of the query logic" in my example this means in the search mutation, I empty the search-results table first before doing load-action ?

yep

i don't have time to write GC, for some reason I thought you wrote one 😄

i'll make do with the other methods

we have been writing pretty large apps, and have not found a need for general GC yet, nor is there a great way to solve it in general, as I said.

You could do things like mark tables with metadata (no-gc), etc.

but I don't tend to do work unless I need it 🙂

what about stale data interfering with newly merged data

anything to worry about there?

If you queried for it, it will overwrite it. How can it be stale?

Untangled does include logic to stomp on stuff that has disappeared (was queried for, but didn't appear)

but that is at an attribute level, not entity

(so a ref might disappear, but not the row in the table)

As I said: no way to be sure (from a library) that a given row in your database is gone, unless the application can prove it. Just because you don't have a UI ref to a user object doesn't mean it is "gone" in your application (might still be persisted on server).

Add in websockets and entity subscriptions with datomic: now we're talking

nods

but then you'd have to manage subscriptions 🙂

so it really just pushes the problem off by one step

leaking subscriptions instead of rows

i didn't normalize my search results and so far it's been fine

that's ok too

i'm using normalization on a case by case basis

"will it help me solve this problem"

if you don't need data in more than one place, it is perfectly acceptable to treat it as a blob

nodS

well, mutating it gets more complex and less modular...but if it is read-only search result data, who cares

I've got a UI that's not updating after a post-mutate after a data-fetch. Looking at the app-state, the data is there where I expect it to be. When I save a file and the react-key is updated, the data shows up in the right place. Any suggestions where I might look?

Something's not triggering a refresh, right?

@grzm try overriding shouldComponentUpdate to return true — see if that causes the re-render

if it does, then the issue is with om’s implementation of shouldComponentUpdate. we’ve seen the behavior before, isolated one case of it, but it’s possible we haven’t found all of them

@ethangracer: Thanks for the idea. I suspect it's more something in my particular application, and that this is just a symptom of something I've done wrong.

@grzm fair enough, I’ve run into that issue plenty of times. you’ve already verified that the data is showing up in your app state, meaning the network request completed. if the request completed and the data was put in your app-state, then the data fetch called merge! with your data on the reconciler. Which schedules a re-render through om. So if the re-render isn’t happening, it’s either because you haven’t included a necessary key in the :refresh parameter to load-data, or because something’s confusing om’s shouldComponentUpdate

Thanks. I'll definitely look into :refresh. I suspect that's it.