SeverpodのGitHubのIssueでIsakと「文通」した話

「文通」はもちろん冗談です。

てか、死語でしょうか？　
私が子どものころには雑誌の巻末によく
「文通してくれる人募集」みたいなコーナーがあったんですけどねえ笑

私はIsakを「知って」いますが、彼は私を
「変な質問をissueに投げてくるアマチュアっぽくて、英語があまり上手じゃない人」
としか思っていないでしょう。
でも、誠実に対応して、問題を解決してくれたので、
私的にはなかなか楽しかった「文通」の報告です。

記事検索でもGPT4でも解決しないError

Severpodともだいぶ仲良くなったと思っていたある日、変なことが起こっているのに気づいた。
userが登録する歴史事象をデータベース化していくサービスを構築中だが、
そのDatabaseでtableを連結する要となるIDがめちゃくちゃrandomになっているのだ。

いや、randomというのは正しくない。
数字は確実に増加傾向にある。ただしその間隔はめちゃくちゃだ。
最初気づいたときは、3000代だったが、5000代になり、やがて一桁上がった。
まだテスト段階なので、ほんとのIDは二桁だ。
だから見つかった、と言えばそれはそう。
Postico2で見たら、一目で「変！」とわかるから。

問題はもう一つあって、「正しいIDが入ることもある」。
つまり「いつこのErrorが起こるか」を予測したり、再現したりするのが難しかった。
記事検索もGPT4もお手上げだった。

となると、最終兵器はGitHubのissueということになる。

そもそもこのIDを取得する方法も

Serverpod使い始めのころに、issueで聞いたのだった。
そしてその結果、こんなcodeを書いて、これで機能しているように見えていた。
https://zenn.dev/flutteruniv_dev/articles/3717146d96baee

が、このLASTVALという呼び方がくせ者だったらしい。
PostgreSQL的には、これは「最後に挿入したデータのID」なのだけれど、
Serverpod的には、Serverpodが自動生成しているほかのいろんなLogなどが、
私の意図している非同期処理と錯綜して
「そっちのIDが入ることもあるかもね」らしいのだ。

ということで結論

LASTVALという「一般名詞」ではなく、その関数独自のIDを返す。
それだけかい!
それだけでした(ﾟﾟ)(｡｡)ﾍﾟｺｯ

  Future<int> addPrincipal(Session session, Principal principal) async {
    await Principal.insert(session, principal);
    return principal.id!;
  }

注　idのうしろの!、これがないとerrorになる

なんで？