[Do Not Merge] Modify in_position? method to fix inconsistencies #11
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
in_position? method wasn't working right due to issues with using following-sibling when before and preceding-sibling when after, this corrects it with new, hopefully proper assumptions. The only item that small change didn't fix was last() which was not working for either because of the way siblings treat the last() command as it will always resolve to true on the first match in those cases. This patch assumes that you'll never have more than one [last()] in your xpath for positioning and swaps it out with the correct final array value of augeas matches. We use an invert boolean on 'after' positions as we will always have an empty? resolving as true if the match exists before the item we're looking for. Whereas we'll always have empty? as false if we do a 'before' and the actual item currently exists after the line we're trying to match.
asasfu
force-pushed
the
patch/in_position
branch
from
0d631dc
to
203e5f8
Compare
Previously last_value would only work properly if you were evaluating the top lines of the file so it would be .../1/*, /2/, /3/ etc. rather than some lines mid way down that would be .../17/*, /18/, /19/ etc. In siblings we actually need to count items, so we now convert last() to be the count; minus 1 if there's more than one object, otherwise it should stay as 1. Also, we should return true if the result of last_value is 1 or less(if less it means something probably went wrong because it didn't return any values, so likely that will never happen, but if 1... then it means we have no items of that type or xpath to compare to anyways, so it will never be, before or after, itself; therefore, always in_position.
|
LGTM. Any news on the tests @asasfu ? |
|
Dear @asasfu, thanks for the PR! This is Vox Pupuli Tasks, your friendly Vox Pupuli Github Bot. I noticed that your pull request has CI failures. Can you please have a look at the failing CI jobs? |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
in_position? method wasn't working right due to issues with using following-sibling when before and preceding-sibling when after, this corrects it with new, hopefully proper assumptions. The only item that small change didn't fix was last() which was not working for either because of the way siblings treat the last() command as it will always resolve to true on the first match in those cases. This patch assumes that you'll never have more than one [last()] in your xpath for positioning and swaps it out with the correct final array value of augeas matches. We use an invert boolean on 'after' positions as we will always have an empty? resolving as true if the match exists before the item we're looking for. Whereas we'll always have empty? as false if we do a 'before' and the actual item currently exists after the line we're trying to match.
-- I still need to complete the unit tests for this. But this should be a working solution unless some side effects or conflicts can be presented.
this is a patch in reference to #10