No-op transactions still cause Rx emissions

[mhernand40]

Take the following querying for example:

UPDATE message
SET seen = 1
WHERE seen != 1;

With SqlBrite, if all messages already have seen = 1, and this UPDATE transaction is run, any Rx Observables observing message queries will not be notified since the transaction, in this case, is a no-op. However, with SqlDelight 1.1.3 the Observables are still notified.

[JakeWharton]

The same logic that was in SQLBrite is in SQLDelight so both should have received updates for this mutation. I'm not sure we'll ever specifically handle this case, but we plan to handle things like primary keys so that a query affecting one key will not trigger an update for another.

[mhernand40]

Alright, perhaps I should come up with a repro project because I specifically have database integration tests to cover this scenario and they started failing once I upgraded to SqlDelight 1.

[mhernand40]

Finally have a repro project. Please see https://github.com/mhernand40/SqlDelight-Issue-1422-Repro

[mhernand40]

I guess in my particular scenario, I was using SqlBrite's executeUpdateDelete() which as you can see, it is able to check if the row was indeed affected before sending the table trigger.

In the case of AndroidSqliteDriver, there is no executeUpdateDelete() equivalent so there is no way currently to detect if the row was updated or not before sending the table trigger.

[AlecKazakova]

Yea, theres unfortunately no guarantee across all sql dialects that we have an API returning the # of results changed. Going to close this one out