On 03/27/2012 12:38 PM, Linda DeMichiel wrote:
> Hi Steve,
>
> On 3/26/2012 6:06 PM, Steve Ebersole wrote:
>> Is the proposal allowing mixing of strategies within a deployment? For
>> example, can an application use a combination of
>> SHARED_SCHEMA and SHARED_TABLE within a single persistence unit? I did
>> not see that specifically addressed (apologize if
>> I missed it) and just wanted to make sure. Specifically it is the
>> mixing of "discriminated" (what you call "shared
>> table") multi-tenancy and "non-discriminated" (separate database or
>> shared database) I am concerned about.
>>
>
> It isn't preventing it. However, in this release I am not proposing that
> we address this, as
> I see the main rationale for usage of the SHARED_TABLE approach to be in
> the single-instance
> SaaS case.
Cool. In my experience it gets quite dicey supporting both
discriminated (SHARED_TABLE) and non-discriminated (other 2)
simultaneously within the same deployment anyway.
>> With regard to "DETERMINING THE MULTITENANCY STORAGE MAPPING
>> STRATEGY", I think there should be an option for the
>> developer/deployer to chose an explicit strategy. Whether that means
>> in addition to the ability to name "functional
>> requirements", I am not sure. If JPA goes the functional requirement
>> route and allows platform providers to choose which
>> strategy to use, also makes sense to allow the platform provider to
>> query the JPA provider to see what it supports,
>> which requires adding that information as well. That way the platform
>> provider can choose between the numerous JPA
>> providers it might have available.
>>
>
> Yes, I did consider this, but didn't include it in the writeup, because
> it wasn't clear to me
> how realistic it was, and it would definitely add complexity. I'd like
> to get feedback from
> the group on this aspect though. Do we really expect both that more than
> one provider would
> be available in a PaaS environment, and, if so, also that the
> application wouldn't be
> dependent on a specific provider (and therefore wire that provider
> choice into the persistence.xml)?
You are right, its probably not a practical expectation that most
deployments are persistence provider agnostic. So this could certainly
be addressed later at such a time when it is more feasible to assume
that deployments are more provider agnostic.
>
>> Even though we don't want to focus on "shared table" with this rev, we
>> need to consider it. At a minimum we will need
>> metadata support to name the column that indicates which rows belong
>> to which tenants.
>>
>> In my experience with implementing this in Hibernate, it is nice to
>> have a flag saying whether multitenancy is enable
>> for the unit and what strategy. But this latter part ties in with your
>> strategy (A) and (B) question. Another option is
>> to let the application specify (a) which strategies it can use and (b)
>> which strategy it prefers.
>>
>
> Hmmmm..... Specifying SHARED_SCHEMA means that SEPARATE_DATABASE would
> work as well, so you
> wouldn't even need to state that. But if SHARED_TABLE were specified
> you'd still need
> to know whether you need a separate database or just a schema, so you'd
> need the additional
> SHARED_SCHEMA or SEPARATE_DATABASE to be specified along with it.
Yes. In my experience, just as you mention, there are really 2 distinct
categories here. SHARED_SCHEMA and SEPARATE_DATABASE both are largely
interchangeable, and then you have SHARED_TABLE. Really the question
here lies in which of these 2 categories the deployment can handle.
What you say in regards to SHARED_SCHEMA and SEPARATE_DATABASE is
absolutely correct, if the app can handle using one strategy it can
handle the other; but that same app may or may not be able to (or want
to) handle SHARED_TABLE. Conversely, an application that is built for
SHARED_TABLE could conceivably operate in SHARED_SCHEMA or
SEPARATE_DATABASE situations as well (native SQL aside, potentially).