calcite-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Aman Sinha <amansi...@apache.org>
Subject Re: Google Summer of Code 2018
Date Wed, 28 Feb 2018 01:17:35 GMT
Good discussion.  Some thoughts in no particular priority order:

   - I think we should also look at the SQL extensions that have been
   proposed in SQL++  [1] .. for instance the WHERE clause can contain a
   QuantifiedExpression such as

                  QuantifiedExpression ::= ( (<ANY>|<SOME>) | <EVERY> )
Variable <IN> Expression ( "," Variable "in" Expression )*
                         <SATISFIES> Expression (<END>)?

   - WHERE predicates on JSON fields should be expressed in a manner that
   allows determining selectivity estimates using NDV and Histograms,
   otherwise cost based optimizations would not be possible.
   - Also, what is this community's thoughts on Higher-Order/Lambda
   functions that some products have to operate on JSON arrays and maps etc.
   ?


[1]
https://ci.apache.org/projects/asterixdb/sqlpp/manual.html#Comparison_operators

-Aman

On Tue, Feb 27, 2018 at 4:09 PM, Julian Hyde <jhyde@apache.org> wrote:

> Mark,
>
> Do you know if Sigma is built using Calcite?
>
> I’m totally in agreement about the power of SQL. You can create
> access-controlled views (or inject filters based on tenant id), give your
> end-users access to that layer, and you know that your users will get
> performance without being able to subvert security. It helps a lot that SQL
> is mathematically closed. If your users don’t like SQL, layer a non-SQL
> language on top of the relational algebra if you like.
>
> I’d appreciate if you could sketch out the JSON feature set that you think
> Calcite needs. We already have https://issues.apache.org/
> jira/browse/CALCITE-950 <https://issues.apache.org/jira/browse/CALCITE-950>;
> read https://issues.apache.org/jira/browse/DRILL-6035 <
> https://issues.apache.org/jira/browse/DRILL-6035> for a (sobering)
> overview of what is needed to fully support reading JSON data.
>
> Julian
>
>
> > On Feb 27, 2018, at 3:25 PM, Mark Hammond <gpo@themarkhammond.com>
> wrote:
> >
> > I'd like to suggest developing a convenient way to compose WHERE
> constraints on base queries, via the JSON api.
> >
> > Having a convenient way to inject rigorous application tenancy
> constraints would be huge boon for SaaS style applications.
> >
> > Calcite, with its JSON driver, could effectively enable any application
> to safely expose SQL-based queries, and remove the need for
> limited-capability domain specific languages.
> >
> > Calcite can already restrict queries to whitelisted operators, and the
> optimiser can deftly handle a bag of tenancy-related constraints.
> >
> > It would be possible to extend further by clamping query COST, etc.
> >
> > E.g. this capability has been productised by stripe,
> https://stripe.com/us/sigma.
> >
> > Cheers,
> > Mark.
> >
> >
> >> On 25 Feb 2018, at 08:24, Michael Mior <mmior@uwaterloo.ca> wrote:
> >>
> >> You have probably seen that Apache was accepted as an organization for
> this
> >> year's GSoC. I thought I would see if anyone in the Calcite community
> can
> >> think of any issues that would be a good fit. It's no guarantee we would
> >> get someone to work on it, but it could be a good push to move some
> >> isolated bits of functionality forward that may not get much attention
> >> otherwise.
> >>
> >> --
> >> Michael Mior
> >> mmior@apache.org
>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message