Yeh, unlike Cassandra, Geode support certain function types (such as CAST
and ITEM). To prevent dropping support for those, i've blacklisted just
the SqlTypeName.GEOMETRY RexNode for now.
It went a step further to hit the ST_Point parameter types issues :)
"No applicable constructor/method found for actual parameters "double,
double"; candidates are: "public static
org.apache.calcite.runtime.GeoFunctions$Geom
org.apache.calcite.runtime.GeoFunctions.ST_Point(java.math.BigDecimal,
java.math.BigDecimal, java.math.BigDecimal)", "public static
org.apache.calcite.runtime.GeoFunctions$Geom
org.apache.calcite.runtime.GeoFunctions.ST_Point(java.math.BigDecimal,
java.math.BigDecimal)""
This is expected as ST_Point takes BigDecimal (e.g. DECIMAL sql type)
rather Double parameters.
While the "cast("loc"[0] AS DOUBLE)" works because "loc"[0] is a Numeric,
the "cast("loc"[0] AS DECIMAL)" doesn't because it tries to cast Numeric to
BigDecimal java types!
Is there other function (apart from CAST) to allow me to convert
the Numeric into BigDecimal?
Thanks,
Christian
On 28 November 2017 at 22:13, Michael Mior <[email protected]> wrote:
> Yes, the appropriate solution would be to check the expressions being
> projected and not to trigger your rule for projections you can't handle.
> For example, check out CassandraProjectRule#matches which validates that
> only field references are being projected.
>
> --
> Michael Mior
> [email protected]
>
> 2017-11-28 15:39 GMT-05:00 Christian Tzolov <[email protected]>:
>
> > Hey there,
> >
> > I have another question related to
> >
> > handling
> >
> > spatial (
> > or
> > any) functions in custom adapter implementations.
> >
> > For e
> >
> > example the
> >
> > rel
> > . plan for the following query
> > (
> > with
> >
> > spatial function
> > )
> >
> >
> > EXPLAIN PLAN FOR SELECT
> > "city",
> > ST_Point(
> > cast("loc" [0] AS DOUBLE),
> > cast("loc" [1] AS DOUBLE)
> > )
> > FROM "geode"."Zips"
> > LIMIT
> > 10;
> >
> > will produce plan like this:
> >
> >
> > GeodeToEnumerableConverterRel
> > GeodeProjectRel(city=[$1], EXPR$1=[*ST_POIN*T(CAST(ITEM($2,
> 0)):DOUBLE,
> > CAST(ITEM($2, 1)):DOUBLE)])
> > GeodeSortRel(fetch=[10])
> > GeodeTableScanRel(table=[[geode, Zips]])
> >
> > Given that my GeodeProjectRel implementation doesn't know about the
> > *ST_POIN*T this should fail? Or somehow get ignored in my case.
> >
> > What is the correct way to handle such cases?
> >
> > Perhaps in my Project rule i should make sure that projection with
> function
> > expression should not be matched so it falls back to the the
> > EnumerableProjection?
> >
> > Thanks,
> > Christian
> >
>
--
Christian Tzolov <http://www.linkedin.com/in/tzolov> | Principle Software
Engineer | Spring <https://spring.io/>.io | Pivotal <http://pivotal.io/> |
[email protected]
