[ https://issues.apache.org/jira/browse/IGNITE-14748?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Ivan Bessonov reassigned IGNITE-14748: -------------------------------------- Assignee: Ivan Bessonov > Ordered @NamedConfigValue > ------------------------- > > Key: IGNITE-14748 > URL: https://issues.apache.org/jira/browse/IGNITE-14748 > Project: Ignite > Issue Type: Sub-task > Reporter: Alexander Belyak > Assignee: Ivan Bessonov > Priority: Major > Labels: iep-55 > > Implement some order for @NamedConfigValue fields. > Imagine that we have some > > {code:java} > @Config > public class PKIndexConfigurationSchema { > @Value > String type; > @NamedConfigValue > IndexColumnConfigurationSchema columns. > > {code} > and > > {code:java} > @Config > public class IndexColumnConfigurationSchema { > @Value > String name; > @Value > boolean asc; > @Value > boolean affinityCol; > } > {code} > > For now we have to use indexes to store such config like: > > {noformat} > "PK": > "type":"PrimaryKey", > "columns": { > "0": { > "name":"REGION", > "asc":true, > "affinity":true > }, > "1": { > "name":"COMPANY", > "asc":true, > "affinity":false > } > } > {noformat} > > because we have to keep it's order. > But if configuration keep order for @NamedConfigValue it can look like: > > {noformat} > "PK": > "type":"PrimaryKey", > "columns": { > "REGION": { > "asc":true, > "affinity":true > }, > "COMPANY": { > "asc":true, > "affinity":false > } > } > {noformat} > 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. > h3. 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. > h3. 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"... -- This message was sent by Atlassian Jira (v8.3.4#803005)