[IGNITE-15564] [Ignite 3] Properly inject names into named list elements

• Type: Improvement
• Status: Resolved
• Priority: Major
• Resolution: Resolved
• Affects Version/s: 3.0.0-alpha2
• Fix Version/s: 3.0.0-alpha4
• Labels: iep-55 ignite-3
• Epic Link: Configuration
• Assignee: Kirill Tkalenko
• Reporter: Ivan Bessonov
• Reviewer: Ivan Bessonov
• Created: 23/Sep/21 08:03
• Updated: 10/Dec/21 13:51
• Resolved: 10/Dec/21 13:51

Description

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):

table.tables : {
    foo : {
        name = foo,
        etc...
    }
}

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.

Approach

Proper solution would be annotating name fields:

@Config
public class TableConfigurationSchema {
    @InjectedName // temporary title, maybe there are better options
    public String name = "default";

    ...
}

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.

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.

 

Issue Links

• links to: GitHub Pull Request #490