Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[Feature] support OR operations for group subscriptions #180

Open
hishnash opened this issue Jun 15, 2023 · 0 comments
Open

[Feature] support OR operations for group subscriptions #180

hishnash opened this issue Jun 15, 2023 · 0 comments

Comments

@hishnash
Copy link
Member

hishnash commented Jun 15, 2023

Currently if you want to subscribe to multiple different groups (eg sub scribe to 2 different status) this works but if a model is updated to transition from one status to the other you will get 2 messages.

One informing you that the model has been deleted (from the old status) and the other informing you the model has been created.

It would be nice if instead we could get just one message saying the model was updated, or if that is not possible 2 messages saying updated rather than one saying created and the other saying deleted.

Solution you'd like

When sending a message over the channel layer we could include all the other groups and a mapping of the actions these groups have.

Then in the consumer side when handling the action we could inspect the OR conditional and resolve that one of these was added and the other deleted thus the change is an UPDATE. Doing it way lets us dynamically create chains of bollean logic consumer side at runtime.

We could repress the follow up messages by caching an update id locally on the console to indicate we have handled the update. (we need to look into a chache that is restricted in size so as to not result in a big memory leak).

Alternatives considered

We could provide a query context that is used when generating groups, so that if you need a || operations it creates a dedicated group for that || possibility. This will work well for constrained datatypes like a status but for values like private keys etc this is not going to work.

Other considerations

How do we do this without breaking existing deployments, some people are currently sending the message content directly to the client in the handler so automatically adding an id field and groups set to the message will have issues.

Maybe we can have a property you pass to the model handler or a new @FilterableModelObserver

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant