Context
ETLocal key names follow a specific structure that determines how they are processed and how they connect to ETSource graph methods and sparse graph queries (SGQ). For example, they may carry the prefix input_, or match node or edge names in ETSource in a particular way.
Current shortcoming
For modellers, the exact constraints are not immediately obvious, nor is it clear what to watch out for when modifying or adding ETLocal keys. The etsource_spec.rb will fail if the constraints are not met, but the output does not straightforwardly indicate what changes are needed.
Additionally, changes may be made solely on the ETSource side, for example to SGQs, without any changes required to ETLocal, causing the need to re-run the spec on ETLocal to be overlooked.
Proposed enhancement
A discussion would be needed on how to tackle this, answering the following questions:
- Why are the naming requirements necessary?
- Is a different approach desirable where naming requirements will not be needed?
- If not, how can we set this up in a way that it's clear that there are restrictions and how to cope with this?
Success criteria
- When adding or changing ETLocal keys, it is clear for a modeller if there are certain requirements or principles to be aware of.
- Automatic testing should be done there where changes are applied (in example above, ETSource could just be merged to master with no failing tests, whereas ETLocal failed a week later).
Could be picked up in the Datasets theme (streamlining dataset pipelines). Notifying @KoenvanB @mabijkerk
Context
ETLocal key names follow a specific structure that determines how they are processed and how they connect to ETSource graph methods and sparse graph queries (SGQ). For example, they may carry the prefix
input_, or match node or edge names in ETSource in a particular way.Current shortcoming
For modellers, the exact constraints are not immediately obvious, nor is it clear what to watch out for when modifying or adding ETLocal keys. The etsource_spec.rb will fail if the constraints are not met, but the output does not straightforwardly indicate what changes are needed.
Additionally, changes may be made solely on the ETSource side, for example to SGQs, without any changes required to ETLocal, causing the need to re-run the spec on ETLocal to be overlooked.
Proposed enhancement
A discussion would be needed on how to tackle this, answering the following questions:
Success criteria
Could be picked up in the Datasets theme (streamlining dataset pipelines). Notifying @KoenvanB @mabijkerk