Do not upload empty updates to Supabase

[Radiokot]

If a local table has been updated and the update resulted in no change for particular rows, then the corresponding CrudEntrys have empty opData. It doesn't seem to make sense to execute such updates. Skipping them speeds up sync.

[simolus3]

Thanks for the contribution! I agree that we should skip uploading empty updates. But since this affects all our SDKs, we'll have to discuss internally on how to best address this. It might make sense to not record empty updates to begin with (so that they'll never even reach the connector), but that might also break users relying on this behavior.

We're investigating adding something like a per-table configuration option to configure how the client collects updates in powersync-ja/powersync-sqlite-core#60, an option to not collect empty updates could be part of that.

As a temporary workaround, you can run the following statement to clear empty updates from the upload queue:

delete from ps_crud WHERE data->>'op' = 'PATCH' and not exists (select 1 from json_each(data->'data'));

To run this automatically, I suppose you could wrap the inner supabase connector like this:

class IgnoreEmptyUpdates(val inner: PowerSyncBackendConnector): PowerSyncBackendConnector() {
    override suspend fun fetchCredentials(): PowerSyncCredentials? = inner.fetchCredentials()

    override suspend fun uploadData(database: PowerSyncDatabase) {
        database.execute("delete from ps_crud WHERE data->>'op' = 'PATCH' and not exists (select 1 from json_each(data->'data'));")
        inner.uploadData(database)
    }
}

[Radiokot]

Thanks for the reply, I understand.
Regarding the suggested workaround: Is ->> possible in SQLite?

[simolus3]

Regarding the suggested workaround: Is ->> possible in SQLite?

It is since version 3.38.0 (we ship a newer version along with the SDK on Android and JDK platforms, recent iOS versions should have that too (it's been released three years ago)).

[Radiokot]

Wow, that's awesome!

[simolus3]

We will address this in the core extension (see this PR), so that this can be an opt-in behavior across all our SDKs. Thank you for the suggestion!