Rails' :timestamp
column type lies; it's actually just an alias for :datetime
.
I'm using mysql, and I want to use actual unix-timestamp TIMESTAMP
columns.
a) Is there a nice way to set this, other than just making the column using SQL?
b) Will ActiveRecord cope with it properly (e.g. converting to Time
when necessary, accepting a unix timestamp Integer
as input, etc)? What gotchas should I expect to have to handle, and where?
Why:
Speed. This is for an extremely active table that's aggregating outside data sources that already use unix timestamps. Converting to datetime (or even converting first to a db string, which goes through 2
gsub
s) uses up the majority of its import time. I could otherwise be doing just a dirt cheapInteger#to_s
call.Timezones. I don't want 'em. I want it stored timezone-agnostically; dealing with timezones is a pain and is completely irrelevant to my needs except at the very final stage before individual user display. The data itself has no need to know what timezone it was recorded in.
Size. It's a large table. TIMESTAMP is half the size of DATETIME.
Yes, I would still be doing updated_at
calculations in code, not mysql. That part isn't a bottleneck.
Why your 'why not' is wrong (preëmptively, to show I'm not asking for noobish reasons :-P):
- "But TIMESTAMP auto updates": That's only true by default, and can be easily switched off.
- I'm actually not using Rails, just ActiveRecord.
- Yes, this is based on actual profiling data; I am not early optimizing.
ActiveRecord::ConnectionAdapters::AbstractMysqlAdapter#quote
(inQuoting#quoted_date
[if passingTime
] orMysql2Adapter#quote_string
[if preconvertingto_s(:db)
]) is actually the most CPU-consuming section of my scraper. I want rid of it.