calcite-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jacques Nadeau <jacq...@apache.org>
Subject Re: Tenanted SQL
Date Fri, 08 Apr 2016 06:26:21 GMT
FYI, In Apache Drill we expose USER for exactly this purpose, allow it to
be used in views and also ensure that it leverages constant reduction and
or partition pruning where possible. I think we also have a group concept
but I can't find the docs on that at the moment.

On Thu, Apr 7, 2016 at 10:08 PM, Julian Hyde <jhyde@apache.org> wrote:

> CURRENT_TENANT would not be an ordinary function. As I said, it should
> work something like CURRENT_TIMESTAMP, which is not an ordinary function
> either.
>
> Yeah, I wish the doc was more flushed out, too. :)
>
>
> > On Apr 7, 2016, at 8:50 PM, Dan Di Spaltro <dan.dispaltro@gmail.com>
> wrote:
> >
> > So are you suggesting doing something like this?
> >
> https://calcite.apache.org/docs/tutorial.html#tables-and-views-in-schemas
> >
> > And using a special function `tenant_id = CURRENT_TENANT()` in place of
> > `gender = \'F\'`
> >
> > I really wish some of the further topics at the bottom were more flushed
> > out, specifically how to add functions.
> >
> > -Dan
> >
> > On Sun, Mar 27, 2016 at 9:11 PM, Julian Hyde <jhyde@apache.org> wrote:
> >
> >> See comments inline.
> >>
> >> Julian
> >>
> >>
> >>> On Mar 25, 2016, at 9:29 AM, Dan Di Spaltro <dan.dispaltro@gmail.com>
> >> wrote:
> >>>
> >>> So I definitely understand the data side of the target database ("A"),
> >> that
> >>> I am virtualizing.
> >>>
> >>> I guess more specific questions would be:
> >>> * How would I expose only two tables from "A" (they would both include
> >> the
> >>> tenantId field), I'm guess I might override the JdbcSchema using some
> >>> whitelist.
> >>
> >> A whitelist is one approach. Another is to keep the JdbcSchema private,
> >> but create views in another schema that reference those tables. Tenants
> >> would only see the views.
> >>
> >>> * Since I want to give everyone the same virtual table space (with
> >>> different "data"), would I need to look in overriding some of the Jdbc
> >> core
> >>> implementation?
> >>
> >> I don’t think you need to change anything in the JDBC adapter. All of
> the
> >> smarts will be in the views.
> >>
> >>> * I would need to use the parsed tree and then add the tenantId filter
> >>> * Somehow pass in the tenantId during query time, ideally at the
> >> statement
> >>> vs the connection level.
> >>
> >> You could put tenantId into the DataContext. In SQL it would be accessed
> >> using a function. This is very similar to how CURRENT_TIMESTAMP function
> >> works.
> >>
> >>>
> >>> Anyways, was just looking for some pointers, as there is a lot of code
> >>> here. And anything would be much appreciated.  I am happy to share some
> >> of
> >>> the work once it's done.
> >>
> >>
> >>
> >>
>
>

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