「文通」はもちろん冗談です。
てか、死語でしょうか？
私が子どものころには雑誌の巻末によく
「文通してくれる人募集」みたいなコーナーがあったんですけどねえ笑
私はIsakを「知って」いますが、彼は私を
「変な質問をissueに投げてくるアマチュアっぽくて、英語があまり上手じゃない人」
としか思っていないでしょう。
でも、誠実に対応して、問題を解決してくれたので、
私的にはなかなか楽しかった「文通」の報告です。
記事検索でもGPT4でも解決しないError
Severpodともだいぶ仲良くなったと思っていたある日、変なことが起こっているのに気づいた。
userが登録する歴史事象をデータベース化していくサービスを構築中だが、
そのDatabaseでtableを連結する要となるIDがめちゃくちゃrandomになっているのだ。
いや、randomというのは正しくない。
数字は確実に増加傾向にある。ただしその間隔はめちゃくちゃだ。
最初気づいたときは、3000代だったが、5000代になり、やがて一桁上がった。
まだテスト段階なので、ほんとのIDは二桁だ。
だから見つかった、と言えばそれはそう。
Postico2で見たら、一目で「変！」とわかるから。
問題はもう一つあって、「正しいIDが入ることもある」。
つまり「いつこのErrorが起こるか」を予測したり、再現したりするのが難しかった。
記事検索もGPT4もお手上げだった。
となると、最終兵器はGitHubのissueということになる。
そもそもこのIDを取得する方法も
Serverpod使い始めのころに、issueで聞いたのだった。
そしてその結果、こんなcodeを書いて、これで機能しているように見えていた。
が、この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になる
なんで？
Discussion