制作的ActiveRecord / Rails的实际使用MySQL的TIMESTAMP列 [英] Making ActiveRecord / Rails use actual mysql TIMESTAMP columns

查看:213
本文介绍了制作的ActiveRecord / Rails的实际使用MySQL的TIMESTAMP列的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

Rails的:时间戳柱式所在;它实际上只是一个别名:日期时间

我使用MySQL和我想用实际的Unix-时间戳 TIMESTAMP 列。

a)是否有一个很好的方式来设置这个,不仅仅是使用SQL使得列之外?

B)的ActiveRecord的配合得当(如转换为时间在必要的时候,接受unix时间戳整数作为输入,等)?我应该期待什么陷阱不得不处理的,在哪里?

原因:

  1. 速度。这是一个非常活跃的表多数民众赞成聚集已经使用UNIX时间戳之外的数据源。转换为日期时间(甚至将第1到一个数据库字符串,经过2 GSUB S)使用了大部分的进口时间。我本来可以做的只是一个便宜整数#to_s 电话。

  2. 时区。我不希望他们。我想它存储的时区,agnostically;处理时区是一种痛苦,是完全不相干的,除了在个人用户显示之前非常最后阶段我的需求。数据本身没有需要知道什么时区也录得

  3. 尺寸。这是一个大桌子。 TIMESTAMP是DATETIME的一半大小。

是的,我仍然会做的updated_at 计算在code,不是MySQL的。这部分是不是瓶颈。

为什么你的'为什么不'是错误的($ P $pëmptively,以示我不要求noobish原因:-P):

  1. 但TIMESTAMP自动更新:这只是默认为真,并可以很容易地关闭。
  2. 在实际上,我没有使用Rails的,只是ActiveRecord的。
  3. 是的,这是基于实际的分析数据;我不是早优化。 的ActiveRecord :: ConnectionAdapters :: AbstractMysqlAdapter#报价(在引用#quoted_date [如果通过时间]或 Mysql2Adapter#quote_string [如果preconverting to_s(:DB)] )其实我刮中最消耗CPU部分。我想摆脱它。
解决方案

这工作(刚刚添加空格字符类型定义,所以:时间戳不覆盖它):

  t.add_column:sometable,:created_at,时间戳
 

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:

  1. 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 gsubs) uses up the majority of its import time. I could otherwise be doing just a dirt cheap Integer#to_s call.

  2. 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.

  3. 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):

  1. "But TIMESTAMP auto updates": That's only true by default, and can be easily switched off.
  2. I'm actually not using Rails, just ActiveRecord.
  3. Yes, this is based on actual profiling data; I am not early optimizing. ActiveRecord::ConnectionAdapters::AbstractMysqlAdapter#quote (in Quoting#quoted_date [if passing Time] or Mysql2Adapter#quote_string [if preconverting to_s(:db)]) is actually the most CPU-consuming section of my scraper. I want rid of it.

解决方案

this works (just added whitespace character to type definition, so :timestamp doesn't override it):

     t.add_column :sometable, :created_at, 'timestamp '

这篇关于制作的ActiveRecord / Rails的实际使用MySQL的TIMESTAMP列的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