Add information about lexical Precedence to Filter spec documentation about mathesar-wiki

[dmos62]

Notably, this goes against the filters product concept document where it says:

The order than you apply filters in does not matter. Since filters only look at the data in a single row, you can apply them in any order and end up with the same result.

[silentninja]

The order than you apply filters in does not matter. Since filters only look at the data in a single row, you can apply them in any order and end up with the same result.

I think it is pointing to the filter condition(id = 1) and not the operator that joins them. Based on what @pavish has commented on the matrix there can be only one joining operator for the whole filter set

[kgodey]

I think it is pointing to the filter condition(id = 1) and not the operator that joins them. Based on what @pavish has commented on the matrix there can be only one joining operator for the whole filter set

Yes, this is correct. What I meant was that if you have the same filters with the same operators applied, the order doesn't matter, i.e. filters are commutative.

---

@silentninja Where is the filter spec documentation that needs to be updated for this issue?

[kgodey]

I wrote up an architecture wiki page for filters, let's keep this updated. I haven't added anything about lexical precedence yet.

[pavish]

If the filter API supports nested filters (which was decided) in a similar format to sqlalchemy-filters, we wouldn't have a scenario with multiple operators.

Do we need to document lexical precedence?

[kgodey]

Do we need to document lexical precedence?

I don't think so. I'll close this issue for now, we can reopen if needed.