On Mon, Apr 17, 2017 at 02:32:22PM +0100, Matthew Wild wrote:
>   - Treat the request as an atomic change: succeed for all, or fail
> all (i.e. if one of the JIDs is malformed, don't allow any of the
> other changes in the request to take place). This would require work
> to either pre-verify the changes (which we don't have code for) or to
> roll back changes that were already made (which is a bit hacky, we'd
> already have sent out notifications, unless we added a new 'batch
> update' version of :set_affiliation()).

I would prefer this. Possibly by collecting the changed state in a new
table, then overwriting the old affiliations table as a commit.

-- 
Zash

-- 
You received this message because you are subscribed to the Google Groups 
"prosody-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to prosody-dev+unsubscr...@googlegroups.com.
To post to this group, send email to prosody-dev@googlegroups.com.
Visit this group at https://groups.google.com/group/prosody-dev.
For more options, visit https://groups.google.com/d/optout.

Attachment: signature.asc
Description: PGP signature

Reply via email to