精度が重要なまれな場合に備えて、時間解析をオプトアウトする方法はありますか?
時系列値を格納するために、複合一意キー(user_id, created_at)
timestamptzを使用しています。 ただし、javascriptがcreated_at
フィールドをミリ秒に切り捨てるため、ページを移動できません。そのため、同じミリ秒以内に2つ作成されると、重複が発生します。
-- record --
id: 'c2ed61d5-ffab-4b0e-a957-c184b3f33132',
created_at: '2016-02-02 15:46:17.681601-05'
precise ^
knexクエリの場合:
knex("series").where("created_at", ">", last.created_at).toString()
select * from series
where created_at > '2016-02-02T15:46:17.681-05:00'
truncated ^
タイムスタンプの解析をオプトアウトすることは、私たちが望んでいる機能です。 カスタマイズ可能な「parseTime」関数など。
しかし、あなたの具体的なケースについてはよくわかりません。 コンピュータクロックの粒度には制限があるため、一意のcreated_at
値を要求してもスケーリングされません。
@ aj0strow行がDBから読み取られるときに、 knex
がtimestamp
をJavascript Dateオブジェクトに変換しないようにしたいということですか?
その場合、その解析は少なくともPostgreSQLではpg
ドライバーによって実行されます。 次のようなコードを使用して、型を異なる方法で解析するようにドライバーを設定できます。
var pgTypes = require('pg').types;
// Don't parse dates to js Date() objects
pgTypes.setTypeParser(1082, 'text');
// Don't parse timestamps to js Date() objects
pgTypes.setTypeParser(1184, 'text');
text
パラメーターの代わりに、ドライバーに独自のパーサー関数を与えることもできます。
@ rhys-vdwユーザーと時間で一意なので、問題ありません。
@elhiguありがとう!
それはまさに私が探していたものです。 クエリで::text
にキャストすることも可能ですが、エラーが発生しやすいので、必要に応じて解析をオフにしてnew Date
解析することをお勧めします。 再度、感謝します。
最も参考になるコメント
@ aj0strow行がDBから読み取られるときに、
knex
がtimestamp
をJavascript Dateオブジェクトに変換しないようにしたいということですか?その場合、その解析は少なくともPostgreSQLでは
pg
ドライバーによって実行されます。 次のようなコードを使用して、型を異なる方法で解析するようにドライバーを設定できます。text
パラメーターの代わりに、ドライバーに独自のパーサー関数を与えることもできます。