[
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.
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 {{<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.
> 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.
> 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)
