h2hdb
h2hdb is the database and coordination core for the H2HDB multi-repository
system. It owns the SQLite/MariaDB schema, bounded transactional workflows, and
backend-neutral application facades. Komga and OPDS use the catalog facade;
ingest uses the transaction-owning ingest facade and downloader uses the queue
facade.
It deliberately does not scan files, parse galleryinfo.txt, manipulate
images, choose filesystem paths, serve HTTP, serialize OPDS documents, or
depend on hbrowser. Those responsibilities belong to consumer adapters and
sibling packages.
What this package provides
- One generated epoch-3/schema-v2 schema for SQLite and MariaDB.
- Safe initialization, full schema auditing, and lightweight readiness probes.
- Current-catalog discovery with Unicode-normalized search, exact facets, keyset pagination, and fixed recently uploaded/downloaded windows.
- Single-publication, acquisition, cover, thumbnail, and ordered-page metadata through immutable backend-neutral values.
- Durable download, ingest, publication, cleanup, lease, and retry coordination through public facades.
Catalog readers only see the current publication head. A caller-supplied revision or cursor is checked against durable database authority and fails closed if the catalog advances or the value was forged.
Compatibility model
The active database identity is epoch=3, schema_version=2. This is a
greenfield contract: schema v2 does not upgrade or adopt schema v1 or any older
database, provide compatibility views, retain old list APIs, or dual-write old
and new shapes. Replace an earlier database with a truly empty database and
rebuild it from source through the current ingest integration.
migrate constructs or resumes only this checksum-bound schema. An interrupted
matching BUILDING run can resume; a previous, foreign, drifted, or otherwise
non-empty database is rejected rather than adopted or repaired in place.
The logical schema sources are
verification/schema/catalog.toml and
verification/schema/operational.toml.
Generated artifacts and executable checks are authoritative for relation and
bootstrap details, so this README does not copy counts that can drift.
Installation
h2hdb requires Python 3.14 or later. Install the published package into each
core administration or consumer environment:
python -m pip install h2hdb
For development from a source checkout, rebuild the repository-local Python and Markdown tool environments with:
./scripts/rebuild-env.sh
Configuration
{
"database": {
"sql_type": "sqlite",
"database": "/var/lib/h2hdb/catalog.sqlite3",
"access_mode": "read-write"
},
"maintenance": {
"optimize_enabled": true
},
"logger": {
"level": "INFO",
"file": null
}
}
For MariaDB, also set host, port, user, password, and database.
The supported MariaDB baseline is 10.11.11, including Synology's
10.11.11-1551 package build. The integration gate pins the upstream
mariadb:10.11.11 image and verifies the server version before creating its
test database.
Read-only consumers should use "access_mode": "read-only" and a database
account limited to the metadata/read privileges required by schema validation
and application reads.
JSON string values consisting exactly of ${ENV_NAME} are resolved from the
process environment before validation. Variable names must match
[A-Za-z_][A-Za-z0-9_]*; missing or invalid variables stop startup without
including their values in the error. Inline interpolation such as
db-${INSTANCE} is deliberately unsupported, and unknown JSON fields are
rejected.
Schema administration
The CLI exposes exactly three operations:
python -m h2hdb migrate --config config.json
python -m h2hdb check --config config.json
python -m h2hdb ready --config config.json
Choose the operation from database state:
| Database state or caller | Operation |
|---|---|
| Truly empty database | Run migrate to construct epoch 3/schema v2 |
Matching interrupted BUILDING epoch |
Rerun migrate to resume |
Matching READY epoch |
Run read-only check for the full audit |
| Consumer startup | Run check; never initialize schema |
| Frequent readiness probe | Run the O(1) read-only ready check |
| Previous, foreign, or drifted schema | Create a new empty database and rebuild |
The wheel-resident generated provider must resolve every required runtime
validator and recurring writer binding before it opens or mutates a database;
the public administration API does not accept a substitute provider. check
holds a read transaction while validating the complete READY schema;
ready validates only the exact epoch/version/manifest marker.
Applications can use the same administration boundary directly:
from h2hdb import VNextDatabaseAdminFacade, load_config
config = load_config("config.json")
admin = VNextDatabaseAdminFacade(config)
admin.initialize() # deployment init job only
admin.check() # full read-only audit
admin.check_readiness() # lightweight probe
Public application API
Consumers should import the public facades and immutable domain values from
h2hdb; they must not import connector, repository, generated-schema, or table
implementation modules.
Current-head catalog reads use open_database, which performs the full
manifest-bound READY audit before returning a VNextCatalogFacade. The
CatalogRevision returned by get_catalog_revision() can fence subsequent
calls and is accepted only while it still equals the current head; a head
advance makes an older descriptor fail closed:
from h2hdb import (
CatalogDiscoveryQuery,
CatalogFacetKind,
CatalogRecentOrder,
load_config,
open_database,
)
catalog = open_database(load_config("readonly-config.json"))
revision = catalog.get_catalog_revision()
query = CatalogDiscoveryQuery(search="example title")
page = catalog.discover_publications(
query=query,
limit=50,
revision=revision,
)
languages = catalog.list_publication_facets(
facet=CatalogFacetKind.LANGUAGE,
query=query,
limit=50,
revision=revision,
)
recent = catalog.list_recent_publications(
order=CatalogRecentOrder.UPLOADED,
revision=revision,
)
publication_id = "urn:h2h:gallery:42"
publication = catalog.get_publication(publication_id, revision=revision)
presentation = catalog.get_publication_presentation(
publication_id,
revision=revision,
)
discover_publications() uses seek cursors and accepts normalized AND search
plus exact language, subject, and contributor filters. Search is backed only by
the revision-scoped SQL index; it does not hydrate every publication to match in
Python. list_publication_facets() exposes exact language, subject, and
contributor counts under the other active filters. list_recent_publications()
has no caller limit or cursor: it returns the complete fixed window of at most
128 acquisition-bearing publications in uploaded or downloaded order.
Acquisitions and images are exposed as immutable, backend-neutral descriptors. The acquisition descriptor carries a download name, media type, and opaque storage-object identity. Presentation reads expose cover, thumbnail, page count, and individual page descriptors with byte extent, media type, digest, and image dimensions. Consumers resolve those descriptors through their own storage adapter; core neither assumes a CBZ layout nor opens image/archive bytes.
Download request creation, bounded listing, and exact-request completion use
VNextDownloadQueueFacade:
from h2hdb import VNextDownloadQueueFacade, load_config
queue = VNextDownloadQueueFacade(load_config("writer-config.json"))
request = queue.request_download(42, "https://example.invalid/gallery/42")
pending = queue.list_download_requests(limit=100)
queue.complete_download_request(request)
Each facade call owns fresh database connections and bounded transactions. Catalog reads use a pinned snapshot and then a fresh current-head fence before returning, so a concurrent head advance fails closed. Repository methods that accept connectors or units of work remain internal coordination surfaces.
VNextIngestFacade.prepare_source() consumes the source adapter once, outside
every database transaction, and freezes the exact observation pages in a
private disk-backed spool. The manifest preflight and later bounded staging
steps therefore read the same immutable bytes even if the live source changes
mid-run; closing the prepared-source handle removes the temporary spool.
After complete_ingest() releases its SHARED gate lease, resident integrations
call VNextIngestFacade.drain_current_only_maintenance(). Each cleanup
transaction selects at most 256 logical cleanup keys/families under a renewable
EXCLUSIVE lease; each selected key executes only a schema-fixed bounded set of
physical deletes. One public attempt advances at most 16 cleanup batches. The
typed result is DONE,
PROGRESSED, BLOCKED, or CONTENDED; residents immediately retry
PROGRESSED, while blocked/contended attempts use the ordinary poll cadence.
Every result retains no caller capability, and durable shard checkpoints make
response-loss replay safe. Cleanup retains the prior payload until the new
current receipt is fully PUBLISHED and no live
publication-candidate or source-build predecessor pins it.
Byte ownership and current limits
The ingest integration owns concrete archive and artwork bytes: it renders, stores, protects, resolves, and eventually releases them through its adapters. Core owns only transactional coordination and sealed neutral descriptors; it does not choose storage paths, mandate CBZ/ZIP, decode artwork, or perform filesystem/object-storage I/O.
The durable contract needed to derive
CatalogPublication.redownload_required for the current revision is not
closed. Readers therefore do not infer it from transient operational rows.
Deployment
The repositories remain independent packages; they are not a shared uv
workspace. See
docs/multi-repo-deployment.md for database
ownership, clean initialization, credentials, startup order, descriptor
resolution, and backup boundaries.
Development and verification
Repository contributors should read AGENTS.md before changing
code or schema. The local fast check and complete release check are:
./scripts/check-fast.sh
./scripts/check-full.sh
The full check covers formatting, typing, tests, generated-schema drift, schema
surface, formal evidence, the installed distribution, SQLite, and the pinned
MariaDB 10.11.11 integration profile. MariaDB tests require Docker and
H2HDB_TEST_MARIADB=1.
For an isolated editable-install smoke containing explicit consumer sources, run:
./scripts/rebuild-multirepo-integration.sh
Consumers otherwise resolve from the configured package index. To exercise an unpublished wheel, Git ref, or local project, pass it explicitly by package name:
./scripts/rebuild-multirepo-integration.sh \
--source h2hdb-ingest=/tmp/h2hdb_ingest.whl \
--source h2hdb-opds='git+https://github.com/Kuan-Lun/h2hdb-opds.git@ref'
License
GNU General Public License version 3 (GPLv3). See LICENSE for the complete
terms.
Download files
Download the file for your platform. If you're not sure which to choose, learn more about installing packages.
Source Distribution
Built Distribution
Filter files by name, interpreter, ABI, and platform.
If you're not sure about the file name format, learn more about wheel file names.
Copy a direct link to the current filters
File details
Details for the file h2hdb-0.28.3.tar.gz.
File metadata
- Download URL: h2hdb-0.28.3.tar.gz
- Upload date:
- Size: 2.5 MB
- Tags: Source
- Uploaded using Trusted Publishing? Yes
- Uploaded via:
twine/7.0.0 CPython/3.13.14
File hashes
| Algorithm | Hash digest | |
|---|---|---|
| SHA256 |
a42ad9d69f0fa5682436e1607a916762ee5910655b5c5f263415017b10e07e04
|
|
| MD5 |
ed3dd1082353f4b73f7816ea6203b7f0
|
|
| BLAKE2b-256 |
ff114126bcbd3f92ef4f3aa3ae78bc0eb03832b09876c09fb23feab7ee921caf
|
Provenance
The following attestation bundles were made for h2hdb-0.28.3.tar.gz:
Publisher:
publish.yml on Kuan-Lun/h2hdb
-
Statement:
-
Statement type:
https://in-toto.io/Statement/v1 -
Predicate type:
https://docs.pypi.org/attestations/publish/v1 -
Subject name:
h2hdb-0.28.3.tar.gz -
Subject digest:
a42ad9d69f0fa5682436e1607a916762ee5910655b5c5f263415017b10e07e04 - Sigstore transparency entry: 2679323444
- Sigstore integration time:
-
Permalink:
Kuan-Lun/h2hdb@d9d57683f65494250b58203a198f8942bb0bc60a -
Branch / Tag:
refs/heads/master - Owner: https://github.com/Kuan-Lun
-
Access:
public
-
Token Issuer:
https://token.actions.githubusercontent.com -
Runner Environment:
github-hosted -
Publication workflow:
publish.yml@d9d57683f65494250b58203a198f8942bb0bc60a -
Trigger Event:
push
-
Statement type:
File details
Details for the file h2hdb-0.28.3-py3-none-any.whl.
File metadata
- Download URL: h2hdb-0.28.3-py3-none-any.whl
- Upload date:
- Size: 1.5 MB
- Tags: Python 3
- Uploaded using Trusted Publishing? Yes
- Uploaded via:
twine/7.0.0 CPython/3.13.14
File hashes
| Algorithm | Hash digest | |
|---|---|---|
| SHA256 |
c78e28dddb3a10a8bb9a6b51d6ad0d75dfa057e93cb0b6de4f906eb5629a4af8
|
|
| MD5 |
eece22285397c3ce7fc091177d69636a
|
|
| BLAKE2b-256 |
f2903a620ce01079bcd1f3594dd96462c88604f36f6938c9cf908bbd141829dd
|
Provenance
The following attestation bundles were made for h2hdb-0.28.3-py3-none-any.whl:
Publisher:
publish.yml on Kuan-Lun/h2hdb
-
Statement:
-
Statement type:
https://in-toto.io/Statement/v1 -
Predicate type:
https://docs.pypi.org/attestations/publish/v1 -
Subject name:
h2hdb-0.28.3-py3-none-any.whl -
Subject digest:
c78e28dddb3a10a8bb9a6b51d6ad0d75dfa057e93cb0b6de4f906eb5629a4af8 - Sigstore transparency entry: 2679323548
- Sigstore integration time:
-
Permalink:
Kuan-Lun/h2hdb@d9d57683f65494250b58203a198f8942bb0bc60a -
Branch / Tag:
refs/heads/master - Owner: https://github.com/Kuan-Lun
-
Access:
public
-
Token Issuer:
https://token.actions.githubusercontent.com -
Runner Environment:
github-hosted -
Publication workflow:
publish.yml@d9d57683f65494250b58203a198f8942bb0bc60a -
Trigger Event:
push
-
Statement type: