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'm using GENERATED ALWAYS AS IDENTITY primary key definitions, which is great, because it makes sure that no-one can accidentally update id columns. It's still possible manually, but needs to be an intentional behavior with OVERRIDING SYSTEM VALUE clause.
However, it doesn't seem to work with supabase-cache-helpers, since it requires primary keys to be part of the update payload to build filters, but doesn't remove them from it.
{
"code": "428C9",
"details": "Column \"id\" is an identity column defined as GENERATED ALWAYS.",
"hint": null,
"message": "column \"id\" can only be updated to DEFAULT"
}
I think it's a bad practice in general to include primary keys in the update payload by default. Foreign keys, sure, but there's little reasons to make primary keys mutable, and it's just a potential source of unintentional errors / breaking data integrity.
letfilterBuilder=qb.update(inputasany,opts);// todo fix type;
Suggested solution
Remove primary_key values from the update payload by default, and enable it with e.g. opts.stripPrimaryKeysFromData = false or equivalent. It could be a breaking change though for some (even if unintentionally), so for a minor version, stripping primary keys could also be opt-in.
The text was updated successfully, but these errors were encountered:
lauri865
changed the title
Bug: primary keys not working with GENERATED ALWAYS AS IDENTITY columns
Primary keys not working with GENERATED ALWAYS AS IDENTITY columns
Feb 13, 2024
Describe the bug
I'm using
GENERATED ALWAYS AS IDENTITY
primary key definitions, which is great, because it makes sure that no-one can accidentally update id columns. It's still possible manually, but needs to be an intentional behavior withOVERRIDING SYSTEM VALUE
clause.However, it doesn't seem to work with
supabase-cache-helpers
, since it requires primary keys to be part of theupdate
payload to build filters, but doesn't remove them from it.The resulting payload is:
Which reults in the following error:
I think it's a bad practice in general to include primary keys in the update payload by default. Foreign keys, sure, but there's little reasons to make primary keys mutable, and it's just a potential source of unintentional errors / breaking data integrity.
Related code:
supabase-cache-helpers/packages/postgrest-core/src/update-fetcher.ts
Line 43 in ec72756
Suggested solution
Remove primary_key values from the update payload by default, and enable it with e.g.
opts.stripPrimaryKeysFromData = false
or equivalent. It could be a breaking change though for some (even if unintentionally), so for a minor version, stripping primary keys could also be opt-in.The text was updated successfully, but these errors were encountered: