August 2023 - hibernate-issues - Jboss List Archives

[JIRA] (HSEARCH-4915) Errors returned by OpenSearch/ElasticSearch not forwarded to caller

by Andreas Lanz (JIRA)

Andreas Lanz ( https://hibernate.atlassian.net/secure/ViewProfile.jspa?accountId=557058%... ) *commented* on HSEARCH-4915 ( https://hibernate.atlassian.net/browse/HSEARCH-4915?atlOrigin=eyJpIjoiNTA... ) Re: Errors returned by OpenSearch/ElasticSearch not forwarded to caller ( https://hibernate.atlassian.net/browse/HSEARCH-4915?atlOrigin=eyJpIjoiNTA... ) Hi @Marko Bekhta, thanks for the quick response. I saw that you were already able to reproduce the issue. Do you still need / want a reproducer from me in that case? If yes, I can prepare one, but it might take a few days. One question: Would it be possible to backport your changes to 6.2 once the PR for main is approved? This issue is quite critical for us. We currently worked around it by simplifying the query, but as the query depends on configurations made by the user, there is no guarantee we won’t see the error again. ( https://hibernate.atlassian.net/browse/HSEARCH-4915#add-comment?atlOrigin... ) Add Comment ( https://hibernate.atlassian.net/browse/HSEARCH-4915#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#100234- sha1:aec3a25 )

9 months, 2 weeks

1
0
0 / 0

[JIRA] (HHH-17080) [Envers] AuditReader.getRevisionNumberForDate(LocalDateTime) uses Epoch Seconds instead of Epoch Millis

by Kai Zander (JIRA)

Kai Zander ( https://hibernate.atlassian.net/secure/ViewProfile.jspa?accountId=557058%... ) *updated* an issue Hibernate ORM ( https://hibernate.atlassian.net/browse/HHH?atlOrigin=eyJpIjoiOTYzMDYwMmI1... ) / Bug ( https://hibernate.atlassian.net/browse/HHH-17080?atlOrigin=eyJpIjoiOTYzMD... ) HHH-17080 ( https://hibernate.atlassian.net/browse/HHH-17080?atlOrigin=eyJpIjoiOTYzMD... ) [Envers] AuditReader.getRevisionNumberForDate(LocalDateTime) uses Epoch Seconds instead of Epoch Millis ( https://hibernate.atlassian.net/browse/HHH-17080?atlOrigin=eyJpIjoiOTYzMD... ) Change By: Kai Zander ( https://hibernate.atlassian.net/secure/ViewProfile.jspa?accountId=557058%... ) {{AuditReader.getRevisionNumberForDate(LocalDateTime)}} delegates to {{RevisionTimestampValueResolver.resolveByValue(LocalDateTime)}}. When the type of the revision timestamp property in our revision entity is {{Long}}/{{long}}, the argument is converted to epoch _seconds_ [here|https://github.com/hibernate/hibernate-orm/blob/6.2.7/hibernate-enve...]: {code:java}return localDateTime.atZone( ZoneId.systemDefault() ).toInstant().getEpochSecond(); // <-- should be toEpochMilli(){code} The result is then used as the parameter in the revision number query: {code:sql}select max(rev) from revision_info where revtstmp <= ?{code} However, the {{revtstmp}} represents epoch _millis_, as can be seen [a few lines up|https://github.com/hibernate/hibernate-orm/blob/6.2.7/hibernate-envers...] in {{RevisionTimestampValueResolver.resolveNow(Object)}}: {code:java}revisionTimestampSetter.set( object, System.currentTimeMillis() );{code} As a result, {{AuditReader.getRevisionNumberForDate(LocalDateTime)}} will basically never return anything if we have a {{@RevisionTimestamp long revtstmp}} attribute. ---- Workaround: Use {{AuditReader.getRevisionNumberForDate(Date)}}, where the {{java.util.Date}} argument is correctly converted to epoch _millis_ in {{RevisionTimestampValueResolver.resolveByValue(Date)}} [here|https://github. com/hibernate/hibernate-orm/blob/6.2.7/hibernate-envers/src/main/java/org/hibernate/envers/internal/revisioninfo/RevisionTimestampValueResolver.java#L57]. ( https://hibernate.atlassian.net/browse/HHH-17080#add-comment?atlOrigin=ey... ) Add Comment ( https://hibernate.atlassian.net/browse/HHH-17080#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#100234- sha1:aec3a25 )

9 months, 2 weeks

1
0
0 / 0

[JIRA] (HHH-17080) [Envers] AuditReader.getRevisionNumberForDate(LocalDateTime) uses Epoch Seconds instead of Epoch Millis

by Kai Zander (JIRA)

Kai Zander ( https://hibernate.atlassian.net/secure/ViewProfile.jspa?accountId=557058%... ) *updated* an issue Hibernate ORM ( https://hibernate.atlassian.net/browse/HHH?atlOrigin=eyJpIjoiODEwOGYzMDQ5... ) / Bug ( https://hibernate.atlassian.net/browse/HHH-17080?atlOrigin=eyJpIjoiODEwOG... ) HHH-17080 ( https://hibernate.atlassian.net/browse/HHH-17080?atlOrigin=eyJpIjoiODEwOG... ) [Envers] AuditReader.getRevisionNumberForDate(LocalDateTime) uses Epoch Seconds instead of Epoch Millis ( https://hibernate.atlassian.net/browse/HHH-17080?atlOrigin=eyJpIjoiODEwOG... ) Change By: Kai Zander ( https://hibernate.atlassian.net/secure/ViewProfile.jspa?accountId=557058%... ) {{AuditReader.getRevisionNumberForDate(LocalDateTime)}} delegates to {{RevisionTimestampValueResolver.resolveByValue(LocalDateTime)}}. When the type of the revision timestamp property in our revision entity is {{Long}}/{{long}}, the argument is converted to epoch _seconds_ [here|https://github.com/hibernate/hibernate-orm/blob/6.2.7/hibernate-enve...]: {code:java}return localDateTime.atZone( ZoneId.systemDefault() ).toInstant().getEpochSecond(); // <-- should be toEpochMilli(){code} The result is then used as the parameter in the revision number query: {code:sql}select max(rev) from revision_info where revtstmp <= ?{code} However, the {{revtstmp}} represents epoch _millis_, as can be seen [a few lines up|https://github.com/hibernate/hibernate-orm/blob/ 46d907deb1f15965c13ade81fba8877c04b33bea 6.2.7 /hibernate-envers/src/main/java/org/hibernate/envers/internal/revisioninfo/RevisionTimestampValueResolver.java#L44] in {{RevisionTimestampValueResolver.resolveNow(Object)}}: {code:java}revisionTimestampSetter.set( object, System.currentTimeMillis() );{code} As a result, {{AuditReader.getRevisionNumberForDate(LocalDateTime)}} will basically never return anything if we have a {{@RevisionTimestamp long revtstmp}} attribute. ---- Workaround: Use {{AuditReader.getRevisionNumberForDate(Date)}}, where the {{java.util.Date}} argument is correctly converted to epoch _millis_ in {{RevisionTimestampValueResolver.resolveByValue(Date)}}. ( https://hibernate.atlassian.net/browse/HHH-17080#add-comment?atlOrigin=ey... ) Add Comment ( https://hibernate.atlassian.net/browse/HHH-17080#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#100234- sha1:aec3a25 )

9 months, 2 weeks

1
0
0 / 0

[JIRA] (HHH-17080) [Envers] AuditReader.getRevisionNumberForDate(LocalDateTime) uses Epoch Seconds instead of Epoch Millis

by Kai Zander (JIRA)

Kai Zander ( https://hibernate.atlassian.net/secure/ViewProfile.jspa?accountId=557058%... ) *updated* an issue Hibernate ORM ( https://hibernate.atlassian.net/browse/HHH?atlOrigin=eyJpIjoiNTZjMDgxYjdk... ) / Bug ( https://hibernate.atlassian.net/browse/HHH-17080?atlOrigin=eyJpIjoiNTZjMD... ) HHH-17080 ( https://hibernate.atlassian.net/browse/HHH-17080?atlOrigin=eyJpIjoiNTZjMD... ) [Envers] AuditReader.getRevisionNumberForDate(LocalDateTime) uses Epoch Seconds instead of Epoch Millis ( https://hibernate.atlassian.net/browse/HHH-17080?atlOrigin=eyJpIjoiNTZjMD... ) Change By: Kai Zander ( https://hibernate.atlassian.net/secure/ViewProfile.jspa?accountId=557058%... ) {{AuditReader.getRevisionNumberForDate(LocalDateTime)}} delegates to {{RevisionTimestampValueResolver.resolveByValue(LocalDateTime)}}. When the type of the revision timestamp property in our revision entity is {{Long}}/{{long}}, the argument is converted to epoch _seconds_ [here|https://github.com/hibernate/hibernate-orm/blob/6.2.7/hibernate-enve...]: {code:java}return localDateTime.atZone( ZoneId.systemDefault() ).toInstant().getEpochSecond(); // <-- should be toEpochMilli() {code} The result is then used as the parameter in the revision number query: {code:sql}select max(rev) from revision_info where revtstmp <= ?{code} However, the {{revtstmp}} represents epoch _millis_, as can be seen [a few lines up|https://github.com/hibernate/hibernate-orm/blob/46d907deb1f15965c13ade...] in {{RevisionTimestampValueResolver.resolveNow(Object)}}: {code:java}revisionTimestampSetter.set( object, System.currentTimeMillis() );{code} As a result, {{AuditReader.getRevisionNumberForDate(LocalDateTime)}} will basically never return anything if we have a {{@RevisionTimestamp long revtstmp}} attribute. ---- Workaround: Use {{AuditReader.getRevisionNumberForDate(Date)}}, where the {{java.util.Date}} argument is correctly converted to epoch _millis_ in {{RevisionTimestampValueResolver.resolveByValue(Date)}}. ( https://hibernate.atlassian.net/browse/HHH-17080#add-comment?atlOrigin=ey... ) Add Comment ( https://hibernate.atlassian.net/browse/HHH-17080#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#100234- sha1:aec3a25 )

9 months, 2 weeks

1
0
0 / 0

[JIRA] (HHH-17080) [Envers] AuditReader.getRevisionNumberForDate(LocalDateTime) uses Epoch Seconds instead of Epoch Millis

by Kai Zander (JIRA)

Kai Zander ( https://hibernate.atlassian.net/secure/ViewProfile.jspa?accountId=557058%... ) *updated* an issue Hibernate ORM ( https://hibernate.atlassian.net/browse/HHH?atlOrigin=eyJpIjoiYzlmNTRlZWE4... ) / Bug ( https://hibernate.atlassian.net/browse/HHH-17080?atlOrigin=eyJpIjoiYzlmNT... ) HHH-17080 ( https://hibernate.atlassian.net/browse/HHH-17080?atlOrigin=eyJpIjoiYzlmNT... ) [Envers] AuditReader.getRevisionNumberForDate(LocalDateTime) uses Epoch Seconds instead of Epoch Millis ( https://hibernate.atlassian.net/browse/HHH-17080?atlOrigin=eyJpIjoiYzlmNT... ) Change By: Kai Zander ( https://hibernate.atlassian.net/secure/ViewProfile.jspa?accountId=557058%... ) {{AuditReader.getRevisionNumberForDate(LocalDateTime)}} delegates to {{RevisionTimestampValueResolver.resolveByValue(LocalDateTime)}}. When the type of the revision timestamp property in our revision entity is {{Long}}/{{long}}, the argument is converted to epoch _seconds_ [here|https://github.com/hibernate/hibernate-orm/blob/6.2.7/hibernate-enve...]: {code:java}return localDateTime.atZone( ZoneId.systemDefault() ).toInstant().getEpochSecond();{code} The result is then used as the parameter in the revision number query: {code:sql}select max(rev) from revision_info where revtstmp <= ?{code} However, the {{revtstmp}} represents epoch _millis_, as can be seen [a few lines up|https://github.com/hibernate/hibernate-orm/blob/46d907deb1f15965c13ade...] in {{RevisionTimestampValueResolver.resolveNow(Object)}}: {code:java}revisionTimestampSetter.set( object, System.currentTimeMillis() );{code} As a result, {{AuditReader.getRevisionNumberForDate(LocalDateTime)}} will basically never return anything if we have a {{@RevisionTimestamp long revtstmp}} attribute. ---- Workaround: Use {{AuditReader.getRevisionNumberForDate(Date)}}, where the {{java.util.Date}} argument is correctly converted to epoch millis _millis_ in {{RevisionTimestampValueResolver.resolveByValue(Date)}}. ( https://hibernate.atlassian.net/browse/HHH-17080#add-comment?atlOrigin=ey... ) Add Comment ( https://hibernate.atlassian.net/browse/HHH-17080#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#100234- sha1:aec3a25 )

9 months, 2 weeks

1
0
0 / 0

[JIRA] (HHH-17080) [Envers] AuditReader.getRevisionNumberForDate(LocalDateTime) uses Epoch Seconds instead of Epoch Millis

by Kai Zander (JIRA)

Kai Zander ( https://hibernate.atlassian.net/secure/ViewProfile.jspa?accountId=557058%... ) *updated* an issue Hibernate ORM ( https://hibernate.atlassian.net/browse/HHH?atlOrigin=eyJpIjoiMWI2ODg2ZjE2... ) / Bug ( https://hibernate.atlassian.net/browse/HHH-17080?atlOrigin=eyJpIjoiMWI2OD... ) HHH-17080 ( https://hibernate.atlassian.net/browse/HHH-17080?atlOrigin=eyJpIjoiMWI2OD... ) [Envers] AuditReader.getRevisionNumberForDate(LocalDateTime) uses Epoch Seconds instead of Epoch Millis ( https://hibernate.atlassian.net/browse/HHH-17080?atlOrigin=eyJpIjoiMWI2OD... ) Change By: Kai Zander ( https://hibernate.atlassian.net/secure/ViewProfile.jspa?accountId=557058%... ) {{AuditReader.getRevisionNumberForDate(LocalDateTime)}} delegates to {{RevisionTimestampValueResolver.resolveByValue(LocalDateTime)}}. When the type of the revision timestamp property in our revision entity is {{Long}}/{{long}}, the argument is converted to epoch _seconds_ [here|https://github.com/hibernate/hibernate-orm/blob/6.2.7/hibernate-enve...]: {code:java}return localDateTime.atZone( ZoneId.systemDefault() ).toInstant().getEpochSecond();{code} The result is then used as the parameter in the revision number query: {code:sql}select max(rev) from revision_info where revtstmp <= ?{code} However, the {{revtstmp}} represents epoch _millis_, as can be seen [a few lines up|https://github.com/hibernate/hibernate-orm/blob/46d907deb1f15965c13ade...] in {{RevisionTimestampValueResolver.resolveNow(Object)}}: {code:java}revisionTimestampSetter.set( object, System.currentTimeMillis() );{code} As a result, {{ AuditRead AuditReader.getRevisionNumberForDate(LocalDateTime)}} will basically never return anything if we have a {{@RevisionTimestamp long revtstmp}} attribute. ---- Workaround: Use {{AuditReader.getRevisionNumberForDate(Date)}}, where the {{java.util.Date}} argument is correctly converted to epoch millis in {{RevisionTimestampValueResolver.resolveByValue(Date)}}. ( https://hibernate.atlassian.net/browse/HHH-17080#add-comment?atlOrigin=ey... ) Add Comment ( https://hibernate.atlassian.net/browse/HHH-17080#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#100234- sha1:aec3a25 )

9 months, 2 weeks

1
0
0 / 0

[JIRA] (HHH-17080) [Envers] AuditReader.getRevisionNumberForDate(LocalDateTime) uses Epoch Seconds instead of Epoch Millis

by Kai Zander (JIRA)

Kai Zander ( https://hibernate.atlassian.net/secure/ViewProfile.jspa?accountId=557058%... ) *updated* an issue Hibernate ORM ( https://hibernate.atlassian.net/browse/HHH?atlOrigin=eyJpIjoiNTk4ODhkM2Nh... ) / Bug ( https://hibernate.atlassian.net/browse/HHH-17080?atlOrigin=eyJpIjoiNTk4OD... ) HHH-17080 ( https://hibernate.atlassian.net/browse/HHH-17080?atlOrigin=eyJpIjoiNTk4OD... ) [Envers] AuditReader.getRevisionNumberForDate(LocalDateTime) uses Epoch Seconds instead of Epoch Millis ( https://hibernate.atlassian.net/browse/HHH-17080?atlOrigin=eyJpIjoiNTk4OD... ) Change By: Kai Zander ( https://hibernate.atlassian.net/secure/ViewProfile.jspa?accountId=557058%... ) {{AuditReader.getRevisionNumberForDate(LocalDateTime)}} delegates to {{RevisionTimestampValueResolver.resolveByValue(LocalDateTime)}}. When the type of the revision timestamp property in our revision entity is {{Long}}/{{long}}, the argument is converted to epoch _seconds_ [here|https://github.com/hibernate/hibernate-orm/blob/6.2.7/hibernate-enve...]: {code:java} return localDateTime.atZone( ZoneId.systemDefault() ).toInstant().getEpochSecond();{code} The result is then used as the parameter in the revision number query: {code:sql}select max(rev) from revision_info where revtstmp <= ?{code} However, the {{revtstmp}} represents epoch _millis_, as can be seen [a few lines up|https://github.com/hibernate/hibernate-orm/blob/46d907deb1f15965c13ade...] in {{RevisionTimestampValueResolver.resolveNow(Object)}}: {code:java}revisionTimestampSetter.set( object, System.currentTimeMillis() );{code} As a result, {{AuditRead.getRevisionNumberForDate(LocalDateTime)}} will basically never return anything if we have a {{@RevisionTimestamp long revtstmp}} attribute. ---- Workaround: Use {{AuditReader.getRevisionNumberForDate(Date)}}, where the {{java.util.Date}} argument is correctly converted to epoch millis in {{RevisionTimestampValueResolver.resolveByValue(Date)}}. ( https://hibernate.atlassian.net/browse/HHH-17080#add-comment?atlOrigin=ey... ) Add Comment ( https://hibernate.atlassian.net/browse/HHH-17080#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#100234- sha1:aec3a25 )

9 months, 2 weeks

1
0
0 / 0

[JIRA] (HHH-17080) [Envers] AuditReader.getRevisionNumberForDate(LocalDateTime) uses Epoch Seconds instead of Epoch Millis

by Kai Zander (JIRA)

Kai Zander ( https://hibernate.atlassian.net/secure/ViewProfile.jspa?accountId=557058%... ) *created* an issue Hibernate ORM ( https://hibernate.atlassian.net/browse/HHH?atlOrigin=eyJpIjoiMjM1OWE5MWM0... ) / Bug ( https://hibernate.atlassian.net/browse/HHH-17080?atlOrigin=eyJpIjoiMjM1OW... ) HHH-17080 ( https://hibernate.atlassian.net/browse/HHH-17080?atlOrigin=eyJpIjoiMjM1OW... ) [Envers] AuditReader.getRevisionNumberForDate(LocalDateTime) uses Epoch Seconds instead of Epoch Millis ( https://hibernate.atlassian.net/browse/HHH-17080?atlOrigin=eyJpIjoiMjM1OW... ) Issue Type: Bug Affects Versions: 6.2.7 Assignee: Chris Cranford ( https://hibernate.atlassian.net/secure/ViewProfile.jspa?accountId=557058%... ) Components: hibernate-envers Created: 15/Aug/2023 00:59 AM Priority: Major Reporter: Kai Zander ( https://hibernate.atlassian.net/secure/ViewProfile.jspa?accountId=557058%... ) AuditReader.getRevisionNumberForDate(LocalDateTime) delegates to RevisionTimestampValueResolver.resolveByValue(LocalDateTime). When the type of the revision timestamp property in our revision entity is Long / long , the argument is converted to epoch seconds here ( https://github.com/hibernate/hibernate-orm/blob/6.2.7/hibernate-envers/sr... ) : return localDateTime.atZone( ZoneId.systemDefault() ).toInstant().getEpochSecond(); The result is then used as the parameter in the revision number query: select max (rev) from revision_info where revtstmp <= ? However, the revtstmp represents epoch millis , as can be seen a few lines up ( https://github.com/hibernate/hibernate-orm/blob/46d907deb1f15965c13ade81f... ) in RevisionTimestampValueResolver.resolveNow(Object) : revisionTimestampSetter.set( object, System.currentTimeMillis() ); As a result, AuditRead.getRevisionNumberForDate(LocalDateTime) will basically never return anything if we have a @RevisionTimestamp long revtstmp attribute. Workaround: Use AuditReader.getRevisionNumberForDate(Date) , where the java.util.Date argument is correctly converted to epoch millis in RevisionTimestampValueResolver.resolveByValue(Date). ( https://hibernate.atlassian.net/browse/HHH-17080#add-comment?atlOrigin=ey... ) Add Comment ( https://hibernate.atlassian.net/browse/HHH-17080#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#100234- sha1:aec3a25 )

9 months, 2 weeks

1
0
0 / 0

[JIRA] (HHH-17079) NPE when using CompositeUserType with generic fields in Hibernate 6

by Marko Bekhta (JIRA)

9 months, 2 weeks

1
0
0 / 0

[JIRA] (HHH-17078) Memory leak in ScrollableResultsConsumer

by Christian Beikov (JIRA)

9 months, 2 weeks

1
0
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

hibernate-issues August 2023