Balance SQLite expression tree for logical operators (AND/OR) to lower the depth

[LZRS]

IMPORTANT: All PRs must be linked to an issue (except for extremely trivial and straightforward changes).

Fixes #2561

Description
Recursively bifurcates the conditional params expressions to prevent occurences of SQLite expression tree exceeding depth of 1000, as suggested in this comment

Alternative(s) considered
Chunking large expression list to limit 50 within parantheses to avoid crashing with Expression tree is too large (maximum depth 1000), as described here

Type
Enhancement Feature

Screenshots (if applicable)

Checklist

• I have read and acknowledged the Code of conduct.
• I have read the Contributing page.
• I have signed the Google Individual CLA, or I am covered by my company's Corporate CLA.
• I have discussed my proposed solution with code owners in the linked issue(s) and we have agreed upon the general approach.
• I have run ./gradlew spotlessApply and ./gradlew spotlessCheck to check my code follows the style guide of this project.
• I have run ./gradlew check and ./gradlew connectedCheck to test my changes locally.
• I have built and run the demo app(s) to verify my change fixes the issue and/or does not break the demo app(s).

[jingtang10]

judging purely by the error message, my hypothesis is that the expression tree depth is O(n) for nested OR operators because the expression tree is constructed naively by parsing the OR operators sequentially. For example, for this expression

a OR b OR c OR d OR e OR f OR g OR h

if the expression tree is constructed naively you'd get:

  o
 / \
a   o
   / \
  b   o
     / \
    c   o
       / \
      d   o
         / \
        e   o
           / \
          f   o
             / \
            g   h

where each o stands for an OR operator. This has depth 8.

But what you really want is actually this:

        o
      /   \
    o       o
   / \     / \
  o   o   o   o
 / \ / \ / \ / \
 a b c d e f g h

where the tree is more "balanced" and this has depth 4. In other words, this is O(log(n)).

If my hypothesis of what causes the problem is correct above, instead of trying to break the OR statements into chunks (and having to come up with a value), all you actually have to do is keep the tree balanced by splitting the top level OR statment at the middle of the list of params.

Does this make sense?

[LZRS]

judging purely by the error message, my hypothesis is that the expression tree depth is O(n) for nested OR operators because the expression tree is constructed naively by parsing the OR operators sequentially. For example, for this expression

a OR b OR c OR d OR e OR f OR g OR h

if the expression tree is constructed naively you'd get:

  o
 / \
a   o
   / \
  b   o
     / \
    c   o
       / \
      d   o
         / \
        e   o
           / \
          f   o
             / \
            g   h

where each o stands for an OR operator. This has depth 8.

But what you really want is actually this:

        o
      /   \
    o       o
   / \     / \
  o   o   o   o
 / \ / \ / \ / \
 a b c d e f g h

where the tree is more "balanced" and this has depth 4. In other words, this is O(log(n)).

If my hypothesis of what causes the problem is correct above, instead of trying to break the OR statements into chunks (and having to come up with a value), all you actually have to do is keep the tree balanced by splitting the top level OR statment at the middle of the list of params.

Does this make sense?

Yeah, it makes sense.

[jingtang10]

there's no guarantee what i said is true @LZRS - i've done no testing or verification and depending on sqlite's implementation what i said could be complete garbage... so pls test and see if this is true :) (for example you could try to see if you'll hit the depth limit a bit later to bifurcate the tree instead of chunking the parameters)

[LZRS]

Alright, no problem. I'll test it out and get back

[LZRS]

there's no guarantee what i said is true @LZRS - i've done no testing or verification and depending on sqlite's implementation what i said could be complete garbage... so pls test and see if this is true :) (for example you could try to see if you'll hit the depth limit a bit later to bifurcate the tree instead of chunking the parameters)

@jingtang10 I tested this out for 1000, 2000 and upto 5000 parameters, and it worked perfectly. I also went ahead a drafted an implementation in the PR

[aditya-07]

Can we add a DatabaseImplTest with