docs(paper): ids are opaque strings, not ULID-shaped - #11
Merged
Conversation
The paper described sqlite-vec as keyed by "a stable ULID-shaped string" in
Section 1. The reference implementation mints uuid4 hex - 32 lowercase hex
chars, not a 26-char Crockford base32 ULID (sqlite_vec.py:434,
transformer.py:65) - and the schemas guarantee only {"type": "string",
"minLength": 1} with no format at all.
The claim has been present since v1 and is live in v4. An implementer binding
to the wire format could reasonably write a ULID validator on the strength of
it and reject every id the reference store produces.
Replaced with an accurate description that also states the format is not part
of the contract, which is the property implementers actually need.
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
1 participant
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.
Section 1 described sqlite-vec as keyed by "a stable ULID-shaped string".
That is wrong. The reference implementation mints
uuid.uuid4().hex— 32 lowercasehex characters, not a 26-char Crockford base32 ULID:
src/memorywire/store/sqlite_vec.py:434—memory_id = uuid.uuid4().hexsrc/memorywire/transformer.py:65—return uuid.uuid4().hexAnd the schemas guarantee no format at all — every record and response types
idas
{"type": "string", "minLength": 1}.The claim has been in every arXiv version since v1 and is live in v4. It matters
because an implementer binding to the wire format could write a ULID validator on
the strength of it and reject every id the reference store produces. This was raised
by an external implementer building an adapter, and already corrected in
correspondence — this brings the paper in line.
Replaced with a description that is accurate and states the property implementers
actually need: the format is not part of the contract.
Fixed in all three copies:
memorywire-paper.md,memorywire-paper.tex, andarxiv-submission/memorywire-paper.tex. Goes out with the next arXiv revision.