Fork me on GitHub
#untangled
<
2016-09-28
>
tony.kay17:09:40

I seem to have gotten the travis CI build of U.C. working better. I reduced the memory footprint of the JVM instances and made sure all of the versions of things used to run the automated tests were up to date, and that hopefully has solved the erratic failures on running the browser that runs the tests.

ethangracer21:09:35

It’s looking to me like load-data is deleting fields on subsequent queries with fewer keywords. e.g. if I first call (load-data [:several :keys {:with [:some :joins]}]), and later I call (load-data [:several :keys]), then the data under the :with key is gone. has anyone else seen the same behavior?

ethangracer21:09:27

doesn’t seem appropriate to me since I might want to update the data at :several and :keys but not another key

tony.kay21:09:56

mmmm...I would be very surprised if that is the case

tony.kay21:09:05

there is no memory of the prior

tony.kay21:09:03

I have a feeling you've got some other bug...perhaps in a post mutation?

ethangracer21:09:33

@tony.kay thought it might be a post-mutation but I’m sure it isn't

ethangracer21:09:12

it definitely could be some other bug

ethangracer21:09:38

but the data for all fields not specified in the second load is gone

tony.kay21:09:54

do they have some similar root?

tony.kay21:09:13

are you using get-query so the normalization will work?

tony.kay21:09:26

what else are you not including in your description?

ethangracer21:09:15

yes to using get-query

ethangracer21:09:22

not sure what you mean by similar root

tony.kay21:09:34

is an ident involved?

ethangracer21:09:36

I don’t think I’m excluding anything relevant

ethangracer21:09:42

yes, normalization is involved

tony.kay21:09:54

not the same

ethangracer21:09:15

I have a survey that is already normalized in app-state

ethangracer21:09:41

then i’m pulling down a survey request, which itself pulls down certain details about that survey

ethangracer21:09:25

the already normalized survey data is a superset of the survey data pulled down with the request

ethangracer21:09:44

but all of that survey data uses the same ident, because both refer to the same survey

ethangracer21:09:32

by the time the post-mutation runs, the data is already incorrect

tony.kay21:09:11

ah, so you're saying the merge is stomping on the object

ethangracer21:09:17

seems that way

tony.kay21:09:21

instead of recursively merging into it

ethangracer21:09:32

that’s my running hypothesis

ethangracer21:09:40

having a hard time tracking it down

tony.kay21:09:09

merge-idents is a separate step in the low level Om merge. I'm trying to remember if we override that or just the general data merge

tony.kay21:09:25

oh, but you're using load-data, so there isn't a rooted ident in the query

tony.kay21:09:44

it is possible it is a bug in the sweep merge

tony.kay21:09:58

which , of course, is the most complicated bit of code in untangled

ethangracer21:09:13

aaah, that would make a lot of sense

tony.kay21:09:15

it has a set of tests...you might beef them up and see if you uncover badness

ethangracer21:09:21

if it marks keys as missing

tony.kay21:09:27

do you remember the basics of the algorithm?

ethangracer21:09:39

I’m not sure I ever bothered to learn it 😬

ethangracer21:09:46

I probably should

tony.kay21:09:15

well, it is a bit involved...here is the basic idea: 1. It uses the query AND the result 2. It follows both through the recursive logic or the query and structure of the data 3. If something is asked for in Q and not in R, then it is marked as missing 4. It if is asked for in Q and IS in R, it should pick the proper merge (or recursive step)

tony.kay21:09:56

Then after the merge runs, a sweep step removes everything marked missing

tony.kay21:09:38

so if you ask [:a {:b [:c]}] with response {:a 1 :b { :c 2} }

tony.kay21:09:10

it will look at key :a in query while looking for a value in result (1).

tony.kay21:09:29

then it will look at join on :b while looking at the value in R at :b

tony.kay21:09:43

of course, T (the target) is involved too

ethangracer21:09:03

shouldn’t this all happen before looking at the app-state?

ethangracer21:09:10

and then just do a deep merge?

tony.kay21:09:10

@adambros wrote the algorithm, so if you find a problem, it might be best to get his help

tony.kay21:09:39

yeah...I may not be remembering exactly how it works 😜

ethangracer21:09:50

well I think you’re right

tony.kay21:09:52

it has to use the query and the result

ethangracer21:09:58

it is definitely deleting stuff from the app state

ethangracer21:09:00

but it shouldn’t be

ethangracer21:09:05

only from the remote result

tony.kay21:09:07

I designed the algorithm on a white board and Anthony implemented it

ethangracer21:09:21

i’ll take the plunge and see what I can figure out

tony.kay21:09:33

welcome. I'd start with tests using your scenario

ethangracer21:09:40

sounds good to me

adambrosio23:09:05

im running into an issue where when i get a 401 i have a network-error-callback that redirects to the logout page but for some reason it gets into an infinite loop when i go to a page that does a load-field BUT i can get out of the loop when i switch to a different tab and it does the logout correctly any ideas?