Is Joda Time's DateTime class persisted differently when given in the UTC timezone? The timestamps look unusual (may be all zeroes).
Joda Time created them just fine with new DateTime(DateTimeZone.UTC). Are they persisted in PostgreSQL in an unfamiliar format?
"2012-09-02 23:43:44.642-07"
"2012-09-03 00:05:01.517-07"
"2012-09-03 00:10:30.704-07"
"1969-12-31 16:00:00-08"
"2012-09-03 00:23:40.556-07"
"1969-12-31 16:00:00-08"
"1969-12-31 16:00:00-08"
"1969-12-31 16:00:00-08"
The versions are:
postgresql-9.1-901.jdbc4.jar
DataNucleus Core/RDBMS 3.1.1
DataNucleus Joda Time 3.1.0-release.
Thank you.
As detailed in the comments, the problem was solved by upgrading the JDBC4 driver for PostgreSQL to 'postgresql-9.1-901-1.jdbc4.jar'.
Related
what is the easiest way to map POJO to/from PostgreSQL user-defined types?
Wait until Hibernate 6.2 is released. This will happen soon (within 2022) and will come with support for mapping embeddables as structs. Also see https://hibernate.atlassian.net/browse/HHH-15327
I'm trying to get some java.time types (LocalDate, ZonedDateTime) to work with Grails 5, GORM 7, with a MongoDb 3.4 database. I'm using the MongoDb plugin v7.3.0, mongodb-driver-core/mongodb-driver-sync v4.5.0.
The appropriate codecs seem to be available from the package org.grails.datastore.bson.codecs, but they don't seem be be getting used. When a document is stored to Mongo, LocalDate and ZonedDateTime are serialized as strings, and when I try to retrieve them, I get this error:
Cannot convert value of type 'java.lang.String' to required type 'java.time.LocalDate' for property 'dob': no matching editors or conversion strategy found.
I've reviewed the GORM for MongoDb docs (https://gorm.grails.org/latest/mongodb/manual/), but there isn't much help there. I would assume the appropriate codecs would be automatically registered, but in case the weren't I followed that documentation to register the codecs in my application.yml file, but that didn't work either. Not sure next step on this, maybe I can't do this in Grails?
Edit: Added example repo: https://github.com/MichaelJRussell/mongo-test
I want to use Java 8 dates in JPA 2.1 entities, but as you know there is no default converters for these types. I have found spring implementation of that converters, but I don't understand implementation.
https://github.com/spring-projects/spring-data-commons/blob/master/src/main/java/org/springframework/data/convert/Jsr310Converters.java
Why spring data Jsr310Converters convert all Jsr310 types to java.util.Date?
Can I map LocalDate to date type field in my database in that case?
**Why conversion java.time.LocalDate <==> java.sql.Date isn't better solution to achieve that goal?
https://github.com/marschall/threeten-jpa
In my opinion this solution is better, but I want to know why spring solution is also good
Does anyone knows if morphia supports automatic timestamp for create/update of documents in a collection in mongodb during its create/modify operations.
I have already come to know that this support is not available in mongodb. I would like to know if there is any way to get the last access/update time of data or documents in morphia driver.
Thanks,
sadish
I'm generally using a base entity, which all other entities extend. It provides the ObjectId, creation date, last change date, a disabled flag,...
The relevant code snippets look like this:
protected Date creationDate;
protected Date lastChange;
// Getters and setters or final setters which don't do anything,
// if you only want to allow the entity to update the values
#PrePersist
public void prePersist() {
creationDate = (creationDate == null) ? new Date() : creationDate;
lastChange = (lastChange == null) ? creationDate : new Date();
}
Sorry in advance if this isn't the exact answer you're looking for. But the short answer is no.
There appears to be no API in the latest Morphia which supports that operation. Maybe there is a bug opened to support this. In the meantime, you should use your favorite constructor for java.util.Date or java.sql.Timestamp.
The source code for Morphia has the appropriate converter built in to handle this TimestampConverter.java.
Only tangentially related. If your reason for using $currentDate is to avoid clock skew problems among multiple hosts, then you're barking up the wrong tree. Though not explicitly stated in the $currentDate documentation, it is documented that MongoDB does nothing to address clock skew among various hosts. This can be found in the documentation for ObjectId.getTimestamp(). Therefore, the usage of $currentDate is going to provide little benefit as opposed to time-stamping in the client side.
I need a consensus on the practice of persisting timestamps, specifically on the pros & cons of using java.util.Date compared to using long.
Scope of this discussion:
Performance
Querying Flexibility (e.g. date range)
Any hazards in coding and querying
Portability (e.g. migration to other DB)
About myself:
I consider myself to be a beginner in JPA, dabbling in it once in a while, not being able to apply it into production level projects until now. In my current project, I commit myself to use ObjectDB (embedded) through JPA calls.
The following class demonstrates 3 possible methods for persisting timestamps in JPA:
#Entity
public class Timestamps {
private java.sql.Timestamp ts1;
private #Temporal(TemporalType.TIMESTAMP) java.util.Date ts2;
private long ts3;
:
}
Regarding performance and memory consumption, ts3 is a bit more efficient.
ts3 may be less convenient to use than ts1 and ts2 (in ObjectDB Database Explorer, reports, etc.).
Basic queries such as retrieval by date range are supported for all the three, but extracting date and time parts (YEAR, MONTH, etc.) in queries is not supported for ts3.
All these forms are expected to be portable.
ts1 and ts2 are practically equivalent.
More details are provided in the ObjectDB manual.
In the documentation of java it looks like timestamp is closer related to java.util.date
http://docs.oracle.com/javase/1.4.2/docs/api/java/sql/Timestamp.html
additionally if you care about the semantic of your code, a timestamp is a date.
You should be aware about java.sql.Timestamp's fact before using it:
There are some classes in the Java platform libraries that do extend an instantiable
class and add a value component. For example, java.sql.Timestamp
extends java.util.Date and adds a nanoseconds field. The equals implementation
for Timestamp does violate symmetry and can cause erratic behavior if
Timestamp and Date objects are used in the same collection or are otherwise intermixed.
The Timestamp class has a disclaimer cautioning programmers against
mixing dates and timestamps. While you won’t get into trouble as long as you
keep them separate, there’s nothing to prevent you from mixing them, and the
resulting errors can be hard to debug. This behavior of the Timestamp class was a
mistake and should not be emulated. (Bloch, Effective Java, 2nd Ed.)