Cloud Firestore inequality operator exception flutter

Question

while i have been using cloud firestore in my flutter app, strange exception occured.

EDITED

this is my code:

Stream<List<Product>> productsStream(int id) async* {
    final k = _db
        .collection('products')
        .where('category_id', isEqualTo: id)
        .where('stock', isGreaterThanOrEqualTo: 1)
        .orderBy('order')
        .snapshots();

    yield* k.map((event) => event.docs
        .map((e) => Product.fromJson(
              e.data(),
            ))
        .toList());

Here what i would like to achieve is to check for a product wether it is in stock and then to order products in an ascending order by order field in my products collection.

But i am receiving this strange error:

Exception: 'package:cloud_firestore/src/query.dart': Failed assertion: line 421 pos 16: 'field == orders[0][0]': The initial orderBy() field '[[FieldPath([order]), false]][0][0]' has to be the same as the where() field parameter 'FieldPath([stock])' when an inequality operator is invoked.

What might be solution?

Answer 1

This is explained in the ordering limitations documentation:

If you include a filter with a range comparison (<, <=, >, >=), your first ordering must be on the same field

So I suspect you should have:

        .where('category_id', isEqualTo: id)
        .where('stock', isGreaterThanOrEqualTo: 1)
        .orderBy('stock')
        .orderBy('order')

Obviously that means it's no longer primarily ordered by order. You'd need to do local sorting if that's a problem - in which case you may find you don't want to order server-side at all.

Although "not equal to" filters aren't mentioned in the documentation, it sounds like they also count as range comparisons in terms of prohibiting filtering.

So basically, I would suggest you either need to filter locally on stock, or you need to order locally on order - you can't do both in the same Firestore query at the moment. Note that this server-side limitation is something that could change in the future (either for all range comparisons, or possibly just to allow "not equal to") so it may be worth retesting periodically.