Skip to content
This repository has been archived by the owner on Jun 19, 2023. It is now read-only.

Commit

Permalink
fix: return raw block CIDs instead of V0 CIDs from AllKeysChan
Browse files Browse the repository at this point in the history
V0 CIDs are always "dag-pb". Using the "raw" codec indicates that these blocks
are just raw data.
  • Loading branch information
Stebalien committed Feb 2, 2020
1 parent e62b875 commit 5f9214c
Showing 1 changed file with 1 addition and 4 deletions.
5 changes: 1 addition & 4 deletions blockstore.go
Original file line number Diff line number Diff line change
Expand Up @@ -224,10 +224,7 @@ func (bs *blockstore) AllKeysChan(ctx context.Context) (<-chan cid.Cid, error) {
log.Warningf("error parsing key from binary: %s", err)
continue
}
k, err := cid.Cast(bk)

This comment has been minimized.

Copy link
@bonedaddy

bonedaddy Mar 2, 2020

Contributor

Doesn't this imply that all CIDs will be v1? What happens if this isn't the case?

This comment has been minimized.

Copy link
@Stebalien

Stebalien Mar 2, 2020

Author Member

No. This is part of ipfs/kubo#6815. The core issue is that the same underlying "block" might have multiple valid CIDs (v0 dag-pb, v1 dag-pb, v1 raw). We're migrating from storing blocks by CID to storing blocks by hash to avoid (well, reduce) this issue.

This means that.

Stage 1:

  • In the datastore layer, blocks will be referred to by multihash.
  • In the blockstore layer, blocks will be referred to by CID but AllKeysChan will return CIDs with the "raw" multicodec.

Stage 2:

  • In the blockstore layer, blocks will be referred to by multihash.
if err != nil {
log.Warningf("failed to cast cid: %s", err)
}
k := cid.NewCidV1(cid.Raw, bk)
select {
case <-ctx.Done():
return
Expand Down

0 comments on commit 5f9214c

Please sign in to comment.