6.0 - Session#createFilter
by Steve Ebersole
Another method I'd like to drop is Session#createFilter. This is method is
easy enough to replace with a call to createQuery instead. Longer term I
can also see Stream or DSL support from our persistent collections to
provide the similar capabilities. But for now its just no real benefit for
the cost of overly-complicating the grammars.
9 years, 2 months
Add entity with InheritanceType.JOINED to native query
by Jan-Willem Gmelig Meyling
Hi Hibernate developers,
I stumbled upon an issue today and I am wondering whether the following would be possible using Hibernate, and if not, whether such could actually be implemented, or if I actually hit a boundary of the alias injection.
My problem has to do with trying to map the result set of a native query to an entity that uses the JOINED InheritanceType. After adding the enitity to my NativeQuery as follows, the aliases for the tables of the subclasses are not set properly (obviously). My question is, though, would it be possible to set these as well? As I can’t figure this out from the current documentation (that only states that all columns should be present in the result set, which I assume to apply to a InheritanceType.SINGLE_TABLE primarily).
The code I am currently using to construct the query is as follows:
session
.createNativeQuery("SELECT {s.*} FROM my_super {s} LEFT JOIN my_sub_a {a} USING (id)")
.addEntity("s", MySuper.class)
.getSingleResult();
Additional code is available on Github gist: https://gist.github.com/JWGmeligMeyling/51e8a305f3c268eda473511e202f76e8
And my question is also posted on Stackoverflow (to gain some extra credits for the answer ;-) ):
http://stackoverflow.com/questions/39359924/add-entity-with-inheritancety...
Thanks in advance,
Jan-Willem
9 years, 2 months
Continue "parameter list" support?
by Steve Ebersole
To be clear, this is the feature that lets you define a query like:
select ... from Person p where p.name in (:names)
And then bind varied multiple values into that single parameter holder:
query.setParameterList( "names", new String[] { "Larry", "Curly", "Moe" } );
query.setParameterList( "names", new String[] { "John", "Jane" } );
Which magically transforms to the following (rough) SQL:
select ... from PERSON p where p.name in (?, ?, ?)
select ... from PERSON p where p.name in (?, ?)
Effectively parameter lists allow expansion of the HQL statement - they
literally are handled by altering the HQL on the fly as we prepare to
execute the query. What that means is that we can really not cache these
queries, at least not until the parameters are bound (which kind of defeats
the purpose).
I'd like to discuss dropping support for parameter lists. There are quite
a few reasons I would like to drop this support:
1. This is the main culprit that leads to the ever-resurrecting
discussion about DB limits on IN clauses. The one valid use case I saw for
that lead me to add multi-load support in 5.1.
2. In terms of a QueryPlan cache, this support means we can never
effectively cache the plans for these queries because the SQL is different
every time we execute the query. The problem though is that we do not know
this until well after the point that we'd resolve the QueryPlan.
chicken-egg.
3. This is more an internal detail, but handling the parameter bindings
for these differently gets quite complicated.
4. An additional internal detail is that re-writing the HQL on the fly
is problematic. And some of that leaks to the user in terms of result
caching and stats (which HQL do we use?).
I get that this can be a useful feature for apps that dynamically build
HQL, although really for dynamic query building I think a criteria approach
is more appropriate. It is not so much supporting this feature that bugs
me, it's how we expose it. So an alternative to dropping this support
would be to support it in a different way. The main issue is that I would
like to *syntactically* understanding that a parameter placeholder will be
used for multi-valued parameter from the query itself. This is a
beyond-JPA feature, so we definitely have some leeway here to define this
however we want.
I am open to suggestions as to the best syntax to declare that.
An alternative would be to make some assumptions. Specifically, the only
time I can think this is used is inside an IN predicate. Am I missing
others? If that is the case, we could simply assume that a IN predicate
with a single parameter placeholder is going to be a multivalued
parameter. That assumption holds valid even if just a single value is
bound. The main win there is that we can get rid of the Query#setParameterList
variants. setParameterList was only ever needed so that we could
understand that the parameter is multivalued - here we'd assume that from
its context as the IN predicate value.
Continuing to support parameters-lists in any form does not really
address point
(1) above; but that's ok - the user really could , But each of the
alternatives does help with the other problems currently stemming from
parameter-list support.
9 years, 2 months
Re: [hibernate-dev] Hibernate mapping deprecation
by Steve Ebersole
Yes that will happen:
https://github.com/hibernate/hibernate-orm/wiki/Roadmap7.0
But not any time soon. Basically we will support an "extended" version of
the JPA orm.xml schema that introduces Hibernate specific concepts.
Historically we stayed away from that because IMO it really is against the
spirit, in not the letter, of the JPA spec. However, IIUC this is exactly
what other JPA providers do. So we will go that route.
For a short time we will continue to support hbm.xml files even after 7.0
*to a point*. There are certain hbm.xml concepts that simply do not map
well to JPA - things JPA handles differently. The main one that comes to
mind is property-ref. There will be a "converter" for converting hbm.xml
-> orm.xml. The intention is to allow build-time conversion of hbm.xml
files to the corresponding orm.xml. For a short time we will continue to
support that conversion on the fly at runtime too. Handling of any
non-supported constructs (property-ref, e.g.) is still being discussed.
For sure as part of the on-the-fly runtime conversion it wouyld result in
an exception. For the build-time tool though we'd ideally inject a comment
of some sort into the generated file and log a warning; the difficulty with
that is that JAXB (to my limited knowledge, at least) does not provide a
way to inject an XML comment somewhere in the doc.
Also, keep in mind that a lot of this conversion work is already done on a
branch. Ideally I would love to offer the "extended orm.xml" feature in
6.x (for some x > 0). So even as part of 6.x you'd be able to play around
with that. TBD exactly when we'd drop support for hbm.xml altogether;
obviously some point after 7
On Thu, Sep 8, 2016 at 8:46 AM Koen Serneels <ks(a)error.be> wrote:
> Hi Steve,
>
>
>
> You probably don’t remember me, but we spoke a while back on IRC about
> some stuff regarding hibernate5<->spring4 integration (like SF building)
> and inconsistencies between metadata build from Hibernate mapping files
> compared to their annotation equivalent. Anyway, if I remember correctly
> you mentioned something during our conversation that Hibernate wants to
> more or less deprecate Hibernate mapping files in the future. I would be
> thankful if you could shed some more light on this.
>
>
>
> To explain the situation: at the moment we are considering migrating our
> Hibernate XML mappings to annotations. But as we have a wrapper/super class
> structure with generics, we are trying to make this fit with annotations.
> However, while this might work (we are still testing, as we want to retain
> compatibility with our existing code) we were also thinking on using the
> JPA mapping format as we have the feeling this could be more elegant (to be
> honest, the mapping files never hurted us)
>
>
>
> Now, is it true that Hibernate is going to deprecate the Hibernate mapping
> format? And is using the JPA mapping format instead a sound (read: future
> proof) choice?
> Unless I’m mistaking, Hibernate as a JPA compliant provider, is supposed
> to continue supporting the JPA mapping format unless this would become
> deprecated in specs, which should not happen anytime soon, no?
>
>
>
> Thanks for your time
>
>
>
> Regards,
>
>
>
> Koen.
>
9 years, 2 months
Java 9 upgraded on CI : build b134
by Sanne Grinovero
Hi all,
I just upgraded all of our CI servers to use build b134 of the preview
of Java 9, so you might see some regressions when the next builds
trigger (please don't ignore them!).
Also, I'm happy to see we were listed among the projects which
provided some useful feedback:
- https://wiki.openjdk.java.net/display/quality/Quality+Outreach+Report+Sep...
I'm surprised that we didn't report many actual bugs directly affecting us.
My guess is that Hibernate actually depends on many other projects
which had to pave the road, in some cases with our help (Maven,
Gradle, Javassist, Lucene, Byteman, JRuby, WildFly, Infinispan,
Narayana... to list a few which have been problematic!).
Some of our features are still disabled when running CI on Java 9. I'd
hope in the next few weeks we could try to re-enable some of them?
Thanks,
Sanne
9 years, 2 months
Hibernate Validator 5.3.0.CR1 released
by Guillaume Smet
Hi,
It's with great pleasure that I announce you the first Candidate Release of
Hibernate Validator 5.3.0.
The idea behind this release is to provide our users with enhancements and
bugfixes while we are making progress towards Bean Validation 2.0 and
Hibernate Validator 6.
Expect a quick release of Hibernate Validator 5.3.0.Final if no outstanding
issues are discovered.
See the announcement post
http://in.relation.to/2016/09/05/hibernate-validator-530-cr1-out/ for more
information about this release!
As always, your feedback is highly welcome!
On a side note, if you are interested in defining the future of Bean
Validation, please come join us working on BV 2.0 here:
http://beanvalidation.org/.
Happy testing!
--
Guillaume
9 years, 2 months
HHH-11042 Count distinct tuples
by Christian Beikov
Hey,
I wanted to start a discussion regarding this issue:
https://hibernate.atlassian.net/browse/HHH-11042
Although the Dialect class contains the method
"supportsTupleDistinctCount", it is never used, so when doing a count
distinct on a tuple, it just renders the tuple instead of doing a
fallback or throwing an error.
I suggested the OP to override the count function in the dialect to do
whatever he thinks is best but then I realized that the count function
is not even used as the logic is hard coded in some locations. The
problematic location in this case is
"org.hibernate.hql.internal.ast.tree.IdentNode.resolveAsAlias" which
does not consider the function at all but renders the SQL directly.
After suggesting him to introduce a custom function instead and some
discussion on how count distinct could be reliably implemented I think I
found a solution that might work for most databases.
On stackoverflow and other sites it is often suggested to use a checksum
to workaround this limitation which obviously is not a good idea. I
proposed to do concatenation with a separator that doesn't appear in the
string and apparently the character '\0' is a valid character which
makes it a good candidate as that should normally not appear in a string.
The final solution to the problem looks something like the following
count(distinct case when col1 is null or col2 is null then null else
col1 || '\0' || col2 end) + count(case when col1 is null or col2 is null
then 1 end)
The first count does a count distinct on all columns concatenated with
'\0' where all values are not null. The second just counts the cases
where one of the column values was null. Together that emits the proper
count based on the assumption that '\0' does not appear in the columns.
What do you think about that solution? I would like to implement it that
way and do a PR.
I would also like to make use of the count function registered in the
dialect to make this overrideable. Hope that's okay?
Regards,
Christian
9 years, 2 months
