[Discussion] Apache Ignite 2.11 Scope Freeze
Hi, Igniters! I'm going to start scope freeze and leave only Resolved tickets in it [1]. You are welcome to discuss. [1] https://lists.apache.org/thread.html/a4be115d2bd4318ae958ac91aba40294dfd62f293b3cb264c8fcf0ae%40%3Cdev.ignite.apache.org%3E
Re: [Discussion] Apache Ignite 2.11 Scope Freeze
I'm planning to diverge branch at 16:00 MSK 7 June, 2021 And here is 2.11 release wiki page [1] [1] https://cwiki.apache.org/confluence/display/IGNITE/Apache+Ignite+2.11 On 2021/06/04 09:11:49, Alexey Gidaspov wrote: > Hi, Igniters! > > I'm going to start scope freeze and leave only Resolved tickets in it [1]. > You are welcome to discuss. > > [1] > https://lists.apache.org/thread.html/a4be115d2bd4318ae958ac91aba40294dfd62f293b3cb264c8fcf0ae%40%3Cdev.ignite.apache.org%3E >
Re: [Discussion] Apache Ignite 2.11 Scope Freeze
I've updated the page https://cwiki.apache.org/confluence/display/IGNITE/Apache+Ignite+2.11 since final freeze is technically possible only after branch divergence (see also https://cwiki.apache.org/confluence/display/IGNITE/Release+Process) Sincerely On 2021/06/04 09:56:15, Alexey Gidaspov wrote: > I'm planning to diverge branch at 16:00 MSK 7 June, 2021 > > And here is 2.11 release wiki page [1] > > [1] https://cwiki.apache.org/confluence/display/IGNITE/Apache+Ignite+2.11 > > On 2021/06/04 09:11:49, Alexey Gidaspov wrote: > > Hi, Igniters! > > > > I'm going to start scope freeze and leave only Resolved tickets in it [1]. > > You are welcome to discuss. > > > > [1] > > https://lists.apache.org/thread.html/a4be115d2bd4318ae958ac91aba40294dfd62f293b3cb264c8fcf0ae%40%3Cdev.ignite.apache.org%3E > > >
Unable to edit fixVersion in jira tickets
Hi, All! What should I do to be able to edit fixVersion in jira tickets?
Re: Unable to edit fixVersion in jira tickets
Hi Alexey, What's your JIRA username? On Fri, Jun 4, 2021 at 1:50 PM Alexey Gidaspov wrote: > Hi, All! > > What should I do to be able to edit fixVersion in jira tickets? >
Re: Unable to edit fixVersion in jira tickets
Hi, Pavel. My JIRA login is agidaspov On 2021/06/04 11:14:02, Pavel Tupitsyn wrote: > Hi Alexey, > > What's your JIRA username? > > On Fri, Jun 4, 2021 at 1:50 PM Alexey Gidaspov wrote: > > > Hi, All! > > > > What should I do to be able to edit fixVersion in jira tickets? > > >
Re: Unable to edit fixVersion in jira tickets
Added you to the Contributors role, now you should be able to edit tickets. On Fri, Jun 4, 2021 at 2:16 PM Alexey Gidaspov wrote: > Hi, Pavel. > > My JIRA login is agidaspov > > On 2021/06/04 11:14:02, Pavel Tupitsyn wrote: > > Hi Alexey, > > > > What's your JIRA username? > > > > On Fri, Jun 4, 2021 at 1:50 PM Alexey Gidaspov > wrote: > > > > > Hi, All! > > > > > > What should I do to be able to edit fixVersion in jira tickets? > > > > > >
Re: Unable to edit fixVersion in jira tickets
Thank you. Now I'm able to edit tickets. One more question - how can I create new version to move some tickets to 2.12? On 2021/06/04 11:37:55, Pavel Tupitsyn wrote: > Added you to the Contributors role, now you should be able to edit tickets. > > > On Fri, Jun 4, 2021 at 2:16 PM Alexey Gidaspov wrote: > > > Hi, Pavel. > > > > My JIRA login is agidaspov > > > > On 2021/06/04 11:14:02, Pavel Tupitsyn wrote: > > > Hi Alexey, > > > > > > What's your JIRA username? > > > > > > On Fri, Jun 4, 2021 at 1:50 PM Alexey Gidaspov > > wrote: > > > > > > > Hi, All! > > > > > > > > What should I do to be able to edit fixVersion in jira tickets? > > > > > > > > > >
Re: [Discussion] Apache Ignite 2.11 Scope Freeze
Hello Alexey. We have implemented a feature to automatically restore the cache group from a snapshot [1]. But this feature requires CLI management [2], which is currently on review and should also be included in 2.11. We plan to finish with it next week. [1] https://issues.apache.org/jira/browse/IGNITE-13805 [2] https://issues.apache.org/jira/browse/IGNITE-14723 пт, 4 июн. 2021 г. в 13:01, Dmitry Pavlov : > > I've updated the page > https://cwiki.apache.org/confluence/display/IGNITE/Apache+Ignite+2.11 > > since final freeze is technically possible only after branch divergence (see > also https://cwiki.apache.org/confluence/display/IGNITE/Release+Process) > > Sincerely > > On 2021/06/04 09:56:15, Alexey Gidaspov wrote: > > I'm planning to diverge branch at 16:00 MSK 7 June, 2021 > > > > And here is 2.11 release wiki page [1] > > > > [1] https://cwiki.apache.org/confluence/display/IGNITE/Apache+Ignite+2.11 > > > > On 2021/06/04 09:11:49, Alexey Gidaspov wrote: > > > Hi, Igniters! > > > > > > I'm going to start scope freeze and leave only Resolved tickets in it > > > [1]. You are welcome to discuss. > > > > > > [1] > > > https://lists.apache.org/thread.html/a4be115d2bd4318ae958ac91aba40294dfd62f293b3cb264c8fcf0ae%40%3Cdev.ignite.apache.org%3E > > > > >
Re: Unable to edit fixVersion in jira tickets
It is in Admin panel: https://issues.apache.org/jira/plugins/servlet/project-config/IGNITE/administer-versions?status=unreleased Not sure if Contributors can add new versions, so I've added 2.12 there. On Fri, Jun 4, 2021 at 2:41 PM Alexey Gidaspov wrote: > Thank you. Now I'm able to edit tickets. One more question - how can I > create new version to move some tickets to 2.12? > > On 2021/06/04 11:37:55, Pavel Tupitsyn wrote: > > Added you to the Contributors role, now you should be able to edit > tickets. > > > > > > On Fri, Jun 4, 2021 at 2:16 PM Alexey Gidaspov > wrote: > > > > > Hi, Pavel. > > > > > > My JIRA login is agidaspov > > > > > > On 2021/06/04 11:14:02, Pavel Tupitsyn wrote: > > > > Hi Alexey, > > > > > > > > What's your JIRA username? > > > > > > > > On Fri, Jun 4, 2021 at 1:50 PM Alexey Gidaspov > > > > wrote: > > > > > > > > > Hi, All! > > > > > > > > > > What should I do to be able to edit fixVersion in jira tickets? > > > > > > > > > > > > > > >
Re: Unable to edit fixVersion in jira tickets
Indeed contributor cannot edit project configuration. So thank you very much. On 2021/06/04 12:13:21, Pavel Tupitsyn wrote: > It is in Admin panel: > https://issues.apache.org/jira/plugins/servlet/project-config/IGNITE/administer-versions?status=unreleased > > Not sure if Contributors can add new versions, so I've added 2.12 there. > > On Fri, Jun 4, 2021 at 2:41 PM Alexey Gidaspov wrote: > > > Thank you. Now I'm able to edit tickets. One more question - how can I > > create new version to move some tickets to 2.12? > > > > On 2021/06/04 11:37:55, Pavel Tupitsyn wrote: > > > Added you to the Contributors role, now you should be able to edit > > tickets. > > > > > > > > > On Fri, Jun 4, 2021 at 2:16 PM Alexey Gidaspov > > wrote: > > > > > > > Hi, Pavel. > > > > > > > > My JIRA login is agidaspov > > > > > > > > On 2021/06/04 11:14:02, Pavel Tupitsyn wrote: > > > > > Hi Alexey, > > > > > > > > > > What's your JIRA username? > > > > > > > > > > On Fri, Jun 4, 2021 at 1:50 PM Alexey Gidaspov > > > > > > wrote: > > > > > > > > > > > Hi, All! > > > > > > > > > > > > What should I do to be able to edit fixVersion in jira tickets? > > > > > > > > > > > > > > > > > > > > >
Re: [Discussion] Apache Ignite 2.11 Scope Freeze
Hello, Pavel. Can you specify the date more precisly? On 2021/06/04 12:05:53, Pavel Pereslegin wrote: > Hello Alexey. > > We have implemented a feature to automatically restore the cache group > from a snapshot [1]. > But this feature requires CLI management [2], which is currently on > review and should also be included in 2.11. We plan to finish with it > next week. > > [1] https://issues.apache.org/jira/browse/IGNITE-13805 > [2] https://issues.apache.org/jira/browse/IGNITE-14723 > > пт, 4 июн. 2021 г. в 13:01, Dmitry Pavlov : > > > > I've updated the page > > https://cwiki.apache.org/confluence/display/IGNITE/Apache+Ignite+2.11 > > > > since final freeze is technically possible only after branch divergence > > (see also > > https://cwiki.apache.org/confluence/display/IGNITE/Release+Process) > > > > Sincerely > > > > On 2021/06/04 09:56:15, Alexey Gidaspov wrote: > > > I'm planning to diverge branch at 16:00 MSK 7 June, 2021 > > > > > > And here is 2.11 release wiki page [1] > > > > > > [1] https://cwiki.apache.org/confluence/display/IGNITE/Apache+Ignite+2.11 > > > > > > On 2021/06/04 09:11:49, Alexey Gidaspov wrote: > > > > Hi, Igniters! > > > > > > > > I'm going to start scope freeze and leave only Resolved tickets in it > > > > [1]. You are welcome to discuss. > > > > > > > > [1] > > > > https://lists.apache.org/thread.html/a4be115d2bd4318ae958ac91aba40294dfd62f293b3cb264c8fcf0ae%40%3Cdev.ignite.apache.org%3E > > > > > > > >
Re: IEP-54: Schema-first approach for 3.0
Hi Igniters,
I and Alex Scherbakov had a discussion on how we could write rows in a more
compact way.
Many thanks to Alex for his ideas and critics.
So, in a long-read below I want to share some thoughts.
Motivation.
In Ignite 3.0 we will have versioned schema and most of the meta info will
be stored in the schema.
This approach gives lesser overheard on row size comparing to BinatyObject
in Ignite 2.0,
but I see we can still save up to 5-25% in some use cases that look
promising.
Apparently, there always is a trade-off between row footprint, field access
performance, and code complexity.
We won't fight to the death for every single byte, but for a relatively low
row footprint overhead.
but still can have different formats/technics for writing compact meta
(sizes, offsets ...) to cover common use cases.
Description.
Ignite table/index operations (but not only them) performance correlates
with the key size.
Because of this, we recommend having the smallest keys as possible, and
small keys like long, UUID, or short strings are widely used.
Value size may differ and depends on the use case. AFAIK some user needs
MB+ sized values.
I don't know if any corner cases take place in production, such as 100+
varlen short columns (especially short) or huge values, or keys > 64kb.
and if they are relevant to Ignite goals and target auditory.
Below I use the term 'chunk' meaning a key or value byte sequence.
Points and technics to save few bytes:
* Chunk size.
If the key is a single long value then using a single byte instead of short
may reduce overhead twice (25% -> 12%).
* Vartable item size (varlen column offset or varlen column size).
Here we can save noticeable amount of byte if the user has many short
varlen columns.
E.g. 10 short strings of 10 bytes (100 in total) can save 10%.
* Using varlen column sizes instead of offsets.
We can use items of 'byte' even if total chunk size do not fit into a byte.
E.g. if the user has 30 strings each of 10 chars (300 bytes in total) then
using 'sizes' of byte (instead of short) here we could save 10%.
This increases complexity (up to linear) to column offset calculation, but
I think we shouldn't bother about performance impact here.
Because CPU is cheap here: vartable items resides locally and in most cases
(32-64) varlen column sizes can fit into one cache line
and calculations can be effectively vectorized.
* Use 'varInt' format for sizes.
Shortly: VarInt format implies we use a sign bit as a flag if a data spans
over more bytes or not.
So, positive byte means byte value. A negative byte means value spans for
more bytes and we have to drop the sign bit and concat the rest 7-bits with
the next byte.
Thus, if a number fits a smaller type then we can use lesser bytes to store
it.
Total chunk size calculation may be a bit tricky
* Strings size precalculation.
The problem is we need to analyze characters to estimate string size before
start key/value serialization.
We can estimate sizes for long strings though, e.g. check symbol-by-symbol
for strings of 64-255, as char[63] will always fit byte[255] and char[256]
will never fit byte[255].
(with varInt format 32-127 bounds can be used).
There are other more restrictive ways:
* Varlen table (vartable) size of byte.
Does one need more than 255 varlen columns? E.g. Oracle has a limit of 1000
total columns.
Actually, the impact is low enough, we can save a byte per-varlen column.
Moreover, we already have optimization to skip the first varlen offset (or
last varlen length).
So, we will not write a vartable for a single varlen column in a chunk.
* Restrict varlen sizes to 64kb and introduce BLOB type for varlength >
64kb.
This allows excluding cases with items of 'int' in vartable. Therefore,
reduces the number of flags, chunk reader/writer implementations, and
overall code complexity.
I'd suggest discussing BLOB type in a separate thread and implements
separately.
Shortly, we can store BLOB 'uuid' in a row instead, and store BLOB content
in separate storage. RowAssembler can write row bytes and pairs
('uuid','content') separately to different arrays. The transport protocol
should be aware of BLOBs.
* Alex idea. We can have 2 varlen tables for small (len of < 255 bytes) and
large varlens (len of < 64k) with byte and short offsets correspondingly.
It is assumed varlen columns are sorted by their types (e.g. shorter first).
Thus can be effective if the user have a number of small varlens and a
larger one. The larger one will force us to use longer vartable items.
The drawback is a user must define max-length constraint for varlens
columns at a schema declaration step to turn on optimization for columns of
short types.
Because column order is defined in the schema, we can't resort to columns
for row in runtime and apply optimization for short values of long-type
columns.
E.g. user defines VARCHAR(1024) column in a schema and pass a short value
of 10 chars, we can't use first vartable item for that string as a second
vartab
Re: [Discussion] Apache Ignite 2.11 Scope Freeze
Hopefully we'll be done by the end of next week (2021.06.11). пт, 4 июн. 2021 г. в 16:06, Alexey Gidaspov : > > Hello, Pavel. > > Can you specify the date more precisly? > > On 2021/06/04 12:05:53, Pavel Pereslegin wrote: > > Hello Alexey. > > > > We have implemented a feature to automatically restore the cache group > > from a snapshot [1]. > > But this feature requires CLI management [2], which is currently on > > review and should also be included in 2.11. We plan to finish with it > > next week. > > > > [1] https://issues.apache.org/jira/browse/IGNITE-13805 > > [2] https://issues.apache.org/jira/browse/IGNITE-14723 > > > > пт, 4 июн. 2021 г. в 13:01, Dmitry Pavlov : > > > > > > I've updated the page > > > https://cwiki.apache.org/confluence/display/IGNITE/Apache+Ignite+2.11 > > > > > > since final freeze is technically possible only after branch divergence > > > (see also > > > https://cwiki.apache.org/confluence/display/IGNITE/Release+Process) > > > > > > Sincerely > > > > > > On 2021/06/04 09:56:15, Alexey Gidaspov wrote: > > > > I'm planning to diverge branch at 16:00 MSK 7 June, 2021 > > > > > > > > And here is 2.11 release wiki page [1] > > > > > > > > [1] > > > > https://cwiki.apache.org/confluence/display/IGNITE/Apache+Ignite+2.11 > > > > > > > > On 2021/06/04 09:11:49, Alexey Gidaspov wrote: > > > > > Hi, Igniters! > > > > > > > > > > I'm going to start scope freeze and leave only Resolved tickets in it > > > > > [1]. You are welcome to discuss. > > > > > > > > > > [1] > > > > > https://lists.apache.org/thread.html/a4be115d2bd4318ae958ac91aba40294dfd62f293b3cb264c8fcf0ae%40%3Cdev.ignite.apache.org%3E > > > > > > > > > > >
[DISCUSSION] Code style. Variable abbrevations
Hello, Igniters. Right now, we have the rule to use some predefined list of abbrevation for variable names [1]. Some of the reviewers ask to follow this rule strictly. > It is required to use abbreviated form for code consistency. I tried to implement this rule in form of checkstyle check [2] and it seems like many of use doesn’t follow this requirement. My check found 4124 violation in core module. Should we make this rule optional in documentation or should we remove it completely? Or should someone proceed and fix all the violations? WDYT? Example of output: ``` [ERROR] /Users/sbt-izhikov-nv/work/ignite/modules/core/src/test/java/org/apache/ignite/internal/processors/cache/persistence/db/IgnitePdsWithTtlTest.java:94: Abbrevation should be used for CACHE_NAME_LOCAL_ATOMIC! Please, use loc, instead of LOCAL [IgniteAbbrevationsRule] [ERROR] /Users/sbt-izhikov-nv/work/ignite/modules/core/src/test/java/org/apache/ignite/internal/processors/cache/persistence/db/IgnitePdsWithTtlTest.java:97: Abbrevation should be used for CACHE_NAME_LOCAL_TX! Please, use loc, instead of LOCAL [IgniteAbbrevationsRule] [ERROR] /Users/sbt-izhikov-nv/work/ignite/modules/core/src/test/java/org/apache/ignite/internal/processors/cache/persistence/db/IgnitePdsWithTtlTest.java:264: Abbrevation should be used for checkpointManager! Please, use mgr, instead of Manager [IgniteAbbrevationsRule] [ERROR] /Users/sbt-izhikov-nv/work/ignite/modules/core/src/test/java/org/apache/ignite/internal/processors/cache/persistence/db/IgnitePdsPartitionPreloadTest.java:63: Abbrevation should be used for DEFAULT_REGION! Please, use dflt, instead of DEFAULT [IgniteAbbrevationsRule] [ERROR] /Users/sbt-izhikov-nv/work/ignite/modules/core/src/test/java/org/apache/ignite/internal/processors/cache/persistence/db/IgnitePdsWholeClusterRestartTest.java:47: Abbrevation should be used for ENTRIES_COUNT! Please, use cnt, instead of COUNT [IgniteAbbrevationsRule] [ERROR] /Users/sbt-izhikov-nv/work/ignite/modules/core/src/test/java/org/apache/ignite/internal/processors/cache/persistence/db/IgnitePdsRebalancingOnNotStableTopologyTest.java:49: Abbrevation should be used for CHECKPOINT_FREQUENCY! Please, use freq, instead of FREQUENCY [IgniteAbbrevationsRule] [ERROR] /Users/sbt-izhikov-nv/work/ignite/modules/core/src/test/java/org/apache/ignite/internal/processors/cache/persistence/db/IgnitePdsTransactionsHangTest.java:75: Abbrevation should be used for MAX_KEY_COUNT! Please, use cnt, instead of COUNT [IgniteAbbrevationsRule] [ERROR] /Users/sbt-izhikov-nv/work/ignite/modules/core/src/test/java/org/apache/ignite/internal/processors/cache/persistence/db/IgnitePdsTransactionsHangTest.java:78: Abbrevation should be used for CHECKPOINT_FREQUENCY! Please, use freq, instead of FREQUENCY [IgniteAbbrevationsRule] [ERROR] /Users/sbt-izhikov-nv/work/ignite/modules/core/src/test/java/org/apache/ignite/internal/processors/cache/persistence/db/SlowHistoricalRebalanceSmallHistoryTest.java:57: Abbrevation should be used for SUPPLY_MESSAGE_LATCH! Please, use msg, instead of MESSAGE [IgniteAbbrevationsRule] [ERROR] /Users/sbt-izhikov-nv/work/ignite/modules/core/src/test/java/org/apache/ignite/internal/processors/cache/persistence/db/IgniteLogicalRecoveryTest.java:74: Abbrevation should be used for SHARED_GROUP_NAME! Please, use grp, instead of GROUP [IgniteAbbrevationsRule] [ERROR] /Users/sbt-izhikov-nv/work/ignite/modules/core/src/test/java/org/apache/ignite/internal/processors/cache/persistence/db/IgniteLogicalRecoveryTest.java:200: Abbrevation should be used for cacheLoader! Please, use ldr, instead of Loader [IgniteAbbrevationsRule] ``` [1] https://cwiki.apache.org/confluence/display/IGNITE/Abbreviation+Rules#AbbreviationRules-VariableAbbreviation [2] https://github.com/apache/ignite/pull/9153
Re: [DISCUSSION] Code style. Variable abbrevations
In my opinion, we should remove this rule. Looks like a waste of time. freq or frequency, cnt or count, it is fine either way. On Fri, Jun 4, 2021 at 7:39 PM Nikolay Izhikov wrote: > Hello, Igniters. > > Right now, we have the rule to use some predefined list of abbrevation for > variable names [1]. > Some of the reviewers ask to follow this rule strictly. > > > It is required to use abbreviated form for code consistency. > > I tried to implement this rule in form of checkstyle check [2] and it > seems like many of use doesn’t follow this requirement. > My check found 4124 violation in core module. > > Should we make this rule optional in documentation or should we remove it > completely? > Or should someone proceed and fix all the violations? > > WDYT? > > > Example of output: > ``` > [ERROR] > /Users/sbt-izhikov-nv/work/ignite/modules/core/src/test/java/org/apache/ignite/internal/processors/cache/persistence/db/IgnitePdsWithTtlTest.java:94: > Abbrevation should be used for CACHE_NAME_LOCAL_ATOMIC! Please, use loc, > instead of LOCAL [IgniteAbbrevationsRule] > [ERROR] > /Users/sbt-izhikov-nv/work/ignite/modules/core/src/test/java/org/apache/ignite/internal/processors/cache/persistence/db/IgnitePdsWithTtlTest.java:97: > Abbrevation should be used for CACHE_NAME_LOCAL_TX! Please, use loc, > instead of LOCAL [IgniteAbbrevationsRule] > [ERROR] > /Users/sbt-izhikov-nv/work/ignite/modules/core/src/test/java/org/apache/ignite/internal/processors/cache/persistence/db/IgnitePdsWithTtlTest.java:264: > Abbrevation should be used for checkpointManager! Please, use mgr, instead > of Manager [IgniteAbbrevationsRule] > [ERROR] > /Users/sbt-izhikov-nv/work/ignite/modules/core/src/test/java/org/apache/ignite/internal/processors/cache/persistence/db/IgnitePdsPartitionPreloadTest.java:63: > Abbrevation should be used for DEFAULT_REGION! Please, use dflt, instead of > DEFAULT [IgniteAbbrevationsRule] > [ERROR] > /Users/sbt-izhikov-nv/work/ignite/modules/core/src/test/java/org/apache/ignite/internal/processors/cache/persistence/db/IgnitePdsWholeClusterRestartTest.java:47: > Abbrevation should be used for ENTRIES_COUNT! Please, use cnt, instead of > COUNT [IgniteAbbrevationsRule] > [ERROR] > /Users/sbt-izhikov-nv/work/ignite/modules/core/src/test/java/org/apache/ignite/internal/processors/cache/persistence/db/IgnitePdsRebalancingOnNotStableTopologyTest.java:49: > Abbrevation should be used for CHECKPOINT_FREQUENCY! Please, use freq, > instead of FREQUENCY [IgniteAbbrevationsRule] > [ERROR] > /Users/sbt-izhikov-nv/work/ignite/modules/core/src/test/java/org/apache/ignite/internal/processors/cache/persistence/db/IgnitePdsTransactionsHangTest.java:75: > Abbrevation should be used for MAX_KEY_COUNT! Please, use cnt, instead of > COUNT [IgniteAbbrevationsRule] > [ERROR] > /Users/sbt-izhikov-nv/work/ignite/modules/core/src/test/java/org/apache/ignite/internal/processors/cache/persistence/db/IgnitePdsTransactionsHangTest.java:78: > Abbrevation should be used for CHECKPOINT_FREQUENCY! Please, use freq, > instead of FREQUENCY [IgniteAbbrevationsRule] > [ERROR] > /Users/sbt-izhikov-nv/work/ignite/modules/core/src/test/java/org/apache/ignite/internal/processors/cache/persistence/db/SlowHistoricalRebalanceSmallHistoryTest.java:57: > Abbrevation should be used for SUPPLY_MESSAGE_LATCH! Please, use msg, > instead of MESSAGE [IgniteAbbrevationsRule] > [ERROR] > /Users/sbt-izhikov-nv/work/ignite/modules/core/src/test/java/org/apache/ignite/internal/processors/cache/persistence/db/IgniteLogicalRecoveryTest.java:74: > Abbrevation should be used for SHARED_GROUP_NAME! Please, use grp, instead > of GROUP [IgniteAbbrevationsRule] > [ERROR] > /Users/sbt-izhikov-nv/work/ignite/modules/core/src/test/java/org/apache/ignite/internal/processors/cache/persistence/db/IgniteLogicalRecoveryTest.java:200: > Abbrevation should be used for cacheLoader! Please, use ldr, instead of > Loader [IgniteAbbrevationsRule] > ``` > > [1] > https://cwiki.apache.org/confluence/display/IGNITE/Abbreviation+Rules#AbbreviationRules-VariableAbbreviation > [2] https://github.com/apache/ignite/pull/9153 > >
Re: [DISCUSSION] Code style. Variable abbrevations
+1 for removal. Cnt and count both seem to be fine. Manual rule enforcement saves a couple of symbols in code, but requires some time from both contributor and reviewer. Sincerely, Dmitriy Pavlov On 2021/06/04 19:18:37, Pavel Tupitsyn wrote: > In my opinion, we should remove this rule. > Looks like a waste of time. freq or frequency, cnt or count, it is fine > either way. > > On Fri, Jun 4, 2021 at 7:39 PM Nikolay Izhikov wrote: > > > Hello, Igniters. > > > > Right now, we have the rule to use some predefined list of abbrevation for > > variable names [1]. > > Some of the reviewers ask to follow this rule strictly. > > > > > It is required to use abbreviated form for code consistency. > > > > I tried to implement this rule in form of checkstyle check [2] and it > > seems like many of use doesn’t follow this requirement. > > My check found 4124 violation in core module. > > > > Should we make this rule optional in documentation or should we remove it > > completely? > > Or should someone proceed and fix all the violations? > > > > WDYT? > > > > > > Example of output: > > ``` > > [ERROR] > > /Users/sbt-izhikov-nv/work/ignite/modules/core/src/test/java/org/apache/ignite/internal/processors/cache/persistence/db/IgnitePdsWithTtlTest.java:94: > > Abbrevation should be used for CACHE_NAME_LOCAL_ATOMIC! Please, use loc, > > instead of LOCAL [IgniteAbbrevationsRule] > > [ERROR] > > /Users/sbt-izhikov-nv/work/ignite/modules/core/src/test/java/org/apache/ignite/internal/processors/cache/persistence/db/IgnitePdsWithTtlTest.java:97: > > Abbrevation should be used for CACHE_NAME_LOCAL_TX! Please, use loc, > > instead of LOCAL [IgniteAbbrevationsRule] > > [ERROR] > > /Users/sbt-izhikov-nv/work/ignite/modules/core/src/test/java/org/apache/ignite/internal/processors/cache/persistence/db/IgnitePdsWithTtlTest.java:264: > > Abbrevation should be used for checkpointManager! Please, use mgr, instead > > of Manager [IgniteAbbrevationsRule] > > [ERROR] > > /Users/sbt-izhikov-nv/work/ignite/modules/core/src/test/java/org/apache/ignite/internal/processors/cache/persistence/db/IgnitePdsPartitionPreloadTest.java:63: > > Abbrevation should be used for DEFAULT_REGION! Please, use dflt, instead of > > DEFAULT [IgniteAbbrevationsRule] > > [ERROR] > > /Users/sbt-izhikov-nv/work/ignite/modules/core/src/test/java/org/apache/ignite/internal/processors/cache/persistence/db/IgnitePdsWholeClusterRestartTest.java:47: > > Abbrevation should be used for ENTRIES_COUNT! Please, use cnt, instead of > > COUNT [IgniteAbbrevationsRule] > > [ERROR] > > /Users/sbt-izhikov-nv/work/ignite/modules/core/src/test/java/org/apache/ignite/internal/processors/cache/persistence/db/IgnitePdsRebalancingOnNotStableTopologyTest.java:49: > > Abbrevation should be used for CHECKPOINT_FREQUENCY! Please, use freq, > > instead of FREQUENCY [IgniteAbbrevationsRule] > > [ERROR] > > /Users/sbt-izhikov-nv/work/ignite/modules/core/src/test/java/org/apache/ignite/internal/processors/cache/persistence/db/IgnitePdsTransactionsHangTest.java:75: > > Abbrevation should be used for MAX_KEY_COUNT! Please, use cnt, instead of > > COUNT [IgniteAbbrevationsRule] > > [ERROR] > > /Users/sbt-izhikov-nv/work/ignite/modules/core/src/test/java/org/apache/ignite/internal/processors/cache/persistence/db/IgnitePdsTransactionsHangTest.java:78: > > Abbrevation should be used for CHECKPOINT_FREQUENCY! Please, use freq, > > instead of FREQUENCY [IgniteAbbrevationsRule] > > [ERROR] > > /Users/sbt-izhikov-nv/work/ignite/modules/core/src/test/java/org/apache/ignite/internal/processors/cache/persistence/db/SlowHistoricalRebalanceSmallHistoryTest.java:57: > > Abbrevation should be used for SUPPLY_MESSAGE_LATCH! Please, use msg, > > instead of MESSAGE [IgniteAbbrevationsRule] > > [ERROR] > > /Users/sbt-izhikov-nv/work/ignite/modules/core/src/test/java/org/apache/ignite/internal/processors/cache/persistence/db/IgniteLogicalRecoveryTest.java:74: > > Abbrevation should be used for SHARED_GROUP_NAME! Please, use grp, instead > > of GROUP [IgniteAbbrevationsRule] > > [ERROR] > > /Users/sbt-izhikov-nv/work/ignite/modules/core/src/test/java/org/apache/ignite/internal/processors/cache/persistence/db/IgniteLogicalRecoveryTest.java:200: > > Abbrevation should be used for cacheLoader! Please, use ldr, instead of > > Loader [IgniteAbbrevationsRule] > > ``` > > > > [1] > > https://cwiki.apache.org/confluence/display/IGNITE/Abbreviation+Rules#AbbreviationRules-VariableAbbreviation > > [2] https://github.com/apache/ignite/pull/9153 > > > > >
[MTCGA]: new failures in builds [6035677] needs to be handled
Hi Igniters, I've detected some new issue on TeamCity to be handled. You are more than welcomed to help. If your changes can lead to this failure(s): We're grateful that you were a volunteer to make the contribution to this project, but things change and you may no longer be able to finalize your contribution. Could you respond to this email and indicate if you wish to continue and fix test failures or step down and some committer may revert you commit. *New Critical Failure in master RDD https://ci.ignite.apache.org/buildConfiguration/IgniteTests24Java8_Rdd?branch=%3Cdefault%3E Changes may lead to failure were done by - vladislav pyatkov https://ci.ignite.apache.org/viewModification.html?modId=927758 - pavel tupitsyn https://ci.ignite.apache.org/viewModification.html?modId=927613 - pavel pereslegin https://ci.ignite.apache.org/viewModification.html?modId=927685 - Here's a reminder of what contributors were agreed to do https://cwiki.apache.org/confluence/display/IGNITE/How+to+Contribute - Should you have any questions please contact dev@ignite.apache.org Best Regards, Apache Ignite TeamCity Bot https://github.com/apache/ignite-teamcity-bot Notification generated at 05:25:19 05-06-2021
Re: IGNITE-13364: Improve index inline defaults
Hello team, I think this is a very valuable optimization. This patch has been developed for a long time, I don't think there is any reason to continue to delay the release of this patch to version 2.12. Is anyone willing to push this forward and merge this patch into the master? 2021/1/27 下午4:52, Maxim Muzafarov 写道: Stanislav, I think the most compatibility impact will be on the in-memory caches with SQL and without explicitly specified inline sizes. I don't think that this is `true` compatibility issue. But I think we should at least mentioned it on our documentation pages and in the release notes. So, I'm +1 to proceed with the merge. Should we include the issue into 2.10 release? On Fri, 8 Jan 2021 at 16:50, Stanislav Lukyanov wrote: Hi Igniters, I'd like to discuss the change implemented by Evgeniy Rudenko in the ticket https://issues.apache.org/jira/browse/IGNITE-13364. I see that the fix is ready for review and merging, and I'm interested in it so I'd like to pick it up on the last mile. I also wanted to bring community's attention to it before the merge as it changes the default behavior. The patch changes how SQL index inline size is calculated. Specifically: 1. When inline size is calculated for a variable-sized field, a constant 10 (configurable via IGNITE_VARIABLE_TYPE_DEFAULT_INDEX_SIZE) is added to the calculated size instead of setting the entire calculation result to 10. For example, consider the following cases Index (int, int, string) Before the change: inline size = 10 After the change: inline size = 5 + 5 + 10 = 20 Index (long, long, long, long, string) Before the change: inline size = 10 After the change: inline size = 9 + 9 + 9 + 9 + 10 = 46 2. If there is a VARCHAR_FIXED, e.g. VARCHAR(5), then instead of the default IGNITE_VARIABLE_TYPE_DEFAULT_INDEX_SIZE Ignite will use the value provided in the calculation 3. If the calculated size exceeds IGNITE_MAX_INDEX_PAYLOAD_SIZE_DEFAULT=64, it will be truncated to 64. All of this only affects calculated inline sizes of new indexes. Existing indexes should not be affected. Indexes with explicitly specified inline size should not be affected. I think the most compatibility impact will be on the in-memory caches with SQL and without explicitly specified inline sizes. After the upgrade these caches may slightly increase in size (because the inline is likely to become bigger) while SQL is also likely to become faster. Please comment. If there are no concerns, I'll proceed with finding a committer to review and merge the fix at the end of the next week. Thanks, Stan
