Says a chart is keyed by its content hash alone - #86
Merged
Conversation
Storage.save_chart/3 keys a chart on Machine.identity/1's content_hash and nothing else - no tenant, namespace, or host scope takes part in the key - so two tenants storing byte-identical charts share one chart row. The moduledoc said where the hash comes from but never what follows from it, and the question a multi-tenant host asks first went unanswered. Storage's moduledoc now says all three parts: the keying, the consequence that a host tenant-qualifies its own per-chart rows in its own tables, and that folding a namespace into the hash would change what a chart's identity is - statifier-ex's contract, not this package's, and not an option offered here. InMemory's moduledoc mirrors the first two, and the README says it once beside the run metadata map, which is where a host reads about scope. Docs only: no fragment, since changelog.d/README.md puts documentation on its "do not" side, and zero code change - stripping the docstrings leaves both modules byte-identical to main. Refs: sp-e8c
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
What
StatifierPersistence.Storage.save_chart/3keys a chart onMachine.identity/1'scontent_hashand nothing else. No tenant,namespace, or host scope takes part in the key, so two tenants that store
byte-identical charts share one chart row. The moduledoc said where the
hash comes from but never what follows from it, and the question a
multi-tenant host asks first was answered nowhere in the package.
Three paragraphs on
Storage's moduledoc now say it:is
:okand does not duplicate the row (theAdapter.save_chart/2contract). The hash answers which chart these bytes are, never who
stored them.
per-chart rows, in its own tables. This package stores nothing per
tenant; a run's opaque
metadatamap (ADR-0006) is where a host tags arun with the scope it already keys its own tables by.
hash would change what a chart's identity is, which is
Statifier.Machine.identity/1's question - statifier-ex's contract, notthis package's. Nothing here proposes it and no option to do it is
offered.
InMemory's moduledoc mirrors the first two on its chart map, and theREADME says it once at the end of "Listing runs by host scope", which is
where a multi-tenant host reads about scope.
Zero code change
Machine-checked, not asserted: stripping every
@moduledoc/@doc/@typedocheredoc from both modules at this HEAD and atorigin/mainleaves the two files byte-identical. The diff is 30 added lines and 0
removed lines across three files, every one of them inside a docstring or
README prose.
No new surface:
grepfordef register,def positions,:namespaceand
namespace:acrosslib/returns zero hits, here as on main.Verification
mix qualitygreen on this HEAD: format, compile (warnings aserrors), credo, dialyzer, deps, 482/482 tests, 95.7% coverage. Doctor,
Gettext and Sobelow are the project's standing not-applicable skips.
mix docsrenders clean, and each of the three claims was grepped out ofthe generated
StatifierPersistence.Storage.htmlandStatifierPersistence.Storage.InMemory.html- the acceptance criteriachecked against the artefact a host actually reads, not against the
source.
reports nothing missing and nothing unverifiable.
No changelog fragment
changelog.d/README.mdputs documentation on its "do not write a fragmentfor" side, and nobody calling the public API can tell the difference: the
behaviour described is the behaviour that already shipped. Consistent with
the sp-a4x and sp-gb2 precedent, neither of which carried one.
Refs: sp-e8c
Closes sp-e8c