SQM - alias registry
by Steve Ebersole
At the moment the alias registry is global for the whole query. I propose
that we should scope this by "query spec" (combined with parent). The
reason being that reusing the same alias in unrelated subqueries is
perfectly fine.
select ...
from Customer c
where c.id in (
select o.customer.id
from Order o
...
)
or c.id in (
select c1.id
from Outstanding o
...
)
Here the aliases `o` don't ever infringe on each other. So imo we should
allow that.
The piece about checking the parent is for a case like:
select ...
from Customer c
where c.id in (
select c.id
from Order o
join o.customer c
...
)
Here the aliases `c` do infringe. In the subquery, we don't really know
which reference the `c` alias should resolve to. We *could* here assuming
that the subquery is uncorrelated. Bu without this rule we really would
not know that the subquery is correlated. Hopefully that makes sense, what
I am getting at.
WDYT?
10 years, 11 months
AttributeConverter and type "hints"
by Steve Ebersole
Reference HHH-9615[1].
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
case.
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
SimpleValue#buildAttributeConverterTypeAdapter.
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?
[1] https://hibernate.atlassian.net/browse/HHH-9615
10 years, 11 months
Re: [hibernate-dev] Does hibernate multi-tenancy lead to reduced heap usage
by amit shah
Including the dev mailing group to get a few suggestions on my question.
Thanks!
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.
>
> Thanks!
>
10 years, 11 months
Antlr sources generated into default package
by Gunnar Morling
Hi,
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.sql.ordering.antlr" and
"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?
Thanks,
--Gunnar
10 years, 11 months
