-
-
Notifications
You must be signed in to change notification settings - Fork 97
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
add failing test for #659 #661
base: 2.x
Are you sure you want to change the base?
Conversation
when we restrict preUpdate to fields only, there remains one failing test (see travis). Not sure, if this is the way to go. But I see no other simple solution for #659. I think it would be safer anyway to restrict the possible changes to a documents fields as there a no other changesets computed after the event. But that currently leaves us with no way to reset the order of children (maybe this should be allowed). |
I think this needs some discussion ... |
events during the flush seem to be a really tricky beast. do you see a way to allow field updates and reorderings, but no renaming? or could we store the renaming operation in a way that the second changeset calculation can check if something was renamed and not get confused? could we look at object identity rather than paths? uuid would only be something for 2.0 as we would change everything to have a uuid. |
I can try to look into the reordering but I fear this will not be an easy thing to fix. |
what are our other options? limiting event listener to update properties?
|
That's already done here, with the one test about reverting the reordering of the children in preUpdate failing, i.e. that would be a bc break of some kind. |
so there a two conditions to make that test fail
without either one of these conditions the test passes!