Firebase x flutter ごみドキュメント(レコード)の撲滅に orderby はいかがですか
結論
orderby 句を使うと、ドキュメントのコレクション (RDBでいうselect 句の結果データ) からゴミデータをわりと楽に消し去れる
その心は
たまたま orderby を使い始めたところ、ゴミデータが排除された collection には orderby に使った句が存在しない場合、そのドキュメント (レコード) を最初から排除した状態で作り上げてくれることが分かった。
final db = FirebaseFirestore.instance;
final collection = db.collection('Employee');
collection
.orderBy("employeeId", descending: true)
.snapshots()
.listen((snapshot) {
たとえば よくある従業員テーブルだと以下のようなデータが基本形だとします
しかし、テスト段階だとゴミデータが混じります。手で作るといろいろめんどいからね。
そうすると Employee はこんないびつなデータに
で、通常はこのデータを for (doc in snapshot) とかで、アプリのローカルの変数にどんどん突っ込んでいくかと思います。これをやると、後者の”鈴木”のデータを処理するときに employeeId がないとかでエラーになります。
この事象を防ぐために以前の拙作メモでは、下記のように当該 document にフィールド名の項目があるかどうかをチェックし、なければデフォルト値を入れるという方法を記載しました。まあこれはこれで重要だと思うんですが
しかし、データを取った後に orderby をかければ、ゴミデータが排除できることがわかりました。よって冒頭のサンプルで上の不完全な従業員データを処理すると、「鈴木」のデータは存在しない collection になります。なので、その後の処理で、やれあの項目がないとかでエラーになることを避けられます。
final db = FirebaseFirestore.instance;
final collection = db.collection('Employee');
collection
.orderBy("employeeId", descending: true)
.snapshots()
.listen((snapshot) {
ただし、これをやると逆に言うと「鈴木」のデータが処理できなくなります。また、このセーフガードがあるからと言って前作で紹介したようなデフォルト値を定義しないのはノーガードかなと思うので、結局は合わせ技で挑むのが良いでしょう。
ちなみに後から思ったのは、項目が存在しない場合はいいけど、ブランクの場合を考慮してないなと。。まあ気が向いたら考えることにします。
この記事が気に入ったらサポートをしてみませんか?