Re: [hibernate-dev] multiLoad support
by andrea boriero
On 25 Jul 2016 19:29, "Steve Ebersole" <steve(a)hibernate.org> wrote:
>
> I wanted to start a consolidated discussion about multi-load support.
This
> relates to a few Jiras, questioning a few different aspects of its current
> behavior:
>
> https://hibernate.atlassian.net/browse/HHH-10984
> https://hibernate.atlassian.net/browse/HHH-10617
>
> Basically this comes down to the following questions/requests...
>
>
> ## Handling locally deleted entities
>
> First (from HHH-10984) is the idea that locally deleted entities are
> currently returned from multi-load calls. The background here is that
> multi-load support was designed based on IdentifierLoadAccess#getReference
> (Session#load). So its outcome follows what is done for #getReference in
> terms of behavior and results. Now one of the behaviors of #getReference
> that differs from IdentifierLoadAccess#load (Session#get) is how locally
> deleted entities are treated: #getReference will return them, whereas
#load
> will not.
>
> So as I see it we have 3 options:
>
> 1. Continue to expose just the one form on MultiIdentifierLoadAccess
and
> either have this filter out the locally deleted objects, or add a new
> option to specify whether locally deleted objects ought to be returned
in
> the results.
> 2. Expose 2 distinct forms on MultiIdentifierLoadAccess:
> 1. Plural form of #getReference (current behavior, more or less)
> 2. Plural form of #load
> 3. Expose 3 distinct forms on MultiIdentifierLoadAccess:
> 1. Plural form of #getReference
> 2. Plural form of #load
> 3. "Hybrid" form
>
>
I am inclined towards the 2 plural forms
> ## Ordering of results
>
> Much of the discussion on HHH-10984 revolves around the (poorly based,
imo)
> assumption that because a List/array of ids is passed in and because a
List
> is returned that we ought to return the results in the order indicated by
> the incoming List/array of ids.
>
> While I do not agree with the assumption there, I can see that that
> behavior might sometimes be beneficial. Is this something we want to
> support? There is certainly a performance overhead, and so I think we
> definitely do not want to support it by default. But do we want to expose
> an option to allow users to request this?
>
+1 for exposing an option for ordering the results
_______________________________________________
> hibernate-dev mailing list
> hibernate-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
9 years, 7 months
"Awaiting Testcase" transition
by Steve Ebersole
I see folks using a generic "template" for the comment added to an issue
when they transition it to the "Awaiting Testcase" status. If we all
agree, we could make that a post-function of the transition - meaning that
comment would be added automatically.
9 years, 7 months
Needing and ORM 5.1.1.Final
by Sanne Grinovero
Hi all,
we're still needing a release of Hibernate ORM 5.1.1 for Hibernate OGM..
could we plan for one soon please?
Thanks,
Sanne
9 years, 7 months
[ORM] EhCache 3 and JCache
by Emmanuel Bernard
Hello guys,
(I meant to send that almost a month ago, apologies Louis).
I’ve met Louis Jacomet from Ehcache at Devoxx France and we discussed how to restart the progress around JCache and EhCache 3 integration.
Louis is willing to step up to make these a reality but will need a bit of help to ramp up knowledge wise. Let me list the key subjects.
== JCache
I think Sanne has the info somewhere in his brain, what is the status of the current code? Any detail on what was missing? It would be nice to drive this one home.
== Ehcache 3
Ehcache 3 has been out recently and it would be nice to get an integration. The API is very different.
There are a few options:
1. make the JCache support extensible to build upon it and use Ehcache specific features when necessary or useful. Ehcache 3 is a JCache implementation.
2. create an new module dedicated to Ehcache 3 and go for it from scratch basically
3. change the Ehcache module and move it from v2 to v3
1. might be the conceptual nicest but it’s unclear how doable that is
2. vs 3. is about migration path for users and whether we consider it a “breaking change” in a 5.x series
== Doc and pointers
As I said, Louis know Ehcache well but needs some input to step into the magic world of second level caching in Hibernate ORM. Things like where is the code, how to test it, is there a doc or an example of a well written one etc.
Can someone give him a hand?
Emmanuel
9 years, 7 months
People can't find our docs
by Guillaume Smet
Hi,
When we search for Hibernate/Hibernate Search issues, Google send
people to *very* outdated docs.
For instance, searching for %1$s gets me to %2$s:
- hibernate collection element ->
https://docs.jboss.org/hibernate/orm/3.3/reference/en/html/collections.html
(yes, *3.3*)
- hibernate search facet ->
https://docs.jboss.org/hibernate/search/4.5/reference/en-US/html/search-q...
These versions of our docs are very well indexed by Google as they
come up before stack overflow but it's really a bad thing to get
people directed to very old versions of our documentation.
Do we have people at RH working on this sort of things who could help
us defining a good strategy to improve that? Did anyone already take a
look at this?
When I was contributing to PostgreSQL, the subject was discussed at
length and they didn't find a good solution at the time to get Google
to preferably link to the last version. Using canonical urls for
instance requires you to regenerate all the old docs when you have to
point to another URL.
They finally decided to integrate links to all versions at the top of
each doc page: https://www.postgresql.org/docs/9.5/static/sql-syntax.html
.
>From my point of view, here are a few things that might help mitigate the issue:
- have a version of the doc labelled as /current/ (or /stable/) on
hibernate.org. From what I've seen, ORM has a /current/ symlink but
it's currently pointing to the 5.1 documentation and is not used on
the website. We should use this link every time we link to the
documentation (especially on SO).
- Maybe we could try to map the old URLs to the new ones by doing
something similar to what PostgreSQL does but dynamically with jQuery.
We could inject it in the old documentation with something like
http://httpd.apache.org/docs/2.2/mod/mod_substitute.html if we can get
this enabled on docs.jboss.org.
- our doc URLs are now named chNN.html which is not very future proof.
Did we have issues keeping the semantic ones? I suppose it's related
to the asciidoc migration? It would be a good way to keep more stable
URL.
- btw, is there a reason why we only generate the html_single output
for Hibernate ORM?
Thoughts, opinions, ideas?
--
Guillaume
9 years, 7 months
[OGM] Mapping of component types in document stores
by Gunnar Morling
Hi,
We had an interesting discussion on how to map element collections of
component types with a single column to document stores such as MongoDB.
E.g. assume we have
@Entity
public class Person {
public String name;
@ElementCollection
public List<Status> statusHistory;
}
@Embeddable
public class Status {
public String name;
}
Currently, that's mapped to documents like this:
{
"name" : "Bob";
"statusHistory" : [
"great",
"mediocre",
"splendid"
]
}
I.e. if the component type has a single column, we omit the field name in
the persistent structure. Whereas if there are multiple columns, it's added
so we can properly read back such documents:
{
"name" : "Bob";
"statusHistory" : [
{ "name" : "great", "date" : "22.06.2016" },
{ "name" : "mediocre", "date" : "15.05.2016" },
{ "name" : "splendid", "date" : "12.04.2016" }
]
}
The question now is, should we also create such array of sub-documents,
each containing the field name, in the case where there only is a single
column. As far as I remember, the current structure has been chosen for the
sake of efficiency but also simplicity (why deal with sub-documents if
there only is a single field?).
Guillaume is questioning the sanity of that, arguing that mapping this as
an element collection of a component type rather than string should mandate
the persistent structure to always contain the field name.
We cannot change the default as we are committed to the MongoDB format, but
if there is agreement that it's useful, we could add an option to enable
this mapping.
I kind of see how this format simplifies migration (in case another field
is added after a while), but personally I still like the more compact looks
of the current approach. Having an option for it works for me.
Any thoughts?
--Gunnar
9 years, 7 months
6.0 persister redesign
by Steve Ebersole
Along with the Type redesign in 6.0 we will need to do some redesigning of
the persister contracts. I'd like to start collaborating on those changes
with the ongoing 6.0 wip work. I plan on having a design meeting in the
"Hibernate ORM" HipcHat room on Monday around 12 pm Central US time for
anyone that would like to participate.
9 years, 7 months
Second-level cache and Inheritance
by Vlad Mihalcea
Hi,
I bumped into this question on our forum:
https://forum.hibernate.org/viewtopic.php?f=1&t=1043470
And after I tried an example using the latest Hibernate version I see that,
for inheritance, all subentities share the parent region name.
This can be found in org.hibernate.internal.CacheImpl
final String cacheRegionName = cacheRegionPrefix +
model.getRootClass().getCacheRegionName();
As you can see, we take the rootClass when constructing the region name.
For this reason, we cannot use different CacheConcurrencyStartegy with
different subclass types.
Is there any reason for this, or should we consider adding support for this
feature?
Vlad
9 years, 7 months
DISTINCT keyword in JPQL
by Vlad Mihalcea
Hi,
In JPQL/HQL, the DISTINCT keyword is meant to avoid returning the same
parent entities when JOIN FETCHING parents with child associations.
JPA backs it up too:
"The DISTINCT keyword is used to specify that duplicate values must be
eliminated from the query result."
However, I see that the DISTINCT is applied on the SQL statement as well.
Why is it so? Is there any reason why we would want such a behaviour?
The problem is that an unnecessary DISTINCT might affect the execution plan:
http://use-the-index-luke.com/sql/join/nested-loops-join-n1-problem?langt...
"The distinct keyword in the SQL query is alarming because most databases
will actually filter duplicate records. Only a few databases recognize that
the primary keys guarantees uniqueness in that case anyway."
Should we provide a Query hint like HINT_DISTINCT_SQL which when explicitly
set, the JPQL DISTINCT keyword generates a DISTINCT keyword on the SQL
statement-level as well.
Without the hint set explicitly, we should not pass the DISTINCT to the SQL
statement.
What do you think?
Vlad
9 years, 7 months
