Skip to content
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

MoveGroup logic enhancements #67

Open
Tracked by #66
migara opened this issue Apr 19, 2024 · 1 comment · May be fixed by #123
Open
Tracked by #66

MoveGroup logic enhancements #67

migara opened this issue Apr 19, 2024 · 1 comment · May be fixed by #123
Assignees
Labels

Comments

@migara
Copy link
Member

migara commented Apr 19, 2024

Currently, a rule group move is performed by moving all the rules around a reference pivot point. For example, if we have N rules in a group and want to move that set of rules before/after a reference rule, we perform N number of API calls. This is not optimal and can be optimised to perform the least number of moves required to achieve the desired outcome.

@migara migara mentioned this issue Apr 19, 2024
21 tasks
@shinmog
Copy link
Collaborator

shinmog commented Apr 25, 2024

The MoveGroup() currently implemented by the generator is better than the old pango logic, but this can be further enhanced.

The current logic determines a pivot rule (last rule in the group if the group is to be located somewhere before or directly before a given rule, otherwise the pivot rule is the first rule in the group), and then after determining the pivot rule, move one index at a time and ensure that that specific index is as desired. This is an enhancement from blindly moving stuff from before, but may not be the most efficient way to accomplish this goal.

IMPORTANT NOTE: Whatever logic comes out of this enhancement, I don't think it's valid to intentionally move a rule that is not in the group. Only rules listed as belonging to the group should be moved.

Example: let's say we want the rules to be ordered like this, with a pivot of top:

A > B > C > D > E

But they are actually like this currently:

A > E > B > C > D

The current logic would move rules B, C, and D. But the better way would be to just move E after D and you're done.

@migara migara added the SDK label Jun 12, 2024
@kklimonda-cl kklimonda-cl linked a pull request Aug 1, 2024 that will close this issue
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants