No Hibernate type for Interval that lets you query with DateTime about jadira HOT 12 CLOSED

Thanks for your suggestion. What change are you proposing? What problem did you face in the build?

from jadira.

I'm proposing creating a new a class similar to PersistentInterval, however, instead of making use of the DstSafeTimestampType (through TimestampColumnDateTimeMapper) we create an alternate Hibernate type that works on DateTime objects instead of Date. We could just modify DstSafeTimestampType directly but I assume we wouldn't want to do that for compatibility reasons. Thoughts?

When I attempt to build the project, using mvn compile, I get the following error:

[ERROR] Failed to execute goal org.apache.maven.plugins:maven-enforcer-plugin:1.3.1:enforce (enforce-versions) on project usertype.core: Execution enforce-versions of goal org.apache.maven.plugins:maven-enforcer-plugin:1.3.1:enforce failed: org.apache.maven.shared.dependency.graph.DependencyGraphBuilderException: Could not resolve dependencies for project org.jadira.usertype:usertype.core:jar:3.1.1.GA-SNAPSHOT: Failure to find org.jadira.usertype:usertype.spi:jar:tests:3.1.1.GA-SNAPSHOT in http://nexus.hq.allstardirectories.com/content/groups/public/ was cached in the local repository, resolution will not be reattempted until the update interval of central has elapsed or updates are forced -> [Help 1]

The URL mentioned in the error is a local proxy that includes Maven Central as well as other repos. Is there a particular repo I need to be pointing too?

from jadira.

Not sure about the build error, looks like it is in usertype.core. You could build the depmgmt and usertype.spi modules before reattempting the full build.

from jadira.

Its a big issue and will not be implemented in Jadira for a small while. Also, you won't be able to make use of this without a database with a 4.2 driver. In (quite a long) time JPA will remove the need for some of the custom mappings, although again, it will depend on driver support.

This link is very relevant as it explains the cases we need to support to evolve to the best forward compatibility:

https://java.net/jira/browse/JPA_SPEC-63

1. Detection of whether a JDBC 4.2 driver is being used - types marked * below cannot be used without the 4.2 driver, whilst types marked + can have either legacy or 4.2 behaviour. A system property or parameter on any type that can use either 4.2 behaviour or old behaviour should be available to force either legacy or 4.2 type mapping, but if it is not specified the 4.2 behaviour will be the default behaviour where available. Note that driver support for specific types can be enumerated by using DatabaseMetadata.getTypeInfo().
2. PersistentDayOfWeek should be renamed to PersistentDayOfWeekAsInteger and a new PersistentDayOfWeek type (_) introduced. This should map to the DAY_OF_WEEK type using setObject
3. PersistentDurationAsString to be supplemented with PersistentDuration (_) mapped to DURATION, PersistentDurationAsDecimal (fields storing the seconds before the decimal point and the nanoseconds after the decimal point) and PersistentDurationAsInteger (stores the seconds)
4. PersistentInstantAsTimestamp(+) to be updated to use setObject by default, falling back to the current behaviour if 4.2 not detected or specified.
5. PersistentLocalDate(+) to be updated to use setObject by default, falling back to the current behaviour if 4.2 not detected or specified.
6. PersistentLocalDateTime(+) to be updated to use setObject by default, falling back to the current behaviour if 4.2 not detected or specified.
7. PersistentLocalTime(+) to be updated to use setObject by default, falling back to the current behaviour if 4.2 not detected or specified.
8. PersistentMonth should be renamed to PersistentMonthAsInteger and a new PersistentMonth type (_) introduced. This should map to the MONTH type using setObject
9. Add PersistentMonthDay to map to MONTHDAY (_) and PersistentMonthDayAsDate and PersistentMonthDayAsTimestamp to supplement existing PersistentMonthDayAsString
10. PersistentOffsetDateTime to be updated to use setObject by default, falling back to the current behaviour if 4.2 not detected or specified. In addition the type should accept the @javax.persistence.TemporalIncludeTimeZone annotation in addition to the existing parameters
11. PersistentOffsetTimeAsTime to be renamed as PersistentOffsetTime (+), also to be updated to use setObject by default, falling back to the current behaviour if 4.2 not detected or specified.In addition the type as well as PersistentOffsetTimeAsTimestamp should accept the javax.persistence.TemporalIncludeTimeZone annotation in addition to the existing parameters
12. PersistentPeriodAsString to be supplemented with PersistentPeriod () mapped to PERIOD, PersistentPeriodAsDuration () mapped to DURATION, PersistentPeriodAsDecimal (fields storing the seconds before the decimal point and the nanoseconds after the decimal point) and PersistentPeriodAsInteger (stores the seconds)
13. PersistentYear should be renamed to PersistentYearAsInteger and a new PersistentYear to YEAR type (_) and PersistentYearAsString introduced.
14. PersistentZonedDateTime to be updated to use setObject by default, falling back to the current behaviour if 4.2 not detected or specified. In addition the type should accept the @javax.persistence.TemporalIncludeTimeZone annotation in addition to the existing parameters
15. PersistentZoneId (_) to be added, mapping to TIMEZONE
16. PersistentZoneOffset (*) to be added, mapping to OFFSET

NB Some more thought about the offset types in 4.2 is needed. Probably multi column types with zone / zone offset are also needed.

from jadira.

Created https://jadira.atlassian.net/browse/JDF-80 for tracking

from jadira.

So, I've done all the preparatory work (renaming etc) that doesn't depend on JDBC 4.2, but then the problem - there is no JDBC 4.2 driver (other than maybe Derby) that could be used to test the setObject functionality to implement the remainder of this. I think it will be some time before those types that use setObject can be added.

from jadira.

Thanks for the info. However, I'm not sure this will solve my issue since Java 8 doesn't include an equivalent to Joda's Interval type. Or am I misunderstanding?

from jadira.

Yes, I think I misunderstood what you were suggesting - however I am glad I did the groundwork for 310 types....

Now I understand what you are asking, for each type you would want to map directly you would need to create a Java type descriptor (like JdbcDateTypeDescriptor) and a corresponding type (like DstSafeDateType).

I wonder if there is an alternative way to do what you are trying to do. For the Single column types this is addressed by having them implement EnhancedUserType and provide an objectToSQLString() method.

from jadira.

Did you manage to get the source building? I have prototyped out the approach and it looks like it should work - if you can build the source I will check in the changes for you to try out. Otherwise I can send you a jar to test. Actually it would help me if you can share any tests for the query on components that you are able for inclusion.

Once we are happy with the approach, there is going to be a need to do some refactoring after - a large number of the other component types could benefit from this change and there will be an opportunity to further rationalise the code subsequently.

from jadira.

I did manage to get it building (I ended up commenting out the modules required Java 5 or Java 8 installed). If you check in your changes, I should be able to try them out.

from jadira.

I've just pushed a prototype change for the PersistentInterval

from jadira.

Sorry about the delay in getting back to you. I was able to get the experimental changes to build. However, I realized that that the functionality I was looking for is already in the latest released version. I had accidentally grabbed the 2.0 version of the project and thought I the latest version (due to the change in artifact names in 3.0). It appears that 3.0 lets me query for Interval types using LocalDateTime and 3.1+ lets me query using DateTime.

You may want to put a note somewhere on the Sourceforge page about what artifact ID to use for the appropriate artifacts.

Sorry about the wild goose chase. Thanks for all of your help.

from jadira.