-
Notifications
You must be signed in to change notification settings - Fork 160
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
Proposal for range selectors #184
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
yeah, seems reasonable to me (I like the key renames too)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I like the general outline of this. The data seems still placeholder though? Does something run these fixtures yet? I'm guessing not, because the data looks like an outline and doesn't look like it would actually fly.
I think that if this was fully real and wired to a working test, I would probably expect to see the fixtures grow to...
- have some real (if small) content -- maybe just "abc" and "def" in the next chunk, etc
- the hashes would have to become real
- the size numbers, I guess, should become real as well
- the subset indices in the selector would presumably become a bit smaller if we're using short fixture data
- the visit probably looks totally different -- I'd expect this to yield one bytes node, wouldn't I?
- which blocks are loaded is a different matter; maybe we want to have a fixture hunk for that as well (but we'd want both this and the expected visit, because they're very dissimilar, and that is highly worth making visible).
Putting |
the fixtures are waiting for ipld/go-ipld-prime#376 to complete - we don't currently have a way to convert a dag from the unix-fs dag-pb standard format to the json format that fixtures expect. That said, this spec level change won't really be able to be evaluated for a bit still because we don't have a spec level definition of what 'unixfs' as an ADL does. |
agree that the visit will have 1 node (and that the current setup is less relevant for the traversal behavior of interest here.) |
Updated with a generated case of partial-selection over a unixfs file. |
That caveat is applicable indeed... but also with real data in it, this kinda presses some buttons in my brain labelled "gorgeous" :D |
Implement an optional `LargeBytesNode` for an `AsLargeBytes() (io.ReadSeeker, error)` method. This allows, per the [selector spec](ipld/ipld#184) the ability to efficiently traverse sub-ranges of ADLs.
This proposes a mechanism for selecting only a subset of a byte or string node that is an ADL over a larger number of nodes after reification.