Ivan Bessonov created IGNITE-15564:
--------------------------------------
Summary: [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
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.3.4#803005)
