On 3/29/2012 11:37 AM, Steve Ebersole wrote:
> 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).
Yes, but the difference here is whether the app is expecting to use multiple schemas (or named
schemas). If so, then SEPARATE_DATABASE and SEPARATE_SCHEMA wouldn't be interchangeable, although
the former could be used in place of the latter. With SHARED_TABLE the same issue holds --i.e.,
if the app were expecting multiple schemas, then the persistence provider would have needed to
have been allocated a database (rather than just a schema).