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

Remove Serializable implementations#41299

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
nicolas-grekas merged 1 commit intosymfony:6.0fromderrabus:remove/serializable
May 27, 2021

Conversation

@derrabus
Copy link
Member

QA
Branch?6.0
Bug fix?no
New feature?no
Deprecations?no
TicketsFix#41094
LicenseMIT
Doc PRN/A

nicolas-grekas and chalasr reacted with hooray emoji
@carsonbot
Copy link

Hey!

I think@fancyweb has recently worked with this code. Maybe they can help review this?

Cheers!

Carsonbot

@nicolas-grekas
Copy link
Member

SwitchUserToken has no unserializer

test failure look related

derrabus reacted with thumbs up emoji

@derrabus
Copy link
MemberAuthor

It is indeed.

The failing test checks if aSwitchUserToken that has been serialized with Symfony 4.4 and PHP 7.2 (I think) can still be unserialized. This does not work anymore because on PHP 7.2, theSerializable interface is used and if we remove that interface, PHP does not know how to unserialize the data. The test will fail again if we remove the deprecatedUser class because the serialized fixture uses it.

I think, the gap is too large here. I would not expect that I can jump from Symfony 4.4 and PHP 7.2 to Symfony 6.0 and PHP 8.0 directly and resume old sessions.

I would regenerate the fixture withInMemoryUser on Symfony 5.3 and PHP 8 and update the test accordingly. Would that be okay?

@derrabus
Copy link
MemberAuthor

🤔 Let's get that deprecated user out of that fixture first.#41385

@derrabus
Copy link
MemberAuthor

Now that the deprecated fixture is out of the way, I could regenerate the fixture on PHP 8. This way, an app could still jump from Symfony 4.4 to 6.0 directly, if PHP is not upgraded at the same time. I'm going to document this is the upgrade notes.

nicolas-grekas and chalasr reacted with thumbs up emoji

@nicolas-grekas
Copy link
Member

Route has no unserializer

one more :)

@derrabus
Copy link
MemberAuthor

one more :)

Fixed. I regenerated the fixture with Symfony 4.4 and PHP 8:

$newFixture =serialize(unserialize($oldFixture));

What is the use-case for serializing routes? I'd like to write an upgrade note here as well.

@nicolas-grekas
Copy link
Member

I think Drupal stores the routes in the DB.

@derrabus
Copy link
MemberAuthor

Oh, I see. In that case, Drupal needs to provide a way to migrate database tables storing serialized routes after a PHP upgrade (if that does not happen already), ideally before they release a version with Symfony 6 support. Is there someone we can contact about that?

@nicolas-grekas
Copy link
Member

/cc@alexpott

@nicolas-grekas
Copy link
Member

As discussed in#41094 (comment), we should keep the interface on implementations (not on interfaces), but they should be final and internal, and only unserialize() should have an implementation: serialize() should throw a BadMethodCall instead

@nicolas-grekas
Copy link
Member

Thank you@derrabus.

@nicolas-grekasnicolas-grekas merged commita2d1e80 intosymfony:6.0May 27, 2021
@derrabusderrabus deleted the remove/serializable branchMay 27, 2021 15:43
@derrabus
Copy link
MemberAuthor

Thank you for resuming my work. 🙂

@fabpotfabpot mentioned this pull requestNov 5, 2021
Sign up for freeto join this conversation on GitHub. Already have an account?Sign in to comment

Reviewers

@chalasrchalasrAwaiting requested review from chalasrchalasr is a code owner

@wouterjwouterjAwaiting requested review from wouterjwouterj is a code owner

@xabbuhxabbuhAwaiting requested review from xabbuhxabbuh is a code owner

@ycerutoycerutoAwaiting requested review from ycerutoyceruto is a code owner

Assignees

No one assigned

Projects

None yet

Milestone

6.0

Development

Successfully merging this pull request may close these issues.

3 participants

@derrabus@carsonbot@nicolas-grekas

[8]ページ先頭

©2009-2025 Movatter.jp