JIRA usage for OGM
by Sanne Grinovero
There are more than 300 open issues, which is fine but rather than
being these well-defined issues most sound like wishful thinking of
someone having a (possibly cool) idea but not really executing on it.
Since JIRA is an issue tracker and not really a planning tool / note
taking app I wish we could limit this practice of having issues like
"explore integration with.." ?
More specifically, could we move "out of the way" all issues related
to Databases which we're moving into the "contrib" repository?
I think it would be nice to have these in a different JIRA project.
Thanks,
Sanne
9 years, 1 month
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*
9 years, 1 month
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
9 years, 1 month
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
9 years, 1 month
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
9 years, 1 month
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
9 years, 1 month
