-
-
Notifications
You must be signed in to change notification settings - Fork 2.1k
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
Change all MasterRequest calls to MainRequest #13251
Conversation
src/Sylius/Bundle/ApiBundle/spec/Context/TokenValueBasedCartContextSpec.php
Show resolved
Hide resolved
src/Sylius/Bundle/ApiBundle/Context/TokenValueBasedCartContext.php
Outdated
Show resolved
Hide resolved
if (\method_exists($event, 'isMainRequest')) { | ||
$isMainRequest = $event->isMainRequest(); | ||
} else { | ||
$isMainRequest = $event->isMasterRequest(); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Maybe it would be good to add deprectation warnings to these clauses. Perhaps using:
https://github.com/symfony/deprecation-contracts/blob/main/function.php
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What do you mean ? The idea here is just to have a version that will work on both Symfony 4.x and 5.3+ without deprecation warning. Then when dropping <5.3 support, only the mainRequest
part will stay.
But I don't see the point in throwing deprecation notice when the goal is to hide them
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Deprecation warnings are intended on classes or methods, not inside methods. Also it's well known1 that the hundreds of deprecations being thrown these days because of this master => main
rename is slowing down performance so please don't add one more :(
Footnotes
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Alright, well the point is to have some sort of pointer that this needs to be removed at some point, in the current situation it is not documented and will continue to work forever. Maybe it's an idea to add a comment or something then?
This may be a wild idea, but there is a lot of duplication of this logic now, perhaps introduce a separate class for this?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I also thought of a separate class, like RequestProvider
or something. Because the logic is often the same, but with some small differences. But it seems way too much for this.
But I agree with you that we need to store somewhere to get rid of this once we only support 5.3+
Perhaps in some .md file ?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
So you're suggesting to merge the current state first and then have it refactored into the new component in a different PR? Why exactly?
If it's too much work, perhaps I could lend a helping hand. 💪
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes, that would be my proposition.
First of all, because creating a new component seems more than just one folder. Sylius is hosting them as separate packages.
Second thing would be that right now, this PR is really easy to read/understand. And I have the small hope that this way, it will get approved/merged before next release 😄
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Valid points, unfortunately.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hey folks, thanks for contribution and discussion about it. Sample trait could be created behind the https://github.com/SyliusLabs umbrella, but it may be too much. The problem is, that 1.11 branch has been already split. I'm not sure, it will land in Sylius v1.11.X series.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think, we can add note to: #13274 or separate issue, as Youri mentioned
I was almost sure this was already merged... Edit: I also triggered a re-run of all checks, because one failed with a segmentation fault. |
Yeah, me too 🤔 IDK what happened |
Looks like it didn't re-run the jobs... |
501e8b0
to
4869756
Compare
So in the end there is no mention of having to remove the Could be a github issue or PR as well as far as I'm concerned. |
I'm ok to write it somewhere, but I can't find any md file that would fit. Perhaps an issue is the way to go 🤔 |
if (\method_exists($event, 'isMainRequest')) { | ||
$isMainRequest = $event->isMainRequest(); | ||
} else { | ||
$isMainRequest = $event->isMasterRequest(); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hey folks, thanks for contribution and discussion about it. Sample trait could be created behind the https://github.com/SyliusLabs umbrella, but it may be too much. The problem is, that 1.11 branch has been already split. I'm not sure, it will land in Sylius v1.11.X series.
src/Sylius/Bundle/AdminBundle/EventListener/ResourceDeleteSubscriber.php
Show resolved
Hide resolved
if (\method_exists($event, 'isMainRequest')) { | ||
$isMainRequest = $event->isMainRequest(); | ||
} else { | ||
$isMainRequest = $event->isMasterRequest(); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think, we can add note to: #13274 or separate issue, as Youri mentioned
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I meant, that we should place this comment above all occurrence of this ACL ifs. But thats a minor stuff. The plan will be as follows:
- Merge it to 1.11, to get rid of deprecation message
- Bump Symfony requirements to Sf ^5.4 on master
- Remove this ACL from the master
At the end, trait would live with us too short, to consider it as separate package in my opinion.
src/Sylius/Bundle/ApiBundle/spec/Context/TokenValueBasedCartContextSpec.php
Show resolved
Hide resolved
src/Sylius/Bundle/ApiBundle/spec/Context/TokenValueBasedCartContextSpec.php
Show resolved
Hide resolved
src/Sylius/Bundle/ApiBundle/spec/Context/TokenValueBasedCartContextSpec.php
Show resolved
Hide resolved
src/Sylius/Bundle/ApiBundle/spec/Context/TokenValueBasedCartContextSpec.php
Show resolved
Hide resolved
src/Sylius/Component/Channel/spec/Context/CachedPerRequestChannelContextSpec.php
Show resolved
Hide resolved
src/Sylius/Component/Channel/spec/Context/CachedPerRequestChannelContextSpec.php
Show resolved
Hide resolved
src/Sylius/Component/Channel/spec/Context/RequestBased/ChannelContextSpec.php
Show resolved
Hide resolved
src/Sylius/Component/Channel/spec/Context/RequestBased/ChannelContextSpec.php
Show resolved
Hide resolved
src/Sylius/Component/Channel/spec/Context/RequestBased/ChannelContextSpec.php
Show resolved
Hide resolved
The base of this pull-request was changed, you need fetch and reset your local branch Unless you added new commits (to this branch) locally that you did not push yet, Feel free to ask for assistance when you get stuck 👍 |
8bc849a
to
1113fa8
Compare
1113fa8
to
4869756
Compare
4869756
to
9354609
Compare
9354609
to
f78ef8b
Compare
Thanks, Stephane! 🥇 |
For now, it should accept both until Symfony <5.3 support is dropped