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 <[email protected]> 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 <[email protected]> > 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 <[email protected]> wrote: > > > >> See comments inline. > >> > >> Julian > >> > >> > >>> On Mar 25, 2016, at 9:29 AM, Dan Di Spaltro <[email protected]> > >> 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. > >> > >> > >> > >> > >
