[
https://issues.apache.org/jira/browse/PHOENIX-5248?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16835127#comment-16835127
]
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
DeleteCompiler.compile
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: https://issues.apache.org/jira/browse/PHOENIX-5248
> 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
(v7.6.3#76005)
