I upgraded from Hibernate Search 4.4 to 5.3 and sucessfully migrated all issues in Hibernate Search Migration Guides, but I'm encountering the following error regarding a date property when using MultiFieldQueryParser.
org.hibernate.search.exception.SearchException: HSEARCH000233: The specified query '+(dateField:value)' contains a string based sub query which targets the numeric encoded field(s) 'myDate'. Check your query or try limiting the targeted entities.
My date property is pretty standard
#Column(name = "my_date")
#Temporal(TemporalType.TIMESTAMP)
#Field
#DateBridge(resolution = org.hibernate.search.annotations.Resolution.DAY)
private Date myDate;
Versions
Hibernate 4.3
Hibernate Search 5.3
had to explicitly import (maven) org.apache.lucene.lucene-queryparser (4.10.4) for org.apache.lucene.queryparser.classic.MultiFieldQueryParser, otherwise it wouldn't find it
Also found this issue (HSEARCH-1870) regarding date values, not sure if related.
Am I missing something on myDate declaration?
EDIT: missed one migration requirement - see my answer bellow.
As it turns out I missed one migration requirement: enconding is set to numeric in HS 5 by default.
Numeric Field(s) being used by default
Numbers and Dates now indexed as Numeric Field by default
Setting the encoding to mimic the behavior in previous versions fixed it.
#Column(name = "my_date")
#Temporal(TemporalType.TIMESTAMP)
#Field
#DateBridge(resolution = org.hibernate.search.annotations.Resolution.DAY, encoding = EncodingType.STRING)
private Date myDate;
Related
I am having an issue upgrading Spring Boot Starter Parent from 2.0.9.RELEASE to 2.3.3.RELEASE. To be more specific, I've traced the issue down to migrating from 2.0.9.RELEASE to 2.1.0.RELEASE. Prior to 2.1.0.RELEASE all of our criteria builder predicates that were doing an equals comparison like the below example were working. With the upgrade to 2.1.0.RELEASE we are no longer able to do equals comparisons as no matching row is returned.
Predicate foreverDatePredicate = criteriaBuilder.equal(root.get("deactivatedAt"), LocalDateTime.of(9999, Month.DECEMBER, 31, 0, 0, 0))
It does appear that with these two Spring Boot releases they went from Hibernate Core 5.2.18.FINAL to 5.3.7.FINAL and possibly JPA 2.1 to 2.2. I'm not sure if these version changes are related to the below problem.
The issue appears to be happening because of a timezone mismatch between what is being used as the timezone locally (PST) and the timezone that is being stored in the database (UTC). In my sql editor I was able to verify the hibernate query works just fine and returns the appropriate rows when a timezone is not supplied in the where clause. All of our datetime columns are being stored in our MySQL database in UTC time. I tried using the following timezone related properties in application.properties and our Hibernate JPA properties but both appeared to either not work or just be completely ignored:
# application.properties
spring.jpa.properties.hibernate.jdbc.time_zone=UTC
# Used in jpaProperties property under entityManagerFactory
hibernate.jdbc.time_zone=UTC
As some other threads have suggested I can set the JVM timezone to UTC, and after trying it this works; however, I would rather avoid doing this as it seems like a pretty far-reaching fix for something that should be able to be resolved at a more granular level:
#PostConstruct
public void started() {
TimeZone.setDefault(TimeZone.getTimeZone("UTC"));
}
I eventually converted our Hibernate entity types that are responsible for mapping to the MySQL datetime columns from LocalDateTime to OffsetDateTime as shown below. OffsetDateTime stores the full timestamp with timezone in UTC time by default and this has resolved the issue and our datetime equals predicates are working again but this has caused a major refactoring headache.
Changed from
#MappedSuperclass
public class BitemporalEntity implements Serializable {
private static final long serialVersionUID = 2966895098986638738L;
#Column(name = "deactivated_at")
protected LocalDateTime deactivatedAt;
To
#MappedSuperclass
public class BitemporalEntity implements Serializable {
private static final long serialVersionUID = 2966895098986638738L;
#Column(name = "deactivated_at")
protected OffsetDateTime deactivatedAt;
I'm just wondering if I'm missing something here. Is using OffsetDateTime instead of LocalDateTime a good resolution to the issue or is there another way?
I have been configuring Spring auditing for my entity classes. Using annotations, I have something like this:
#CreatedDate
#NotNull
private Date createdDate
#CreatedBy
#NotNull
private User createdBy
The createdBy field is being set correctly, however persisting the object fails with a null createdDate. I am guessing that this may be related to type conversion for Eclipselink?
#Temporal annotation is available since the release of JPA 1.0. #Temporal solves the one of the major issue of converting the date and time values from Java object to compatible database type and retrieving back to the application.
#Column(name = "XDATE")
#Temporal(TemporalType.DATETIME)
private Date xDate; //java.util.Date
I hope this will resolve your problem. For more info please refer this link
I am using EclipseLink 2.6.0 in my project together with MySQL 5.6.19.
Since mysql 5.6.4 supports a fieldtype DATETIME(6) which allows to store a date with milliseconds precision in its value. Also EclipseLink 2.6.0 says it supports this functionality.
I am creating a database from my entities. And I am not able to force it to create a proper field. In logs, during database creation I constantly see:
CREATE TABLE MY_TABLE (..., DATE_FIELD DATETIME ...)
when, obviously, what I want is:
CREATE TABLE MY_TABLE (..., DATE_FIELD DATETIME(6), ...)
I tried using both, simple and annotated version:
private java.util.Date date1;
#Temporal(value = TemporalType.TIMESTAMP)
private java.util.Date date2;
but the outcome is always the same. So how does the Eclipselink supports this? How to determine the proper field type?
Thanks specializt for the tip, easy solution:
#Column(length=6)
private Date myTime;
works also with YodaTime converter (description)
#Column(length=6)
#Converter(name = "dateTimeConverter", converterClass = pl.ds.eemediation.storage.entities.converters.JodaDateTimeConverter.class)
#Convert("dateTimeConverter")
private DateTime date;
In my hibernate-4 entity, I am mapping a joda-time DateTime property using the recommended jadira usertypes:
#Entity
#Table(name="timing")
public class TimingEntity {
...
#Basic(optional=false)
#Column(name="moment")
#Type(type="org.jadira.usertype.dateandtime.joda.PersistentDateTime")
public DateTime getMoment() {
...
My database is MySQL. With hibernate property hbm2ddl.auto set to create value, I have the following column generated in my timing table:
CREATE TABLE `timing` (
...
`moment` DATETIME NOT NULL,
...
)
The generated CREATE TABLE contains the DATETIME column. The DATETIME in MySQL has only seconds precision, without fractional part. In order to enable fractional part, up to microseconds, MySQL 5.6.4 and higher enables DATETIME(precision) columns, for example DATETIME(3) to have milliseconds precision.
My question is -- is there way to specify precision for my temporal fields generated with hbm2ddl? At least, is this a matter of jadira usertypes, or java.sql, or jdbc driver machinery?
P.S. When I manually modify the DB table to have the exact column precision I want, say, DATETIME(3), everything works OK - joda DateTimes are written and read from the DB with milliseconds precision.
I've found one more solution that allows not to hardcode MySQL column definition snippet in your #Column annotation. Define your own hibernate dialect by overriding org.hibernate.dialect.MySQLDialect:
package org.yourproject;
import java.sql.Types;
import org.hibernate.dialect.MySQL5Dialect;
public class MySQL564PlusDialect extends MySQL5Dialect {
public MySQL564PlusDialect() {
super();
registerColumnType( Types.TIMESTAMP, 6, "datetime($l)" );
}
}
and specify it as hibernate property hibernate.dialect=org.yourproject.MySQL564PlusDialect (the dialect you'll want to extend may vary, e.g. org.hibernate.dialect.MySQL5InnoDBDialect instead).
Now you can adjust precision of your DATETIME from within #Column annotation by using length attribute:
#Basic(optional=false)
#Column(name="moment", length=3)
#Type(type="org.jadira.usertype.dateandtime.joda.PersistentDateTime")
public DateTime getMoment() {
...
which will produce DATETIME(3) column definition meaning milliseconds precision. If you need the simple DATETIME (no fractional seconds), just don't specify length. You can use value of length up to 6 which would mean microseconds precision.
If you happen to use a dialect different from the above one (for example the standard org.hibernate.dialect.MySQLDialect or maybe some other database), that will not break your code: the length attribute on #Column will be ignored.
P.S. It would be more sensible to exploit the precision attribute of #Column instead of length, but simple replacing of "datetime($l)" pattern with "datetime($p)" one in my own dialect implementation does not work offhand.
Use can use #Column#columnDefinition property for it
#Basic(optional=false)
#Column(name="moment" columnDefinition="DATETIME(3) NOT NULL")
#Type(type="org.jadira.usertype.dateandtime.joda.PersistentDateTime")
public DateTime getMoment()
{
...
Also you can try #Column#precision property, but in documentation is written that this working only for decimals.
I am using this code:
#Column(name = "FECHA_CREACION_TIMESTAMP",columnDefinition="DATE DEFAULT SYSDATE", insertable=false)
#Temporal(TemporalType.TIMESTAMP)
private Date fechaCreacionTimestamp;
But when I insert some data to the table, it doesn't have the date just have the date like null.
Updated Answer: (Now that I know that you are using Oracle)
What you need is to make sure that the column doesn't get included in the insert statements. For that, you need to update your #Column annoation like:
#Column(..other properties.., insertable = false)
See here for more details.
Now, you also need to make sure that the generated value is available in your domain object after you perform the insert. If you are using Hibernate, and do not mind using Hibernate annotations, you can put the following annotation on your field.
#org.hibernate.annotations.Generated(org.hibernate.annotations.GenerationTime.INSERT)
Hibernate will automatically perform the required select query for you.
If you are not using Hibernate, you will need to do a select yourself to fetch the generated value after performing the insert. JPA doesn't have anything to specify that this should be done automatically.
you can use something like :
#Column(name = "FECHA_CREACION_TIMESTAMP",columnDefinition="TIMESTAMP DEFAULT CURRENT_TIMESTAMP", insertable=false)
#Temporal(TemporalType.TIMESTAMP)
private Date fechaCreacionTimestamp;