-
Notifications
You must be signed in to change notification settings - Fork 1.2k
feat: support adding async iterators #2379
Conversation
| const shouldPin = pin && isRootDir && !opts.onlyHash && !opts.hashAlg | ||
|
|
||
| if (shouldPin) { | ||
| await ipfs.pin.add(file.hash, { preload: false }) |
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.
We could probably do this asynchronously as well?
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.
Probably needs to be done in the gc read lock for add though
| yield { | ||
| path: file.path === undefined ? b58Hash : (file.path || ''), | ||
| hash: b58Hash, | ||
| size: file.unixfs.fileSize() |
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 will be different to when you don't specify onlyHash as the node has been serialized so includes the protobuf overhead. Typically we only show the user the hash when they've said onlyHash so I don't know how much of a problem this is. I think we want to switch this over to only show file sizes eventually anyway so it might not be a big deal.
| }) | ||
|
|
||
| const retStream = new AddHelper(s, p) | ||
| const output = new AddHelper(stream, { |
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 it-to-stream or stream-to-it help here to avoid buffering and respect backpressure?
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.
Good shout, I'll pull those in.
| const iterator = pipe( | ||
| source, | ||
| validateInput(), | ||
| normalizeInput(opts), |
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 made a comprehensive normalise in https://github.com/ipfs/js-ipfs-http-client/pull/1063/files#diff-7cec0363d7e0ecfb1f2d5e04b55e2cac and https://github.com/ipfs/js-ipfs-http-client/pull/1063/files#diff-8913549ebf1a95e3151ad16513fa9a6f - it would be good to check this is supporting the same inputs (or come to an agreement on what inputs we support).
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.
Nice, maybe we could move that into ipfs-utils?
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.
Yes, will do 👍
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 going to have a go at moving those utility functions over to ipfs-utils so they can be shared between the http client & core as it's going to simplify this a little.
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 going to refactor some of it though, because it's full of Buffer.from which involves a buffer copy which is slow.
|
I might actually break this up into three PRs - one for |
Pulled out of #2379. BREAKING CHANGE: Order of output from the CLI command `ipfs add` may change between invocations given the same files since it is not longer buffered and sorted. Previously, js-ipfs buffered all hashes of added files and sorted them before outputting to the terminal, this might be because the `glob` module does not return stable results. This gives a poor user experience as you see nothing then everything, compared to `go-ipfs` which prints out the hashes as they become available. The tradeoff is the order might be slightly different between invocations, though the hashes are always the same as we sort DAGNode links before serializing so it doesn't matter what order you import them in.
|
@achingbrain those PRs are now merged 😇 |
0dfd370 to
dd4fd43
Compare
alanshaw
left a comment
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 remove glob from dependencies?
alanshaw
left a comment
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, pending dependency updates and CI passing
Not yet - it's still used in |
dd4fd43 to
bd31372
Compare
Some ipfs.add() tests need to be skipped until ipfs#2379 is merged License: MIT Signed-off-by: Marcin Rataj <lidel@lidel.org>
Some ipfs.add() tests need to be skipped until ipfs#2379 is merged License: MIT Signed-off-by: Marcin Rataj <lidel@lidel.org>
6d990a7 to
687d8d0
Compare
376ae40 to
e0f4e9b
Compare
|
There are a few |
Adds a `ipfs._addAsyncIterator` method for adding async iterators and refactors all add methods to call this, as when the Great Async Iteator Migration is complete this will become the one, true method to add files to IPFS.
02a25b8 to
29a541b
Compare
This switch to js-ipfs before PR-2379 ipfs/js-ipfs#2379 switched ipfs.add to ipfs._addAsyncIterator and it broke /api/v0/add exposed by embedded js-ipfs in Brave. It seems old polyfills are no longer enough. Real fix requires more time to investigate, so for now we switch to version before js-ipfs/PR-2379. Used js-ipfs commit is from ipfs/js-ipfs#2304 before it was rebased on top of master after PR-2379, making it the last safe version. Real fix will be tracked in #757

Adds a
ipfs._addAsyncIteratormethod for adding async iterators and refactors all add methods to call this, as when the Great Async Iterator Migration is complete this will become the one true method to add files to IPFS.Purposefully does not add symmetrical
ipfs._catAsyncIteratormethods as this PR is big enough already.Also fixes up the
jsipfs addprogress indicator so it works more like thego-ipfsone and prints out hashes as it goes instead of buffering them all up in one go, at the cost of not sorting the outout.Also, also allows you to control preload behaviour from the command line.
Depends on: