Hi Evgeny, Le lundi 7 janvier 2019, 09:30:26 CET Evgeny a écrit : > On Mon, Jan 7, 2019 at 10:44 AM, Goffi <[email protected]> wrote: > > Is there any implementation in the wild which would have issue with > > node order? > > Sure, any clustered database will have issues with > such naive approach: after partitioning during merge > you'll end up with duplicated orders, like 2 items > with order=4.
I think you are talking about the feature in general (the question you are answering to was about using ordering of <order/> elements to know which level they are applied to vs using an explicit attribute for the same thing). I'm not sure to get your issue, I've talked about it this morning on xsf@ muc. Are you talking about the fact that "date of modification" (as defined in the protoXEP) could be out of sync between clusters? If so, ordering by date of modification as described in the protoXEP is the same as defaut ordering with XEP-0060 alone, so I don't see how this is different of current situation. If this is something else, can you please describe it with an example so I can understand better the problem? Thanks As I've said earlier, this protoXEP is not much different from the "ORDER BY" clause in SQL which can be used with clustered databases, so I don't see any reason why this would not work in this case. ++ Goffi _______________________________________________ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: [email protected] _______________________________________________
