-
Notifications
You must be signed in to change notification settings - Fork 10
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
feat: add support for sync car reading #121
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.
Other than interface for the sync reader everything looks good to me, although I did provide some additional feedback which you can address or disregard as you find fit.
Please add a sync interface though, or if you really disagree let's find a compromise.
src/reader-browser.js
Outdated
* @param {Uint8Array} bytes | ||
* @returns {CarReader} blip blop | ||
*/ | ||
static fromBytesSync (bytes) { |
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 think it might be a good idea to align naming convention with https://github.com/ipld/js-car/blob/master/src/buffer-writer.js which is same idea but a writer interface.
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.
what do you means ?
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.
Things like CarBufferReader
as opposed to CarReaderSync
, same thing for method names and stuff.
src/reader-browser.js
Outdated
@@ -139,6 +140,22 @@ export class CarReader { | |||
} | |||
} | |||
|
|||
/** | |||
* |
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 think it should say something about the fact that no verification occurs with this reader, meaning that block that follows CID may not in fact have that CID.
src/reader-sync-browser.js
Outdated
this._header = header | ||
this._blocks = blocks | ||
this._keys = blocks.map((b) => b.cid.toString()) | ||
} |
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.
Can we have a method to perform verification that will verify that blocks match claimed CIDs ?
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.
@Gozala this would be worthwhile but needs to be an option and should be tackled in a separate PR. Opened an issue here and it'd be great if someone could pick this off: #123
As noted there, this requires having the hashers available to do the validation, which is always a problem in JS—what do you do if someone shows up with blake2b CIDs?
Also worth having notes in the README, although pretty much all of the JS stack doesn't perform this kind of validation, so there's a bit of a caveat emptor all round on that front unfortunately.
I'm not sure As long as the 3 of you agree on the details don't let me be a blocker, other than the desire for decent docs. |
i was able to make |
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.
There's so many small things here I'm not even sure I got all of them.
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.
Just a few minor problems but I think nothing blocking...🚀
README.md
Outdated
- [`CarBufferReader.fromBytes(bytes)`](#carbufferreaderfrombytesbytes) | ||
- [`CarBufferReader.readRaw(fd, blockIndex)`](#carbufferreaderreadrawfd-blockindex) | ||
- [License](#license) | ||
- [Contribution](#contribution) |
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.
This is just the API listing not the ToC for the whole README...
src/buffer-reader-browser.js
Outdated
* @returns {boolean} | ||
*/ | ||
has (key) { | ||
return Boolean(this._cids.find((cid) => cid.equals(key))) |
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.
return Boolean(this._cids.find((cid) => cid.equals(key))) | |
return this._blocks.some(b => b.cid.equals(key)) |
src/buffer-reader-browser.js
Outdated
const index = this._keys.indexOf(key.toString()) | ||
return index > -1 ? this._blocks[index] : undefined |
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.
Why not just find the block?
const index = this._keys.indexOf(key.toString()) | |
return index > -1 ? this._blocks[index] : undefined | |
return this_blocks.find(b -> b.cid.equals(key)) |
src/buffer-reader-browser.js
Outdated
this._header = header | ||
this._blocks = blocks | ||
this._keys = blocks.map((b) => b.cid.toString()) | ||
this._cids = this._blocks.map(b => b.cid) |
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'm not sure I understand the benefit of _keys
and _cids
, or why in has
we do .equals()
and in get
we do a string comparison?
I guess this._cids
is so we don't have to recompute the array every time .cids()
it's called - but personally I'd just cache the result after the first call.
@rvagg seems ready to merge. |
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.
lgtm, very nice work all!
## [5.1.0](v5.0.3...v5.1.0) (2023-01-27) ### Features * add support for sync car reading ([#121](#121)) ([c3917aa](c3917aa))
🎉 This PR is included in version 5.1.0 🎉 The release is available on: Your semantic-release bot 📦🚀 |
Remove sync car reader code that has moved upstream into [@ipld/car](ipld/js-car#121 (comment)) Fixes #401 License: MIT Signed-off-by: Oli Evans <oli@protocol.ai>
Remove sync car reader code in favour of CarBufferReader that landed upstream in [@ipld/car](ipld/js-car#121 (comment)) Fixes #401 ❤️ License: MIT Signed-off-by: Oli Evans <oli@protocol.ai> --------- Signed-off-by: Oli Evans <oli@protocol.ai> Co-authored-by: Benjamin Goering <171782+gobengo@users.noreply.github.com> Co-authored-by: Alan Shaw <alan.shaw@protocol.ai>
Remove sync car reader code in favour of CarBufferReader that landed upstream in [@ipld/car](ipld/js-car#121 (comment)) Fixes #401 ❤️ License: MIT Signed-off-by: Oli Evans <oli@protocol.ai> --------- Signed-off-by: Oli Evans <oli@protocol.ai> Co-authored-by: Benjamin Goering <171782+gobengo@users.noreply.github.com> Co-authored-by: Alan Shaw <alan.shaw@protocol.ai>
This PR adds a new class CarReaderSync to support syncronous car reading.
Changes:
decodeV2Header
,decodeVarint
andgetMultihashLength
BytesReader
interface has a new arg in theexactly
method to seek after reading, defaults to false (previous behavior)I was hoping to be able to extract more from the async decoder than i did, but i think this is useful and does not introduce any breaking change.
The new CarReaderSync is exported in package.json.