You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Describe the bug
I store data in a bytea column and subscribe to it using Realtime. Simply storing data with
String_bytesToHex(Uint8List bytes) {
final buffer =StringBuffer();
for (final byte in bytes) {
buffer.write(byte.toRadixString(16).padLeft(2, '0'));
}
return buffer.toString();
}i
await _supabase.from('test').upsert({
'data':'\\x${_bytesToHex(Uint8List([1, 2, 3])}', /
})
// This is fine_hexToBytes(await _supabase.from('test').upsert({
'data':'\\x${_bytesToHex(Uint8List([1, 2, 3])}', /
}).select());
leads to a consistent result in the Supabase dashboard as well as when trying to retrieving it using a SELECT.
However, when I have a subscription to this table, i.e.
_backendSubscription?.onPostgresChanges(
schema: publicSchema,
table: _backendTables[syncable],
event:PostgresChangeEvent.all,
callback: (p) {
// This is wrong... prints out a doubly hex-encoded string binary...print(_hexToBytes(p['data']));
},
The resulting record has a double encoded field, leading me to manually patch it every time which seems wrong.
To Reproduce
Steps to reproduce the behavior:
Start a Realtime subscription on a table with bytea column.
Add a new record.
Print the bytea column.
Expected behavior
A hex representation of the binary data in the table.
Actual
A hex representation of the hex representation of the binary data in the table.
Screenshots
If applicable, add screenshots to help explain your problem.
N/A
Version (please complete the following information):
Describe the bug
I store data in a bytea column and subscribe to it using Realtime. Simply storing data with
leads to a consistent result in the Supabase dashboard as well as when trying to retrieving it using a SELECT.
However, when I have a subscription to this table, i.e.
The resulting record has a double encoded field, leading me to manually patch it every time which seems wrong.
To Reproduce
Steps to reproduce the behavior:
Expected behavior
A hex representation of the binary data in the table.
Actual
A hex representation of the hex representation of the binary data in the table.
Screenshots
If applicable, add screenshots to help explain your problem.
N/A
Version (please complete the following information):
Additional context
Add any other context about the problem here.
This may be server related and not SDK-specific.
The text was updated successfully, but these errors were encountered: