Hi Alex,
Find below the details you requested.
CacheConfiguration<OrderId, OrdersToMatch> cacheConfiguration = new
CacheConfiguration<>();
cacheConfiguration.setCacheMode(CacheMode.PARTITIONED);
cacheConfiguration.setBackups(2);
cacheConfiguration.setExpiryPolicyFactory(CreatedExpiryPolicy.factoryOf(new
Duration(MINUTES, 30)));
cacheConfiguration.setAtomicityMode(CacheAtomicityMode.ATOMIC);
cacheConfiguration.setName("ORDERSTOMATCH");
cacheConfiguration.setSqlSchema("PUBLIC");
*cacheConfiguration.setIndexedTypes(OrderId.class, OrdersToMatch.class);*
cacheConfiguration.setOnheapCacheEnabled(true);
cacheConfiguration.setEvictionPolicyFactory(new
LruEvictionPolicyFactory<>());
explain plan for
SELECT _key FROM PUBLIC.ORDERSTOMATCH
IgniteExchange(distribution=[single]): rowcount = 1.0, cumulative cost =
IgniteCost [rowCount=2.0, cpu=2.0, memory=1.0, io=1.0, network=5.0], id =
1098
IgniteIndexScan(table=[[PUBLIC, ORDERSTOMATCH]], index=[_key_PK],
requiredColumns=[{0}], inlineScan=[false], collation=[[0
ASC-nulls-first]]): rowcount = 1.0, cumulative cost = IgniteCost
[rowCount=1.0, cpu=1.0, memory=1.0, io=1.0, network=1.0], id = 1087
It is using Index scan.
Thanks,
Amit Jolly
On Fri, Aug 16, 2024 at 3:03 AM Alex Plehanov <plehanov.a...@gmail.com>
wrote:
> Amit,
>
> Can you please show the output of "EXPLAIN PLAN FOR <YOUR_QUERY>"?
> I've found the bug in index scan on binary object field (ticket [1]),
> but I can't reproduce it with select without "order by", or without
> forcing index scan.
>
> [1]: https://issues.apache.org/jira/browse/IGNITE-23004
>
> ср, 14 авг. 2024 г. в 18:07, Amit Jolly <amit.jo...@gmail.com>:
> >
> > HI, Jeremy & Alex,
> >
> > First of all thanks for the quick response.
> >
> > Sorry for the confusion here, We are trying to switch from using H2 as a
> default query engine to Calcite due to above mentioned CVE's.
> > I have read the ticket and understood that those CVE's do not have any
> impact on how Ignite uses H2.
> > We are trying to explain the same to our internal security audit team
> and at the same time trying to evaluate Calcite.
> >
> > Below is the query we are using
> >
> > SELECT _key FROM OrdersToMatchCache
> >
> > OrdersToMatchCache has OrderId.java as key and OrdersToMatch.java as
> value
> >
> > OrderId.java
> > ====================
> > import lombok.Data;
> > import org.apache.ignite.cache.query.annotations.QuerySqlField;
> > import java.io.Serializable;
> >
> > @Data
> > public class OrderId implements Serializable {
> > @QuerySqlField
> > private String orderId;
> > @QuerySqlField
> > private String regionId;
> > @QuerySqlField
> > private Integer date;
> > }
> >
> >
> > OrdersToMatch.java
> > ====================
> > import lombok.Data;
> > import org.apache.ignite.cache.query.annotations.QuerySqlField;
> > import java.io.Serializable;
> >
> > @Data
> > public class OrdersToMatch implements Serializable {
> > @QuerySqlField
> > private List<Order> buyOrders = new ArrayList<>();
> > @QuerySqlField
> > private List<Order> sellOrders = new ArrayList<>();
> > }
> >
> >
> > Order.java
> > ====================
> > import lombok.Data;
> > import java.io.Serializable;
> >
> > @Data
> > public class Order implements Serializable {
> > private String direction; // BUY or SELL
> > private Integer qty;
> > }
> >
> > Thanks,
> >
> > Amit Jolly
> >
> > On Wed, Aug 14, 2024 at 10:27 AM Jeremy McMillan <j...@gridgain.com>
> wrote:
> >>
> >> Amit:
> >>
> >> I'm concerned that you may be misreading the CVE details in the ticket
> you cited, since you indicated you are moving TO H2.. Also the stack trace
> is a Calcite stack trace. This is ambiguous whether this is the before
> (persistence config changes) depicted or after changing persistence
> depicted.
> >>
> >> A) The CVEs cited in the ticket
> https://issues.apache.org/jira/browse/IGNITE-15241 are all H2
> vulnerabilities.
> >> B) The H2 vulnerabilities cited all involve behaviors of H2 that Ignite
> does not use, therefore Ignite is affected neither by Calcite nor H2
> persistence involvement.
> >>
> >> I don't want to discourage you from moving from H2 to Calcite, but
> maybe this isn't as urgent as it appears, so please proceed carefully. As
> Alex requested, it will be helpful for the community to see which queries
> produce exceptions and which ones do not. H2 and Calcite have different SQL
> parsers and query planners and underlying implementations, so it should not
> be surprising that queries might need rework in the course of switching.
> You should expect to encounter issues like this one, and others like it.
> It's a migration effort.
> >>
> >>
> >> On Tue, Aug 13, 2024 at 9:17 AM Amit Jolly <amit.jo...@gmail.com>
> wrote:
> >>>
> >>> Hi,
> >>>
> >>> We are trying to switch to H2 due to Security Vulnerabilities as
> listed in JIRA https://issues.apache.org/jira/browse/IGNITE-15241
> >>>
> >>> We are seeing below errors post switching. We are just running select
> * From table query.
> >>>
> >>> Caused by: java.lang.ClassCastException: class
> org.apache.ignite.internal.binary.BinaryObjectImpl cannot be cast to class
> java.lang.Comparable (org.apache.ignite.internal.binary.BinaryObjectImpl is
> in unnamed module of loader 'app'; java.lang.Comparable is in module
> java.base of loader 'bootstrap')
> >>> at
> org.apache.ignite.internal.processors.query.calcite.exec.exp.ExpressionFactoryImpl.compare(ExpressionFactoryImpl.java:223)
> ~[ignite-calcite-2.16.0.jar:2.16.0]
> >>> at
> org.apache.ignite.internal.processors.query.calcite.exec.exp.ExpressionFactoryImpl.access$100(ExpressionFactoryImpl.java:85)
> ~[ignite-calcite-2.16.0.jar:2.16.0]
> >>> at
> org.apache.ignite.internal.processors.query.calcite.exec.exp.ExpressionFactoryImpl$1.compare(ExpressionFactoryImpl.java:157)
> ~[ignite-calcite-2.16.0.jar:2.16.0]
> >>> at
> java.base/java.util.Map$Entry.lambda$comparingByKey$6d558cbf$1(Map.java:560)
> ~[?:?]
> >>> at
> java.base/java.util.PriorityQueue.siftUpUsingComparator(PriorityQueue.java:660)
> ~[?:?]
> >>> at java.base/java.util.PriorityQueue.siftUp(PriorityQueue.java:637)
> ~[?:?]
> >>> at java.base/java.util.PriorityQueue.offer(PriorityQueue.java:330)
> ~[?:?]
> >>> at
> org.apache.ignite.internal.processors.query.calcite.exec.rel.Inbox.pushOrdered(Inbox.java:239)
> ~[ignite-calcite-2.16.0.jar:2.16.0]
> >>> at
> org.apache.ignite.internal.processors.query.calcite.exec.rel.Inbox.push(Inbox.java:201)
> ~[ignite-calcite-2.16.0.jar:2.16.0]
> >>> at
> org.apache.ignite.internal.processors.query.calcite.exec.rel.Inbox.onBatchReceived(Inbox.java:177)
> ~[ignite-calcite-2.16.0.jar:2.16.0]
> >>> at
> org.apache.ignite.internal.processors.query.calcite.exec.ExchangeServiceImpl.onMessage(ExchangeServiceImpl.java:324)
> ~[ignite-calcite-2.16.0.jar:2.16.0]
> >>> at
> org.apache.ignite.internal.processors.query.calcite.exec.ExchangeServiceImpl.lambda$init$2(ExchangeServiceImpl.java:195)
> ~[ignite-calcite-2.16.0.jar:2.16.0]
> >>> at
> org.apache.ignite.internal.processors.query.calcite.message.MessageServiceImpl.onMessageInternal(MessageServiceImpl.java:276)
> ~[ignite-calcite-2.16.0.jar:2.16.0]
> >>> at
> org.apache.ignite.internal.processors.query.calcite.message.MessageServiceImpl.lambda$onMessage$0(MessageServiceImpl.java:254)
> ~[ignite-calcite-2.16.0.jar:2.16.0]
> >>> at
> org.apache.ignite.internal.processors.query.calcite.exec.QueryTaskExecutorImpl.lambda$execute$0(QueryTaskExecutorImpl.java:66)
> ~[ignite-calcite-2.16.0.jar:2.16.0]
> >>>
> >>> Any idea what might be causing this?
> >>>
> >>> Regards,
> >>>
> >>> Amit Jolly
>
