Skip to content

Read the type relations from the type-indexed catalog array - #94

Open
estebanzimanyi wants to merge 1 commit into
MobilityDB:masterfrom
estebanzimanyi:fix/typerelations-reltype-catalog
Open

Read the type relations from the type-indexed catalog array#94
estebanzimanyi wants to merge 1 commit into
MobilityDB:masterfrom
estebanzimanyi:fix/typerelations-reltype-catalog

Conversation

@estebanzimanyi

Copy link
Copy Markdown
Member

MobilityDB replaced the four arrays of pairs MEOS_SETTYPE_CATALOG,
MEOS_SPANTYPE_CATALOG, MEOS_SPANSETTYPE_CATALOG and MEOS_TEMPTYPE_CATALOG with
one array indexed by the type, MEOS_RELTYPE_CATALOG, whose entry names the types
related to the type it is indexed by.

The type-relation registry is read from that array. Each entry contributes both
directions of the relations it names, so a base reaches its set and span type
from its own entry or from theirs; a span set reaches its base through its span;
and the temporal role, which no base names at its own entry because several
temporal types share one base, is the inverse of temptype_basetype resolved in
MeosType order. The registry carries 22 bases, with float8, int4 and int8 each
resolving all four templates.

A located catalog out of which no relation parses raises instead of attaching an
empty registry: the consumers read the registry to resolve the concrete
collection type of a value-domain result, so an empty one degrades every one of
them without a signal. The JMEOS object layer defers valuespans, toSpan, values
and valueBins on the concrete number surfaces, and the JVM consumer refresh
fails to compile against the jar it has just built.

The live-source check resolves the tree through the extractor's own locator, so
it runs on the build path that derives the catalog rather than skipping there.

MobilityDB replaced the four arrays of pairs MEOS_SETTYPE_CATALOG,
MEOS_SPANTYPE_CATALOG, MEOS_SPANSETTYPE_CATALOG and MEOS_TEMPTYPE_CATALOG with
one array indexed by the type, MEOS_RELTYPE_CATALOG, whose entry names the types
related to the type it is indexed by.

The type-relation registry is read from that array. Each entry contributes both
directions of the relations it names, so a base reaches its set and span type
from its own entry or from theirs; a span set reaches its base through its span;
and the temporal role, which no base names at its own entry because several
temporal types share one base, is the inverse of temptype_basetype resolved in
MeosType order. The registry carries 22 bases, with float8, int4 and int8 each
resolving all four templates.

A located catalog out of which no relation parses raises instead of attaching an
empty registry: the consumers read the registry to resolve the concrete
collection type of a value-domain result, so an empty one degrades every one of
them without a signal. The JMEOS object layer defers valuespans, toSpan, values
and valueBins on the concrete number surfaces, and the JVM consumer refresh
fails to compile against the jar it has just built.

The live-source check resolves the tree through the extractor's own locator, so
it runs on the build path that derives the catalog rather than skipping there.
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