[
https://issues.apache.org/jira/browse/IGNITE-15564?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17457157#comment-17457157
]
Semyon Danilov commented on IGNITE-15564:
-----------------------------------------
LGTM! Thanks for the contribution, merged to main
> [Ignite 3] Properly inject names into named list elements
> ---------------------------------------------------------
>
> Key: IGNITE-15564
> URL: https://issues.apache.org/jira/browse/IGNITE-15564
> Project: Ignite
> Issue Type: Improvement
> Affects Versions: 3.0.0-alpha2
> Reporter: Ivan Bessonov
> Assignee: Kirill Tkalenko
> Priority: Major
> Labels: iep-55, ignite-3
> Fix For: 3.0.0-alpha4
>
> Time Spent: 6h 20m
> Remaining Estimate: 0h
>
> h3. Problem
> Current design of named lists has a flaw that is best shown in classes like
> "TableConfigurationSchema". It's the field called "name". Simple table
> configuration would look like this (prefix "table.tables" looks bad BTW):
> {code:java}
> table.tables : {
> foo : {
> name = foo,
> etc...
> }
> }{code}
> Table name must be duplicated and I actually doubt that we validate names
> equality. Same applies to columns and indexes. There's probably more, I
> didn't check.
> Obviously, developers want to access named list element name inside of the
> element itself. And there's no API for that.
> h3. Approach
> Proper solution would be annotating name fields:
> {code:java}
> @Config
> public class TableConfigurationSchema {
> @InjectedName // temporary title, maybe there are better options
> public String name = "default";
> ...
> }{code}
> Injected name must be a string. It's treated like "@Value" field BUT has no
> "update" method associated with it. Basically, name is considered immutable
> and "explicitly uninitializable" in this context. So how do you initialize it
> then?
> * if schema is used as a named list - name is passed into "create*"/"rename"
> methods. Field is automatically updated after that.
> * if schema if used as a regular config value, we have two options:
> ** generate special extended interfaces that will in fact have setters for
> names. These will only be used for "non-named-list" values;
> ** always use default value provided in either schema itself (as in example)
> or in "@Value(name = "default") if it makes any sense. This option looks
> better for me and it's easier to implement.
> h3. Implementation notes
> Compile-time code generation is easy, just reuse already existing methods and
> add few "if" clauses.
> I don't think that methods like "traverse*" or "construct*" should process
> name fields. So there's a filtering to be done in ConfigurationAsmGenerator.
> "NamedConfigValue#syntheticKeyName" should probably be removed. Instead we
> should use injected field name or just "name" if there's none. Otherwise
> there will be a confusion.
> All classes that use constant "NamedListNode#NAME" are a subject to
> modification. There's a high chance that they will inject values for
> annotated fields. Maybe we need a new method in "InnerNode" for this, it's
> not clear yet.
> Classes that implement ConfigurationSource should be carefully examined as
> well, especially HOCON* ones.
>
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
