[IGNITE-14748] Ordered @NamedConfigValue

• Type: Sub-task
• Status: Resolved
• Priority: Major
• Resolution: Fixed
• Fix Version/s: 3.0.0-alpha3
• Labels: iep-55 ignite-3
• Ignite Flags: Docs Required
• Assignee: Ivan Bessonov
• Reporter: Alexander Belyak
• Reviewer: Aleksandr Polovtsev
• Created: 20/May/21 09:04
• Updated: 06/Aug/21 08:44
• Resolved: 20/Jul/21 07:25

Description

Implement some order for @NamedConfigValue fields.

Imagine that we have some

 

@Config
public class PKIndexConfigurationSchema {
    @Value
    String type;
    @NamedConfigValue
    IndexColumnConfigurationSchema columns.
 

and

 

@Config
public class IndexColumnConfigurationSchema {
    @Value
    String name;
    @Value
    boolean asc;
    @Value
    boolean affinityCol;
}

 

For now we have to use indexes to store such config like:

 

"PK":
    "type":"PrimaryKey",
    "columns": {
        "0": {
            "name":"REGION",
            "asc":true,
            "affinity":true
        },
        "1": {
            "name":"COMPANY",
            "asc":true,
            "affinity":false
        }
    }

 

because we have to keep it's order.

But if configuration keep order for @NamedConfigValue it can look like:

 

"PK":
    "type":"PrimaryKey",
    "columns": {
        "REGION": {
            "asc":true,
            "affinity":true
        },
        "COMPANY": {
            "asc":true,
            "affinity":false
        }
    }

And to allow insert value in the middle it will be nice to have some methods like:

• listChange.create(idx, key, consumer(elementChange))

or

• listChange.createAfter(prevKeyOrNull, key, consumer(elementChange))

in addition to existing:

• listChange.create(key, consumer(elementChange))
• listChange.update(key, consumer(elementChange))
• listChange.delete(key)

BTW, lets remove listChange.update method.

Implementation notes

It would make sense to store order number inside of named list entry. It would look like implicit configuration parameter <idx>, for example. This value will be recalculated on every update.

Index will be stored in named list itself, entries will not contain it. Reason is simple - named list entries can be used as regular "inner" nodes and we can't distinguish one from the another. That's why index is implicit.

API notes

I don't get why we need to remove update method. It would be helpful to update their semantics, like "create" would throw "AlreadyExistsException" or something, update would do similar thing with "KeyNotFound"...

Issue Links

• links to: GitHub Pull Request #208