FlakeId issueshttps://git.pleroma.social/pleroma/elixir-libraries/flake_id/-/issues2020-12-03T04:11:03Zhttps://git.pleroma.social/pleroma/elixir-libraries/flake_id/-/issues/5Using FlakeId in JSON field2020-12-03T04:11:03ZAlex GleasonUsing FlakeId in JSON fieldIn order to do a join on a json field, we can't store the FlakeId strings, we can only store a UUID string. Eg:
```elixir
%Example{
id: "A1oBVcaRQRCOdu9tuy",
data: %{
"user_id" => "00000175-d284-af33-8cdd-4241fb990000"
}
}
```...In order to do a join on a json field, we can't store the FlakeId strings, we can only store a UUID string. Eg:
```elixir
%Example{
id: "A1oBVcaRQRCOdu9tuy",
data: %{
"user_id" => "00000175-d284-af33-8cdd-4241fb990000"
}
}
```
This makes a `join ... on users.id = example.data->>'user_id'::uuid` possible. Wondering if there's a more semantic way to do this.https://git.pleroma.social/pleroma/elixir-libraries/flake_id/-/issues/4Configurable worker ID source2020-04-16T17:49:51ZminibikiniConfigurable worker ID sourceCurrently, it's Random. Normal flakes use the MAC address.
We changed it to a random for safety reason in the Pleroma ecosystem and because breaking this unique safety was okay (we don't run clusters). However, some people do run huge c...Currently, it's Random. Normal flakes use the MAC address.
We changed it to a random for safety reason in the Pleroma ecosystem and because breaking this unique safety was okay (we don't run clusters). However, some people do run huge clusters, care less about leaking some information and need guarantees which they could get with the MAC source.
Probably, the default worker ID source should be `Random`.
*Suggested by @href.*hrefhref@random.shhrefhref@random.shhttps://git.pleroma.social/pleroma/elixir-libraries/flake_id/-/issues/3More robust time backwards detection2020-04-16T17:49:51ZminibikiniMore robust time backwards detectionBy storing a file, right now it won't work if the app is restarted between the time goes backward.
*Suggested by @href.*By storing a file, right now it won't work if the app is restarted between the time goes backward.
*Suggested by @href.*hrefhref@random.shhrefhref@random.shhttps://git.pleroma.social/pleroma/elixir-libraries/flake_id/-/issues/2Have other uniqueness strategies than a Worker2020-04-16T17:49:51ZminibikiniHave other uniqueness strategies than a WorkerIt can do a lot of flakes per second already, but in some cases, it's totally possible to isolate it per-process.
*Suggested by @href.*It can do a lot of flakes per second already, but in some cases, it's totally possible to isolate it per-process.
*Suggested by @href.*hrefhref@random.shhrefhref@random.shhttps://git.pleroma.social/pleroma/elixir-libraries/flake_id/-/issues/1Backdate flakes2020-07-20T12:36:00Zhrefhref@random.shBackdate flakesWe should allow to create flakes that happened in the past.
It's a sensitive operation-- but could really be useful for sorting when you are importing historical data, for example.
The only caveat is that you **SHOULD** be able to pick...We should allow to create flakes that happened in the past.
It's a sensitive operation-- but could really be useful for sorting when you are importing historical data, for example.
The only caveat is that you **SHOULD** be able to pick a _unique_ workerId for that flakes. If you know what you are doing, andthat the given workerid is guaranteed to be unique, you're safe.hrefhref@random.shhrefhref@random.sh