95 lines
3.9 KiB
Markdown
95 lines
3.9 KiB
Markdown
# Storage And Search Foundation
|
|
|
|
Libre Study should query study resources through stable app-level search and resource interfaces. The UI should not care whether a result came from local JSON packages, browser indexes, Tauri SQLite, hosted SQLite, or a future server database.
|
|
|
|
## Current Phase 5 Result
|
|
|
|
- Browser/local preview still loads LibreBible JSON/JSONL packages.
|
|
- Visible page hydration now goes through a shared page-query method instead of the reader assuming every resource is already attached to the whole-library array.
|
|
- Verse search now goes through a cached verse search index instead of open-coded filtering.
|
|
- KJV Strong's-number search uses a compact package index where available.
|
|
- KJV page Strong's links load from `strongs-by-chapter` shards where available, with whole-file loading kept as a fallback for older packages.
|
|
- The native SQLite path has explicit reference/attachment indexes and an FTS5 verse-search table.
|
|
- Browser indexes are disposable and rebuildable from loaded package surfaces, which keeps them compatible with later SQLite/server-backed search.
|
|
|
|
## Resource Data vs User Data
|
|
|
|
Public resource data belongs to LibreBible:
|
|
|
|
- translations
|
|
- Strong's links
|
|
- lexicons and dictionaries
|
|
- footnotes and study notes
|
|
- commentaries
|
|
- maps and place metadata
|
|
- audio Bible metadata
|
|
- pronunciation metadata
|
|
|
|
User workspace data belongs to Libre Study:
|
|
|
|
- sessions
|
|
- notes
|
|
- visual settings
|
|
- timeline events
|
|
- tags
|
|
- highlights
|
|
- saved searches
|
|
- future collaboration state
|
|
|
|
## Query Interface Goals
|
|
|
|
The app should ask stable questions:
|
|
|
|
- search this translation for text
|
|
- find verses by Strong's number
|
|
- get notes for visible verses
|
|
- get commentary for a verse or range
|
|
- get dictionary/lexicon entries for terms, lemmas, or Strong's numbers
|
|
- get maps for places connected to this verse/page
|
|
- get audio for this chapter, verse, or lemma
|
|
|
|
The backing implementation can change without rewriting the page UI.
|
|
|
|
## SQLite Index Plan
|
|
|
|
SQLite remains appropriate for desktop, local, and private alpha use. It needs explicit tables and indexes instead of ad hoc file reads.
|
|
|
|
Core resource tables:
|
|
|
|
- `resources`: resource id, type, title, version, license, package version.
|
|
- `verses`: translation id, source verse id, book, chapter, verse, text.
|
|
- `verse_strongs`: translation id, source verse id, position, surface, Strong's number.
|
|
- `lexicon_entries`: Strong's number, language, lemma, transliteration, pronunciation, definitions.
|
|
- `verse_notes`: resource id, translation id, source verse id, note type, caller, text.
|
|
- `commentary_entries`: resource id, book, chapter, verse start, verse end, title, text.
|
|
- `dictionary_entries`: resource id, term, slug, definitions, scripture refs.
|
|
- `places`: place id, canonical name, aliases, coordinates, bounds.
|
|
- `verse_places`: source verse id or range, place id, confidence/source.
|
|
- `audio_segments`: resource id, translation/language, book, chapter, verse range, file path/url, timestamps.
|
|
- `pronunciations`: resource id, language, term, lemma, Strong's number, file path/url, source.
|
|
|
|
Indexes:
|
|
|
|
- `verses(translation_id, book, chapter, verse)`
|
|
- `verses(source_verse_id)`
|
|
- `verse_strongs(strong)`
|
|
- `verse_strongs(translation_id, source_verse_id)`
|
|
- `verse_notes(translation_id, source_verse_id, note_type)`
|
|
- `commentary_entries(book, chapter, verse_start, verse_end)`
|
|
- `dictionary_entries(term)`
|
|
- `places(canonical_name)`
|
|
- `verse_places(place_id)`
|
|
- `audio_segments(book, chapter, verse_start, verse_end)`
|
|
- `pronunciations(strong_number)`
|
|
- `pronunciations(lemma)`
|
|
|
|
Full-text indexes:
|
|
|
|
- Bible text through SQLite FTS5.
|
|
- Notes and commentaries through SQLite FTS5.
|
|
- Dictionary/lexicon definitions through SQLite FTS5.
|
|
|
|
## Hosted Web Path
|
|
|
|
For the private alpha, server-side SQLite is acceptable. Before public multi-user accounts and collaboration, user/account/session data should move to a server database such as Postgres while public resource packages can remain static, indexed, or separately cached.
|