[
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 {{<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.
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, 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.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
