Revision as of 10:08, 2 March 2011 by James.sutherland.oracle.com (New page: == Comments == * @TenantShared seems much too complicated, why would the user ever require multiple tenant ids in the same Entity? ** Would be better to support the simple case, and allow ...)
- @TenantShared seems much too complicated, why would the user ever require multiple tenant ids in the same Entity?
- Would be better to support the simple case, and allow the user to use AdditionalCriteria if they have more complex requirements.
- Also, why have the property specified in TenantId and have the nested Column, why not just have a fixed property name "eclipselink.tenant" and have a TenantColumn similar to DiscriminatorColumn?
- Will need someway to know the type of the TenantId, similar to the DiscriminatorType, or just maybe have a type which is a Class.
- Instead of changing every buildRow method to specifically include the tenant column it would be nice to have a more generic mechanism, that can be used for other purposes or more advanced tenant requirements. We could add a special mapping to the descriptor that writes to the column, or have some sort of generic ExtensionPolicy or set of policies on the descriptor that have hooks to support Tenants, SoftDeletes, Auditing, History, etc.
- James.sutherland.oracle.com 15:08, 2 March 2011 (UTC)