Re: [threeten-develop] Requesting advice regarding database persistence

SourceForge Headquarters 225 Broadway Suite 1600 San Diego, CA 92101 +1 (858) 454-5900

Storing as a string is reliable, but not ideal for any operation other
than storing/reading. If you can change Datomic why not edit the core
to have dedicated types that match JSR-310 based on ints? ie. research
how dates are stored in other DBs like Postgres.
Stephen

On 9 December 2013 22:21, Rafael de F. Ferreira
<pu...@ra...> wrote:
> Thanks for your replies.
>
> I'm using the Datomic database from Clojure. It is quite far from
> tradicional RDBMS, so JDBC can't help. I'm on threeten backport.
>
> Currently we are mapping to and from java.util.Dates, but I'm afraid to be
> bitten by j.u.Date's bugs and overall strangeness. We already saw a bug in
> our codebase when mapping from Dates to YearMonths; the call to
> Date.getMonth would return different values depending on which TZ the
> machine was running. We fixed this one by not calling anything on Date and
> converting from j.u.Date -> threeten.LocalDate -> threeten.YearMonth; but
> I'm afraid of what else might be lurking.
>
> If we always start with a LocalDate, then subsequently convert it to and
> from j.u.Dates, is it guaranteed that we will always get the same LocalDate
> we started with? Can TZs or DST affect the conversion?
>
> Has anyone ever did the "packing-into-a-long" option?
>
>
> --
> Rafael de F. Ferreira.
> http://www.rafaelferreira.net/
>
>
> On Mon, Dec 9, 2013 at 4:09 PM, jo...@gm... <jo...@gm...> wrote:
>>
>> If you happen to be using JPA, I came across this open Jira item for
>> JPA/threeten support:
>> https://java.net/jira/browse/JPA_SPEC-63
>>
>> I'm using threetenbp in a small JPA project right now and simply
>> converting to java.sql.Date/Timestamp for persistence purposes (not for any
>> business logic).  It's fairly cumbersome since, as far as I know, JPA
>> doesn't seem to support User Types like pure Hibernate so I have to use
>> method level annotations and include some JPA baggage like this:
>>
>>     @Column(name = "some_date")
>>     protected Date getJpaSomeDate() {
>>         return localDateToJpaDate(someDate);
>>     }
>>
>>     protected void setJpaSomeDate(Date someDate) {
>>         this.someDate = localDateFromJpaDate(someDate);
>>     }
>>
>>     @Transient
>>     public LocalDate getSomeDate() {
>>         return someDate;
>>     }
>>
>>
>>
>> On Mon, Dec 9, 2013 at 12:16 PM, Douglas Surber
>> <dou...@or...> wrote:
>>>
>>> The JDK 8 version of JDBC includes support for most of the SQL types
>>> that correspond to 310 classes.
>>>
>>> DATE - LocalDate
>>> TIME - LocalTime
>>> TIMESTAMP WITH OUT TIME ZONE - LocalDateTime
>>> TIMESTAMP WITH TIME ZONE - OffsetDateTime
>>>
>>> JDK 8 version of JDBC does not include a mapping between the INTERVAL
>>> types and the corresponding 310 classes.
>>>
>>> There is no SQL type that exactly corresponds to any other 310
>>> classes. As a result, the JDBC spec is silent for all other classes.
>>>
>>> I would strongly encourage JDBC developers to use the new 310
>>> classes. There are problems with java.util.Date, java.sql.Date,
>>> java.sql.Time, and java.sql.Timestamp. You should consider them
>>> deprecated. The 310 classes are vastly superior.
>>>
>>> Douglas
>>>
>>>
>>>
>>> At 08:57 AM 12/9/2013, Rafael de F. Ferreira wrote:
>>>
>>> >Are there guidelines established for persisting threeten classes to
>>> >databases? For the purposes of this question we can separate date
>>> >and time classes in three categories:
>>> >    * Timestamps: only the Instant class, representing a point in a
>>> > timeline
>>> >    * Unanchored: recurring time specifications such as MonthDay and
>>> > LocalTime
>>> >    * Achored: represent some extent of time in a human timeline.
>>> > They are tuples of date and time fields with varied degrees of
>>> > resolution. Eg: LocalDate, LocalDateTime and YearMonth.
>>> >
>>> >I'm supposing a database with support for storing the usual
>>> >primitives and timestamps. The latter are represented as
>>> >java.util.Dates in the API.
>>> >
>>> >For Instants seems a no brainer to map from and to j.u.Date s.
>>> >
>>> >So far I haven't needed to map Unanchored classes, so I haven't put
>>> >much thought.
>>> >
>>> >For Anchored classes, I can see several approaches:
>>> >    * Store them as Strings
>>> >        * Pro: Simple bidirectional conversion
>>> >        * Con: No way to do comparative queries
>>> > (before/after/between)
>>> >        * Con: No reasonable way to query for parts of an instance
>>> > (i.e. all local dates with year 1970)
>>> >    * Store each temporal field as a separate db attribute/column
>>> >        * Pro: Easy to query for parts of an instance
>>> >        * Con: Hard to write comparative queries, each query needs
>>> > to enforce lexicographical tuple ordering.
>>> >        * Con: Polluted db schema
>>> >        * Neutral: Possible to write comparative queries among
>>> > different resolution anchored classes (get all LocalDates between
>>> > two YearMonths, for instance)
>>> >        * Neutral: Relatively simple bidirectional conversion
>>> >    * Transform the Anchored class to a j.u.Date
>>> >        * Pro: Easy to convert using 310 methods
>>> >        * Pro: Easy to write comparative queries
>>> >        * Pro: Possible to write comparative queries among different
>>> > resolution anchored classes
>>> >        * Con: Exposure to conversion bugs, not getting back what is
>>> > put in (we encontered this with a naive j.u.Date->YearMonth
>>> > conversion)
>>> >        * Con: requires understanding the flawed j.u.Date APIs:
>>> > interaction with TZ, DST, etc. The lack of which risks incurring
>>> > hard-to-diagnose bugs
>>> >        * Neutral: Relatively easy to write queries for parts of an
>>> > instance (as comparative queries)
>>> >    * Map the temporal fields to portions of a Long
>>> >        * Pro: Once conversions are done, easy to write comparative
>>> > queries
>>> >        * Pro: Easy to write queries for parts of an instance
>>> >        * Pro: Easy to write comparatice queries among different
>>> > resolution anchored classes
>>> >        * Con: Non-trivial conversion code
>>> >        * Con: Hard to interpret stored data without running
>>> > conversion code.
>>> >
>>> >
>>> >Now with the questions :)
>>> >
>>> >Has anyone else explored this space? Am I missing something in this
>>> >characterization? What option are you guys usually leaning towards?
>>> >
>>> >Thanks and sorry for the explosion of bullet points.
>>> >--
>>> >Rafael de F. Ferreira.
>>> ><http://www.rafaelferreira.net/>http://www.rafaelferreira.net/
>>> >
>>>
>>> > >------------------------------------------------------------------------------
>>> >Sponsored by Intel(R) XDK
>>> >Develop, test and display web and hybrid apps with a single code
>>> >base.
>>> >Download it for free now!
>>>
>>> > >http://pubads.g.doubleclick.net/gampad/clk?id=111408631&iu=/4140/ostg.clktrk
>>> >
>>> >_______________________________________________
>>> >threeten-develop mailing list
>>> >thr...@li...
>>> >https://lists.sourceforge.net/lists/listinfo/threeten-develop
>>>
>>>
>>>
>>> ------------------------------------------------------------------------------
>>> Sponsored by Intel(R) XDK
>>> Develop, test and display web and hybrid apps with a single code base.
>>> Download it for free now!
>>>
>>> http://pubads.g.doubleclick.net/gampad/clk?id=111408631&iu=/4140/ostg.clktrk
>>> _______________________________________________
>>> threeten-develop mailing list
>>> thr...@li...
>>> https://lists.sourceforge.net/lists/listinfo/threeten-develop
>>
>>
>>
>>
>> ------------------------------------------------------------------------------
>> Sponsored by Intel(R) XDK
>> Develop, test and display web and hybrid apps with a single code base.
>> Download it for free now!
>>
>> http://pubads.g.doubleclick.net/gampad/clk?id=111408631&iu=/4140/ostg.clktrk
>> _______________________________________________
>> threeten-develop mailing list
>> thr...@li...
>> https://lists.sourceforge.net/lists/listinfo/threeten-develop
>>
>
>
> ------------------------------------------------------------------------------
> Sponsored by Intel(R) XDK
> Develop, test and display web and hybrid apps with a single code base.
> Download it for free now!
> http://pubads.g.doubleclick.net/gampad/clk?id=111408631&iu=/4140/ostg.clktrk
> _______________________________________________
> threeten-develop mailing list
> thr...@li...
> https://lists.sourceforge.net/lists/listinfo/threeten-develop
>