Skip to content

Build namespace types as object types#1264

Open
jwils wants to merge 1 commit into
mainfrom
joshuaw/namespace-type-factory-extensions
Open

Build namespace types as object types#1264
jwils wants to merge 1 commit into
mainfrom
joshuaw/namespace-type-factory-extensions

Conversation

@jwils

@jwils jwils commented Jun 20, 2026

Copy link
Copy Markdown
Collaborator

Summary

Namespace types are now built as regular ObjectType instances via new_object_type. new_namespace_type applies the namespace-specific settings (graphql_only true and resolve_fields_with nil) before yielding, so object-type factory extensions apply to namespace types without swapping constructors or maintaining a dedicated NamespaceType subclass.

Because GraphQL-only types have no backing datastore representation, HasIndices#index now rejects index definitions on any GraphQL-only type. That keeps namespace types unindexable at the shared indexing boundary instead of via a namespace-only subclass override.

The Apollo factory extension no longer needs a separate namespace hook because namespace creation now flows through its existing new_object_type extension.

Testing Performed

  • bundle exec rspec elasticgraph-schema_definition/spec/unit/elastic_graph/schema_definition/factory_spec.rb
  • bundle exec rspec elasticgraph-schema_definition/spec/unit/elastic_graph/schema_definition/graphql_schema/namespace_type_spec.rb elasticgraph-schema_definition/spec/unit/elastic_graph/schema_definition/graphql_schema/object_type_spec.rb
  • bundle exec rspec elasticgraph-schema_definition/spec/unit/elastic_graph/schema_definition/runtime_metadata/object_types_by_name/namespace_type_spec.rb elasticgraph-schema_definition/spec/unit/elastic_graph/schema_definition/datastore_config/index_mappings/namespace_type_spec.rb
  • bundle exec rspec elasticgraph-apollo/spec/unit/elastic_graph/apollo/schema_definition_spec.rb
  • script/type_check
  • script/lint
  • git diff --check

@myronmarston myronmarston left a comment

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The approach you've taken here feels pretty messy. Temporarily changing what's essentially a global variable never feels good.

Two alternate approaches I'd consider:

  1. Delegation: instead of having NamespaceType subclass ObjectType, do class NamespaceType < DelegateClass(ObjectType) so that it wraps an object_type instance. Then a new_object_type override in an extension will apply to the ObjectType that gets wrapped by NamespaceType.
  2. Don't use a separate type for namespace_type at all--instead, have factory.new_namespace_type use factory.new_object_type and apply namespace-specific settings (e.g. graphql_only true, resolve_fields_with nil) to it before yielding. For the index override that raises an error we could have the root index method raise an error for graphql_only types as it doesn't make sense to define an index on a graphql-only type.

I think I like the latter solution best, as namespace_type.rb doesn't really have much logic.

Thoughts?

@jwils jwils force-pushed the joshuaw/namespace-type-factory-extensions branch from 9a863cb to c920a13 Compare June 20, 2026 20:52
Namespace types behave like regular object types with a couple of factory-applied settings: they are GraphQL-only and have no default field resolver. Build them through new_object_type so object-type factory extensions still apply, without introducing a separate NamespaceType subclass or mutating factory constructor state.

Since GraphQL-only types have no backing datastore representation, reject index definitions for any GraphQL-only type in HasIndices#index. This keeps namespace types unindexable and makes the invariant explicit at the shared indexing boundary.
@jwils jwils force-pushed the joshuaw/namespace-type-factory-extensions branch from c920a13 to 6af2bef Compare June 20, 2026 21:57
@jwils jwils changed the title Build namespace types through new_object_type Build namespace types as object types Jun 20, 2026
@jwils

jwils commented Jun 20, 2026

Copy link
Copy Markdown
Collaborator Author

Option 1 I think looked just as messy, so agree with you and went with option 2. @rossroberts-toast let me know if you have any concerns.

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.

2 participants