That last plan should read:
CruxToEnumerableConverter
CruxProject(NAME=[$1], EXPR$1=[*(2, $3)])
CruxTableScan(table=[[crux, PERSON]])
The point being that it would great to get EnumerableCalc going.
I did consult the JDBC adapter and saw it makes use of a JDBCCalc rule -
and I attempted to
Hi,
Thanks for bearing with.
I'm stuck as to when EnumerableCalc fires vs Project.
We added a Project rule because it's a) desirable so we only pull back
fields we need from the underlying db, and b) we needed it for inner join
joins to be pushed down to our DB.
That is to say that with us impl
Thanks. Another Q:
In Crux we store documents, and values within those documents can be
Clojure.lang.Keywords. I'm still deciding how to handle them with Calcite -
one option being simply to wash them into Strings via the enumerator, which
is our first pass.
I did experiment with defining this ke
> On Apr 30, 2020, at 8:56 AM, Jon Pither wrote:
>
> We went down the route of wrapping Calcite with our own JDBC driver that
> strips out the `VALIDTIME AS OF (...)` from ``VALIDTIME AS OF (...) SELECT
> * FROM FOO`. We do this by overriding CalcitePrepareImpl and adding
> internalParameters
We went down the route of wrapping Calcite with our own JDBC driver that
strips out the `VALIDTIME AS OF (...)` from ``VALIDTIME AS OF (...) SELECT
* FROM FOO`. We do this by overriding CalcitePrepareImpl and adding
internalParameters to the CalciteSignature, that our enumerator then uses
when exec
Hi,
Another route we're looking at is to use `ALTER SESSION SET VALID_TIME =
date('2010')`. When we experiment with this - hoping to trigger
`SqlSetOption` - we get an java.lang.UnsupportedOperationException:
CalcitePrepareImpl.java: 369
org.apache.calcite.prepare.CalcitePrepareImpl/exec
Hi Stamatis & Calcite team,
Thanks for your response. We've made some good progress since - following
JdbcConvention as you suggest - and now we've got the Crux adapter handling
joins, sorts and more. We're in a good place I feel, and it's exciting to
see Calcite providing a SQL layer on top of ou
Hi Jon,
Thanks for your kind words. I'm sure people working on the project are very
happy to receive some positive feedback for their work from time to time :)
I had a quick look on your project and definitely looks interesting.
If your engine (Crux) uses better join algorithms than the ones pro
Hi Calcite Devs,
Firstly, thank you to all of you for building this fantastic tool.
I'm currently experimenting with using Calcite on top of our document
database Crux (opencrux.com) offering bitemporal features using a Datalog
query language. You can see our efforts here, written in Clojure!
ht