ちりもつもればミルキーウェイ

好奇心に可処分時間が奪われる

gofrs/uuidに出してたパッチがマージされたよ(そしてあとから気づいた細かいパッチをまた出したよ)

はじめに

だいぶ前パッチ出した記事書きました。
https://convto.hatenablog.com/entry/2022/06/08/011812

具体的な話はそちらに譲るとして、マージされたんでその話と、関連する修正も出したのでその話をしようと思います。

やりたいこともまだあるにはあるんですが、方針の相談がわりと必要そうで、アクティブなメンテナも少なくてやり取りのリードタイムかかりそうだからやるかはわかりません

でマージされたパッチってどれ

これです。リリース済みだからもう使えるよ

github.com

なにやったの

draft-peabody-dispatch-new-uuid-format というドラフトがあり、UUID v6~v8 までが提案されてました。
gofrs/uuidはdraftの初期からv7を試験的に実装しており、draftの最新に実装が追従できてない状態だったので更新したという感じです。

(ちなみに余談ですが同draftは draft-ietf-uuidrev-rfc4122bis としてRFC4122の改定に取り組むことを目指して頑張るようです)

で、元draftのrev3の時点で追従できてないのを発見してパッチ上げた次第です。現在のdraftはrev4まで出てるし今後はdraft-ietf-uuidrev-rfc4122bisとして進むしで、rev3にはなったんですがまだ古めです。

追加で出した細かいパッチってなに?

これです

github.com

元PRのレビューで「ミリ秒単位の時刻取得は UnixMill() つかったほうがいいんじゃん?」と言われてそれもそうだと思って修正したんですが、よくよく考えたら古いGoで動かんやんということでそれを戻そう!というやつですね。

PRにも書いたけど UnixMill() はgo1.17で増えたやつだから、すくなくとも現在サポート中のgo1.19, go1.18では普通に使えて影響ないです。
ただ、古いGoつかっててうまくメンテされてないプロジェクトもあるにはあるだろうし、gofrs/uuidはgoのversionごとにbuild分けたりもしてないので UnixMill() 使わんほうが丸いなぁと思ってパッチ出し直した次第です。

(buildtagでバージョンごとに挙動分けるのもアリはアリなんですが、ほぼ同一の挙動でそこまでしなくてもいいかなーと思いシンプルな対応にしてます。ほげほげid系のプロジェクトは見た感じだいたいそんな雰囲気)

多分やらないけどやりたいとは思っていること

draftみたかぎりrev3から仕様のdiffはそんなに大きくない感じするので、余裕があったら更新してあげたいなーとはおもっている。

あとrev3にはバッチによる単位時間あたりめちゃめちゃ発行するようなユースケースでもsortableな性質を担保するために、通し番号的なのをつかうパターンも仕様としてサポートされてるんですが、いくつかの手段が紹介されてるからどれで実装する?というのを決めねばならないので多分やらない。 アクティブに反応してくれるメンテナがいたらやったかもしれないけど、最初のパッチも3ヶ月くらい経って忘れた頃にレビューしてもらった感じだし、ちょっとやりとりのコスト掛かりそうだからやらんと思う

さいごに

つかってるプロジェクトに多かれ少なかれ貢献できたのはよかったです。 UnixMill() いれちゃったのは(大きい問題ではないとおもうけど)ごめんよ

今後も精進します