lora_database/lib.rs
1//! In-memory Lora database — the database-facing orchestration layer.
2//!
3//! `lora-database` owns the parse → analyze → compile → execute pipeline
4//! and exposes a single [`Database`] entry point that transports (HTTP,
5//! benches, examples, embedded callers) can drive without knowing about the
6//! underlying crates.
7//!
8//! # Quick start
9//!
10//! ```no_run
11//! use lora_database::Database;
12//!
13//! let db = Database::in_memory();
14//! db.execute("CREATE (:User {name: 'alice'})", None).unwrap();
15//! ```
16
17mod database;
18
19pub use database::{Database, QueryRunner, SnapshotAdmin, WalAdmin, WalStatus};
20
21// Re-export the WAL configuration types so transports / operators can
22// build a `Database::open_with_wal` argument without taking a direct
23// `lora-wal` dependency.
24pub use lora_wal::{SyncMode, WalConfig};
25
26// Re-export the core execution types so callers don't need a direct
27// dependency on `lora-executor`.
28pub use lora_executor::{ExecuteOptions, LoraValue, QueryResult, ResultFormat};
29
30// Re-export the default in-memory backing store so callers only need to
31// depend on `lora-database` for the happy path.
32pub use lora_store::InMemoryGraph;
33
34// Snapshot surface — re-exported so bindings/servers don't need a direct
35// `lora-store` dependency just to name the meta / error types.
36pub use lora_store::{SnapshotError, SnapshotMeta, Snapshotable};
37
38// Standalone parsing entry point (does not require building a `Database`).
39pub use lora_parser::parse_query;