Necessary for lexicon joins, which are injected into query plans as
necessary by the query planner. You can use a
LexPredicate to
perform either a forward (
BigdataValue to
IV) or reverse
(
IV to
BigdataValue) lookup. Either lookup will cache
the
BigdataValue on the
IV as a side effect.
Note: If you query with
IV or
BigdataValue which is
already cached (either on one another or in the termsCache) then the
cached value will be returned (fast path).
Note: Blank nodes will not unify with themselves unless you are using
told blank node semantics.
Note: This has the side effect of caching materialized
BigdataValues on
IVs using
IV#setValue(BigdataValue) for use in downstream operators that
need materialized values to evaluate properly. The query planner is
responsible for managing when we materialize and cache values. This keeps
us from wiring
BigdataValue onto
IVs all the
time.
The lexicon has a single TERMS index. The keys are
BlobIVs formed
from the
VTE of the
BigdataValue,
BigdataValue#hashCode(), and a collision counter. The value is
the
BigdataValue as serialized by the
BigdataValueSerializer.
There are four possible ways to query this index using the
LexPredicate.
lex(-BigdataValue,+IV)
The
IV is given and its
BigdataValue will be sought.
lex(+BigdataValue,-IV)
The
BigdataValueis given and its
IV will be sought.
This case requires a key-range scan with a filter. It has to scan the
collision bucket and filter for the specified Value. We get the collision
bucket by creating a prefix key for the Value (using its VTE and
hashCode). This will either return the IV for that Value or nothing.
lex(+BigdataValue,+IV)
The predicate is fully bound. In this case we can immediately verify
that the Value is consistent with the IV (same VTE and hashCode) and then
do a point lookup on the IV.