This can also somewhat fix #3238 and make the behaviour consistent

But for backward compatibility, it should be behind some flag which will default to false.

@morki What backwards compatibility are you concerned about? This doesn't change the query behavior, only the API of generated code (but only the return value, so should be source-compatible).

@MariusVolkhart as I understand this, it can compile fine, but it changes the behaviour. From your example:

updatePlayerName(4, "Hero")

This now normally executes the query. But with your change, the same compiles fine, but does not execute the query. This code will execute the query:

updatePlayerName(4, "Hero").executeAsOne()

Do I understand it right?

@morki Oh, gotcha. No, that's not how this works.

In the example,

updatePlayerName(4, "Hero").executeAsOne()

updatePlayerName would have to return an ExecutableQuery. The ExecutableQuery allows the query execution to be deferred and this deference is what would cause a behavior change.

However, in the changes in this PR, updatePlayerName returns a QueryResult. The query is still executed immediately, as it was before. The only change is that the result of the query, which was already reported by the driver, is now exposed. That is to say, this PR does not change query execution behavior, only exposes and additional result that is already immediately available. See https://github.com/cashapp/sqldelight/pull/4578/files#diff-3d7267ef64e0f3f32d17e8f5379be391dcf82cecd259a4b42cff03c8ed105a3e for a good example of how the generated code changes.

@MariusVolkhart oh, thank you for the explanation and sorry for bad understanding. I was probably tired when quickly reviewing.

I think my main concern is how this can leak implementation details of individual drivers. I don't know that all the supported drivers actually return the same thing for each of the mutator queries.

I don't know the right way to solve it. SQLDelight would need some knowledge of how the driver works and choose to return the result if its the thing we want to expose, or run a separate query to get the last_change_id or changes() (in SQLite, IDK what it is for other dialects) so that its guaranteed to behave the same with different drivers

Or we just let them go through as is and its up to the consumer to know what the driver returns, but I don't think thats right

I lean towards the "we just let them go through as is and it's up to the consumer to know what the driver returns" approach.

Firstly, not exposing the return value limits the capabilities of SQLDelight relative to the underlying driver. SqlDriver already has an API that returns the mutated count, and it's a behavior common in many systems (DBMS, JDBC, etc). It feels like quite a severe, yet artificial, limitation compared to Hibernate, JDBC, etc to not expose the ability to query the mutated count.

Secondly, exposing the mutated count means that people can develop custom drivers for implementations (SQLJS, Sqlite) that do query last_change or changes(), if they want that functionality. This assumes that we don't want such functionality built-in, which is reasonable, since a second query that might not be consumed is undesirable.

Thirdly, developers using a driver that doesn't support this will surely either know, or quickly find out when they try to use it, that their driver doesn't support this functionality.