You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@openjpa.apache.org by Mark Struberg <st...@yahoo.de.INVALID> on 2019/01/21 14:53:10 UTC
java8 time API support
hi folks!
Over the last few days I started to implement the Java8 time types which are required by the JPA-2.2 spec.
* LocalDate* LocalTime* LocalDateTime* OffsetTime* OffsetDateTime
The first 3 are pretty much finished. Will work on the later 2 today.I first started to implement LocalDate as ValueHandler. But some databases (postgres, etc) do have native support for those types. So I figured it might be better to add support for it directly in the DBDictionary. This also improves performance.
Wdyt?Any input or ideas how to make it better?
LieGrue,strub
Re: java8 time API support
Posted by Romain Manni-Bucau <rm...@gmail.com>.
Le mer. 23 janv. 2019 à 10:29, Mark Struberg <st...@yahoo.de.invalid> a
écrit :
> Txs Romain!
>
> Found a bit more info.
>
> There is a new Type in Java8 java.sql.Types.TIME_WITH_TIMEZONE even.
>
> Seems like a few databases do support timezones in the date, others don't
>
> Oracle: TIMESTAMP WITH TIME ZONE -> stores the tst + the timezone in the
> DB in a bijective way
> PostgreSQL: TIME WITH TIME ZONE -> always only stores in UTC. No way to
> regain access to the original TZ information.
> h2: RECORD_UTC. Stores the UTC, same as with PostgreSQL
>
This is supposed to be in SQL spec but my experience with it is close to
yours: sometimes it works, depends the DB :(
>
> Btw, even for those databases which support timezones it's actually NOT an
> offset. Because the offset might change if daylight saving
> So I wonoder if there is any way to get it 100% right.
>
> The question is whether OffsetDateTime is actually more like an Instant
> then? Because we will loose the TZ.
>
My understanding is that we don't need to get the same model in a
write/read roundtrip but the same instant as well
>
>
> Btw, I would also like to support java.time.Instant. Wdyt?
>
yes and Zoned flavors
>
> It is _not_ required by the JPA-2.2 spec, but afaict this is silly. It
> should have been.
>
+1, my understanding of the "not support" is jdbc restriction in types but
I can be wrong here
> Do we also want to add this to our DBDictionary and support it out of the
> box?
>
If there is a native db type yes, if not let's just bridge to a native type
internally?
>
> LieGrue,
> strub
>
>
>
> > Am 23.01.2019 um 08:45 schrieb Romain Manni-Bucau <rmannibucau@gmail.com
> >:
> >
> > pg has "with time zone" option like "time with time zone"
> > now I wonder if the dictionnary shouldn't get the config of the default
> > timezone and if we dont have a type with tz then we convert in the
> default
> > timezone
> > so if i want to store a CEST time and default is UTC then the next select
> > will get it in UTC but since it is an OffsetXXX it will be "right".
> >
> > wdyt?
> >
> > Romain Manni-Bucau
> > @rmannibucau <https://twitter.com/rmannibucau> | Blog
> > <https://rmannibucau.metawerx.net/> | Old Blog
> > <http://rmannibucau.wordpress.com> | Github <
> https://github.com/rmannibucau> |
> > LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book
> > <
> https://www.packtpub.com/application-development/java-ee-8-high-performance
> >
> >
> >
> > Le mer. 23 janv. 2019 à 08:38, Mark Struberg <st...@yahoo.de.invalid>
> a
> > écrit :
> >
> >> The OpenJPA internal 'infrastructure' is now ready.
> >>
> >> The problem arises about how to store OffsetTime and OffsetDateTime in
> the
> >> DB though.
> >>
> >> My first implementation now converts it to the default TZ and uses
> >> java.sql.Date to store it.
> >> This results in the correct time being stored to the db, but of course,
> >> the offset is gone.
> >>
> >> Does someone has any ideas/links/knowledge about it?
> >> Mainly want to target derby/Oracle/PostgreSQL/MySQL/MariaDB/DB2 in the
> >> first round.
> >>
> >> LieGrue,
> >> strub
> >>
> >>
> >>> Am 22.01.2019 um 03:42 schrieb Maxim Solodovnik <solomax666@gmail.com
> >:
> >>>
> >>> Thanks for that, will try to test LocalDate support in our project
> later
> >>> this week :)
> >>>
> >>> On Tue, 22 Jan 2019 at 00:00, Francesco Chicchiriccò <
> >> ilgrosso@apache.org>
> >>> wrote:
> >>>
> >>>> On 21/01/19 16:07, Romain Manni-Bucau wrote:
> >>>>> +1000 to make it part of the dictionary, makes way more sense IMHO
> >>>>
> >>>> +1001 then, I also think it's better :-)
> >>>>
> >>>> Thanks Mark!
> >>>> Regards.
> >>>>
> >>>>> Le lun. 21 janv. 2019 à 15:53, Mark Struberg
> <struberg@yahoo.de.invalid
> >>>
> >>>> a
> >>>>> écrit :
> >>>>>
> >>>>>> hi folks!
> >>>>>> Over the last few days I started to implement the Java8 time types
> >> which
> >>>>>> are required by the JPA-2.2 spec.
> >>>>>> * LocalDate* LocalTime* LocalDateTime* OffsetTime* OffsetDateTime
> >>>>>> The first 3 are pretty much finished. Will work on the later 2
> today.I
> >>>>>> first started to implement LocalDate as ValueHandler. But some
> >> databases
> >>>>>> (postgres, etc) do have native support for those types. So I figured
> >> it
> >>>>>> might be better to add support for it directly in the DBDictionary.
> >> This
> >>>>>> also improves performance.
> >>>>>> Wdyt?Any input or ideas how to make it better?
> >>>>>>
> >>>>>> LieGrue,strub
> >>>>
> >>>> --
> >>>> Francesco Chicchiriccò
> >>>>
> >>>> Tirasa - Open Source Excellence
> >>>> http://www.tirasa.net/
> >>>>
> >>>> Member at The Apache Software Foundation
> >>>> Syncope, Cocoon, Olingo, CXF, OpenJPA, PonyMail
> >>>> http://home.apache.org/~ilgrosso/
> >>>>
> >>>>
> >>>
> >>> --
> >>> WBR
> >>> Maxim aka solomax
> >>
> >>
>
>
Re: java8 time API support
Posted by Mark Struberg <st...@yahoo.de.INVALID>.
Txs Romain!
Found a bit more info.
There is a new Type in Java8 java.sql.Types.TIME_WITH_TIMEZONE even.
Seems like a few databases do support timezones in the date, others don't
Oracle: TIMESTAMP WITH TIME ZONE -> stores the tst + the timezone in the DB in a bijective way
PostgreSQL: TIME WITH TIME ZONE -> always only stores in UTC. No way to regain access to the original TZ information.
h2: RECORD_UTC. Stores the UTC, same as with PostgreSQL
Btw, even for those databases which support timezones it's actually NOT an offset. Because the offset might change if daylight saving
So I wonoder if there is any way to get it 100% right.
The question is whether OffsetDateTime is actually more like an Instant then? Because we will loose the TZ.
Btw, I would also like to support java.time.Instant. Wdyt?
It is _not_ required by the JPA-2.2 spec, but afaict this is silly. It should have been.
Do we also want to add this to our DBDictionary and support it out of the box?
LieGrue,
strub
> Am 23.01.2019 um 08:45 schrieb Romain Manni-Bucau <rm...@gmail.com>:
>
> pg has "with time zone" option like "time with time zone"
> now I wonder if the dictionnary shouldn't get the config of the default
> timezone and if we dont have a type with tz then we convert in the default
> timezone
> so if i want to store a CEST time and default is UTC then the next select
> will get it in UTC but since it is an OffsetXXX it will be "right".
>
> wdyt?
>
> Romain Manni-Bucau
> @rmannibucau <https://twitter.com/rmannibucau> | Blog
> <https://rmannibucau.metawerx.net/> | Old Blog
> <http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> |
> LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book
> <https://www.packtpub.com/application-development/java-ee-8-high-performance>
>
>
> Le mer. 23 janv. 2019 à 08:38, Mark Struberg <st...@yahoo.de.invalid> a
> écrit :
>
>> The OpenJPA internal 'infrastructure' is now ready.
>>
>> The problem arises about how to store OffsetTime and OffsetDateTime in the
>> DB though.
>>
>> My first implementation now converts it to the default TZ and uses
>> java.sql.Date to store it.
>> This results in the correct time being stored to the db, but of course,
>> the offset is gone.
>>
>> Does someone has any ideas/links/knowledge about it?
>> Mainly want to target derby/Oracle/PostgreSQL/MySQL/MariaDB/DB2 in the
>> first round.
>>
>> LieGrue,
>> strub
>>
>>
>>> Am 22.01.2019 um 03:42 schrieb Maxim Solodovnik <so...@gmail.com>:
>>>
>>> Thanks for that, will try to test LocalDate support in our project later
>>> this week :)
>>>
>>> On Tue, 22 Jan 2019 at 00:00, Francesco Chicchiriccò <
>> ilgrosso@apache.org>
>>> wrote:
>>>
>>>> On 21/01/19 16:07, Romain Manni-Bucau wrote:
>>>>> +1000 to make it part of the dictionary, makes way more sense IMHO
>>>>
>>>> +1001 then, I also think it's better :-)
>>>>
>>>> Thanks Mark!
>>>> Regards.
>>>>
>>>>> Le lun. 21 janv. 2019 à 15:53, Mark Struberg <struberg@yahoo.de.invalid
>>>
>>>> a
>>>>> écrit :
>>>>>
>>>>>> hi folks!
>>>>>> Over the last few days I started to implement the Java8 time types
>> which
>>>>>> are required by the JPA-2.2 spec.
>>>>>> * LocalDate* LocalTime* LocalDateTime* OffsetTime* OffsetDateTime
>>>>>> The first 3 are pretty much finished. Will work on the later 2 today.I
>>>>>> first started to implement LocalDate as ValueHandler. But some
>> databases
>>>>>> (postgres, etc) do have native support for those types. So I figured
>> it
>>>>>> might be better to add support for it directly in the DBDictionary.
>> This
>>>>>> also improves performance.
>>>>>> Wdyt?Any input or ideas how to make it better?
>>>>>>
>>>>>> LieGrue,strub
>>>>
>>>> --
>>>> Francesco Chicchiriccò
>>>>
>>>> Tirasa - Open Source Excellence
>>>> http://www.tirasa.net/
>>>>
>>>> Member at The Apache Software Foundation
>>>> Syncope, Cocoon, Olingo, CXF, OpenJPA, PonyMail
>>>> http://home.apache.org/~ilgrosso/
>>>>
>>>>
>>>
>>> --
>>> WBR
>>> Maxim aka solomax
>>
>>
Re: java8 time API support
Posted by Romain Manni-Bucau <rm...@gmail.com>.
pg has "with time zone" option like "time with time zone"
now I wonder if the dictionnary shouldn't get the config of the default
timezone and if we dont have a type with tz then we convert in the default
timezone
so if i want to store a CEST time and default is UTC then the next select
will get it in UTC but since it is an OffsetXXX it will be "right".
wdyt?
Romain Manni-Bucau
@rmannibucau <https://twitter.com/rmannibucau> | Blog
<https://rmannibucau.metawerx.net/> | Old Blog
<http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> |
LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book
<https://www.packtpub.com/application-development/java-ee-8-high-performance>
Le mer. 23 janv. 2019 à 08:38, Mark Struberg <st...@yahoo.de.invalid> a
écrit :
> The OpenJPA internal 'infrastructure' is now ready.
>
> The problem arises about how to store OffsetTime and OffsetDateTime in the
> DB though.
>
> My first implementation now converts it to the default TZ and uses
> java.sql.Date to store it.
> This results in the correct time being stored to the db, but of course,
> the offset is gone.
>
> Does someone has any ideas/links/knowledge about it?
> Mainly want to target derby/Oracle/PostgreSQL/MySQL/MariaDB/DB2 in the
> first round.
>
> LieGrue,
> strub
>
>
> > Am 22.01.2019 um 03:42 schrieb Maxim Solodovnik <so...@gmail.com>:
> >
> > Thanks for that, will try to test LocalDate support in our project later
> > this week :)
> >
> > On Tue, 22 Jan 2019 at 00:00, Francesco Chicchiriccò <
> ilgrosso@apache.org>
> > wrote:
> >
> >> On 21/01/19 16:07, Romain Manni-Bucau wrote:
> >>> +1000 to make it part of the dictionary, makes way more sense IMHO
> >>
> >> +1001 then, I also think it's better :-)
> >>
> >> Thanks Mark!
> >> Regards.
> >>
> >>> Le lun. 21 janv. 2019 à 15:53, Mark Struberg <struberg@yahoo.de.invalid
> >
> >> a
> >>> écrit :
> >>>
> >>>> hi folks!
> >>>> Over the last few days I started to implement the Java8 time types
> which
> >>>> are required by the JPA-2.2 spec.
> >>>> * LocalDate* LocalTime* LocalDateTime* OffsetTime* OffsetDateTime
> >>>> The first 3 are pretty much finished. Will work on the later 2 today.I
> >>>> first started to implement LocalDate as ValueHandler. But some
> databases
> >>>> (postgres, etc) do have native support for those types. So I figured
> it
> >>>> might be better to add support for it directly in the DBDictionary.
> This
> >>>> also improves performance.
> >>>> Wdyt?Any input or ideas how to make it better?
> >>>>
> >>>> LieGrue,strub
> >>
> >> --
> >> Francesco Chicchiriccò
> >>
> >> Tirasa - Open Source Excellence
> >> http://www.tirasa.net/
> >>
> >> Member at The Apache Software Foundation
> >> Syncope, Cocoon, Olingo, CXF, OpenJPA, PonyMail
> >> http://home.apache.org/~ilgrosso/
> >>
> >>
> >
> > --
> > WBR
> > Maxim aka solomax
>
>
Re: java8 time API support
Posted by Mark Struberg <st...@yahoo.de.INVALID>.
The OpenJPA internal 'infrastructure' is now ready.
The problem arises about how to store OffsetTime and OffsetDateTime in the DB though.
My first implementation now converts it to the default TZ and uses java.sql.Date to store it.
This results in the correct time being stored to the db, but of course, the offset is gone.
Does someone has any ideas/links/knowledge about it?
Mainly want to target derby/Oracle/PostgreSQL/MySQL/MariaDB/DB2 in the first round.
LieGrue,
strub
> Am 22.01.2019 um 03:42 schrieb Maxim Solodovnik <so...@gmail.com>:
>
> Thanks for that, will try to test LocalDate support in our project later
> this week :)
>
> On Tue, 22 Jan 2019 at 00:00, Francesco Chicchiriccò <il...@apache.org>
> wrote:
>
>> On 21/01/19 16:07, Romain Manni-Bucau wrote:
>>> +1000 to make it part of the dictionary, makes way more sense IMHO
>>
>> +1001 then, I also think it's better :-)
>>
>> Thanks Mark!
>> Regards.
>>
>>> Le lun. 21 janv. 2019 à 15:53, Mark Struberg <st...@yahoo.de.invalid>
>> a
>>> écrit :
>>>
>>>> hi folks!
>>>> Over the last few days I started to implement the Java8 time types which
>>>> are required by the JPA-2.2 spec.
>>>> * LocalDate* LocalTime* LocalDateTime* OffsetTime* OffsetDateTime
>>>> The first 3 are pretty much finished. Will work on the later 2 today.I
>>>> first started to implement LocalDate as ValueHandler. But some databases
>>>> (postgres, etc) do have native support for those types. So I figured it
>>>> might be better to add support for it directly in the DBDictionary. This
>>>> also improves performance.
>>>> Wdyt?Any input or ideas how to make it better?
>>>>
>>>> LieGrue,strub
>>
>> --
>> Francesco Chicchiriccò
>>
>> Tirasa - Open Source Excellence
>> http://www.tirasa.net/
>>
>> Member at The Apache Software Foundation
>> Syncope, Cocoon, Olingo, CXF, OpenJPA, PonyMail
>> http://home.apache.org/~ilgrosso/
>>
>>
>
> --
> WBR
> Maxim aka solomax
Re: java8 time API support
Posted by Maxim Solodovnik <so...@gmail.com>.
Thanks for that, will try to test LocalDate support in our project later
this week :)
On Tue, 22 Jan 2019 at 00:00, Francesco Chicchiriccò <il...@apache.org>
wrote:
> On 21/01/19 16:07, Romain Manni-Bucau wrote:
> > +1000 to make it part of the dictionary, makes way more sense IMHO
>
> +1001 then, I also think it's better :-)
>
> Thanks Mark!
> Regards.
>
> > Le lun. 21 janv. 2019 à 15:53, Mark Struberg <st...@yahoo.de.invalid>
> a
> > écrit :
> >
> >> hi folks!
> >> Over the last few days I started to implement the Java8 time types which
> >> are required by the JPA-2.2 spec.
> >> * LocalDate* LocalTime* LocalDateTime* OffsetTime* OffsetDateTime
> >> The first 3 are pretty much finished. Will work on the later 2 today.I
> >> first started to implement LocalDate as ValueHandler. But some databases
> >> (postgres, etc) do have native support for those types. So I figured it
> >> might be better to add support for it directly in the DBDictionary. This
> >> also improves performance.
> >> Wdyt?Any input or ideas how to make it better?
> >>
> >> LieGrue,strub
>
> --
> Francesco Chicchiriccò
>
> Tirasa - Open Source Excellence
> http://www.tirasa.net/
>
> Member at The Apache Software Foundation
> Syncope, Cocoon, Olingo, CXF, OpenJPA, PonyMail
> http://home.apache.org/~ilgrosso/
>
>
--
WBR
Maxim aka solomax
Re: java8 time API support
Posted by Francesco Chicchiriccò <il...@apache.org>.
On 21/01/19 16:07, Romain Manni-Bucau wrote:
> +1000 to make it part of the dictionary, makes way more sense IMHO
+1001 then, I also think it's better :-)
Thanks Mark!
Regards.
> Le lun. 21 janv. 2019 à 15:53, Mark Struberg <st...@yahoo.de.invalid> a
> écrit :
>
>> hi folks!
>> Over the last few days I started to implement the Java8 time types which
>> are required by the JPA-2.2 spec.
>> * LocalDate* LocalTime* LocalDateTime* OffsetTime* OffsetDateTime
>> The first 3 are pretty much finished. Will work on the later 2 today.I
>> first started to implement LocalDate as ValueHandler. But some databases
>> (postgres, etc) do have native support for those types. So I figured it
>> might be better to add support for it directly in the DBDictionary. This
>> also improves performance.
>> Wdyt?Any input or ideas how to make it better?
>>
>> LieGrue,strub
--
Francesco Chicchiriccò
Tirasa - Open Source Excellence
http://www.tirasa.net/
Member at The Apache Software Foundation
Syncope, Cocoon, Olingo, CXF, OpenJPA, PonyMail
http://home.apache.org/~ilgrosso/
Re: java8 time API support
Posted by Romain Manni-Bucau <rm...@gmail.com>.
+1000 to make it part of the dictionary, makes way more sense IMHO
Romain Manni-Bucau
@rmannibucau <https://twitter.com/rmannibucau> | Blog
<https://rmannibucau.metawerx.net/> | Old Blog
<http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> |
LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book
<https://www.packtpub.com/application-development/java-ee-8-high-performance>
Le lun. 21 janv. 2019 à 15:53, Mark Struberg <st...@yahoo.de.invalid> a
écrit :
> hi folks!
> Over the last few days I started to implement the Java8 time types which
> are required by the JPA-2.2 spec.
> * LocalDate* LocalTime* LocalDateTime* OffsetTime* OffsetDateTime
> The first 3 are pretty much finished. Will work on the later 2 today.I
> first started to implement LocalDate as ValueHandler. But some databases
> (postgres, etc) do have native support for those types. So I figured it
> might be better to add support for it directly in the DBDictionary. This
> also improves performance.
> Wdyt?Any input or ideas how to make it better?
>
> LieGrue,strub
>