calcite-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mark Hammond <>
Subject Re: Google Summer of Code 2018
Date Wed, 28 Feb 2018 04:01:47 GMT
Thanks Julian for the context. I have no insight on Sigma, unfortunately.

I'm working toward adding such functionality to an Elixir Ecto based platform, and so will
sketch something in due course - just concerned this may not be in time for a GSoC submission.


> On 28 Feb 2018, at 08:09, Julian Hyde <> 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 <>;
read <>
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 <> 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,
>> Cheers,
>> Mark.
>>> On 25 Feb 2018, at 08:24, Michael Mior <> 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

View raw message