[jira] [Updated] (IGNITE-14748) Ordered @NamedConfigValue
[ 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 {{}}, 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)
[jira] [Updated] (IGNITE-14748) Ordered @NamedConfigValue
[ https://issues.apache.org/jira/browse/IGNITE-14748?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ivan Bessonov updated IGNITE-14748: --- Ignite Flags: (was: Docs Required,Release Notes 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: 10m > 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 {{}}, 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)
[jira] [Updated] (IGNITE-14748) Ordered @NamedConfigValue
[ https://issues.apache.org/jira/browse/IGNITE-14748?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ivan Bessonov updated IGNITE-14748: --- Labels: iep-55 ignite-3 (was: iep-55) > 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 > Time Spent: 10m > 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 {{}}, 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)
[jira] [Updated] (IGNITE-14748) Ordered @NamedConfigValue
[ https://issues.apache.org/jira/browse/IGNITE-14748?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ivan Bessonov updated IGNITE-14748: --- Fix Version/s: 3.0.0-alpha3 > 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: 10m > 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 {{}}, 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)
[jira] [Updated] (IGNITE-14748) Ordered @NamedConfigValue
[ https://issues.apache.org/jira/browse/IGNITE-14748?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ivan Bessonov updated IGNITE-14748: --- Labels: iep-55 (was: ) > Ordered @NamedConfigValue > - > > Key: IGNITE-14748 > URL: https://issues.apache.org/jira/browse/IGNITE-14748 > Project: Ignite > Issue Type: Sub-task >Reporter: Alexander Belyak >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 {{}}, 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)
[jira] [Updated] (IGNITE-14748) Ordered @NamedConfigValue
[ https://issues.apache.org/jira/browse/IGNITE-14748?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ivan Bessonov updated IGNITE-14748: --- Description: 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 {{}}, 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"... was: 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 {{}}, 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. > Ordered @NamedConfigValue > - > > Key: IGNITE-14748 > URL: https://issues.apache.org/jira/browse/IGNITE-14748 > Project: Ignite > Issue Type: Sub-task >Reporter: Alexander Belyak >Priority: Major > > Implement some order for @NamedConfigValue fields. > Imagine that we have some > > {code:java} > @Config > public class PKIndexConfigurationSchema { > @Value > String type; > @NamedConfigValue > IndexColumnConfigurationSchema columns.
[jira] [Updated] (IGNITE-14748) Ordered @NamedConfigValue
[ https://issues.apache.org/jira/browse/IGNITE-14748?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ivan Bessonov updated IGNITE-14748: --- Description: 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 {{}}, 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. was: 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. > Ordered @NamedConfigValue > - > > Key: IGNITE-14748 > URL: https://issues.apache.org/jira/browse/IGNITE-14748 > Project: Ignite > Issue Type: Sub-task >Reporter: Alexander Belyak >Priority: Major > > 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
[jira] [Updated] (IGNITE-14748) Ordered @NamedConfigValue
[ https://issues.apache.org/jira/browse/IGNITE-14748?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexander Belyak updated IGNITE-14748: -- Description: 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. was: 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. > Ordered @NamedConfigValue > - > > Key: IGNITE-14748 > URL: https://issues.apache.org/jira/browse/IGNITE-14748 > Project: Ignite > Issue Type: Sub-task >Reporter: Alexander Belyak >Priority: Major > > 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: > *
[jira] [Updated] (IGNITE-14748) Ordered @NamedConfigValue
[ https://issues.apache.org/jira/browse/IGNITE-14748?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexander Belyak updated IGNITE-14748: -- Description: 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. was: 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. > Ordered @NamedConfigValue > - > > Key: IGNITE-14748 > URL: https://issues.apache.org/jira/browse/IGNITE-14748 > Project: Ignite > Issue Type: Sub-task >Reporter: Alexander Belyak >Priority: Major > > 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,
[jira] [Updated] (IGNITE-14748) Ordered @NamedConfigValue
[ https://issues.apache.org/jira/browse/IGNITE-14748?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexander Belyak updated IGNITE-14748: -- Parent: IGNITE-13511 Issue Type: Sub-task (was: Improvement) > Ordered @NamedConfigValue > - > > Key: IGNITE-14748 > URL: https://issues.apache.org/jira/browse/IGNITE-14748 > Project: Ignite > Issue Type: Sub-task >Reporter: Alexander Belyak >Priority: Major > > 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. > > -- This message was sent by Atlassian Jira (v8.3.4#803005)