Documentation
¶
Overview ¶
Package ingitdbschema ships DataTug's inGitDB project-store schema as static files and copies them into a store directory when a project store is initialised.
Founder decision, 2026-09-17: "DataTug project ingitdb schema should be defined and copy-pasted. No need to create it dynamically." and "if we need modify ingitdb schema it belong to ingitdb module, not dalgo." This package therefore contains no dynamic schema construction and imports no DALgo driver. It imports ingitdb-go/ingitdb as a test-only dependency (to load and validate this package's own schema in tests); production code (schema.go) only copies bytes it never parses.
See spec/features/dalgo-project-store, REQ:canonical-project-layout and REQ:extension-namespace, and the "No dynamic schema creation" bullet of REQ:driver-prerequisites-are-recorded.
Index ¶
Constants ¶
This section is empty.
Variables ¶
This section is empty.
Functions ¶
func WriteSchema ¶
WriteSchema copies DataTug's static inGitDB schema into dir, which becomes (or already is) an inGitDB store root: dir/.ingitdb/root-collections.yaml and dir/ext/.collection/... after this call.
WriteSchema is safe to call against a store that already has some or all of the schema on disk. A file whose existing content matches the embedded schema (ignoring CRLF-vs-LF line-ending differences, so a Windows checkout with autocrlf is not reported as a conflict) is left untouched (idempotent). Beyond that, the two files this package ships are treated differently (founder decision, 2026-09-17):
- Every file under ext/ is DataTug-owned: WriteSchema writes it whether it was previously absent or held different (older) content, upgrading it in place. This is the "overwrite our own files" rule — ext/ holds nothing this package did not itself put there.
- .ingitdb/root-collections.yaml is NOT DataTug-owned: it may be shared with other extensions' own root-collection entries, so a differing copy is left untouched and reported as a conflict error naming its path, exactly as before this decision. WriteSchema does not attempt to merge or selectively update entries in it.
Every file WriteSchema does write (whether previously absent or being upgraded) is created via a temp file in its own directory, fsynced and renamed into place (see createFile), so a run interrupted partway through never leaves a partially written file at a schema path: a retry always sees that file as either its old content (untouched) or the new content (fully written), never partial.
WriteSchema assumes a single writer, matching dalgo2ingitdb's own contract (its Database.NoConcurrency field doc): it does not detect or arbitrate a concurrent WriteSchema call against the same directory.
Types ¶
This section is empty.
Source Files