-
Notifications
You must be signed in to change notification settings - Fork 276
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
[suggestion] Sort query results by metadata key #2553
Comments
yes, that's better IMO
de facto providing the client with a server side forward cursor that points somewhere within the snapshot? Any modifications made post query, but during the lifetime of the cursor won't be observed. I'm not sure this resolves the issue described |
actually, I've looked it up again. That should do it, it's a problem on our side that pagination isn't resumable. It should be resumable |
Overall looks good, but: One client can affect the sorting order of another client if we let clients generate a timestamp. My suggestion is to allow the client to only set a flag in the metadata that the new asset should contain a timestamp, but the timestamp will be generated on the server and inserted into the metadata. |
We should let clients define custom timestamps. This should be handled by the smartcontract infra. Letting people define different timestamps is a permission issue, not a problem of our algorithm. It is possible (likely) that in real cases being able to sub-sort by different parameters (other than timestamp) is desirable behaviour! |
Signed-off-by: Vladimir Pesterev <pesterev@pm.me>
Signed-off-by: Vladimir Pesterev <pesterev@pm.me>
Signed-off-by: Vladimir Pesterev <pesterev@pm.me>
Signed-off-by: Vladimir Pesterev <pesterev@pm.me>
Signed-off-by: Vladimir Pesterev <pesterev@pm.me>
Signed-off-by: Vladimir Pesterev <pesterev@pm.me>
Signed-off-by: Vladimir Pesterev <pesterev@pm.me>
Signed-off-by: Vladimir Pesterev <pesterev@pm.me>
Signed-off-by: Vladimir Pesterev <pesterev@pm.me>
Signed-off-by: Vladimir Pesterev <pesterev@pm.me>
Signed-off-by: Vladimir Pesterev <pesterev@pm.me>
Signed-off-by: Vladimir Pesterev <pesterev@pm.me>
Signed-off-by: Vladimir Pesterev <pesterev@pm.me>
Signed-off-by: Vladimir Pesterev <pesterev@pm.me>
Signed-off-by: Vladimir Pesterev <pesterev@pm.me>
Signed-off-by: Vladimir Pesterev <pesterev@pm.me>
Signed-off-by: Vladimir Pesterev <pesterev@pm.me>
Signed-off-by: Vladimir Pesterev <pesterev@pm.me>
Signed-off-by: Vladimir Pesterev <pesterev@pm.me>
Signed-off-by: Vladimir Pesterev <pesterev@pm.me>
Signed-off-by: Vladimir Pesterev <pesterev@pm.me>
Signed-off-by: Vladimir Pesterev <pesterev@pm.me>
Signed-off-by: Vladimir Pesterev <pesterev@pm.me>
Signed-off-by: Vladimir Pesterev <pesterev@pm.me>
Signed-off-by: Vladimir Pesterev <pesterev@pm.me>
Signed-off-by: Vladimir Pesterev <pesterev@pm.me>
Signed-off-by: Vladimir Pesterev <pesterev@pm.me>
Signed-off-by: Vladimir Pesterev <pesterev@pm.me> Signed-off-by: BAStos525 <jungle.vas@yandex.ru>
Signed-off-by: Vladimir Pesterev <pesterev@pm.me>
Signed-off-by: Vladimir Pesterev <pesterev@pm.me>
Signed-off-by: Vladimir Pesterev <pesterev@pm.me>
Signed-off-by: Vladimir Pesterev <pesterev@pm.me>
Signed-off-by: Vladimir Pesterev <pesterev@pm.me>
Signed-off-by: Vladimir Pesterev <pesterev@pm.me>
Feature request
Solving #2501 via #2515 rerquires us to store a timestamp for all assets. This doubles the memory overhead and increases the time complexity of all queries that can return multiple$O ( \log n)$ , where $n$ is the (usually large) number of assets over which we're paginating.
Asset
s orAssetId
s byMotivation
Instead, a better solution would be to allow sorting of arbitrary query results based off of the metadata in each element. We still get the near-doubling of RAM usage, and time complexity for the queries which request sorting is also affected, however:
Who can help?
@pesterev @Anrdey
The text was updated successfully, but these errors were encountered: