1.前提条件
table A (booking)
ーステータス（予約 キャンセル）
ー日付A
ー日付B
tableB (payment)
ーbooking(リレーション)
ーPrice
ー区分
Repeating Groupのデータはtable A (booking)のデータを利用している。
2.発生している問題
Repeating Group table A (booking)表示しているデータにtableB (payment)の
ーbooking(リレーション)がない場合はRepeating Groupで表示されるデータを非表示（対象外）にしたいがやり方がわかりません。
何卒よろしくお願いいたします。
（例）
table A (booking)
ー001
ー予約
ー1/2
ー1/5
ー002
ーキャンセル
ー1/2
ー1/5
ー003 →ここを非表示（対象外）にしたい
ーキャンセル →ここを非表示（対象外）にしたい
ー1/2 →ここを非表示（対象外）にしたい
ー1/5 →ここを非表示（対象外）にしたい
ー004
ーキャンセル
ー1/2
ー1/5
tableB (payment)
ー001(リレーション)
ー10000
ー料金A
ー002(リレーション)
ー2000
ー料金B
ー004(リレーション)
ー2000
ー料金B
※tableB (payment)に003のリレーションがない
→このデータtable A (booking)を表示させないようにしたい。
「tableB (payment)のpaymentーbooking(リレーション)がない場合、検索対象外にする」ということですね。
（前提が違っていればすみませんが、ご指摘ください）
つまり、
bookingをsearch forを使って検索していく際に
「このbookingがどのpaymentにも紐づけられていない」
という条件を作っていく必要があるかと思います。
現状のDBの構成を変更せずに行う場合は以下のようになります。
search for bookings 後にfiltered を開いていただき、
「Advanced」を選択し、以下の画像のように、paymentのDBでdo a search forの検索を記述します。
すると、bookingがいずれかのpaymentに紐づいている(search for payment first item is not empty ) なbookingのみを検索対象することができます。
「いいね！」 1
補足としてですが
ただし、booking一つ一つに対して、paymentの全レコードに対して検索をかける構成になっています。
アプリのユーザー数や使用量が大きくなり
booking、paymentが膨大になると、bubbleのデータ通信量の指標になっておりますWUを大きく消費してしまう可能性もありますので、なるべくfilteredを使わなくて済むDB設計にしてあげることも考慮していくことが求められるかと思います。
「いいね！」 1
アドバイスいただきありがとうございます。実現できました。
大変感謝しております。
懸念されていたように、やはり検索結果の表示速度が遅いようで
これを解消するにはどんな方法がありますでしょうか？
以下、考えてみた方法です。
１、 Repeating Groupの検索対象をtableB (payment)にしてみる
→表示順番がtable A (booking)の日付Aの順番にする方法がわからない（泣）
２、表示用のtableCを作成する。バッチ処理？？
３、table A (booking)にtableB (payment)にリレーションするカラムを追加する。
いかがでしょうか？
何卒よろしくお願いいたします。
1番の手法を最初にお伝えすべきでした。
型はbookingにして
検索条件を
search for payment each item booking
booking isn’t empty
並び替えは sorted byを使ってください。
「いいね！」 2
ご回答いただきありがとうございました。挑戦しましたが、結果うまくいきませんでした。ちょっと他の方法も考えてみます。
お力添えできずすみません。
うまくいかなかったという意味は、
表示させたいものを表示できなかったということでしょうか。
よろしければ詳しくお聞かせいただけると幸いです。
「いいね！」 1
