joda-time support

482 views
Skip to first unread message

Vincent Côté-Roy

unread,
Apr 26, 2011, 12:17:35 PM4/26/11
to squ...@googlegroups.com
Hello,

I was wondering if it was possible to use joda-time with squeryl? It
is so much better than the jdk's date/calendar.

Thanks

Vincent

Wille Faler

unread,
Apr 26, 2011, 12:22:32 PM4/26/11
to squ...@googlegroups.com
..second that, could it potentially be added quite easily with implicit conversion to/from jdk date/calendars?

2011/4/26 Vincent Côté-Roy <vinc...@jucent.com>

Maxime Lévesque

unread,
Apr 26, 2011, 2:37:06 PM4/26/11
to squ...@googlegroups.com

I'm a bit reluctant to add a dependency on JodaTime, though I really agree that the jdk date/calendar sucks,
if the dependency can be only a compile time one, then I'd seriously consider it.

Adding a new kind of field is done like this :

  https://github.com/max-l/Squeryl/commit/b1981f43523ed5ea50a5d09d8b6563345956f859

In theory the dependency on JodaTime should be compile time only, but I would't bet on it.

Implicit convs in your code is an easy solution though, given that dates are small objects it, the GC penalty
shouldn't be too big.

David Whittaker

unread,
Apr 26, 2011, 2:46:41 PM4/26/11
to squ...@googlegroups.com
I wonder if we might not be far from the point where it's best to offer a few optional modules along with core Squeryl.  In this case squeryl-joda.jar could have the joda time dependency, and it might be nice to have modules for some of the more popular databases so we can add functions that don't exist in all supported DBs.  Just a thought.

2011/4/26 Maxime Lévesque <maxime....@gmail.com>

Wille Faler

unread,
Apr 26, 2011, 2:49:49 PM4/26/11
to squ...@googlegroups.com
+1

Rather than bake everything into one cake, have a minimal core, true to purpose, with optional modules, such as Joda-time support, "Oracle special case functions" (someone mentioned MD5 earlier today, which is not necessarily widely supported) etc.

Maxime Lévesque

unread,
Apr 26, 2011, 2:59:43 PM4/26/11
to squ...@googlegroups.com

I've been contemplating for a while some refactorings that would make introducing new field types simple to the point
that adding YourOwnType would only involve adding an "implicit YourOwnTypeHelper" in the scope.

I think it can be done, but I have to make a proof of concept first.

Joonas Javanainen

unread,
Apr 28, 2011, 2:57:13 PM4/28/11
to Squeryl
This sounds very good because we cannot possibly cover all types users
would like to use and runtime dependencies should be kept minimal.
Once implicit custom type support is in place, we could then implement
addon modules just like David and Willie suggested.

Joda Time support is on my todo-list for squeryl so I'm willing to
have a shot at it if the necessary refactorings are done at some
point.
It's also the only thing blocking me from using squeryl in certain
projects. I'd be happy to switch to squeryl from a bit quirkier ORMs
(Eclipselink and Hibernate, I'm looking at you!).

- Joonas

On Apr 26, 9:59 pm, Maxime Lévesque <maxime.leves...@gmail.com> wrote:
> I've been contemplating for a while some refactorings that would make
> introducing new field types simple to the point
> that adding YourOwnType would only involve adding an "implicit
> YourOwnTypeHelper" in the scope.
>
> I think it can be done, but I have to make a proof of concept first.
>
> On Tue, Apr 26, 2011 at 2:49 PM, Wille Faler <wille.fa...@gmail.com> wrote:
> > +1
>
> > Rather than bake everything into one cake, have a minimal core, true to
> > purpose, with optional modules, such as Joda-time support, "Oracle special
> > case functions" (someone mentioned MD5 earlier today, which is not
> > necessarily widely supported) etc.
>
> > On 26 April 2011 19:46, David Whittaker <d...@iradix.com> wrote:
>
> >> I wonder if we might not be far from the point where it's best to offer a
> >> few optional modules along with core Squeryl.  In this case squeryl-joda.jar
> >> could have the joda time dependency, and it might be nice to have modules
> >> for some of the more popular databases so we can add functions that don't
> >> exist in all supported DBs.  Just a thought.
>
> >> 2011/4/26 Maxime Lévesque <maxime.leves...@gmail.com>
>
> >>> I'm a bit reluctant to add a dependency on JodaTime, though I really
> >>> agree that the jdk date/calendar sucks,
> >>> if the dependency can be only a compile time one, then I'd seriously
> >>> consider it.
>
> >>> Adding a new kind of field is done like this :
>
> >>>https://github.com/max-l/Squeryl/commit/b1981f43523ed5ea50a5d09d8b656...
>
> >>> In theory the dependency on JodaTime should be compile time only, but I
> >>> would't bet on it.
>
> >>> Implicit convs in your code is an easy solution though, given that dates
> >>> are small objects it, the GC penalty
> >>> shouldn't be too big.
>
> >>> On Tue, Apr 26, 2011 at 12:22 PM, Wille Faler <wille.fa...@gmail.com>wrote:
>
> >>>> ..second that, could it potentially be added quite easily with implicit
> >>>> conversion to/from jdk date/calendars?
>
> >>>> 2011/4/26 Vincent Côté-Roy <vincen...@jucent.com>

