Make query parameters like "where" an optional parameter to the generated methods

[StefanLobbenmeier]

Is your feature request related to a problem? Please describe.
A clear and concise description of what the problem is. Ex. I'm always frustrated when [...]
I would like to be able to have more control over the queries that I end up executing without having to manually implement them

Describe the solution you'd like
A clear and concise description of what you want to happen.
For example:

  Future<List<HealthEntryProxy>> getHealthEntryProxiesAll() async {
    var dbClient = await db;
    var result = await dbClient.query(theHealthEntryTableHandler,
        columns: theHealthEntryColumns, where: '1');

    return result.map((e) => HealthEntryProxy.fromMap(e)).toList();
  }

would be something like this

  Future<List<HealthEntryProxy>> getHealthEntryProxiesAll({where: '1', whereArgs: []}) async {
    var dbClient = await db;
    var result = await dbClient.query(theHealthEntryTableHandler,
        columns: theHealthEntryColumns, where: where, whereArgs: whereArgs);

    return result.map((e) => HealthEntryProxy.fromMap(e)).toList();
  }

Describe alternatives you've considered
A clear and concise description of any alternative solutions or features you've considered.
The alternative for me would be manually creating these methods

Additional context
Add any other context or screenshots about the feature request here.

[matei-tm]

Thanks for the improvement proposal.
Yes, it would be interesting to implement such a requirement. But there are a few pitfalls that make it difficult to develop this initiative at this time. The flexibility of the "WHERE" condition in an OOP approach requires the dynamic code generation. Unfortunately, the mobile platforms for which "f-orm-m8" is primarily dedicated does not support the reflection or runtime dynamic code generation (for example, the Apple kernel does not allow dynamic code generation on iOS devices).
 A static generated code implementation that takes into account the non-finite set of WHERE clause expression variants is completely out of the question.
The variant you propose can be a solution but it creates a ballast that is hard to administer as a support. Who will be responsible for validating where + whereArgs, the f-orm-m8 code generator or the developer who uses it as a blackbox?
For now, anyone can derive the DbProvider in an implementation close to its requirements.
Equally well, if someone is brave enough to make a PR with a robust implementation of the requirement, he is welcome and encouraged to contribute to this project.

[StefanLobbenmeier]

I actually did not intend to generate code for every possible case, simply using a parameterized method would be enough control for my purposes.
I did not think about validation yet. However, from my understanding the underlying SQLite Driver will throw an Exception in case the parameters are invalid, that should be enough, right?

[matei-tm]

You're right. If we skip the validation, your proposed solution is a viable candidate.