firestore

結論：orderByは指定フィールドの存在でもフィルタリングする FirestoreのorderBy()句は、指定したフィールドが存在しないドキュメントを自動的に除外する。 並べ替えだけでなく、暗黙的にフィルタリングも行うため、予期しないデータ欠落が発生する可能性がある。 問題：orderByで結果が減る // 「createdAt」フィールドでソート query := client.Collection("users").OrderBy("createdAt", firestore.Asc) このクエリでは、createdAtフィールドが存在しないドキュメントは結果に含まれない。 例： ✅ {id: 1, name: "Alice", createdAt: "2025-01-01"} → 結果に含まれる ❌ {id: 2, name: "Bob"} → 結果から除外される（createdAtがない） 公式ドキュメントの記載 orderBy() 句は、指定したフィールドの有無によるフィルタも行います。指定したフィールドがないドキュメントは結果セットには含まれません。 Cloud Firestore でデータを並べ替えたり制限する | Firebase 範囲比較との組み合わせ制約 範囲比較（<, <=, >, >=）のフィルタがある場合、最初のorderBy()は同じフィールドで行う必要がある。 // ❌ NG: 範囲比較（age）と異なるフィールド（name）で最初にorderBy query := client.Collection("users"). Where("age", ">", 20). OrderBy("name", firestore.Asc) // エラー: 最初のorderByはageにする必要がある // ✅ OK: 範囲比較と同じフィールド（age）で最初にorderBy query := client.Collection("users"). Where("age", ">", 20). OrderBy("age", firestore.Asc). OrderBy("name", firestore.Asc) 対策：フィールド存在を意識する 1....

結論：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のゼロ値 - 実例：boolean型の罠 問題のあるコード type Config struct { EnableFeature bool `firestore:"enableFeature,omitempty"` } config := Config{EnableFeature: false} // ❌ Firestoreに保存されない！ // "enableFeature"フィールド自体が消える これでは「false」と「未設定」が区別できない。 解決策：ポインタ型を使う type Config struct { EnableFeature *bool `firestore:"enableFeature,omitempty"` } // パターン1: 未設定 config := Config{EnableFeature: nil} // → フィールド省略（未設定として扱える） // パターン2: 明示的にfalse falseValue := false config := Config{EnableFeature: &falseValue} // → ✅ falseとして保存される // パターン3: true trueValue := true config := Config{EnableFeature: &trueValue} // → ✅ trueとして保存される 動作比較 omitemptyあり type User struct { Name string `json:"name"` Age int `json:"age,omitempty"` Active bool `json:"active,omitempty"` } user := User{Name: "Alice", Age: 0, Active: false} // JSON: {"name":"Alice"} // ❌ Age=0 と Active=false は消える omitemptyなし user := User{Name: "Alice", Age: 0, Active: false} // JSON: {"name":"Alice","age":0,"active":false} // ✅ 0 と false もちゃんと保存される Firestore/JSONでの使い分け データ削減を優先する場合 Email string `json:"email,omitempty"` // 未入力のメールアドレスは保存しなくていい 値の区別が必要な場合 // boolean型: falseと未設定を区別したい IsAdmin *bool `firestore:"isAdmin,omitempty"` // 数値型: 0と未設定を区別したい Score *int `firestore:"score,omitempty"` まとめ omitemptyは空値を省略してデータサイズを削減できる false、0、空文字列は「空」扱いで消える（最大の罠） 値の区別が必要ならポインタ型を使う JSON/Firestoreどちらでも同じ仕組みで動作 Some illustrations on this site, including the Go Gopher, are by Renée French and licensed under CC BY 4....

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