-
Notifications
You must be signed in to change notification settings - Fork 25.3k
Component Templates: Add {created,modified}_date
#131536
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: main
Are you sure you want to change the base?
Conversation
…-tracking * upstream/main: (44 commits) Term vector API on stateless search nodes (elastic#129902) TEST Fix ThreadPoolMergeSchedulerStressTestIT testMergingFallsBehindAndThenCatchesUp (elastic#131636) Add inference.put_custom rest-api-spec (elastic#131660) ESQL: Fewer serverless docs in tests (elastic#131651) Skip search on indices with INDEX_REFRESH_BLOCK (elastic#129132) Mute org.elasticsearch.indices.cluster.RemoteSearchForceConnectTimeoutIT testTimeoutSetting elastic#131656 [jdk] Resolve EA OpenJDK builds to our JDK archive (elastic#131237) Add optimized path for intermediate values aggregator (elastic#131390) Correctly handling download_database_on_pipeline_creation within a pipeline processor within a default or final pipeline (elastic#131236) Refresh potential lost connections at query start for `_search` (elastic#130463) Add template_id to patterned-text type (elastic#131401) Integrate LIKE/RLIKE LIST with ReplaceStringCasingWithInsensitiveRegexMatch rule (elastic#131531) [ES|QL] Add doc for the COMPLETION command (elastic#131010) ESQL: Add times to topn status (elastic#131555) ESQL: Add asynchronous pre-optimization step for logical plan (elastic#131440) ES|QL: Improve generative tests for FORK [130015] (elastic#131206) Update index mapping update privileges (elastic#130894) ESQL: Added Sample operator NamedWritable to plugin (elastic#131541) update `kibana_system` to grant it access to `.chat-*` system index (elastic#131419) Clarify heap size configuration (elastic#131607) ...
// always output millis even if instantSource returns millis == 0 | ||
private static final DateTimeFormatter ISO8601_WITH_MILLIS_FORMATTER = new DateTimeFormatterBuilder().appendInstant(3) | ||
.toFormatter(Locale.ROOT); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
can see about putting this into some util method once i merge pipelines PR
same as for pipelines, i can't find anything i can re-use for this functionality
guess i'm asking for votes whether to go util method or fine with duplication of this for pipelines/component and index templates
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Have you checked whether there is anything suitable in org.elasticsearch.common.time.DateFormatters
? If so, you should certainly use that. If not, I guess we could consider adding it. Might be worth pinging the Core Infra team who own that to see whether they think it's appropriate and if they have a view on the naming.
N.B. That would require you to use a org.elasticsearch.common.time.DateFormatter
rather than a java.time.format.DateFormatter
. This shouldn't be a problem for you. (I couldn't say why we have this interface: the only implementation of it seems to be the one which ultimately delegates to the JDK class.)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I expect your third PR will introduce a third usage of this pattern, so it's also okay if you do the work to common them up in that third PR.
@@ -70,19 +99,23 @@ public static ComponentTemplate parse(XContentParser parser) { | |||
} | |||
|
|||
public ComponentTemplate(Template template, @Nullable Long version, @Nullable Map<String, Object> metadata) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
only used in tests, so no concern about not providing created/modified_date
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Pull Request Overview
This PR adds system-managed created_date
and modified_date
tracking properties to component templates in Elasticsearch. These timestamps track when templates are created and last modified.
Key Changes
- Extended
ComponentTemplate
class to includecreatedDateMillis
andmodifiedDateMillis
fields - Modified template creation/update logic to automatically set these timestamps using an injectable
InstantSource
- Added validation to prevent users from manually setting these system-managed properties
Reviewed Changes
Copilot reviewed 15 out of 15 changed files in this pull request and generated 2 comments.
Show a summary per file
File | Description |
---|---|
ComponentTemplate.java | Added new timestamp fields, serialization/deserialization, and date formatting |
MetadataIndexTemplateService.java | Implemented timestamp logic for template creation and updates with InstantSource injection |
PutComponentTemplateAction.java | Added validation to reject user-provided timestamp values |
TransportVersions.java | Added new transport version for backward compatibility |
Various test files | Updated constructors and assertions to handle new timestamp fields |
20_tracking.yml | Added REST API tests for timestamp behavior and validation |
Comments suppressed due to low confidence (1)
server/src/main/java/org/elasticsearch/rest/action/admin/indices/RestPutComponentTemplateAction.java:34
- [nitpick] The constant name 'COMPONENT_TEMPLATE_TRACKING_INFO' doesn't follow the same naming pattern as the existing constants which describe specific features (e.g., 'SUPPORTS_FAILURE_STORE'). Consider renaming to 'SUPPORTS_COMPONENT_TEMPLATE_TRACKING_INFO' for consistency.
private static final String COMPONENT_TEMPLATE_TRACKING_INFO = "component_template_tracking_info";
server/src/test/java/org/elasticsearch/cluster/metadata/MetadataIndexTemplateServiceTests.java
Show resolved
Hide resolved
server/src/main/java/org/elasticsearch/cluster/metadata/ComponentTemplate.java
Show resolved
Hide resolved
Hi @szybia, I've created a changelog YAML for you. |
Pinging @elastic/es-data-management (Team:Data Management) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks, LGTM, just a couple of comments.
// always output millis even if instantSource returns millis == 0 | ||
private static final DateTimeFormatter ISO8601_WITH_MILLIS_FORMATTER = new DateTimeFormatterBuilder().appendInstant(3) | ||
.toFormatter(Locale.ROOT); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Have you checked whether there is anything suitable in org.elasticsearch.common.time.DateFormatters
? If so, you should certainly use that. If not, I guess we could consider adding it. Might be worth pinging the Core Infra team who own that to see whether they think it's appropriate and if they have a view on the naming.
N.B. That would require you to use a org.elasticsearch.common.time.DateFormatter
rather than a java.time.format.DateFormatter
. This shouldn't be a problem for you. (I couldn't say why we have this interface: the only implementation of it seems to be the one which ultimately delegates to the JDK class.)
...rc/main/java/org/elasticsearch/rest/action/admin/indices/RestPutComponentTemplateAction.java
Show resolved
Hide resolved
// always output millis even if instantSource returns millis == 0 | ||
private static final DateTimeFormatter ISO8601_WITH_MILLIS_FORMATTER = new DateTimeFormatterBuilder().appendInstant(3) | ||
.toFormatter(Locale.ROOT); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I expect your third PR will introduce a third usage of this pattern, so it's also okay if you do the work to common them up in that third PR.
Add new system-managed properties to component templates:
created_date
: when the template with a given ID was createdmodified_date
: when the template was updated