Add helper function to fix JS subkey encoding #75
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
When forwarding
data
lines to the core extension, our JS SDK would encodesubkey
values as JSON (before encoding the rest of the message as JSON too).This means that
ps_oplog.key
entries created by the JS SDK look likefoo/bar/"baz"
, while all other SDKs are usingfoo/bar/baz
directly. To prepare the adoption of the Rust sync client in the JS SDK (and for consistency with our other SDKs), we have to migrateps_oplog
entries.The migration will happen in the JS SDK since it's the only SDK affected by this. However, the logic to strip the JSON encoding is not really expressible with builtin SQL functions alone, so this adds a
powersync_remote_duplicate_key_encoding
that detects improper"
keys to remove them.The idea is that the JS SDK would use an entry in
ps_kv
to detect whether a migration has ran and, if it hasn't, runUPDATE ps_oplog SET key = powersync_remote_duplicate_key_encoding(key);
when opening the database.