Posts

結論：omitemptyは便利だが罠がある omitemptyタグは空値を省略できて便利だが、falseや0が保存できなくなる罠がある。 特にboolean型で**「false」と「未設定」を区別したい場合は要注意**だ。 omitemptyとは 空値の場合にフィールドを省略するタグ。JSON/Firestoreへの保存時にデータサイズを削減できる。 type User struct { Name string `json:"name"` Email string `json:"email,omitempty"` // 空なら省略 } ⚠️ 最大の罠：「空」とみなされる値 以下の値は「空」として扱われ、omitempty付きフィールドから消える: 型 空とみなされる値 保存できない値の例 真偽値 false ❌ falseが保存不可 数値 0 ❌ 0が保存不可 文字列 "" ❌ 空文字列が保存不可 スライス/マップ nil または長さ0 ❌ 空配列が保存不可 ポインタ nil - time.Timeのゼロ値は、JSONでは「空」に当たらず消えない。下の「struct と time.Time は omitempty で消えない」を参照。 実例：boolean型の罠 問題のあるコード type Config struct { EnableFeature bool `firestore:"enableFeature,omitempty"` } config := Config{EnableFeature: false} // ❌ Firestoreに保存されない！ // "enableFeature"フィールド自体が消える これでは「false」と「未設定」が区別できない。 ...

Firestore MongoDB互換の要点まとめ 概要 Googleが「Firestore with MongoDB compatibility」を 発表 MongoDB用ドライバやMQL（MongoDB Query Language）をそのまま使ってFirestoreを操作可能 Firestoreのスケーラブルな基盤の上にMongoDB互換レイヤーを構築 現時点ではEnterpriseエディションのPreview機能 仕組み MongoDBクエリをFirestore内部クエリに変換する互換APIレイヤーを提供 collection.find() などのMongoDBドライバ呼び出しをそのまま利用可能 MongoDB→Firestoreへのクエリ変換処理で、未対応や制限付きの演算子が存在 Firestoreのインデックス構造に基づいて最適化されるが、MongoDBとは挙動が異なる クエリ互換性 基本的なクエリ（比較、論理、範囲、配列など）は概ね対応 複雑なAggregation Pipeline、ジオクエリ、テキスト検索（$text）などは未対応または制限あり $regex など一部の正規表現検索は動作する可能性があるが完全な互換ではない $where、$lookupなどのサーバーサイドスクリプト・結合系クエリは非対応 like検索・部分一致 MongoDBでは $regex で部分一致検索が可能 Firestoreネイティブでは前方一致（prefix検索）のみ対応 MongoDB互換モードでも正規表現機能は一部制限あり 任意の位置一致や複雑な正規表現検索は非対応または非推奨 制限・注意点 現時点でPreview段階のためAPI変更の可能性あり MongoDBすべての演算子を網羅していない Firestore独自のクエリ制限（フィルター数上限など）は引き継がれる 同一クエリでもMongoDBより遅くなるケースあり（インデックス構造差による） リアルタイム更新やオフライン対応などFirestore特有の機能との完全互換は未実装 利用上の位置づけ MongoDBからFirestoreへの移行を容易にするための互換レイヤー 機能完全再現ではなく、移行コスト低減が主目的 高度な全文検索や結合が必要な場合はMongoDB本体を利用すべき Refs https://cloud.google.com/blog/products/databases/announcing-firestore-with-mongodb-compatibility https://cloud.google.com/firestore/mongodb-compatibility/docs/overview https://firebase.google.com/docs/firestore/enterprise/migrate-to-firestore-with-mongodb https://medium.com/@aswinalexandersam/firestore-with-mongodb-compatibility-current-state-limitations-and-opportunities-fbf03542d0c3 https://dev.to/franckpachot/firestore-with-mongodb-compatibility-testing-pagination-queries-jmf https://stackoverflow.com/questions/79631546/the-query-limitation-with-max-30-filter-parameters-still-exists-in-gcp-firestore

問題 golangci-lint をコンテナ内で実施すると以下エラーが発生した コンテナ内でのみ発生して、ホストで実行すると発生しなかった WARN [runner] Can't process results by diff processor: can't prepare diff by revgrep: no version control repository found cmd/main.go:1: : error obtaining VCS status: exit status 128 Use -buildvcs=false to disable VCS stamping. (typecheck) 原因 golangci-lint は git の情報を取得しようとするが、コンテナ内の 作業ディレクトリが git の安全なディレクトリとして登録されていないために発生する 解決方法 以下 .gitconfig を作成して、compose.yaml で /root/.gitconfig:ro でマウントした [safe] directory = /work # コンテナ内の作業ディレクトリを指定 directory = /work/api # コンテナ内の作業ディレクトリを指定

疑問 GCP ErrorReporting でのエラー通知の挙動についてわかっていなかったので、メモ まとめ ErrorReporting に出力され、通知設定先（Email/Slack）に内容が飛ぶ 同じエラーはグループ化され、既存のエラーグループに属する場合は通知されない 原則として「新しいタイプのエラー」や「一度解決済みとマークされたエラーが再発したとき」にのみ通知 解決済みとすれば再度通知される エラーが原因で発生する通知は、1時間に最大5回まで送信可能

GOで 構造体に定義したメソッドと埋め込みされたメソッドが同じシグニチャで無限ループに遭遇した 以下実装で発生していた type SampleService struct { repository.SampleRepositoryHandler } func (s *SampleService) TargetFunction(ctx context.Context, sampleID, exampleID string) error { err := s.TargetFunction(ctx, sampleID, exampleID) if err != nil { // ... } } それまで異なる名前だったので、メソッド名変更を実施したタイミングで発生した為、気づかなかった ポイント 構造体埋め込み（匿名フィールド）は、委譲（delegation）として機能する 埋め込んだ型のメソッドを、親構造体のメソッドとして呼び出せる s.TargetFunction は SampleService のメソッドと、埋め込んだ SampleRepositoryHandler のメソッド両方を持つ 名前が重複している場合は、親構造体のメソッドが優先される 解決策 埋め込みで呼べたとしても、明示的に記載すべき