supabase / walrus

Applying RLS to PostgreSQL WAL
Apache License 2.0
119 stars 9 forks source link

Enable filters for delete events #53

Closed w3b6x9 closed 1 week ago

w3b6x9 commented 2 years ago

Feature request

Is your feature request related to a problem? Please describe.

I want to be able to filter delete events based on primary key(s) and when replica identity is set to full, filter based on all columns available in database table.

Describe the solution you'd like

For DELETE events:

Additional context

roobox commented 9 months ago

I am really desperately waiting for this feature!

Zeulni commented 9 months ago

Stumped upon that, need the same feature for my team!

christophemenager commented 7 months ago

Thanks for opening this issue @w3b6x9.

This should be at least clearly documented, it created a major in production for my mobile app...

andy-leezard commented 6 months ago

Hello, are we getting any official fix on this matter soon?

w3b6x9 commented 6 months ago

This should be at least clearly documented, it created a major in production for my mobile app...

@christophemenager great call, i'll let our Realtime team know and we'll add it to our docs.

gsw85 commented 6 months ago

The UPDATE event ignoring filter as well

Stiffjobs commented 5 months ago

The UPDATE event ignoring filter as well

Mine is working on UPDATE event

georgii-ivanov commented 3 months ago

Can we just filter by old record ID? So we know it, just implementing that filter would be helpful

alexeigs commented 2 months ago

It basically means you can't listen to the deletion of any user records currently because you'd subscribe to all deletion events on this table across the entire user base, right?

I hope there's a fix or a recommended workaround added to the documentation given it's a major challenge everyone using realtime capabilities may face.

cphoover commented 2 months ago

I really think that the limitations to realtime... such as this... such as the limitations on filtering multiple columns... such as the scaling issues related to listening to postgres_changes... should preclude supabase from being marketed as a realtime db...

These limitations really make using subscriptions to db changes useless for most real world applications.

I understand you can have a server that consumes postgres_changes and then emits with broadcast... but ideally these features would exist baked into the framework without having to host an additional server layer.