-
Notifications
You must be signed in to change notification settings - Fork 13
Inconsistent timestamps behaviour when hard setting the :at/:on values #4
Comments
I would think that this is a bug, I added a standalone to reproduce the behavior at: http://github.com/snusnu/dm-snippets/commit/e134b6d9c1ad45e3bf80dd417783a27d4cb49c0c by Martin Gamsjaeger (snusnu) |
If you set these fields on your own, then why do you use dm-timestamps? One of the reasons why one would want to use this plugin is to not care about setting these fields manually. I’m not entirely sure if this is a valid bug. by Piotr Solnica (solnic) |
I’m not entirely sure either but it seems a bit weird that stuff behaves differently for created_at(on) and updates_at(on) by Martin Gamsjaeger (snusnu) |
Well for me, I need it in testing. :) by Fred Wu |
I would accept a patch (with specs) to dm-timestamps that makes it so those values are not set if While I think this is a bit of an edge case, in other parts of DM we’ve made it so that user-supplied data takes precedence over defaults set by the system, so I think it fits in with the approach we’ve taken elsewhere. by Dan Kubb (dkubb) |
I’d like to help because this is blocking me from writing tests for my own project. A little direction? I’m new to working with git & plugins. Bear with me on what’s probably a 101 question, and feel free to point me to resources on contributing I’m pretty sure I have this fixed (with specs), but can’t get spec to work:
I’ve tried cloning the dm-core project, but those files do not exist. FWIW, here’s what I have so far:
by orbiteleven |
Er, scratch that last diff for this one :)
diff --git a/spec/spec_helper.rb b/spec/spec_helper.rb
|
Hey orbiteleven, To get up and running just clone dm-timestamps and do: cd dm-timestamps
export ADAPTER=sqlite
bundle install
bundle exec spec spec/integration This needs bundler to be installed, if you don’t have just do gem i bundler. Regarding your patch - you need to check if attribute_dirty?(:updated_at/:updated_on) returns true and only if it does you don’t set the values. Thanks for you help :) by Piotr Solnica (solnic) |
Much better, thanks for the help. I’ve attached my patch for this ticket. I hope it helps! If not, constructive criticism welcome. by orbiteleven |
I'm seeing this issue to. I have created_at and updated_at properties. updated_at sets properly but in order to get created_at to work I have to declare timestamps :created_at, :updated_at in the model. |
So in a model we have
timestamps :at
.It creates
created_at
andupdated_at
, that's fine.However, upon creating a new record, if I hard set both values,
created_at
respects my provided value, butupdated_at
does not. I can only assume the :on pair behaves the same too.Is this a feature or a bug?
Created by Fred Wu - 2010-04-16 05:30:23 UTC
Original Lighthouse ticket: http://datamapper.lighthouseapp.com/projects/20609/tickets/1245
The text was updated successfully, but these errors were encountered: