Extended search with attributes returned #306
Labels
Milestone
Comments
roman-khimov
added
U4
|
By "FIELD" I mean attribute key, of course. |
roman-khimov
added a commit
that referenced
this issue
Dec 18, 2024
1. Additional fields allow to avoid HEADs in most cases since applications tend to use 1-2 fields to choose between results/check for flags and pick the object they want to GET. Or they just want to have some fields to display object list, but they don't need a full HEAD. 2. Sorting is critical here, absent sorting we can't limit reply in number of elements returned and we can't have cursors to continue search. 3. Limits on number of returned elements allow to use single message instead of a stream. 4M of the default message fits 256 full-sized 16K headers and we expect just a few attributes in fact, so 1000 elements shouldn't be a problem. 4. We can't go backwards with the order easily, so this is omitted for now. Signed-off-by: Roman Khimov <[email protected]>
roman-khimov
added a commit
that referenced
this issue
Dec 23, 2024
1. Additional fields allow to avoid HEADs in most cases since applications tend to use 1-2 fields to choose between results/check for flags and pick the object they want to GET. Or they just want to have some fields to display object list, but they don't need a full HEAD. 2. Sorting is critical here, absent sorting we can't limit reply in number of elements returned and we can't have cursors to continue search. 3. Limits on number of returned elements allow to use single message instead of a stream. 4M of the default message fits 256 full-sized 16K headers and we expect just a few attributes in fact, so 1000 elements shouldn't be a problem. 4. We can't go backwards with the order easily, so this is omitted for now. Signed-off-by: Roman Khimov <[email protected]>
cthulhu-rider
added a commit
that referenced
this issue
Feb 13, 2025
A bit more to cover current NeoFS S3 gateway needs. Refs #306. Signed-off-by: Leonard Lyubich <[email protected]>
cthulhu-rider
added a commit
that referenced
this issue
Feb 13, 2025
A bit more to cover current NeoFS S3 gateway needs. Refs #306. Signed-off-by: Leonard Lyubich <[email protected]>
cthulhu-rider
added a commit
that referenced
this issue
Feb 18, 2025
Without this, it makes almost impossible to make proper inter-node merge-sort and continuation. Since not all matchers allow understanding the primary attribute's value, compliance with the presented requirement is in demand. Refs #306. Signed-off-by: Leonard Lyubich <[email protected]>
cthulhu-rider
added a commit
that referenced
this issue
Feb 18, 2025
Without this, it makes almost impossible to make proper inter-node merge-sort and continuation. Since not all matchers allow understanding the primary attribute's value, compliance with the presented requirement is in demand. Refs #306. Signed-off-by: Leonard Lyubich <[email protected]>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Is your feature request related to a problem? Please describe.
I'm always frustrated when we can't have something like
ORDER BYin our searches. It'd simplify nspcc-dev/neo-go#3496 greatly, but:Describe the solution you'd like
We can extend search result with attributes if they're requested. It can be different from "ORDER BY", something like "WITH FIELD", but the result would be
[]{oid, []attributeValue}(ordered by requested attributes) instead of[]oid. Then the request originator can do anything it wants with these fields including ordering or choosing the most appropriate version of an object (REST).Describe alternatives you've considered
Dunno. Currently it's just an idea.
The text was updated successfully, but these errors were encountered: