Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Cursors #34

Open
jb55 opened this issue May 20, 2024 · 0 comments
Open

Cursors #34

jb55 opened this issue May 20, 2024 · 0 comments
Assignees

Comments

@jb55
Copy link
Contributor

jb55 commented May 20, 2024

We should support cursor queries. These don't return results in one-shot, but allow you to stream results out incrementally.

This may simplify the design of:

So let's do this first

Goals

It would be nice to make a cursor "indexable" at the cost of extra memory. This is a memory of which indices have been visited:

operations: cursor_start, cursor_next, cursor_next

index    operation
---------------------
          cursor_start
a   
b
c
d       <-cursor_next
e
f
g       <-cursor_next
h

resulting indexable cursor memory:

cursor_index = [d, g]

cursor_at(0) => d
cursor_at(1) => g

cursor_jump_to(0) => d
cursor_next       => g

Indexable cursors would allow you to perform resumable and paginated queries in realtime. This will enable infinite scroll, you will also be able to index/seek into these queries at any point, which will be useful for building performant infinite timeline renderers: “render notes 5..8 in this cursor query”

Alternate approach

Alternately, we can simply add a function that gets the current index key from the cursor position:

data[] index_key = cursor_index()

this would allow us to save these keys in memory outside of nostrdb to create our own indexable cursor externally. This removes a lot of complexity (from nostrdb at least).

Let's say we did a query: {"kinds":[1]} and scrolled down to cursor index 10 with key A. We could close the transaction and save that index key. When we start scrolling again we can restart the query starting at A

Our virtual table renderer would see that we have cursor_index_key A saved at index 10 (the 11th result from the cursor query), When we try to render 11, we might notice we only have index 10, so we could resume the cursor query at index key A. This would enable resumable cursor queries, which should be able to implement everything we need?

We should only need to save at most one index key at the end of the scroll position, because all other entries are like what we have now in notedeck: it is simply an array of the indexed result (typically the note key). This is the index's value.

@jb55 jb55 changed the title Cursor api Cursors May 20, 2024
@jb55 jb55 moved this to In Progress in Damus Roadmap 🛣️ May 20, 2024
@jb55 jb55 self-assigned this May 20, 2024
@jb55 jb55 moved this from In Progress to Planned in Damus Roadmap 🛣️ May 24, 2024
@jb55 jb55 moved this from Planned to Backlog in Damus Roadmap 🛣️ Jun 10, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
Status: Backlog
Development

No branches or pull requests

1 participant