CREATE TEMPORAL PROPERTY

Register one node property as a temporal property so future updates to that property are stored as hidden timestamped history behind the property itself.

Generic Description

Use CREATE TEMPORAL PROPERTY when one property on a node should keep historical values, retention, and rollups without exposing a separate public stream or event-series identifier.

CREATE TEMPORAL PROPERTY :User.weight
TYPE FLOAT
RETENTION 31536000000
ROLLUP daily EVERY 86400000 KEEP 31536000000 USING (min, max, avg, last, changes)

Consumer-Level Explanation

This clause says:

After that, normal property writes are still normal writes from the user's perspective, but the engine also records temporal history and rollup state behind the property.

Temporal history is owned by real graph nodes. A direct temporal append for a missing subject node is rejected, and deleting the subject node removes the hidden temporal-property records, rollup buckets, and global timeline contributions for that subject.

When no rollup is declared, Nexyron now registers a default daily rollup for the temporal property. The default rollup always includes event count, first timestamp, last timestamp, average event interval, latest value, and change count. Numeric scalar streams also get numeric min, max, average, and sum. String and boolean streams get distinct-count and mode-style summaries. Object streams get both whole-value summaries and per-index_path aggregate keys such as amount_min, amount_avg, status_mode, and status_changes.

Object-valued temporal properties also maintain their object field contract. Ingest-created object streams register their payload columns as index_paths, and object appends through the normal temporal-property write path can repair missing object index_paths from observed scalar fields. That makes fields such as value.amount or value.status available to Cypher planning and Abstraction Builder validation instead of leaving the object opaque.

Conceptual Explanation

This is the canonical temporal model for time-varying node state.

Use it when the changing thing is really a property of one stable entity:

Do not use this clause when the temporal thing should be a graph-visible event node family. In that case model the events as normal graph-visible nodes with explicit timestamps.

Advanced Example

CREATE TEMPORAL PROPERTY :Device.battery_pct
TYPE FLOAT
RETENTION 2592000000
ROLLUP hourly EVERY 3600000 KEEP 31536000000 USING (min, max, avg, last, changes)
ROLLUP daily EVERY 86400000 KEEP 31536000000 USING (min, max, avg, last, changes)

Object temporal properties should declare known payload paths explicitly when they are known at schema time:

CREATE TEMPORAL PROPERTY :Member.payment_transactions
TYPE OBJECT
RETENTION 31536000000
INDEX PATHS (amount, status, payment_method)

If those paths are missing on an existing database, the database admin repair action can infer scalar object fields from retained temporal history and update the temporal metadata without reingesting the source data.

Real Use Cases

Real Limitations And Tradeoffs