Potential Issue with where clauses

[TimothyGillespie]

Currently the .where() method will take the first parameter and put it in back ticks while making the second parameter an value for a prepared statement. This should be okay for the very most cases, but if the user does something odd it like trying to put the value first and then the column name it might not work - or worse: It works but is now SQL Injectable.

Another issues potential issue is the free choice of the operator which will be simply plugged in between. If the user puts a variable in that place it is another SQL injection potential. I think some option to limit this would be appropriate.

Anyway the question is: what should it ideally do and what is an acceptable simplification?

[TimothyGillespie]

For an illustration you can see #15

[JanHolger]

Regarding the order of parameters: I can't stop anyone from killing him/her/itself.
Regarding the validation of the operator and potentially also the column definitions: I totally agree that we need to validate those to prevent sql injection when directing user input into it. For the operator this should be achievable by validating against a list of valid operators. For the query column we could validate against [A-Za-z0-9_-] as long as it doesn't have the raw flag. I've added a card on the project linking this issue.