Add parent_relationship API and RelationshipChainResolver with validation#1238
Merged
myronmarston merged 8 commits intoJun 8, 2026
Conversation
myronmarston
reviewed
Jun 4, 2026
myronmarston
left a comment
Collaborator
There was a problem hiding this comment.
I'm not done reviewing but I wanted to submit my feedback so far.
myronmarston
requested changes
Jun 4, 2026
myronmarston
approved these changes
Jun 8, 2026
myronmarston
left a comment
Collaborator
There was a problem hiding this comment.
LGTM--just one minor suggestion!
myronmarston
pushed a commit
that referenced
this pull request
Jun 8, 2026
## What Removes the `match_field` attribute from `ListPathSegment` in the runtime metadata, and switches the list-vs-object segment discriminator in `SourcedFromNestedPathSegment.from_hash` from `match_field` to `source_field`. ## Why `match_field` was always `"id"` — ElasticGraph relationships join on `id` via foreign keys, so the value carried no information. Serializing a constant into runtime metadata adds noise without value, and keeping it would have meant emitting `match_field: "id"` into `runtime_metadata.yaml` once nested sourced paths are actually populated. This mirrors the equivalent cleanup already applied to the schema-definition `PathSegment` in #1238. The match is now implicit: list elements are matched on `id` against the value at `source_field`. If non-`id` primary keys are supported in the future, the field can be reintroduced then. ## Scope / risk Low. `ListPathSegment` is not yet constructed by any production code — only by the round-trip serialization unit test — so there is no schema-artifact churn and nothing downstream consumes the removed field. Specs and type checks pass.
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.
Summary
ElasticGraph's
sourced_fromfeature allows fields on an indexed type to be populated from events published by a different source type. Today, this only works for top-level indexed types.This PR is an incremental step toward supporting
sourced_fromon embedded (non-indexed) types — types that live nested inside a root document.To enable this, we introduce a
parent_relationshipAPI that lets users declare how an embedded type connects back up to the root indexed type.This PR adds the API and validates the chain of
parent_relationshipdeclarations — producing clear error messages for misconfigured schemas. Valid configurations are artifact no-ops for now; later PRs will use the validated chain to produce runtime metadata that tells the indexer how to navigate into nested documents and update the correct fields.Example API Usage
Validations
indexing_only: trueparent_field_name:)parent_field_name:)