[jira] [Created] (CALCITE-5722) Sarg.isComplementedPoints fails with anti-points which are equal under `compareTo` but not `equals`

2023-05-24 Thread Ian Bertolacci (Jira) 
Ian Bertolacci created CALCITE-5722:
---

 Summary: Sarg.isComplementedPoints fails with anti-points which 
are equal under `compareTo` but not `equals`
 Key: CALCITE-5722
 URL: https://issues.apache.org/jira/browse/CALCITE-5722
 Project: Calcite
  Issue Type: Bug
Affects Versions: 1.34.0
Reporter: Ian Bertolacci


Example:
{code:java}
final Sarg badComplimentPointsSarg =
  Sarg.of(
RexUnknownAs.UNKNOWN,
TreeRangeSet.create(
  Arrays.asList(
// Create anti-point around 1, with different scales
Range.lessThan(new BigDecimal("1")),
Range.greaterThan(new BigDecimal("1.000"))
  )
)
  );
assertThat(badComplimentPointsSarg.isComplementedPoints(), is(true));
{code}
will fail.

This is because [RangeSets.isPoints uses direct equality and not 
`Comparable.compareTo` 
equality|https://github.com/apache/calcite/blob/main/core/src/main/java/org/apache/calcite/util/RangeSets.java#LL132C1-L133C1]

The values {{`1`}} and {{`1.000`}} are not equal under 
`BigDecimal.equals` but are equal under `BigDecimal.compareTo`.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Created] (CALCITE-5721) Capture build scans on ge.apache.org to benefit from deep build insights

2023-05-24 Thread Clay Johnson (Jira) 
Clay Johnson created CALCITE-5721:
-

 Summary: Capture build scans on ge.apache.org to benefit from deep 
build insights
 Key: CALCITE-5721
 URL: https://issues.apache.org/jira/browse/CALCITE-5721
 Project: Calcite
  Issue Type: Improvement
  Components: build
Reporter: Clay Johnson


Currently, the Apache Calcite build is configured to publish build scans to the 
publicly available [scans.gradle.com|https://scans.gradle.com/]. This will 
enhance that functionality by instead publishing build scans to 
[ge.apache.org|https://ge.apache.org/], hosted by the Apache Software 
Foundation and run in partnership between the ASF and Gradle. This Gradle 
Enterprise instance has all features and extensions enabled and is freely 
available for use by the Apache Calcite project and all other Apache projects.

On this Gradle Enterprise instance, Apache Calcite will have access not only to 
all of the published build scans but other aggregate data features such as:
 * Dashboards to view all historical build scans, along with performance trends 
over time
 * Build failure analytics for enhanced investigation and diagnosis of build 
failures
 * Test failure analytics to better understand trends and causes around slow, 
failing, and flaky tests

If interested in exploring a fully populated Gradle Enterprise instance, please 
explore the Maven builds already connected to 
[ge.apache.org|https://ge.apache.org/], the [Spring project’s 
instance|https://ge.spring.io/scans?search.relativeStartTime=P28D&search.timeZoneId=Europe/Zurich],
 or any number of other [OSS 
projects|https://gradle.com/enterprise-customers/oss-projects/] for which we 
sponsor instances of Gradle Enterprise.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

Re: Share intermediate data between nodes during plan execution

2023-05-24 Thread Dan Zou 
Hi Vladislav,
Could you please provide more details? Do you want to reuse part of RelNode 
trees?

Best,
Dan Zou   





> 2023年5月24日 06:44，Vladislav Matyushevski  写道：
> 
> Vladislav

Re: Share intermediate data between nodes during plan execution

2023-05-24 Thread Stamatis Zampetakis 
Hey Vladislav,

I see two operators relevant to your use-case:
* Spool [1]
* Correlate [2]

Both allow some form of propagating data from one side of the join to
the other. Check the code and relevant discussions to see how they are
used.

Best,
Stamatis

[1] 
https://github.com/apache/calcite/blob/b0420947ddeb2c9e18afe896dbf7adaf49a715a2/core/src/main/java/org/apache/calcite/rel/core/Spool.java
[2] 
https://github.com/apache/calcite/blob/b0420947ddeb2c9e18afe896dbf7adaf49a715a2/core/src/main/java/org/apache/calcite/rel/core/Correlate.java

On Wed, May 24, 2023 at 8:32 AM Roman Kondakov
 wrote:
>
> Hi Vladislav,
>
> Can you share more details regarding your use case?
>
> If you want to share the same object between join inputs, you can use
> RelShuttleImpl [1] to traverse the RelNode tree and every time you are
> visiting a Join relation you need to put the object to the stack and
> remove it from there when you are leaving the Join. In this case the
> shared object will be available on the top of the stack for both sides
> of the Join.
>
> [1]
> https://github.com/apache/calcite/blob/b0420947ddeb2c9e18afe896dbf7adaf49a715a2/core/src/main/java/org/apache/calcite/rel/RelShuttleImpl.java#L49
>
> Thanks,
>
> Roman
>
> On 24.05.2023 05:44, Vladislav Matyushevski wrote:
> > Greetings Calcite team!
> >
> > I`m using the Calcite + Avatica and curious to know:
> > Is there a way how I can share an Object (e.g. Map) between left and right
> > parts of join?
> > Sharing is needed due to the fact that the left part is producing data that
> > must be re-used in the right part.
> > I`m thinking of the following solution:
> > There is a getProvider() method, which returns me CalciteJDBC41Connection.
> > And if I have my own implementation of this class then I`ll be able to
> > extend it and enrich the class with methods I need. However, it
> > doesn't feel like a good idea. I believe there might be a proper solution
> > for this.
> >
> >
> > Thanks in advance,
> > Vladislav
> >