Maxime Lévesque

unread,
Apr 28, 2011, 4:36:24 PM4/28/11
to squ...@googlegroups.com

Then I encourage you to stick with Date and Timestamp and put imlicit convs to and from JodaTime in your code.
I'll know pretty soon if the refactoring is possible. If it can work like I'd like it to work,
you'll just need implement a trait and expose an instance of it as an implicit val.

Joonas Javanainen

unread,
Apr 29, 2011, 7:09:40 AM4/29/11
to Squeryl
Yes, using implicit conversions is a good workaround, but it doesn't
work well for some Joda Time types:

1. TimeZone information
In Joda Time, some types like DateTime include chronology/timezone
information.
The types in java.sql are really just millisecond value wrappers so
implicit conversions will lose the time zone. For example, when using
PostgreSQL and Joda Time, I would expect to have the following
mappings:
Instant <=> timestamp without timezone
DateTime <=> timestamp with timezone

2. Types that cannot be represented with a millisecond value
Using implicits with Period/Interval is very awful. Consider the fact
that you have to model a Period like this:

class SomeDomainEntity(period: String, ...)
implicit def str2period(s: String) = new Period(s)
implicit def period2str(p: Period) = p.toString

Interval is even worse as it's typically mapped as two 64-bit long
columns.

Anyway...I don't want to rush you to do refactoring just for Joda
Time, but thanks in advance if you have time to investigate this at
some point.

- Joonas

On Apr 28, 11:36 pm, Maxime Lévesque <maxime.leves...@gmail.com>
wrote:

aw

unread,
Jun 9, 2011, 3:51:19 AM6/9/11
to Squeryl
I'd like to +1 for joda-time support.
Personally, I am not so offended by the additional dependency as I
consider joda-time an unofficial standard because it addresses so many
issues of Date and Calendar. (I'm very much looking forward to the
JSR-310 "standard" -- if that ever happens... See
http://sourceforge.net/projects/threeten/)

A major issue I have with using Date or Calendar is that these are
mutable, and that can lead to tricky bugs.
Another advantage of Joda-time is that we can make it obvious as to
whether we are storing a Date, Time, or Timestamp. (JPA's
TemporalType seems inferior to just saying LocalDate or
LocalDateTime.)

Matthias Heininger

unread,
Apr 3, 2014, 6:15:46 AM4/3/14
to squ...@googlegroups.com
One more "+" for JodaTime support 

David Whittaker

unread,
Apr 9, 2014, 10:25:03 AM4/9/14
to squ...@googlegroups.com
Now that Squeryl is a Github organization, I think Max would agree that we'd be happy to have a Squeryl "module" like squeryl-jodatime that exists as it's own project.  I'd like to see some community involvement in creating and supporting it though.  If anyone wants to take the initiative on that, now would be a good time to speak up.  If no community members have the time to create & maintain this though, it's unlikely that anyone who has been actively working on Squeryl is going to take it on until we need it for our own projects, regardless of the number of +1s.


On Thu, Apr 3, 2014 at 6:15 AM, Matthias Heininger <muenc...@googlemail.com> wrote:
One more "+" for JodaTime support 

--
You received this message because you are subscribed to the Google Groups "Squeryl" group.
To unsubscribe from this group and stop receiving emails from it, send an email to squeryl+u...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Алексей Лоскутов

unread,
Jul 14, 2014, 7:55:55 AM7/14/14
to squ...@googlegroups.com
I use implicit conversion and CustomTypeMode

class TimeStamp(t: Timestamp) extends TimestampField(t)

implicit def jodaToTimeStamp(dateTime: DateTime): TimeStamp = new TimeStamp(new Timestamp(dateTime.getMillis))

implicit def timeStampToJoda(timeStamp: TimeStamp): DateTime = new DateTime(timeStamp.value.getTime)

вторник, 26 апреля 2011 г., 20:17:35 UTC+4 пользователь vincentcr написал:

Bhashit Parikh

unread,
Sep 11, 2017, 4:16:12 AM9/11/17
to Squeryl
If anyone wants to take the initiative on that

Is that offer still open? I think I'll be able to contribute there. 

David Whittaker

unread,
Sep 17, 2017, 9:54:45 PM9/17/17
to squ...@googlegroups.com
Sure.  You probably don’t need much to get started though.  I think it makes sense to get going in a personal GH repo, and we can move it to the Squeryl org when it’s matured enough.
Reply all
Reply to author
Forward
0 new messages