On 2025/03/19 10:00:00 </o=ExchangeLabs/ou=Exchange Administrative Group
(FYDIBOHF23SPDLT)/cn=Recipients/cn=3da34e28d9d240d4abadbbb549f9ff21-houzj.fnst>wrote:
On Wed, Mar 19, 2025 at 8:56 AM Dean wrote:
> Unfortunately, neither column lists nor row filters can provide the level of
> control I'm proposing. These revised examples might help illustrate the use
> case for DRF:
>
> Alice, Bob, and Eve subscribe to changes on a `friend_requests` table.
> Row-level security ensures CRUD access based on user IDs.
>
> 1. Per-subscriber column control: Bob makes a change to the table. Alice
> should receive the entire record, while Eve should only receive the
> timestamp - no other columns. Why DRF is needed: Column lists are static
> and apply equally to all subscribers, meaning we can't distinguish Alice's
> subscription from Eve's.
I would like to confirm the concept to ensure I understand it correctly. If
your goal is for the two subscriptions, Alice and Eve, to utilize different
column lists, you can achieve this by creating two separate publications:
Alice_pub and Eve_pub. You can specify the desired column list for the table in
Eve_pub. Consequently, the subscription Alice will subscribe to Alice_pub,
receiving the full record, while Eve will subscribe to Eve_pub, receiving a
limited set of columns. If this does not fully meet your requirements, could
you please provide additional details or clarify your specific needs ?
> 2. Bob DELETEs a row from the table. Alice should see the DELETE event, while
> Eve should not even be aware of an event. Why DRF is needed: The
> deterministic nature of row filters makes them unsuitable for
> per-subscriber filtering based on session data.
>
>
> The goal of DRF is to allow per-subscriber variations in change broadcasts,
> enabling granular control over what data is sent to each subscriber based on
> their session context.
Same as above, it would be helpful to elaborate a bit more.
Best Regards,
Hou zj
