Add mechanism to define order of named variables

[zebulon98]

Not sure if this is a bug or a feature, but I have noticed that the order of parameters in functions is assigned randomly in my code following the build of .drift SQL functions into dart. I think I might have read about this so it might be a feature, but cannot find any reference to it now so logging it here for an answer. This is using the release 2.4.2 of Drift.

I have two functions (updateSortOrder and addSortOrder), which both take two int parameters, position and fid, in that order (see screen shot below).

These functions are both working with a simple table with two fields - fid and position. fid is the primary key. Both fields are int values.

Following the build of the .drift file into dart, one of the dart functions takes the parameters in position-fid order and the other takes the parameters in fid-position order. I have tried flipping the parameter order in the .drift file and rebuilding (the parameters were originally both fid-position order), but this seems to make no difference to the parameter order in the built dart file.

The parameter order for updateSortOrder in Dart is position-fid as follows:

The parameter order for addSortOrder in Dart is fid-position as follows:

I would have thought that if both functions are working on the same table and there was some logic driving this, then both functions would have the same parameter order even if this was controlled by the build process rather than my code.

Is this a bug or feature? If it is a feature, what is the logic for deciding the parameter order in the built Dart functions?

[simolus3]

There actually is some consistent ordering to function parameters: We sort them by their logical variable number in SQL. If you're not using explicitly-indexed variables (e.g. VALUES (?2, ?1)), that works out to the order in which the variables are first used.

I think this is a decent approach in general, but we should probably try to honor the order of variables if they're explicitly declared. Suddenly starting to do that would be breaking, but it's something to keep in mind for the next major version.

[North101]

If you'd prefer to remove the ambiguity you can enable named_parameters in the build options: https://drift.simonbinder.eu/docs/advanced-features/builder_options/

You can also force addSortOrder to be position, fid by changing your insert to:

INSERT INTO frequencysort(position, fid)
VALUES(:position, :fid)

Though you can't change the order for uodateSortOrder

[zebulon98]

There actually is some consistent ordering to function parameters: We sort them by their logical variable number in SQL. If you're not using explicitly-indexed variables (e.g. VALUES (?2, ?1)), that works out to the order in which the variables are first used.

I think this is a decent approach in general, but we should probably try to honor the order of variables if they're explicitly declared. Suddenly starting to do that would be breaking, but it's something to keep in mind for the next major version.

Thanks for the quick response. I thought I had seen something about this before, but wasn't sure so thanks for clearing this up for me. I am happy to close this as resolved unless you want to keep it open as a feature request? (I am new to github so not sure what the etiquette is.)

[zebulon98]

If you'd prefer to remove the ambiguity you can enable named_parameters in the build options: https://drift.simonbinder.eu/docs/advanced-features/builder_options/

You can also force addSortOrder to be position, fid by changing your insert to:

INSERT INTO frequencysort(position, fid)
VALUES(:position, :fid)

Though you can't change the order for uodateSortOrder

Thanks. I'll read that documentation for future reference. I've fixed my issue for now and learned a valuable lesson - always hover over the function to check what it thinks the required order is. 😆