[jira] [Updated] (IGNITE-14748) Ordered @NamedConfigValue

["Sergey Chugunov (Jira)" <ji...@apache.org>]

     [ https://issues.apache.org/jira/browse/IGNITE-14748?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Sergey Chugunov updated IGNITE-14748:
-------------------------------------
    Ignite Flags: Docs Required

> 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, ignite-3
>             Fix For: 3.0.0-alpha3
>
>          Time Spent: 8h 20m
>  Remaining Estimate: 0h
>
> 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)