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 <[email protected]> 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 <[email protected]> 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
>> [email protected]

Reply via email to