phoenix-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Geoffrey Jacoby (JIRA)" <>
Subject [jira] [Commented] (PHOENIX-5248) Allow MULTI_TENANT to use any PK column
Date Tue, 07 May 2019 21:19:00 GMT


Geoffrey Jacoby commented on PHOENIX-5248:

Turns out that the multi-tenant logic isn't well-encapsulated in one particular place, but
implemented independently in many. My non-exhaustive review found logic that would need to
be changed in: 

ExpressionCompiler -- resolveColumn checks to make sure don't reference MT column in clause

ScanUtil.getTenantIdBytes -- Called from many places


PostIndexDDLCompiler.compile: Used to skip first (tenanted) column when collecting column
names for data and index tables

ProjectionCompiler:getMinPKOffset: Used to skip first tenant column or view index id. Called
from several places in ProjectionCompiler which all have the assumption that it should skip
0, 1, or 2 columns (no MT or view index, one, or both)  and then do everything else. 

UpsertCompiler:upsertSelect assumes which field is the MT field, and fills it with the connection's
tenantId automatically

UpsertCompiler:compile:400 also assumes position of MT field and omits it from column list.

UpsertCompiler:compile:777 places the tenantId value in a fixed column position

WhereOptimizer:188 places tenantId value in a fixed column

WhereOptimizer:846,1446 also makes assumptions on MT PK position

> Allow MULTI_TENANT to use any PK column
> ---------------------------------------
>                 Key: PHOENIX-5248
>                 URL:
>             Project: Phoenix
>          Issue Type: Improvement
>            Reporter: Geoffrey Jacoby
>            Assignee: Geoffrey Jacoby
>            Priority: Major
> Phoenix's multi-tenancy support is incredibly useful, because it allows systems to give
users connections that transparently filter a multi-tenant environment to return only their
data. However, it's only supported for the leading column of the PK and has to be manually
enabled per-table.
> One common use case I've encountered is a multi-tenant table whose keyspace is fully
covered by disjoint views, with the views all filtering on enumerations of the same PK column
-- let's call it ViewId.  The most natural way to represent that is by a PK of <ViewId,
TenantId, ...> which would allow fast lookups by tenant connections AND fast cross-tenant
queries by admin processes. However, multi-tenancy requires the key be <TenantId, ViewId>
which is only fast for the tenant connections, not global processes. It would be great if
I could set a property on the table, MULTI_TENANT_COLUMN = "TenantId", and column was used
for auto-filtering instead. 

This message was sent by Atlassian JIRA

View raw message