Make ValidPath (nar) hash optional if ca field is present
#4059
Conversation
And after much labor fix all test failures
…dresses-in-path-info
|
I'm not convinced this is a good idea. It seems that it makes everything way messier. I mean, it's basically a regression: NAR hashes used to be optional which meant that there lots of places where you could end up with a zero hash in your database. |
Ericson2314
force-pushed
the
unified-contentAddresses-in-path-info
branch
from
702fd80
to
04ecf5c
Compare
Ericson2314
changed the title
hash optional if ca field is presenthash optional if ca field is present
|
There might be other ways of accomplishing my goal, such as an alternative to To reiterate, I want to keep the requirement the database are narinfo files have this info. I suppose even having remote store / legacy ssh store continue to require NAR hashes is workable too. It just means one would have to talk to these new CA-only store directly and not via a remote store protocol. |
…dresses-in-path-info
…dresses-in-path-info
|
I marked this as stale due to inactivity. → More info |
|
I closed this issue due to inactivity. → More info |
We port the
Thesedata type from Haskell to C++ to maintain the invariant that we must have at least one of a CA or nar hash. This ensures that we can always validate the store entry.Additionally, we also insure that the
LocalStoreandBinaryCacheStorealways have NAR hashes, which makes this feature easier to undo without breaking data in the wild.LocalStoreandBinaryCacheStoresound like all the "base" stores we have today, so what's the prupose? The intended use-case for this feature would be novel stores that serve data by CA, such aHashedMirrorStoreto replace the hashed mirrors mechanism, IPFS store, or software archive stores.CC @nlewo
This PR is pretty noisy. Most of it is just replacing
.fieldwith various accessor methods.Fix #3640