Skip to content

noxDB

Schema, migrations, and Python tooling for ccr_metadata, the lab's MariaDB metadata database (MariaDB ≥ 10, InnoDB, Galera). The database stores metadata and file pointers; bulk data lives on disk.

What's in here

  • Install

    Install the package, configure ~/.my.cnf, and connect through the LiSC SSH jump host.

  • Quickstart

    End-to-end example: open a pool, register a subject + visit + sample, export a project.

  • Schema

    The subject → visit → sample lineage, the project_samples membership junction, table layout, and naming conventions.

  • Preparing data

    How to structure your data before loading it into the database.

  • Testing

    Running the test suite and writing new tests.

  • Monitoring

    The noxdb_sweep cron job: liveness, schema drift, population counts, and DB/disk integrity checks, emailed as a report.

  • Contributing

    Contribution guidelines, branching model, and release process.

  • API reference

    Auto-generated from docstrings for every public module.

  • Changelog

    Versioned release notes (Keep a Changelog format).

Model

Two independent axes (since migration 003_cross_project_samples):

lineage:     subject ──┬── visit ──── sample ──┬── sample_files
                        │              │        └── sample_metadata (EAV)
                        │              │
                        │              └── (subject is stable: sex, origin)
                        └── visit_metadata (EAV, attached to visit)

membership:  project ──< project_samples >── sample   (many-to-many)
  • subject → visit → sample — pure lineage / provenance, with no project affiliation.
  • project — a named set of samples; owns no rows directly.
  • project_samples — the many-to-many junction that is the sole source of truth for which samples belong to which project (one sample can belong to several — e.g. shared plate controls).

See Schema for the full breakdown.

Contact