1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
//! SQL-on-FHIR support for storage backends.
//!
//! The ViewDefinition → SQL pipeline:
//!
//! 1. [`ir`] — `PlanNode` tree and value types (`LitValue`, `Expr`, …).
//! 2. [`compile_path`] — FHIRPath expression → `Expr` lowering.
//! 3. [`compile_view`] — ViewDefinition JSON → `PlanNode` (`build_plan`).
//! 4. [`dialect`] — `SqliteDialect` / `PgDialect` implementations of the
//! `Dialect` trait (JSON accessors, parameter syntax, etc.).
//! 5. [`emit`] — `PlanNode` → parameterised SQL (`emit_plan`).
//! 6. [`compiler`] — public façade combining `build_plan` + `emit_plan` into
//! `compile_view_definition_dialect`, the entry point used by the runners.
//!
//! Backend runners:
//! - [`sqlite`] — `SqliteInDbRunner` (SQL) for SQLite.
//! - [`postgres`] — `PgInDbRunner` (SQL) for PostgreSQL.
//! - [`mongodb`] — `MongoInDbRunner` (aggregation pipeline) for MongoDB.
//! - [`in_process`] — `InProcessSofRunner`, a backend-agnostic runner that
//! evaluates the view with the `helios-sof` engine over scanned resources
//! (used by S3 / S3-primary composites, which have no query engine).
//!
//! Inline `resource:` parameters on `$viewdefinition-run` are handled by the
//! REST layer via the in-process `helios-sof` FHIRPath evaluator, so this
//! module does not need a per-backend inline runner.
use FhirVersion;
/// Thin alias for [`helios_fhir::get_field_type`] — keeps existing
/// `super::lookup_field_type(...)` call sites inside this crate working
/// without sprinkling the `helios_fhir::` prefix everywhere.
pub
/// Thin alias for [`helios_fhir::field_exists_anywhere`] — see the canonical
/// definition there.
pub