You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The simplest thing that we should implement first is filters. This would allow you to perform a nostr query, filtering notes based on arbitrary conditions.
The reason we want this inside the query engine is mainly for memory and efficiency reasons. If the query is acting across thousands of records, we shouldn't need to pull everything out of the database to act on it.
This becomes increasingly important in cursor queries, allowing you to filter as your query walks along an index.
Where filter is a nostrscript. Of course in nostrdb, we don't need to pass this in the filter itself, we can just pass it as an argument to the query. In the future this could be a wasm nostrscript.
We can use something like messagepack to pass this value back to the API consumer/client. This would allow the client to unpack the accumulated value, what the client does with that is up for them to decide and integrate into their UI.
Future: Environment?
Maybe these nostrscripts read and write to some environment. This would allow query algorithms to change over time. This is probably out of scope of nostrdb, maybe this environment can be configured by the client.
The text was updated successfully, but these errors were encountered:
To enable algorithms and aggregation queries, we need a new concept: filters and reducers.
We should implement cursors first as it may simplify this design:
Filters
The simplest thing that we should implement first is filters. This would allow you to perform a nostr query, filtering notes based on arbitrary conditions.
The reason we want this inside the query engine is mainly for memory and efficiency reasons. If the query is acting across thousands of records, we shouldn't need to pull everything out of the database to act on it.
This becomes increasingly important in cursor queries, allowing you to filter as your query walks along an index.
Example
An example filter query could be (in pseudocode):
Where
filter
is a nostrscript. Of course in nostrdb, we don't need to pass this in the filter itself, we can just pass it as an argument to the query. In the future this could be a wasm nostrscript.Reducers/Folds
See: https://en.wikipedia.org/wiki/Fold_(higher-order_function)
An even more powerful concept is allowing reducers instead of a filter. Reducer allow you to accumulate a value during a query. For example:
This would implement a count of the number of kind 1 notes in your database.
you can implement a filter from a reducer, so it is more general:
Encoding
We can use something like messagepack to pass this value back to the API consumer/client. This would allow the client to unpack the accumulated value, what the client does with that is up for them to decide and integrate into their UI.
Future: Environment?
Maybe these nostrscripts read and write to some environment. This would allow query algorithms to change over time. This is probably out of scope of nostrdb, maybe this environment can be configured by the client.
The text was updated successfully, but these errors were encountered: