Context
Today timeless data acts as a "fallback" for all timelines. Any time we do a latest-at or range-query, we resolve the query results as if there is an event at -Inf on the timeline and include it in the query results as appropriate.
This query-level merging of timeless and timefull data adds significant complexity to the book-keeping and query processing for very little practical gain.
Proposal
A vast simplification for timeless data is that once an (Entity, Component) path is set to timeless, it becomes an override rather than a fallback. This means during any query we can check the timeless map first. If we find timeless data, we return it, and otherwise we can do regular query logic, but without the complexity of a fallback.
Conceptually timeless data becomes a single hashmap mapping: (Entitypath, ComponentName) => DataCell.
We will define it as an error / undefined behavior if a user logs a mixture of timeless and timeful data for the same Entity-Component Path.
Logging timeless data multiple times to the same path still only saves a single copy of the data. We make no attempt to version the timeless data or provide multi-valued results in a range query.
Changes in Behavior for Users
If users are currently using timeless data for it's "fallback" properties by logging timeless data first, and later logging timeful data, they will need to update their code. In most cases something very similar can be accomplished by logging a piece of data to -Inf on an appropriate set of timelines.
Timeless data will no longer show up implicitly as an event on the timeline at -Inf in the same way. We will need to design an alternative representation for this timeless data to accommodate for the lack of an event-marker.
Additional Considerations
- We may want to consider renaming this concept from "timeless" to "static" as these new semantics are very close to static data concepts in many languages.
Related:
Context
Today timeless data acts as a "fallback" for all timelines. Any time we do a latest-at or range-query, we resolve the query results as if there is an event at -Inf on the timeline and include it in the query results as appropriate.
This query-level merging of timeless and timefull data adds significant complexity to the book-keeping and query processing for very little practical gain.
Proposal
A vast simplification for timeless data is that once an (Entity, Component) path is set to timeless, it becomes an override rather than a fallback. This means during any query we can check the timeless map first. If we find timeless data, we return it, and otherwise we can do regular query logic, but without the complexity of a fallback.
Conceptually timeless data becomes a single hashmap mapping:
(Entitypath, ComponentName) => DataCell.We will define it as an error / undefined behavior if a user logs a mixture of timeless and timeful data for the same Entity-Component Path.
Logging timeless data multiple times to the same path still only saves a single copy of the data. We make no attempt to version the timeless data or provide multi-valued results in a range query.
Changes in Behavior for Users
If users are currently using timeless data for it's "fallback" properties by logging timeless data first, and later logging timeful data, they will need to update their code. In most cases something very similar can be accomplished by logging a piece of data to -Inf on an appropriate set of timelines.
Timeless data will no longer show up implicitly as an event on the timeline at -Inf in the same way. We will need to design an alternative representation for this timeless data to accommodate for the lack of an event-marker.
Additional Considerations
Related:
TimeInt::BEGINNINGvs.TimeInt::MINvs.Option<TimeInt>#4832log_tickcannot coexist #2074