record + mongodb: dealing with timestamps

[harryh]

The Java MongoDB driver (which scamongo is built on top of) has native
support for java.util.Dates.

I want to build a JodaDateTimeField record Field. How should I build
this so my high level code only has to deal with Joda DateTime objects
but they get properly converted to Dates before getting sent to the
java driver.

Some ideas:

1) Modify scamongo to recognize DateTimes and do the conversion
there. But should the mongo driver really have to do that? What if
there are other future types that people want to use with it? It
shouldn't have to be modified anytime someone wants to save a new
type.

2) Just store the DateTimes in the datastore as Strings. This
actually works fine now. But it's pretty gross.

3) Punt on building JodaDateTimeField and just build DateField. But
this makes my application logic more complex.

Not entirely sure how this is supposed to work from the perspective of
record? Where is the translation from complex types (DateTime) to
simple types the datastore can understand (Date) supposed to happen?

-harryh

[Ross Mellgren]

Create a new subclass of DateField that has additional methods for converting to/from DateTime, or create a new field type from scratch that does this. I can't speak to how well scamongo would support that, but that would be my take on how to start.

-Ross

> --
> You received this message because you are subscribed to the Google Groups "Lift" group.
> To post to this group, send email to lif...@googlegroups.com.
> To unsubscribe from this group, send email to liftweb+u...@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/liftweb?hl=en.
>

[harryh]

> Create a new subclass of DateField that has additional methods for converting to/from DateTime, or
> create a new field type from scratch that does this. I can't speak to how well scamongo would support
> that, but that would be my take on how to start.

That would certainly work, though it does clutter up my code some.
And the problem can be further generalized. What if Mongo didn't have
native support for Dates in the driver so we needed to, say, convert
them to ints (seconds since the epoch).

Then I would need to sublcass LongField (DateTimeLongField) in my
application instead yes? It seems like there is a bit of a potential
explosion of field types here that just translate from high order
types the application wants to use, and low level types the datastore
can handle.

It would be nice if record had a clean way of dealing with this sort
of thing. Which isn't to say I know exactly how that would work...

-harryh

[Ross Mellgren]

You could write a trait that gives the conversion and mix it into a normal DateField. You couldn't use value/valueBox or set/setBox, but something else like dateTimeValue / setDateTime.

-Ross

[Timothy Perrett]

It would be nice if Record had a lot of things - its massivly a work in progress for sure. I see Ross (the new record-master, DJ if you will) has already responded.

Ross, whats up with the latest stuff for record? Am I meant to be splitting the connection stuff from mapper whilst you pontificate how to make record work with max's stuff? Im afraid I cant remember good chap!

Cheers, Tim

[Ross Mellgren]

On Mar 29, 2010, at 4:07 PM, Timothy Perrett wrote:
> Ross, whats up with the latest stuff for record? Am I meant to be splitting the connection stuff from mapper whilst you pontificate how to make record work with max's stuff? Im afraid I cant remember good chap!

Once I get home I'll push the lift-json integration changes for lift-record. Then I'm going to work on some examples so Max can get started on the squeryl integration and I'll help him with that. Then I'm going to try and put the Debasish-Active-Record-Pattern-Considered-Harmful thing to rest in one way or another.

If you want to split out connection, that would be rad (and help Max)

-Ross