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

Making the serializer configurable by transport#30628

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

Merged

Conversation

@weaverryan
Copy link
Member

@weaverryanweaverryan commentedMar 21, 2019
edited by sroze
Loading

QA
Branch?master
Bug fix?no
New feature?yes
BC breaks?yes
Deprecations?no
Tests pass?yes
Fixed tickets#30293 (already closed, but I don't think this was reasonably possible before)
LicenseMIT
Doc PRTODO - as many of the new messenger PRs will be done at once

Use cases:

  • Messenger - Use different Serializer #30293
  • Transport A will be consumed by your Symfony app (so native php serialization is cool) but transport B will be consumed by another app, so you want to serialize as JSON
  • Upgrading from Symfony 4.2 to 4.3. The change to thePhpSerialize means that messages that were sent to the queue on 4.2, will fail on 4.3. The solution is to use the old serializer in your config. This would allow you to make your existing transport use the old serializer, then migrate to a new transport using the new serializer (then remove the old one later).

Thanks!

Koc and bigfoot90 reacted with hooray emoji
@weaverryanweaverryanforce-pushed themessenger-serializer-by-transport branch 2 times, most recently frome7ae82e to79425a3CompareMarch 21, 2019 15:45
@weaverryan
Copy link
MemberAuthor

Ready to go again

Status: Needs review

@weaverryan
Copy link
MemberAuthor

Rebased and ready!

@weaverryanweaverryanforce-pushed themessenger-serializer-by-transport branch from44c9e38 to7b66e39CompareMarch 31, 2019 14:50
@fabpotfabpotforce-pushed themessenger-serializer-by-transport branch from7b66e39 toef6f23eCompareMarch 31, 2019 14:54
@fabpot
Copy link
Member

Thank you@weaverryan.

@fabpotfabpot merged commitef6f23e intosymfony:masterMar 31, 2019
fabpot added a commit that referenced this pull requestMar 31, 2019
…rryan)This PR was merged into the 4.3-dev branch.Discussion----------Making the serializer configurable by transport| Q             | A| ------------- | ---| Branch?       | master| Bug fix?      | no| New feature?  | yes| BC breaks?    | yes| Deprecations? | no| Tests pass?   | yes| Fixed tickets |#30293 (already closed, but I don't think this was reasonably possible before)| License       | MIT| Doc PR        | TODO - as many of the new messenger PRs will be done at onceUse cases:*#30293* Transport A will be consumed by your Symfony app (so native php serialization is cool) but transport B will be consumed by another app, so you want to serialize as JSON* Upgrading from Symfony 4.2 to 4.3. The change to the `PhpSerialize` means that messages that were sent to the queue on 4.2, will fail on 4.3. The solution is to use the old serializer in your config. This would allow you to make your existing transport use the old serializer, then migrate to a new transport using the new serializer (then remove the old one later).Thanks!Commits-------ef6f23e Making the serializer configurable by transport
@weaverryanweaverryan deleted the messenger-serializer-by-transport branchMarch 31, 2019 15:33
@nicolas-grekasnicolas-grekas modified the milestones:next,4.3Apr 30, 2019
@fabpotfabpot mentioned this pull requestMay 9, 2019
Sign up for freeto join this conversation on GitHub. Already have an account?Sign in to comment

Reviewers

@fabpotfabpotfabpot approved these changes

+2 more reviewers

@ogizanagiogizanagiogizanagi left review comments

@srozesrozesroze approved these changes

Reviewers whose approvals may not affect merge requirements

Assignees

No one assigned

Projects

None yet

Milestone

4.3

Development

Successfully merging this pull request may close these issues.

6 participants

@weaverryan@fabpot@sroze@ogizanagi@nicolas-grekas@carsonbot

[8]ページ先頭

©2009-2025 Movatter.jp