Time in dm-timestamps

[Ashley Moran]

Hi all

In all my current projects that use dm-timestamps, I run into an issue
with the use of DateTime. Because, when using the DataObjects
adapter, it saves to a precision of one second, writing specs is very
hard. To prove that one object is saved after another, you have to
introduce a delay of >= 1s to be sure of the order.

However, Time saves to a precision of microseconds. Because of this,
I have the following section in all my Merb init.rb files:

DataMapper::Timestamp::TIMESTAMP_PROPERTIES = {
:updated_at => [ Time, lambda { |r, p| Time.now } ],
:updated_on => [ Date, lambda { |r, p| Date.today } ],
:created_at => [ Time, lambda { |r, p| r.created_at || (Time.now
if r.new_record?) } ],
:created_on => [ Date, lambda { |r, p| r.created_on ||
(Date.today if r.new_record?) } ],
}.freeze

I just wondered, is there any reason why dm-timestamps can't use Time
instead of DateTime by default? It would increase the precision of
the timestamp data, but there may be issues I'm unaware of.

Thanks for any input

Ashley

--
http://www.patchspace.co.uk/
http://www.linkedin.com/in/ashleymoran
http://aviewfromafar.net/
http://twitter.com/ashleymoran

[Dan Kubb (dkubb)]

Hi Ashley,

> Because, when using the DataObjects
> adapter, it saves to a precision of one second, writing specs is very
> hard. To prove that one object is saved after another, you have to
> introduce a delay of >= 1s to be sure of the order.

Couldn't something like this work:

now = DateTime.now
DateTime.stub!(:now).and_return(now)
resource1.save

DateTime.stub!(:now).and_return(now + 1)
resource2.save

Then you could see if resource2 was created after resource1 or not
without introducing any delay into the specs. I'm not normally a big
fan of mocks/stubs, but I think to work around time relative issues
like this it's a reasonable approach.

> I just wondered, is there any reason why dm-timestamps can't use Time  
> instead of DateTime by default?  It would increase the precision of  
> the timestamp data, but there may be issues I'm unaware of.

None that I can think of. If you create ticket for this, and submit a
patch I will make sure it gets in before the next RC (which at the
earlier will be tomorrow night, and the latest Sunday night).

Dan
(dkubb)

[sickill]

Hi Dan,

> None that I can think of.  If you create ticket for this, and submit a
> patch I will make sure it gets in before the next RC (which at the
> earlier will be tomorrow night, and the latest Sunday night).

As I remember there was a talk about date/time properties and their
precisions some time ago (could be a year ago).
I remember that someone had following argument against more precision:
if you set updated_at to 2009/06/26 12:25:00.123456 and DB will store
milliseconds as .1234 (because that's its precision) this would mean
that we have different data in DB and in model. Probably this could
make tracking dirty attributes more tricky. But I think we can come up
with some solution to this, ie cast time to the precision which DB
uses upon attribute assignment. What do you think? Does property have
access to such information like underlying datetime/timestamp/whatever
column's precision?

[Dan Kubb (dkubb)]

Hi sickill,

> As I remember there was a talk about date/time properties and their
> precisions some time ago (could be a year ago).
> I remember that someone had following argument against more precision:
> if you set updated_at to 2009/06/26 12:25:00.123456 and DB will store
> milliseconds as .1234 (because that's its precision) this would mean
> that we have different data in DB and in model. Probably this could
> make tracking dirty attributes more tricky.

Ahh, yeah, I remember this now, and I think it was about a year ago.

The problem was that people were writing specs that persisted a
resource, then they fetched it back, but it wouldn't match the
original because of differences in time precision. Time#== and
Time#eql? will only return true if every part of the Time objects are
equal, even milliseconds, which is totally what you'd expect.

I don't remember if this prompted any changes on our part in DM or DO,
or if it was the reason for selecting DateTime instead of Time in dm-
timestamps though.

> But I think we can come up with some solution to this, ie cast time to the
> precision which DB uses upon attribute assignment. What do you think?

Truncating the time upon attribute assignment should be possible,
although I don't know if it's a good idea yet. It seems a big too
magical to me, but I'd like to hear other people's opinion on this.

Even if we did decide to do it, I'd wait until the
DataMapper::Property class is refactored (it's going to be split up
into a single base class, and the logic for each primitive separated
into subclasses). Once this is done it will be much simpler to add
Time specific casting logic to DateTime::Property::Time for example.

> Does property have access to such information like underlying
> datetime/timestamp/whatever column's precision?

Currently there is nowhere to get this information from, although it
wouldn't be too difficult to add.

Dan
(dkubb)

[Ashley Moran]

On 26 Jun 2009, at 21:52, Dan Kubb (dkubb) wrote:

> Even if we did decide to do it, I'd wait until the
> DataMapper::Property class is refactored (it's going to be split up
> into a single base class, and the logic for each primitive separated
> into subclasses). Once this is done it will be much simpler to add
> Time specific casting logic to DateTime::Property::Time for example.

Should I raise a ticket in the mean time to reference this thread, or
hold fire until the related issues are resolved?

Thanks

[Dan Kubb (dkubb)]

Hi Ashley,

On Jun 29, 1:22 pm, Ashley Moran <ashley.mo...@patchspace.co.uk>
wrote:

> > Once this is done it will be much simpler to add
> > Time specific casting logic to DateTime::Property::Time for example.
>
> Should I raise a ticket in the mean time to reference this thread, or  
> hold fire until the related issues are resolved?

When in doubt raise a ticket ;)

I think in this case it would be totally appropriate to create a
ticket to remind us to revisit it on the mailing list once
DM::Property is refactored better.

--

Dan
(dkubb)

[Ashley Moran]

On 29 Jun 2009, at 21:34, Dan Kubb (dkubb) wrote:

> When in doubt raise a ticket ;)

I hope you realise how much ticked harassment you've now exposed
yourself to from me =)

> I think in this case it would be totally appropriate to create a
> ticket to remind us to revisit it on the mailing list once
> DM::Property is refactored better.

I will do exactly this!

Cheers

[Ashley Moran]

On 29 Jun 2009, at 21:34, Dan Kubb (dkubb) wrote:

> I think in this case it would be totally appropriate to create a
> ticket to remind us to revisit it on the mailing list once
> DM::Property is refactored better.

Done =)

http://datamapper.lighthouseapp.com/projects/20609-datamapper/tickets/932-dm-timestamps-should-serialise-datetime-to-higher-accuracyuse-time