Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

No Hibernate type for Interval that lets you query with DateTime #12

Closed
asdcdow opened this issue Apr 2, 2014 · 12 comments
Closed

No Hibernate type for Interval that lets you query with DateTime #12

asdcdow opened this issue Apr 2, 2014 · 12 comments

Comments

@asdcdow
Copy link

asdcdow commented Apr 2, 2014

The existing PersistentInterval type requires that you create Hibernate queries using java.util.Date. It would be nice if we could query using DataTime instead.

I was going to create a pull request for this but had issues getting master to build.

@chrisphe
Copy link
Member

chrisphe commented Apr 2, 2014

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

@asdcdow
Copy link
Author

asdcdow commented Apr 3, 2014

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?

@chrisphe
Copy link
Member

chrisphe commented Apr 3, 2014

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.

@chrisphe
Copy link
Member

chrisphe commented Apr 3, 2014

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.

@chrisphe
Copy link
Member

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

@chrisphe
Copy link
Member

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.

@asdcdow
Copy link
Author

asdcdow commented Apr 22, 2014

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?

@chrisphe
Copy link
Member

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.

@chrisphe
Copy link
Member

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.

@asdcdow
Copy link
Author

asdcdow commented Apr 23, 2014

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.

@chrisphe
Copy link
Member

I've just pushed a prototype change for the PersistentInterval

@asdcdow
Copy link
Author

asdcdow commented Apr 28, 2014

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.

@asdcdow asdcdow closed this as completed Apr 28, 2014
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants