这是 MySQL 的正确排序数组:
[
[1330210800000, 1],
[1330297200000, 6],
[1330383600000, 10],
[1330470000000, 2],
[1330556400000, 5],
[1330815600000, 9],
[1331593200000, 2],
[1331852400000, 4],
[1331938800000, 8],
[1332111600000, 8],
[1332198000000, 4],
[1332284400000, 8],
[1332370800000, 3],
[1332630000000, 2]
]
但是对于 PostgreSQL,数组是:
[
[1330588800000, 5],
[1332399600000, 3],
[1330848000000, 9],
[1330416000000, 10],
[1331622000000, 2],
[1330329600000, 6],
[1330502400000, 2],
[1332140400000, 8],
[1332313200000, 8],
[1330243200000, 1],
[1332226800000, 4],
[1331967600000, 8],
[1332658800000, 2],
[1331881200000, 4]
]
postgreSQL 顺序错误,日期不同,点击次数不同:
这是我 Controller 中的查询:
@kliks = Klik.count( :group => "DATE( created_at )" )
.map{|k, v| [(Time.parse(k).to_i * 1000), v] }
最佳答案
您没有在查询中指定任何特定的顺序,因此数据库可以按照它想要的任何顺序自由返回您的结果。显然 MySQL 正在对结果进行排序,作为其 GROUP BY 的副作用,但 PostgreSQL 不一定会这样做。所以你的第一个“错误”只是你的一个错误假设。如果您希望数据库进行排序,那么您需要这样的东西:
Klik.count(:group => 'date(created_at)', :order => :date_created_at)
如果你丢掉 * 1000
并对整数时间戳进行排序:
1330210800, 1, MySQL
1330243200, 1, PostgreSQL
1330297200, 6, MySQL
1330329600, 6, PostgreSQL
1330383600, 10, MySQL
1330416000, 10, PostreSQL
...
您会发现它们实际上排列得非常好,每个 MySQL/PostgreSQL 对中的整数时间戳相差 32400 秒(又名 9 小时)或 28800 秒(又名 8 小时或 9 小时,经过 DST 调整)。据推测,您在一次转化中包含时区(使用 DST),而另一次则保留为 UTC。
关于mysql - PostgreSQL 组序数组完全错误,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/9862452/