回答編集履歴
1
誤解釈修正
test
CHANGED
|
@@ -1,13 +1,33 @@
|
|
|
1
|
+
そもそもですが，pushIDは**全体が時間情報，というわけではありません**．
|
|
2
|
+
|
|
3
|
+
|
|
4
|
+
|
|
1
5
|
[The 2^120 Ways to Ensure Unique Identifiers](https://firebase.googleblog.com/2015/02/the-2120-ways-to-ensure-unique_68.html)
|
|
6
|
+
|
|
7
|
+
> The first 48 bits are a timestamp,（後略）
|
|
8
|
+
|
|
9
|
+
> The timestamp is followed by 72 bits of randomness,（後略）
|
|
10
|
+
|
|
11
|
+
|
|
12
|
+
|
|
13
|
+
すなわち，pushIDは前半が時間情報，**後半がランダム**な文字列だということです．
|
|
14
|
+
|
|
15
|
+
同一ミリ秒に複数クライアントからの書き込みがあったとしても，後半のおかげでまず被りません（逆に言えばサーバ側でのvalidateはしないと思われます）．
|
|
16
|
+
|
|
17
|
+
|
|
18
|
+
|
|
19
|
+
検証していただいた現象については，
|
|
2
20
|
|
|
3
21
|
> (前略) if a client creates multiple push IDs in the same millisecond, we just 'increment' the random bits by one.
|
|
4
22
|
|
|
5
23
|
|
|
6
24
|
|
|
7
|
-
|
|
25
|
+
つまり，**同一端末でミリ秒も同一な場合であったので，ランダム部分のインクリメントが発動した**，というパターンになります（jsのfor文程度で同一ミリ秒を達成できるのかというのはやや疑問ですが）．
|
|
26
|
+
|
|
27
|
+
決して「単一クライアントからの連続書き込み程度では被らないが，**複数クライアントからでは被る可能性がある**」**というわけではありません**（理由は前述の通り）．
|
|
8
28
|
|
|
9
29
|
|
|
10
30
|
|
|
11
|
-
ちなみに今月頭に発表となった[Firestore](https://firebase.googleblog.com/2017/10/introducing-cloud-firestore.html)のほうでは[時間に関係なくIDが生成
|
|
31
|
+
ちなみに今月頭に発表となった[Firestore](https://firebase.googleblog.com/2017/10/introducing-cloud-firestore.html)のほうでは[時間に関係なくIDが生成](https://firebase.google.com/docs/firestore/manage-data/add-data#add_a_document)されます．
|
|
12
32
|
|
|
13
|
-
|
|
33
|
+
このあたりのややこしいことは考えなくて済みますが，時間順に並べたい場合はタイムスタンプを明示的に保持する必要があります．
|