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.

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 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.

Reply via email to