mirror of
https://github.com/0xrsydn/idx-cli.git
synced 2026-11-07 09:45:36 +00:00
A snapshot republished for the same as-of date (the TRUE ticker fix) kept the date, latest release, and release count, so sync saw nothing to do and existing installs kept the bad data without --force. The manifest gains an optional snapshot.replaces_sqlite_sha256 listing earlier builds for that date. Queries never write to a synced file, so a local database byte-identical to a listed build is replaced; one that matches nothing (local imports or edits) still needs --force. The publisher fills the list on a same-date rebuild. Older clients ignore the field. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
3.5 KiB
3.5 KiB
Ownership Snapshot Sync
idx ownership sync installs a maintained SQLite snapshot into the local ownership DB path.
The command is intentionally manifest-driven so the repo can publish snapshots in GitHub releases, object storage, or a local filesystem path without changing the CLI.
Publishing snapshots is a maintainer task; see docs/OWNERSHIP_PUBLISH.md.
Consumer Inputs
The manifest location is resolved in this order:
idx ownership sync --manifest <path-or-url>IDX_OWNERSHIP_SNAPSHOT_MANIFESTownership.snapshot_manifestinconfig.toml- built-in published manifest URL:
https://github.com/0xrsydn/idx-cli/releases/download/ownership-snapshot-current/ownership-snapshot-manifest.json
The value can be either:
- a local path to a manifest JSON file
- a remote
http://orhttps://URL
Manifest Contract
Current schema version: 1
{
"schema_version": 1,
"generated_at": "2026-03-31T12:00:00Z",
"source": {
"family": "above1",
"listing_page_url": "https://www.idx.co.id/id/berita/pengumuman/",
"query_url": "https://www.idx.co.id/primary/NewsAnnouncement/GetAllAnnouncement?...",
"pdf_url": "https://www.idx.co.id/StaticData/NewsAndAnnouncement/...pdf",
"title": "Pemegang Saham di atas 1% (KSEI)",
"publish_date": "2026-03-10T00:00:00",
"original_filename": "b9b638e5a8_8928aca255.pdf"
},
"snapshot": {
"kind": "sqlite",
"compression": "none",
"version": "2026-02-27",
"download_url": "https://example.com/ownership-snapshot-2026-02-27-<sha256>.sqlite",
"sqlite_sha256": "<64-char hex sha256>",
"size_bytes": 123456,
"release_count": 2,
"latest_as_of_date": "2026-02-27",
"latest_release_sha256": "<latest ownership_releases.sha256>",
"latest_row_count": 7261,
"ticker_count": 955,
"replaces_sqlite_sha256": ["<sqlite_sha256 of an earlier build for this date>"]
}
}
Semantics:
sourceis optional provenance metadata describing the IDX/KSEI report used to build the snapshot.source.pdf_urlis a legacy field name: since June 2026 it holds the XLSX URL.download_urlpoints to the SQLite artifact itself. The filename is an implementation detail: published assets are immutable and content-addressed (ownership-snapshot-YYYY-MM-DD-<sha256>.sqlite), so consumers must always followdownload_urland validate it withsqlite_sha256andsize_bytes.sqlite_sha256andsize_bytesare validated before install.latest_*andrelease_countare validated against the downloaded SQLite contents before replacement.replaces_sqlite_sha256(optional, omitted when empty) lists earlier builds published for the samelatest_as_of_datethat this snapshot supersedes, for example after a parser fix. Clients up to v0.2.x ignore it.
Replacement Rules
Without --force, sync behaves conservatively:
- no local DB: install snapshot
- empty local DB: replace with snapshot
- local latest release older than snapshot: replace with snapshot
- local DB file is byte-identical to
sqlite_sha256: no-op - local DB file is byte-identical to a build in
replaces_sqlite_sha256: replace (queries never write to a synced file, so this means it was not modified) - local latest release/date/count matches snapshot: no-op
- local latest release matches but has fewer releases than snapshot: replace to fill missing history
- local DB newer than snapshot: no-op and keep local data
- local DB diverges at the same latest date: no-op and require
--force
Replacement is staged through a temp file and validated before the local DB is swapped in.