On 17.04.2017 22:21, Matthew Wild wrote:
> On 17 April 2017 at 19:34, Kim Alvefur <z...@zash.se> 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.
You received this message because you are subscribed to the Google Groups
To unsubscribe from this group and stop receiving emails from it, send an email
To post to this group, send email to email@example.com.
Visit this group at https://groups.google.com/group/prosody-dev.
For more options, visit https://groups.google.com/d/optout.