Sort nodes by "crated-at" time in node iterator, latest first

[akindyakov]

Resolves: #431

Root task : #351

Problem

Fragments in truthsayer feed are always ordered by creation date, for that node iterator should return them already ordered.

If nodes are created always "late after early", the existing code works. But, when browser history bootstrap engaged OR sync from date centre to local storage engaged, nodes are added at arbitrary order. Thus nodes in search grid are ordered incorrectly.

Solution

For that I had to change the structure of all-nids "lav" a little, using structure there that includes nid and additional fields, that are used to re-order nodes by. Right now, there is only one "sort by" field - created_at, a time stamp of node creation. Every time, when "all-nids" are requested, returned nids are sorted by created_at time.

Alternative solution

...that I've considered and decided not to implement: creation a separate index yek - lav for creation date. This way, all-nids are not ordered but at the creation of iterator, we'd fetch creation date for each nide using index nid-> created_at. Thus there will be N + 1 async calls for each creation of iterator, which is quite slow, I'm afraid.

[SergNikitin]

Nice, thank you!!! Just FYI - this will mess up whatever you have stored in local storage already, hopefully nothing super-important 😅 I wonder if I should turn all the values in the store into {...} objects so this kind of change is easier later on

[akindyakov]

this will mess up whatever you have stored in local storage already, hopefully nothing super-important 😅

This is a very good point, thanks for pointing it out! What if I make "sync" in #429 two side door - in local mode it would copy nodes from datacentre to local storage and vice versa. So we can do the following to preserve currently locally stored nodes:

1. Land truthsayer
2. Upload locally stored nodes to data centre
3. Land archaeologist
4. Download nodes from data centre to local storage

I wonder if I should turn all the values in the store into {...} objects so this kind of change is easier later on

Yes, I think it's very good idea

[akindyakov]

This is a very good point, thanks for pointing it out! What if I make "sync" in #429 two side door - in local mode it would copy nodes from datacentre to local storage and vice versa. So we can do the following to preserve currently locally stored nodes

Ah, backward sync from local storage to data centre is much more difficult to implement. Doesn't worth it, I believe. Let's drop those cards and live with it then 😅 (local mode is available for 3 of us only anyway)