Skip to content
EN FR

Collections, data providers and persistence

Documentation status: guide. Exact provider APIs depend on the selected module and Runtime version.

Separate declaration from executable provider

The declarative model describes a class and its collections. At runtime, activated ClassItem metadata resolves a collection provider appropriate to that declaration and configuration. A provider is the executable query/data-access boundary used by datasets, services and other projections. An ObjectItem is a runtime business object; it should not be equated with one SQL table row.

Common path

  1. Define the collection and its business identity at the MODEL layer.
  2. Load packages and assemble APPLICATION metadata.
  3. Resolve the collection provider from the activated runtime class.
  4. Define query, filter, pagination, object identity, transaction and posting expectations.
  5. Project results to datasets, service endpoints or serialized payloads.
  6. Test read/write behavior independently from the transport and view.

SQL providers, brokers, collection adapters and serializers cover different responsibilities. Choosing a database backend should not silently redefine the conceptual contract. Serialization of model/graph data and database persistence can also carry different identity and version rules.

Validate the boundary

Test empty results, pagination, sorting, partial failures, transaction boundaries, identity preservation and concurrent updates. Diagnose whether a mismatch belongs to the model declaration, provider, mapping, serializer or presentation layer before changing semantics.

Collections, views and datasets · Persistence and consistency · Data plane · SQL/provider deployment

LaTeX sources: datastructures-and-brokers.tex; collection-providers.tex; sql-data-engine.tex; serialization-and-deserialization.tex.