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 firstname.lastname@example.org. Visit this group at https://groups.google.com/group/prosody-dev. For more options, visit https://groups.google.com/d/optout.
Description: PGP signature