Schema support for inherited indexes

[marcdaniels-toast]

Overview

First of likely three PRs implementing index inheritance (Issue #1029). Adds schema definition infrastructure to allow concrete types to inherit index definitions from parent abstract types (unions/interfaces), enabling mixed-type indices where multiple types share a single datastore index.

Problem

Currently every indexed type must define its own index. This PR enables patterns like:

schema.interface_type "Store" do |t|
  t.field "id", "ID!"
  t.index "stores"  # Shared index
end

schema.object_type "OnlineStore" do |t|
  t.implements "Store"
  # Inherits "stores" index from Store
end

schema.object_type "MobileStore" do |t|
  t.implements "Store"
  # Also inherits "stores" index
end

Both OnlineStore and MobileStore documents live in the same stores index, requiring __typename for query-time type resolution.

Key Changes

Schema Definition:

• Added back index_def() to resolve own or inherited indices from parent abstract types
• Applied semantic definition of root_document_type?(): true when a type is indexed (own index or inherited)
• Added directly_queryable?() to indicate when a type is a root graphql Query type
• all directly_queryable types are root_document_types, but not vice versa

Validation:

• Concrete types can implement multiple abstract types, but at most one may have an index (prevents ambiguity)

Tests

• Added inheritance tests to index_definition_names_spec.rb (concrete + transitive)
• Added __typename data_params tests to update_targets_spec.rb
• Enhanced documentation in abstract_types_spec.rb
• Removed dead root_document_type?() stubs from scalar/enum types

What's Not Included

This PR is infrastructure only:

• No examples added to widgets.rb yet
• No schema artifacts regenerated yet
• No indexer changes yet
• No GraphQL changes yet
• No end-to-end acceptance tests yet

These are deferred to PR2 (Indexer) and PR3 (Schema + GraphQL + Acceptance).

Related

• Part of Defining an index on an abstract type doesn't work correctly #1029
• Follows Refactor indexing methods for clarity ahead of "transitive" indexing #1066
• Part of 3-PR series: (1) Schema support ← this PR, (2) Indexer support, (3) End-to-end integration

[myronmarston]

I'm not done with my review (notably, I haven't reviewed the specs yet) but I wanted to submit what I have so far.

[myronmarston]

This is really close!

[myronmarston]

This is fantastic! Appreciate the back-and-forth that helped us arrive at a better design!

[myronmarston]

@marcdaniels-toast I was about to merge but I noticed that we lost some of the earlier fixes you had done, such as in 40ed8d1. I believe the changes in that commit (the added json_schema_spec.rb spec + the results.rb fix that makes that spec pass) are necessary for inherited indexes to work properly--otherwise, at ingestion time, we'll run into the error I reported in #1029.

Was that reversion intentional? (If so, can you share why?)

By the way, this PR is large enough (and we've gone through enough rounds of review) that if there is more to do (such as bring those changes back), I think I'd prefer to do it in a follow up PR so that we can merge that one and I have a smaller diff to review for the remaining changes...rather than trying to incorporate them into this already large PR.

[marcdaniels-toast]

@myronmarston I think we're okay. Notice how that commit corresponds to back when I had the previous (wrong) semantics for [root_document_type?]:

elasticgraph/elasticgraph-schema_definition/lib/elastic_graph/schema_definition/mixins/has_indices.rb

Line 105 in 40ed8d1

has_own_index_def?

So back then, I had to change the filter for matching indexed types to use !type.own_or_inherited_index_def.nil? which is now more simply done with type.root_document_type? (Is the type indexed via direct or inherited?) And hence no need to change that select condition.

That spec test does look valuable though since it tests enum type correctness for a mix of inherited and own indexes. I confirmed locally that that test passes on this branch. I can make a new PR that just adds this one test if you're still okay with merging this as is.

[myronmarston]

So back then, I had to change the filter for matching indexed types to use !type.own_or_inherited_index_def.nil? which is now more simply done with type.root_document_type? (Is the type indexed via direct or inherited?) And hence no need to change that select condition.

Makes sense, thanks!

That spec test does look valuable though since it tests enum type correctness for a mix of inherited and own indexes. I confirmed locally that that test passes on this branch. I can make a new PR that just adds this one test if you're still okay with merging this as is.

Sounds good!