Support the creation of queries from strings

[boenrobot]

While the basic functionality of the Query class works for most cases, it can quickly become difficult to use (or at the very least lead to verbose code) as the size of the query grows.

A more intuitive approach would be the creation of a query from a string. The string itself should use the familiar syntax from shell's "where" argument... with some reduced functionality of course (e.g. there's no regex in queries yet).

Among other things, I'm still wondering what to call it though... Query::parse(), Query::expression(), Query:fromString()...

[Max13]

@boenrobot I suggest you just use the constructor:

$query = new Query('where adress=10.10.10.10');

Then you tokenize the string on every space and =, !=, >, <, ...

[boenrobot]

The constructor is called internally by static methods with an empty query (before filling it with what the user supplied), but an empty query is not something that a user should be allowed to end up with... So that's a no go.

That said, if you could implement a static method that does the actual tokenization and conversion to query words AND supports proper brackets, I would be very happy to accept a pull request.

[Max13]

Here is what I have for now: https://gist.github.com/Max13/70880d1e2d421b6f602501ba37e1dcb5

I have 5 tests, including && and ||, but currently I have no clue how to take the parenthesis into consideration, neither if regex is the best method (probably not).

[boenrobot]

The query is basically expressed in reverse polish notation, meaning one needs to implement https://en.wikipedia.org/wiki/Shunting-yard_algorithm after properly tokenizing the whole thing... Regex in general is the best way to tokenize it, but whether your specific one is the best is a separate matter, and I'm not sure about that.

Also, keep in mind that there are a few more things one can do in a where in addition to brackets (and which do have query equivalents). Notably, what I see missing is negation of expressions (e.g. !(a || b)), "or equals" operators ("prop >= value" should be translated to "(prop > value || prop = value)" under the hood, and analogously for "<="), and I'm also not sure if your regex would support "is set" checks, e.g. propX && propY="" being equal to

?propX
?propY=
?#&

and !propX && !propY="" being equal to

?-propX
?-propY=
?#&