Reference HHH-10050. There is a request to incorporate parameterized
type resolution into the decision of whether an auto-apply
AttributeConverter should apply to a given attribute.
For those on the list better at parameter type resolution, is the best
solution here to use ClassMate? Or is there a better way to achieve this?
The specific request here is to support @Lob together with an
AttributeConverter. But other combinations apply as well. So I want to
address the more generic case, but let's talk in terms of this specific
Ultimately the problem is in SimpleValueBinder and the fact that it keeps
just one representation of the "determined Type" (`explicitType`) and that
it furthermore treats that value as if it were explicitly requested. When
it is determining the Type to use and it sees @Lob, @Natioanlized, etc it
assumes that that implicitly defines the Type to use, but then treats that
determination as if it were explicit.
Late we have a check to make sure that the user did not mix applying an
AttributeConverter and an (really) explicit Type definition on an
attribute, because that would be a unresolvable situation.
Really, instead I think this should work quite differently. To me, I would
not say that @Lob equates to an explicit Type request. Instead I would say
that it is a hint as to the Type, and actually even more limited I would
say it is a hint as to just the JDBC type. Really @Lob has no bearing on
the Java model type.
So what I'd propose instead (keeping changes as minimal as possible until
we rewrite the annotation binding code) would be to defer this decision for
@Lob into SimpleValue itself. I think the least disruptive way would be a
method on SimpleValue similar in intent to SimpleValue#makeNationalized.
So add a SimpleValue#makeLob that we'd call from SimpleValueBinder when
@Lob was present. We would then incorporate handling LOB interpretation
into SimpleValue#setTypeUsingReflection and
Does this sound reasonable to everyone? Emmanuel, you wrote and designed
SimpleValueBinder; does that make sense from the perspective of the overall
design/intent of SimpleValueBinder?
Including the dev mailing group to get a few suggestions on my question.
On Wed, Sep 23, 2015 at 4:54 PM, amit shah <amits.84(a)gmail.com> wrote:
> We are planning to integrate hibernate 4 multi-tenancy feature into our
> application. With this feature I assume we would have only one session
> factory instance irrespective of the number of tenants. (right?). If so,
> would it lead to reduced heap usage or would the single session factory
> instance occupy the same amount of memory as multiple instances did before?
> Are there any other performance benefits with this integration?
> I wanted to get an understanding on this before starting with the actual
> implementation since it involves considerable code changes.
When building hibernate-core, I am observing a strange mismatch of
package declaration and file location of generated Antlr sources (this
is about the current parser in ORM, not SQM):
The files are generated into
hibernate-core/target/generated-src/antlr/main/, i.e. the default
package. But the package declarations within the files are
"org.hibernate.hql.internal.antlr". Subsequently, I am seeing lots of
compile errors in Eclipse.
Apparently it's not an issue with Gradle and I suppose also not in
IntelliJ, but I am puzzled how this actually works. Anyone observing
the same and with an idea how to generate the files into a directory
structure matching their package statements?