-
-
Notifications
You must be signed in to change notification settings - Fork 3k
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
Clarify handling blocks that aren't serialized objects #2067
Comments
I think:
|
Once CIDv1 lands, you will be able to address raw blocks. That should solve this issue |
I don't see how the issue will solve itself. |
@robcat the mcodec is embedded in the cid of the block, so yeah, the blockstore will technically be storing the mcodec. |
@whyrusleeping Example: A CID with unary encoding gets pulled. I'm expecting the blockstore to store it in binary form on my (binary) disk and to be able to retrieve it with the unary CID. |
@robcat try |
Ok I got it, the block gets named But in my view the blockstore shouldn't be aware of the CID version and codec, these exist at a higher level (i.e. the object layer, where the deserialization happens). |
There is reason for that, I will allow @whyrusleeping to elaborate. |
@robcat Short answer, it could go either way. Long answer: We could potentially make the blockstore not care about formats and manage to handle things for the most part without them. The reason we opted for storing formats is that it makes everything we store on disk self describing. You can, without any other context, look at blocks and be able to tell what they are. This is really helpful for writing tools like |
Elaborating on #2067 (comment) a bit: there must be some sort of flag to allow hash specification. Currently |
@mib-kd743naq mmm, yeah. Great point. |
We can now add 'raw blocks' to ipfs that can be pinned as normal |
Currently, arbitrary data can be stored and retrieved with block.{put/get}. However, the resulting blocks cannot be pinned, as pinning tries to deserialize an object.
It would seem either blocks should be enforced to always be serialized objects, or pinning should be able to handle non-object blocks.
The text was updated successfully, but these errors were encountered: