October 2022 - hibernate-issues - Jboss List Archives

[JIRA] (HHH-15605) Date comparisons with attributeconverters for Zoneddatetime broken in Hibernate 6

by Hannes Rosenögger (JIRA)

Hannes Rosenögger ( https://hibernate.atlassian.net/secure/ViewProfile.jspa?accountId=5ec3d02... ) *created* an issue Hibernate ORM ( https://hibernate.atlassian.net/browse/HHH?atlOrigin=eyJpIjoiOTc2NTRiMjE2... ) / Bug ( https://hibernate.atlassian.net/browse/HHH-15605?atlOrigin=eyJpIjoiOTc2NT... ) HHH-15605 ( https://hibernate.atlassian.net/browse/HHH-15605?atlOrigin=eyJpIjoiOTc2NT... ) Date comparisons with attributeconverters for Zoneddatetime broken in Hibernate 6 ( https://hibernate.atlassian.net/browse/HHH-15605?atlOrigin=eyJpIjoiOTc2NT... ) Issue Type: Bug Affects Versions: 6.1.4 Assignee: Unassigned Components: query-hql Created: 17/Oct/2022 02:03 AM Environment: Spring boot 2.7.4 with hibernate 5.6.11 running on jdk17 works fine Spring boot 3.0.0-SNAPSHOT with hibernate 6.1.4 running in jdk17 doesn't work Priority: Major Reporter: Hannes Rosenögger ( https://hibernate.atlassian.net/secure/ViewProfile.jspa?accountId=5ec3d02... ) In one of my applications, we use an attribute converter to store zoneddatetime objects as human-readable strings in the database. This works just fine with hibernate 5.6.11, but in hibernate 6.1.4 it suddenly breaks when comparing dates. Normal crud operations work as intended. The error message with hibernate 6 is: java.lang.IllegalArgumentException: Unsure how to handle given Java type [java.lang.String] as TemporalType#TIMESTAMP I’ve created a small sample project to showcase the behavior: https://github.com/123Haynes/data-jpa-demo/blob/main/src/test/java/com/ex... ( https://github.com/123Haynes/data-jpa-demo/blob/main/src/test/java/com/ex... ) (main branch with spring boot 2.7.4 and hibernate 5.6.11, testcase works as intended) https://github.com/123Haynes/data-jpa-demo/blob/spring-boot-3/src/test/ja... ( https://github.com/123Haynes/data-jpa-demo/blob/spring-boot-3/src/test/ja... ) (branch spring-boot-3 with hibernate 6.1.4, testcase fails with the error mentioned) I’m not sure if I missed something that I need to change in the release notes, or if this usecase is really broken. Any help with this would be greatly appreciated. 🙂 ( https://hibernate.atlassian.net/browse/HHH-15605#add-comment?atlOrigin=ey... ) Add Comment ( https://hibernate.atlassian.net/browse/HHH-15605#add-comment?atlOrigin=ey... ) Get Jira notifications on your phone! Download the Jira Cloud app for Android ( https://play.google.com/store/apps/details?id=com.atlassian.android.jira.... ) or iOS ( https://itunes.apple.com/app/apple-store/id1006972087?pt=696495&ct=EmailN... ) This message was sent by Atlassian Jira (v1001.0.0-SNAPSHOT#100209- sha1:13f5f09 )

2 years, 2 months

1
0
0 / 0

[JIRA] (HSEARCH-4703) HSearch Outbox table module -> inaccesible private field error using Java 9 modules

by Automation for Jira (JIRA)

Automation for Jira ( https://hibernate.atlassian.net/secure/ViewProfile.jspa?accountId=557058%... ) *updated* an issue Hibernate Search ( https://hibernate.atlassian.net/browse/HSEARCH?atlOrigin=eyJpIjoiNTY5NGU2... ) / Bug ( https://hibernate.atlassian.net/browse/HSEARCH-4703?atlOrigin=eyJpIjoiNTY... ) HSEARCH-4703 ( https://hibernate.atlassian.net/browse/HSEARCH-4703?atlOrigin=eyJpIjoiNTY... ) HSearch Outbox table module -> inaccesible private field error using Java 9 modules ( https://hibernate.atlassian.net/browse/HSEARCH-4703?atlOrigin=eyJpIjoiNTY... ) Change By: Automation for Jira ( https://hibernate.atlassian.net/secure/ViewProfile.jspa?accountId=557058%... ) Pull Request: https://github.com/hibernate/hibernate-search/pull/3270 Status: In Progress Pull Request Sent ( https://hibernate.atlassian.net/browse/HSEARCH-4703#add-comment?atlOrigin... ) Add Comment ( https://hibernate.atlassian.net/browse/HSEARCH-4703#add-comment?atlOrigin... ) Get Jira notifications on your phone! Download the Jira Cloud app for Android ( https://play.google.com/store/apps/details?id=com.atlassian.android.jira.... ) or iOS ( https://itunes.apple.com/app/apple-store/id1006972087?pt=696495&ct=EmailN... ) This message was sent by Atlassian Jira (v1001.0.0-SNAPSHOT#100209- sha1:13f5f09 )

2 years, 2 months

1
0
0 / 0

[JIRA] (HHH-15561) Function "IDENTITY" not found when inserting audited revision using Hibernate Envers

by Jan Schatteman (JIRA)

2 years, 2 months

1
0
0 / 0

[JIRA] (HHH-15561) Function "IDENTITY" not found when inserting audited revision using Hibernate Envers

by Jan Schatteman (JIRA)

2 years, 2 months

1
0
0 / 0

[JIRA] (HHH-15561) Function "IDENTITY" not found when inserting audited revision using Hibernate Envers

by Jan Schatteman (JIRA)

2 years, 2 months

1
0
0 / 0

[JIRA] (HHH-15561) Function "IDENTITY" not found when inserting audited revision using Hibernate Envers

by Jan Schatteman (JIRA)

2 years, 2 months

1
0
0 / 0

[JIRA] (HHH-15561) Function "IDENTITY" not found when inserting audited revision using Hibernate Envers

by Jan Schatteman (JIRA)

2 years, 2 months

1
0
0 / 0

[JIRA] (HSEARCH-4714) Early sanity checks for property names

by Automation for Jira (JIRA)

2 years, 2 months

1
0
0 / 0

[JIRA] (HSEARCH-3567) Automatic reindexing on one-sided association updates

by Yoann Rodière (JIRA)

Yoann Rodière ( https://hibernate.atlassian.net/secure/ViewProfile.jspa?accountId=557058%... ) *updated* an issue Hibernate Search ( https://hibernate.atlassian.net/browse/HSEARCH?atlOrigin=eyJpIjoiMjRjMjVj... ) / Improvement ( https://hibernate.atlassian.net/browse/HSEARCH-3567?atlOrigin=eyJpIjoiMjR... ) HSEARCH-3567 ( https://hibernate.atlassian.net/browse/HSEARCH-3567?atlOrigin=eyJpIjoiMjR... ) Automatic reindexing on one-sided association updates ( https://hibernate.atlassian.net/browse/HSEARCH-3567?atlOrigin=eyJpIjoiMjR... ) Change By: Yoann Rodière ( https://hibernate.atlassian.net/secure/ViewProfile.jspa?accountId=557058%... ) Let's imagine a model with two entity types {{A}} and {{B}}, pointing to each other through an association: {{A.b}} and {{B.a}}. {{A}} is an indexed entity, and its indexed document includes some parts of {{B}} through the association {{A.b}} (e.g. there's a field {{b.c}} in A's indexed document). When the user updates the association between {{A}} and {{B}}, we expect him to update both sides of the association: {{A.b}} *and* {{B.a}}. If the user were to only update {{B.a}}, we would know that the entity previously pointed to by B.a needs to be reindexed, but we wouldn't know which entity this was, since {{B.a}} was updated (set to null or to another entity)... There are two problems with this limitations: 1. ORM allows only updating one side of the association (the owning side), which means users are likely to only update one side from time to time. When they do, Hibernate Search will silently "forget" to reindex. Best case, users will spot the problem, will assume Search is buggy and painstakingly update their application to update both sides of the association; worst case they will not spot the problem and they will ship a buggy application. 2. This effectively precludes us from allowing unidirectional associations, where {{A.b}} doesn't exist and is replaced with a query: if we did that, we wouldn't be able to reindex when the association is updated on the {{B}} side. In Search 5 (and 6 after [https://hibernate.atlassian.net/browse/ HSEARCH-4303 |https://hibernate.atlassian.net/browse/HSEARCH-4303|smart-link] ), we partially support such one-sided association updates: if {{B}} was completely deleted and the association {{B.a}} was left untouched, we walk through that association and reindex {{A}}. However this only works when the association is updated implicitly though deletion of {{B}}, and {{B.a}} is eager or already loaded, {{A.b}} is lazy. I think we should support support one-sided association updates. We would only have to store in the work plan, for each entity and each relevant association from that entity, the list of entities removed from associations: * When a {{*ToOne}} association is set to null, or simply changed, we'd use the entity update event to find the previous value of that association. * When a {{*ToMany}} association is updated or replaced, we'd use the collection update or replace event to find the entities removed from the association. * When an entity is deleted, we'd use the before delete event to load every relevant association, and add updates to the work plan for the inverse side of each association. This might be a bit heavy resource wise, but we would only need to do that for associations from an "indexedEmbedded" or otherwise contained type to its containing type. There may be ways to optimize this. The big question is, of course, would extracting this information be easy, or even possible at all? ( https://hibernate.atlassian.net/browse/HSEARCH-3567#add-comment?atlOrigin... ) Add Comment ( https://hibernate.atlassian.net/browse/HSEARCH-3567#add-comment?atlOrigin... ) Get Jira notifications on your phone! Download the Jira Cloud app for Android ( https://play.google.com/store/apps/details?id=com.atlassian.android.jira.... ) or iOS ( https://itunes.apple.com/app/apple-store/id1006972087?pt=696495&ct=EmailN... ) This message was sent by Atlassian Jira (v1001.0.0-SNAPSHOT#100208- sha1:492d0ce )

2 years, 2 months

1
0
0 / 0

[JIRA] (HSEARCH-3567) Automatic reindexing on one-sided association updates

by Yoann Rodière (JIRA)

2 years, 2 months

1
0
0 / 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

hibernate-issues October 2022