Read the type relations from the type-indexed catalog array - #94
Open
estebanzimanyi wants to merge 1 commit into
Open
Read the type relations from the type-indexed catalog array#94estebanzimanyi wants to merge 1 commit into
estebanzimanyi wants to merge 1 commit into
Conversation
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.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
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.