Jacques>This sounds like it will mean we will need to make calcite-core
test artifacts available
Test artifacts publication is yet another anti-pattern just like "base test
class".
This change has been discussed:
https://lists.apache.org/thread/fz96p94h016p11g777otqntjxg2oxgh1
If you want to
Julian,
Thanks for taking time, and working on this.
"Fixture" is a too broad term, and I do not mean we should replace it
completely with AssertJ.
What I mean is that AssertJ allows creating *discoverable* assertions.
Hamcrest assertions are hard to create and hard to discover in IDE.
---
Re
It’s possible, and I would think desirable, to simplify
“clean” = true
and for that matter
“clean” is true
to
“clean”
and based on your experiments it looks as if we do it already.
Julian
> On Nov 16, 2021, at 18:06, Gavin Nicol wrote:
>
> I'm writing a FilterableTable
I'm writing a FilterableTable implementation and so far all is well. When
handling more complex filters I've come across the need to pass in a boolean
flag via a filter clause, something like:
select "foo" from "bar" where "clean"=true and "id"='1234'
This results in a filter like:
I think it is a great idea to make the tests more accessible. A few
comments to consider in your work (no response expected):
- I would vote to try to minimize the use of non-interface class
inheritance , especially in downstream cases. For example, I would avoid a
dominant path using
I am working on https://issues.apache.org/jira/browse/CALCITE-4885,
"Fluent test fixtures so that dependent projects can write parser,
validator and rules tests".
I wanted to give you all a heads up, because it's going to change
quite a few lines of code.
Here's the problem I'm trying to solve.
We've had 7 responses so far on the straw poll. For a reminder, results are
here:
https://docs.google.com/spreadsheets/d/1EXhrRkYp2owGAK2e3bBw1bEvNj5O3V22iTqndBAuyG8/edit?usp=sharing
My high level observations:
- There isn't a lot of agreement on most questions :D.
- 70% of people
Hi,
Sorry for being unclear. We have tried to generate SQL similar to the three
examples using the RelBuilder and the Uncollect expression. Something like
this.
relBuilder.scan("table");
final Holder correlVar = Holder.empty();
relBuilder.variable(correlVar);
relBuilder.values(new String[]
Hello,
I don't understand what you want to do here. There's an UNNEST operator in
Calcite, see the comment at the bottom of this section:
https://calcite.apache.org/docs/reference.html#collection-functions.
Cordialement / Best Regards,
*Thomas Rebele, PhD* | R Developer | Germany | www.tibco.com
Hi
We are trying to generate relational algebra for SQL that uses UNNEST of
arrays in BigQuery. Here are three examples of SQL (in Big Query standard
query syntax) that we want to be able to handle and generate from
relational algebra. Any tips on how you would do that in Calcite?
SELECT id,
Vladimir Sitnikov created CALCITE-4889:
--
Summary: Double join is created for NOT IN
Key: CALCITE-4889
URL: https://issues.apache.org/jira/browse/CALCITE-4889
Project: Calcite
Issue
Hi Mahendrakar,
I would say that Values should be handled more or less the same way that we
handle a TableScan so returning null seems like a bug.
However, to be sure it would help if you can come up with a concrete
query/plan that cannot be decorrelated due to this.
If that's the case please
Hi Anthony,
I don't completely understand what point 1 and 2 concretely mean.
1) Calcite does a pretty good job pushing computations to the underlying
DBMS when that is possible.
JdbcAdapterTest [1] has a few examples where the whole query is pushed to
the database.
Can you give more details on
13 matches
Mail list logo
