Philip, thanks for responding. Two things: 1. Im not talking about changing t.datetime to timestamp. Right now, even t.timestamp doesn't return timestamp for mysql.
2. Im questioning if Rails can function properly if you chose to use TIMESTAMP over DATETIME *assuming* you are comfortable with the field having a default timestamp value. In your case, you wouldnt be comfortable with that behavior for "published_at", but might be for "created_at". My hypothesis based on the evidence I have is that changing a DATETIME to TIMESTAMP should NOT effect anything in your Rails app assuming you understand that you must have a default value on the timestamp field. Anyone else like to step up to the plate? Aryk Philip Hallstrom wrote: >> 2. TIMESTAMP requires a default value, hence interfering with the >> magic >> timestamp logic from Rails. This is NOT TRUE either. In my tests, >> Rails >> populates the created_at/created_on field the same way as it would for >> DATETIME, since it ignores the default timestamp value assigned to it >> from the TIMESTAMP data type. > > What if I have a "published_at" field? If you force that to be a > TIMESTAMP (since I'm assuming your arguing that a migration with > t.datetime should turn into a MySQL TIMESTAMP) then all of my records > will have some value in published_at when the non-published ones > should have a null value. > > Would that be a reason not to do it? It's late and I haven't thought > it all the way through :) -- Posted via http://www.ruby-forum.com/. --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en -~----------~----~----~----~------~----~------~--~---
