Skip to content

Derive the lattice's type membership from the source - #104

Merged
estebanzimanyi merged 1 commit into
MobilityDB:masterfrom
estebanzimanyi:feat/derive-the-lattice-membership-from-the-source
Aug 31, 2026
Merged

Derive the lattice's type membership from the source#104
estebanzimanyi merged 1 commit into
MobilityDB:masterfrom
estebanzimanyi:feat/derive-the-lattice-membership-from-the-source

Conversation

@estebanzimanyi

Copy link
Copy Markdown
Member

Which temporal types a class holds is MEOS's to state, so the parse reads it
from meos_catalog.c at each run instead of the model file carrying a copy: a
class naming a predicate takes the types that predicate admits, and a leaf
takes the base type MEOS_RELTYPE_CATALOG gives the one type it models,
through the same reader attach_type_relations uses. Temporal publishes 20
types and TSpatial 14, and a type MEOS adds reaches the published lattice
with no edit here.

The model file states neither, and a test holds that it does not — a copy is
what drifts, so the fix is that there is none to drift. What it keeps is the
design: the class tree, each class's prefixes, and the one type a leaf models,
which is that class's identity rather than a restatement of MEOS.

Deriving requires the source, so the attach raises where meos_catalog.c is
unreachable. An empty membership is indistinguishable in the output from a
class MEOS genuinely has no type for, and every consumer of the published
lattice would inherit it, so there is no honest degradation to fall back to.
locate_catalog is public for the same reason it is shared: two readers of one
array are two things to keep in step.

Which temporal types a class holds is MEOS's to state, so the parse reads it
from `meos_catalog.c` at each run instead of the model file carrying a copy: a
class naming a `predicate` takes the types that predicate admits, and a leaf
takes the base type `MEOS_RELTYPE_CATALOG` gives the one type it models,
through the same reader `attach_type_relations` uses. `Temporal` publishes 20
types and `TSpatial` 14, and a type MEOS adds reaches the published lattice
with no edit here.

The model file states neither, and a test holds that it does not — a copy is
what drifts, so the fix is that there is none to drift. What it keeps is the
design: the class tree, each class's prefixes, and the one type a leaf models,
which is that class's identity rather than a restatement of MEOS.

`objectModel.membership.status` reads `derived`, or `source-unavailable` where
`meos_catalog.c` is not reachable, and the lattice then names no membership at
all. A class naming no type would read the same as one MEOS has no type for,
so the status is what tells them apart — the answer the error contract beside
it already gives. A source that IS readable and disagrees with the model raises
instead: a predicate the model names that MEOS does not declare, a predicate
admitting nothing, a leaf modelling a type the relation catalog does not
relate. `locate_catalog` is public for the same reason it is shared: two
readers of one array are two things to keep in step.
@estebanzimanyi
estebanzimanyi force-pushed the feat/derive-the-lattice-membership-from-the-source branch from 8a9a791 to 33f36c4 Compare August 31, 2026 14:06
@estebanzimanyi
estebanzimanyi merged commit 26290ab into MobilityDB:master Aug 31, 2026
2 checks passed
@estebanzimanyi
estebanzimanyi deleted the feat/derive-the-lattice-membership-from-the-source branch August 31, 2026 15:52
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant