HHH-11396 - Timezone handling
by Christian Beikov
Hey everyone,
I'd like to get your opinion on something. We had this issues regarding
timezone handling which Vlad closed pretty quickly saying it isn't a
Hibernate problem and I generally agree, but still would like to know
what you think about it.
So basically what we do in the LocalDateJavaDescriptor(and also in some
other places) is to use the value returned by java.sql.Date in some way
and pack that into the target type. In this case this happens behind the
scenes when invoking java.sql.Date.toLocalDate() but internally it just
calls LocalDate.of(getYear() + 1900, getMonth() + 1, getDate()).
Now IMO the problem really is in java.sql.Date because it does a
timezone conversion. The user who created the issue HHH-11396
<https://hibernate.atlassian.net/browse/HHH-11396> pointed out he was
using a DATE column type because he wanted to have a simple date i.e.
year, month and date. When using java.sql.Date and the consumer is in a
timezone after UTC i.e. UTC+1, the calculations of java.sql.Date will
subtract that offset during /normalization/ and the millisecond value
will change by that offset. This means that a date in the DBMS that is
2000-01-01 will become 1999-12-31 when the client is in UTC+1.
One possible fix is to simply configure UTC for the consumer, then there
will be no timezone shift.
I think what java.sql.Date does is wrong because a date has no time
part, so there shouldn't be any time shifts. We should workaround that
by shifting the millisecond value back when constructing a LocalDate.
What do you think should we do? Does anyone maybe know why java.sql.Date
behaves that way?
--
Mit freundlichen Grüßen,
------------------------------------------------------------------------
*Christian Beikov*
7 years, 8 months
Cursor leak
by Vikas Bali
Hi
I've observed cursor leak when using hibernate core version 4.1.6 with Java 8 and JBOSS EAP 7 env. I simply loading objects from database using hibernate and I do see for each hibernate execution, cursor is opened and it never closed till jobs server instance is down.
I have tried using current session, new session and stateless session, cursor never gets closed.
Please suggest any workaround to deal with this leak.
Thanks
Vikas
7 years, 8 months
Can someone confirm if DB2 9.5 supports "cross join"?
by Gail Badner
I created HHH-11499 to create a new dialect for DB2 to use "cross join"
syntax instead of "," (as is currently done in DB2Dialect).
Although DB2 9.1 reached its end of life April 30, 2015, some applications
may still be using that version, so I will create a new DB2 dialect that
extends DB2Dialect and overrides getCrossJoinSeparator() to return " cross
join ".
The question is what to call the new dialect.
According to DB2 9.5 and 9.7 documentation, "cross join" syntax is
supported in those versions. I am able to confirm this on 9.7, but I do not
have access to DB2 9.5 to try it out.
If someone can confirm this will work on DB2 9.5 by the time Hibernate
5.2.9 is released, then I'll name the new dialect DB295Dialect; otherwise,
I'll name it DB297Dialect.
Thanks!
Gail
7 years, 8 months
HHH-11144
by Gail Badner
HHH-11144 involves an entity that has 2 one-to-many associations with the
same type of entity, and both associations have orphanRemoval = true.
Andrea created a PR with test case at [1]
I am not sure if this is a valid mapping. I I would like your thoughts on
this.
Here is an excerpt of the relevant bits:
@Entity(name = "Item")
public static class Item {
@OneToMany(mappedBy = "parent", cascade = CascadeType.ALL, orphanRemoval
= true)
protected Set<ItemRelation> lowerItemRelations = new LinkedHashSet<>();
@OneToMany(mappedBy = "child", cascade = CascadeType.ALL, orphanRemoval =
true)
protected Set<ItemRelation> higherItemRelations = new LinkedHashSet<>();
}
@Entity(name = "ItemRelation")
public static class ItemRelation {
@ManyToOne(optional = false)
@JoinColumn(name = "PARENT_ID")
private Item parent;
@ManyToOne(optional = false)
@JoinColumn(name = "CHILD_ID")
private Item child;
}
HHH-11144 describes inconsistent behavior observed when
Item#lowerItemRelations and Item#higherItemRelations both contain the same
ItemRelation, then one of the collections is cleared.
If the non-cleared collection is uninitialized, then the ItemRelation is
orphan deleted.
If the non-cleared collection is initialized, then the orphan-deleted
ItemRelation is rescued when PERSIST_ON_FLUSH cascades to the non-cleared
collection elements. The next time the collections are loaded from the
database, both will still contain that same ItemRelation.
The spec says:
"Portable applications must otherwise not depend upon a specific order of
removal, and must not reassign an entity that has been orphaned to another
relationship or *otherwise attempt to persist it*"
Is Hibernate doing the right thing by rescuing an orphan-deleted entity?
In addition, this mapping allows a particular EntityRelation to be
associated with 2 different Item entities, which would mean that the same
ItemRelation would have 2 different owners with respect to orphan deletion..
The spec says:
"The orphanRemoval functionality is intended for entities that are privately
“owned” by their parent entity."
Does this mean that the mapping is invalid, since it would allow multiple
parent entities, or does it mean that the resulting behavior is undefined
(thus non-portable)?
Please let me know your thoughts.
Thanks,
Gail
[1] https://github.com/hibernate/hibernate-orm/pull/1607
7 years, 8 months
Hibernate ORM 5.1.5
by Gail Badner
It turns out that I need to release Hibernate ORM 5.1.5 after all, so it
can be included in WildFly. I created the 5.1.5 tag yesterday, and now I am
going through the steps to release 5.1.5 to the community.
In the process I will have to reopen all the jiras that were backported to
add 5.1.5 as a fix version, then re-close them.
There may be more 5.1 community releases after 5.1.5. If there is something
you think should be backported to 5.1 (or 5.0) please feel free to let me
know by clicking the "Backport" checkbox in the Jira or adding a jira
comment directed to me using [~gbadner] or @gbadner.
Please do not backport a fix yourself without checking with me first.
Thanks,
Gail
7 years, 8 months
6.0 - design question: "model navigation" exposed as an API?
by Steve Ebersole
Currently in 6.0 we have the notion of a Navigable which models any "piece"
of the application's domain model[1]. We also have the notion of
a NavigableVisitationStrategy which defines the strategy for handling the
visitation of the nodes in a Navigable tree. In other words, Hibernate
defines a common visitor for how to walk the application's mapped domain
model and the NavigableVisitationStrategy implementation controls which
sub-trees are walked; e.g. we'd use this to apply JPA EntityGraphs or to
stop joining joinable Navigables after we have reached the
`max_fetch_depth` setting value.
It is important to note that this is very, very different from JPA's model
and walking it. JPA's model essentially precludes those model nodes from
defining relational mappings as part of its type system in any sane way;
this is due to various reasons because of the model's design[2]. This
Navigable walking would walk the real/full relational mapping model.
The design question is whether we want to expose this "domain mode walking"
as a general public API feature. This has been requested before; Max once
asked for it although I forget why.
Making this an API means exposing quite a few things. Typical visitor
pattern, the visitor (NavigableVisitationStrategy) exposes "handle" methods
based on specific Navigable sub-types. Those sub-types would need to be
moved to API. I don't have a particular concern with that, just mentioning
it.
Opinions on whether this should become an API?
For sure we'd mark it @Incubating, if we decide to do it.
[1] Short synopsis: Navigables include things like EntityPersister,
CollectionPersister, EmbeddedPersister, PersistentAttribute,
CollectionIndex, CollectionElement. A Navigable is always relative to a
NaviagbleSource. NaviagbleSources are any domain Navigable
(NavigableSource extends Navigable) which includes things like
EntityPersister, EmbeddedPersister, SingularPersistentAttribute,
CollectionElementEntity, CollectionElementEmbedded, etc . The
NaviagbleSource will be null in the case of EntityPersister (as a root),
but in all other cases the NaviagbleSource is non-null.
[2] I won't get into the reasons here, but we can certainly follow up if
anyone challenges that assertion.
7 years, 9 months
Hibernate#isPropertyInitialized vs Hibernate#isInitialized
by Gail Badner
I think there can be an inconsistency between
Hibernate#isPropertyInitialized vs Hibernate#isInitialized when it comes to
an extra-lazy collection of an enhanced entity.
IIUC, after fixing HHH-11161 [1], if an extra-lazy collection is accessed
on an enhanced entity, the collection property is set to an uninitialized
PersistentCollection and calling Hibernate#isPropertyInitialized(
collectionfieldName ) will return true, even though the collection itself
is uninitialized.
I would have expected that false would be returned.
I've added a comment to the issue and asked Luis about it. Luis has pointed
out the 3 stages of an extra-lazy collection on an enhanced entity. I've
listed them below and added my understanding of what Hibernate#initialize
and Hibernate#isPropertyInitialized will return in each instance:
1) the attribute is not loaded at all;
Hibernate.isPropertyInitialized( enhancedEntity, "extraLazyCollection" )
returns false;
Hibernate.initialize( enhancedEntity.getExtraLazyCollection() ) returns
false; a side-affect
is that the attribute will be set to an uninitialized
PersistentCollection.
2) the attribute is loaded, but the elements are not loaded;
Hibernate.isPropertyInitialized( enhancedEntity, "extraLazyCollection" )
returns true,
because the property is initialized to a PersistentCollection (even
though the PersistentCollection itself is uninitialized).
Hibernate.initialize( enhancedEntity.getExtraLazyCollection() ) returns
false.
3) the attribute is loaded and the elements are loaded.
Hibernate.isPropertyInitialized( enhancedEntity, "extraLazyCollection" )
returns true.
Hibernate.initialize( enhancedEntity.getExtraLazyCollection() ) returns
true.
Opinions about the inconsistency in 2)? Is this a bug in the code or in the
Javadoc?
Thanks,
Gail
[1] https://hibernate.atlassian.net/browse/HHH-11161
7 years, 9 months
