Address Entity-table limitations #24427
Draft
+1,975
−105
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.
Description
Extends the entity suggestion and filtering system to support:
related_identifier) — entity attributes can now specify which column to use when relating entries, instead of always assuming_id.{node_id} ({hostname})).Motivation and Context
When using the entity table, we can define
EntityAttributes which allow us to specify arelated_collectionandrelated_property(the value displayed in the filter options).Problem 1: Wrong identifier column. Some entities don't reference related entities by MongoDB ObjectId. For example, inputs reference nodes via a
node_id(UUID string), not the node's_id. When a user selected a node from the filter dropdown, the filter returned no results because it was matching against_idwhen it should match againstnode_id.Problem 2: Non-human-readable display values. Sometimes there is no single database field that lets users easily identify an entity. For example, nodes are best identified by a combination of the short
node_idandhostname(since hostnames alone may be shared across nodes).Problem 3: Filtering on runtime state. Input runtime status (RUNNING, FAILED, etc.) is held in memory across cluster nodes, not stored in MongoDB. There was no way to filter inputs by their actual runtime state — only by
desired_state, which may differ from reality.Changes
Custom Identifier Columns
EntityAttributegains three new optional fields:related_identifier— the column in the related collection to match against (defaults to_id)related_display_fields— list of fields to include in the composite display valuerelated_display_template— template string for formatting (e.g."{node_id} ({hostname})")These are plumbed through:
EntitySuggestionResource/EntitySuggestionService— the suggestion endpoint now acceptsidentifier,display_fields,display_template, andidentifier_typequery parameters.MongoEntitySuggestionService— projects and returns the correct fields; builds display values usingCompositeDisplayFormatter.EntitySuggestionrecord — gains an optionaltargetIdfield so the frontend knows which value to use as the filter value (the identifier column value), distinct from the MongoDB_id.EntityTitleServiceImpl/EntityIdentifier— the title resolution service now respects custom identifier fields and types when looking up entity titles, and uses composite display formatting when display fields/template are provided.SuggestionsListFilter,useFilterValueSuggestions,useFiltersWithTitle,PaginationTypes) — passes the new attribute metadata through to the suggestion API and title resolution, and usestargetIdas the filter value when present.Composite Display Formatting
CompositeDisplayFormatteris a utility that builds a display string from a BSON Document:{field}placeholders with document values, cleans up empty parentheses from missing values.Computed Field Filtering
A new provider-based system for filtering on values that don't exist in MongoDB:
ComputedFieldProvider(interface) — implementations return aSet<String>of entity IDs that match a given filter value. Registered via Guice Multibinder.ComputedFieldRegistry(singleton) — maps field names to their providers. Injected intoDbFilterExpressionParser.DbFilterExpressionParser— now separates filter expressions into database fields vs. computed fields. Computed fields are resolved via their provider, and the resulting IDs are injected into the MongoDB query as{ _id: { $in: [...] } }. Multiple values for the same computed field are OR'd; different computed fields are AND'd (intersection).DbQueryCreator— accepts an optionalauthTokenparameter (needed for cluster-wide queries) and passes it through to the filter parser.Input Runtime Status (concrete example)
InputRuntimeStatusProviderimplementsComputedFieldProviderfor theruntime_statusfield:InputRegistrydirectly (no HTTP overhead).RemoteInputStatesResource.IOState.Typevalues into user-friendly categories: Running, Not Running, Setup Mode, Failed.Supporting changes:
InputRegistry— refactored to use an internalInputStateCachewith dual-indexed storage (byIdandbyStatemaps) for efficient lookups by input ID or by state. Subscribes toIOStateChangedEventon the EventBus to keep state indexes updated in real time.InputStatesResource— newGET /system/inputstates/localendpoint returningMap<String, String>(inputId → status) for cluster-wide aggregation.RemoteInputStatesResource— Retrofit interface updated withgetLocalStatuses().InputsResource— theruntime_statusattribute is defined withfilterOptions(static set of status group labels) and wired to theComputedFieldRegistry. Thedesired_stateattribute is no longer filterable (replaced byruntime_status). The paginated list endpoint extracts the auth token fromHttpHeadersand passes it through for computed field queries.ServerBindings— bindsComputedFieldRegistryand registersInputRuntimeStatusProvider.Todo:
Frontend fetches input states to refresh the input state. We need a proper batch call to return only input states for the currently viewable inputs.
Test Plan
abc123 (graylog-node-1))node_id