Re: [DISCUSSION] Reserve partitions for CacheQueries

Hi! > Existing users may already have some logic in place to handle inconsistencies Pavel, I'm not aware of such users but your comment makes sense. So, I' OK with adding an option for ScanQuery. Naming of the option is debatable. The name "reservePartitions" looks good, but we actually already

0-day CVE in log4j

All This blew up today: CVE-2021-44228 ( https://www.bleepingcomputer.com/news/security/new-zero-day-exploit-for-log4j-java-library-is-an-enterprise-nightmare/ ) Will there be a risk assessment with respect to Ignite for this CVE? Thanks, Raymond. -- Raymond Wilson

Re: 0-day CVE in log4j

Hello. The issue to update dependency was created: https://issues.apache.org/jira/browse/IGNITE-16101 I want to include it to the 2.12 scope. сб, 11 дек. 2021 г., 09:19 Raymond Wilson : > All > > This blew up today: CVE-2021-44228 ( > >

Re: [DISCUSSION] Reserve partitions for CacheQueries

Actually I brought a point about using SQL queries instead of scan queries because I worry about inconsistency between different implementations. AFAIR Scan and SQL queries implementations are totally different. Could you tell me how Index queries fit there? My general ideas are as follows: 1. In

[DISCUSSION] Validation key type and schema on a data insertion [IGNITE-16098]

Hi, Igniters. There was know issue described at the [IGNITE- 16098] case 1. These issue is the cause of not symmetric cache API and SQL API: we cannot create the same table by SQL and cache API (with se identical internal structures). In more detail: it is impossible now to create a sorted PK