Movatterモバイル変換


[0]ホーム

URL:


Skip to content

Navigation Menu

Sign in
Appearance settings

Search code, repositories, users, issues, pull requests...

Provide feedback

We read every piece of feedback, and take your input very seriously.

Saved searches

Use saved searches to filter your results more quickly

Sign up
Appearance settings

[Doctrine Bridge] return 0 on equality when sorting listeners/subscribers#27126

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 ourterms of service andprivacy statement. We’ll occasionally send you account related emails.

Already on GitHub?Sign in to your account

Closed
bendavies wants to merge2 commits intosymfony:3.4frombendavies:doctrine-tag-priority-sorting-consistency
Closed

[Doctrine Bridge] return 0 on equality when sorting listeners/subscribers#27126

bendavies wants to merge2 commits intosymfony:3.4frombendavies:doctrine-tag-priority-sorting-consistency

Conversation

@bendavies
Copy link
Contributor

@bendaviesbendavies commentedMay 2, 2018
edited
Loading

QA
Branch?3.4
Bug fix?yes?
New feature?no
BC breaks?no
Deprecations?no
Tests pass?yes
Fixed tickets
LicenseMIT
Doc PR

In our app (simplified), we have two event subscribers,A andB.
The app relies onA running beforeB, but we had mistakenly left their priorities as the default,0. By luck/chance, they were sorted such thatA sorted beforeB. All was well.

Then all of a sudden, they started firing in the 'wrong' order,B thenA.
Debugging this, it was because we added a third event listener,C, which caused the order ofA andB to be reversed.
This can be seen here:
https://3v4l.org/SQefd
Note that the order ofa andb is reversed oncec is added.

Adding an equality check (mimicking the spaceship operator) "fixes" the issue (even thought the behavior ofuasort is undefined), and makes the results consistent, I hope?

Now, clearly it was our fault for not defining priorities, but we may have been alerted to the error of our ways if the ordering returned from the sort was consistent in the first place.

$b =isset($b['priority']) ?$b['priority'] :0;

if ($a ===$b) {
return0;

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others.Learn more.

Let's return $b - $a and remove both the if and the ternary operator.

Copy link
ContributorAuthor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others.Learn more.

done!

@dmaicher
Copy link
Contributor

dmaicher commentedMay 2, 2018
edited
Loading

@nicolas-grekas@stof now that I see this PR here I remembered I also worked on this a while ago:

#22001

What exactly happened to this change? 😄 Was it reverted somehow?

Edit: I think it got lost during this merge? or not?bendavies@a707bbf#diff-27d2e9b071d766df504c3fe4131e7abf

@dmaicher
Copy link
Contributor

dmaicher commentedMay 2, 2018
edited
Loading

Ok I think it got lost during this merge 😢

dc66960#diff-27d2e9b071d766df504c3fe4131e7abf

So it never propagated to any higher branch than 2.8. What to do?

Copy link
Contributor

@ostroluckyostrolucky left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others.Learn more.

@nicolas-grekas
Copy link
Member

@ostrolucky bug fix. It doesn't make sense to return a non-zero for equal values. Sorting algorithms have undefined behavior when doing so.

@nicolas-grekas
Copy link
Member

@dmaicher are you fine with this PR? If not, can you please advise? Or would you like to submit another PR if the change required is too big?

@nicolas-grekasnicolas-grekas added this to the3.4 milestoneMay 2, 2018
@dmaicher
Copy link
Contributor

dmaicher commentedMay 3, 2018
edited
Loading

@nicolas-grekas well the thing is that#21977 now effectively is not fixed anymore on 3.4+ 😕

So I would propose to port the changes I made for 2.8 with a new PR into 3.4. I think this might also solve the sorting issue fixed here as I used the "stable sort" approach that is also used elsewhere when sorting tagged services by priority.

I will prepare a new PR today and then@bendavies can you verify it also solves your sorting issue?

garf reacted with thumbs up emoji

@dmaicher
Copy link
Contributor

here is the new PR:#27133

@bendavies can you verify that your problems are also solved by it?

@nicolas-grekas
Copy link
Member

Closing in favor of#27133
Thank you@bendavies for raising the issue.

nicolas-grekas added a commit that referenced this pull requestMay 4, 2018
…s (dmaicher)This PR was merged into the 3.4 branch.Discussion----------[Doctrine Bridge] fix priority for doctrine event listeners| Q             | A| ------------- | ---| Branch?       | 3.4| Bug fix?      | yes| New feature?  | no| BC breaks?    | no| Deprecations? | no| Tests pass?   | yes| Fixed tickets |#21977| License       | MIT| Doc PR        | -As discussed in#27126 this ports changes from#22001 to 3.4 that were dropped when merging 2.8 into 3.2 here:dc66960#diff-27d2e9b071d766df504c3fe4131e7abfI took my original changeset from 2.8 and applied all commits since then on top of that.Commits-------b3ac938 [Doctrine Bridge] fix priority for doctrine event listeners
Sign up for freeto join this conversation on GitHub. Already have an account?Sign in to comment

Reviewers

@nicolas-grekasnicolas-grekasnicolas-grekas approved these changes

@stofstofstof approved these changes

+1 more reviewer

@ostroluckyostroluckyostrolucky requested changes

Reviewers whose approvals may not affect merge requirements

Assignees

No one assigned

Projects

None yet

Milestone

3.4

Development

Successfully merging this pull request may close these issues.

6 participants

@bendavies@dmaicher@nicolas-grekas@stof@ostrolucky@carsonbot

[8]ページ先頭

©2009-2025 Movatter.jp