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
