Models in the Console

The Create Model form asks for a model key, a file URL and an attribute-generation method in one breath, which makes it hard to tell what the file will contain from where the values live. They are two different things.

A model describes what one item looks like

A model is a shape: a unique key plus a list of properties, each with a name and a type (string, int, float, date, boolean, json, any, plus the array types Array<string>, Array<int>, Array<float> and Array<date>). It holds no values.

Create Model writes one file — models/product.dcupl.json for the model key Product — containing that shape, and adds the file to dcupl.lc.json as a model resource. Both halves matter: a model file that is not declared in the loader config is never loaded.

The form's Attribute Creation picks where the properties come from: Manually (next Step) opens an empty property list to fill in, Data Resource infers them from a data file already in the project, and Example Data infers them from CSV or JSON you paste.

The rows usually arrive separately

flowchart LR
  M["model resource<br/>Product.dcupl.json"] --> C["dcupl core"]
  D["data resource<br/>model: Product"] --> C
  C --> L["Loaded model<br/>shape + rows"]

Values reach a model through a separate data resource in the loader config that names this model key — a CSV or a JSON file. That is why the loader always registers models before it parses data: a data resource is parsed against its model (CSV columns get their types from it). A data resource with no matching model is not dropped: by default the loader creates a model of that key and infers its properties from the rows.

A model may also carry rows inline, in a data block inside the definition itself. Those are not samples or fixtures: they are forwarded into exactly the same load path as an external data resource. Use them for small, stable lookup tables that you would rather keep next to the shape.

Two model files that declare the same key merge: properties and references accumulate across the files, so one model can be assembled from several files.

References vs properties

A property holds a value on the item. A reference points at another model, and is either:

• singleValued — one target item, such as an order's customer.
• multiValued — many, such as an order's products.

Once both models are loaded, an order reaches its products through that link instead of copying their values into its own rows. Keep the shared data in one model and reference it; that is what keeps queries across relationships cheap.

Attributes that fail validation are dropped rather than fatal — they surface in the Quality Analyzer on the running app, not as a load failure. If a column you expect is missing, look there first.