drift
drift copied to clipboard
Option to convert sql variables to camelCase
At the moment colon-named variables (:id) generates method with positioned arguments:
myQuery:
SELECT *
FROM MyTable
WHERE x_column = :x_value AND y_column = :y_value;
Selectable<MyQueryData> myQuery(String x_value, String y_value)
If the order of same-type variables in sql query change in the future, api will break.
Could there be required named variables?
Selectable<MyQueryData> myQuery({@required String x_value, @required String y_value})
Also the variable names for Dart (not sql-string) may be converted to lowerCamelCase like column names?
Selectable<MyQueryData> myQuery({@required String xValue, @required String yValue})
Not sure about in-sql variables code style
Or maybe arguments order in Dart could be the same as in .moor, if declared. I mean at the moment
myQuery(:x_value AS TEXT, :y_value AS TEXT):
SELECT *
FROM MyTable
WHERE y_column = :y_value AND x_column = :x_value;
produces
Selectable<DistrictData> myQuery(String y_value, String x_value)
but could
Selectable<DistrictData> myQuery(String x_value, String y_value)
This was suggested in #918 and I believe it's currently implemented on the develop branch
I believe it's currently implemented on the develop branch
Exactly. It requires the named_parameters build option for backwards compatibility, but this will be supported in the next moor version.
Or maybe arguments order in Dart could be the same as in .moor, if declared
We sort by the index of the parameter. This usually matches the declaration order in the actual statement, but it doesn't respect parameter hints from moor files. Changing this would be a subtle breaking change, so I think the current behavior will have to do. It shouldn't be much of an issue with named parameters.
Also the variable names for Dart (not sql-string) may be converted to lowerCamelCase like column names?
Hm, good point. We could have another build option for this.