| Comment: | Merge remote-tracking branch 'origin/main' into feat/chunked-blobs |
|---|---|
| Timelines: | family | ancestors | descendants | both | main | trunk | feat/chunked-blobs |
| Files: | files | file ages | folders |
| SHA3-256: |
0f72c73fe6ed343d4ed01476d3ab8918 |
| User & Date: | [email protected] on 2026-10-28 22:47:48.000 |
| Other Links: | branch diff | manifest | tags |
|
2026-10-28
| ||
| 22:52 |
Record chunked length in blob.content and verify parts on read
Review of the chunked-blob change found a missing last part read back short with no error, and a chunked write outside a transaction could leave a torn row that looked held. A chunked row now keeps its stored length in blob.content as an INTEGER. Reads check the parts run unbroken from seq 0, are full-sized but for the last, and add up to that length; anything else is ErrPartsCorrupt, and a NULL content is no longer mistaken for a chunked one. StoredLenSQL reads the length off the row and needs no schema probe. Chunked writes, and the phantom fill around them, run in a savepoint of the caller's transaction or a transaction of their own, so a failed part leaves nothing behind. A value needing more than 4096 parts is an error, not a panic, since stored values can come from peers. The cone and sparse local payload reads use ReadStoredExact, which loads a value only at the length already budgeted for. MaxValueBytes is documented as process-wide, and unversioned content as not chunked. check-in: 0fc4d176c3 user: [email protected] tags: feat/chunked-blobs, main, trunk | |
| 22:47 | Merge remote-tracking branch 'origin/main' into feat/chunked-blobs check-in: 0f72c73fe6 user: [email protected] tags: feat/chunked-blobs, main, trunk | |
| 21:53 |
Store blobs over a hosted value limit across blobpart rows
A hosted SQLite that caps value size (a Durable Object's 2 MB) cannot hold a large file's stored blob in one blob.content value. With the new db.DriverConfig.MaxValueBytes set, a stored value over the limit is written in 1,000,000-byte parts to blobpart(rid, seq, content), created on first use, leaving blob.content NULL and blob.size the expanded length, so phantoms (size < 0) stay unambiguous. Chunking sits below compression: hashes, deltas and the wire format are unchanged. internal/blob owns the seam (ReadStored, WriteStored, InsertStored, StoredHead, DropStored, SweepParts and two scan expressions), and every direct reader or writer of blob.content now goes through it: delta rewrite and undelta, receive, clone send and walk, compaction, sparse demotion, seed drop, shun purge, horizon cost and cone preparation. Zero, the default, keeps every value inline and creates no table, so local stores stay byte-identical. A store with blobpart rows is not readable by stock fossil; enable it only for hosted backends. Closes #459 check-in: 1fd12b3ed3 user: [email protected] tags: feat/chunked-blobs, main, trunk | |
| 21:50 |
Merge pull request #519 from danmestas/conf/hz-4-1-1-zit-scope
conformance: HZ-4.1-1 scoped to zit and go-libfossil origins check-in: 1455a3803e user: [email protected] tags: main, trunk | |