calcite-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Julian Hyde <jh...@apache.org>
Subject Re: Google Summer of Code 2018
Date Wed, 28 Feb 2018 00:09:39 GMT
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