On 17.04.2017 22:21, Matthew Wild wrote: > On 17 April 2017 at 19:34, Kim Alvefur <[email protected]> wrote: >> 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. > > I'd prefer it too, but it's not trivial. > > [...] > > Does this make sense?
Yes, it does and I think I understand what you want to achieve. I'll give it a try this weekend and if I run into problems I'll send a patch with some pseudo-code to the list to avoid running in the wrong direction for too long. Best Regards Lennart -- 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 [email protected]. To post to this group, send email to [email protected]. Visit this group at https://groups.google.com/group/prosody-dev. For more options, visit https://groups.google.com/d/optout.
