Remove Serializable implementations #41299
Conversation
| Q | A |
|---|---|
| Branch? | 6.0 |
| Bug fix? | no |
| New feature? | no |
| Deprecations? | no |
| Tickets | Fix #41094 |
| License | MIT |
| Doc PR | N/A |
|
Hey! I think @fancyweb has recently worked with this code. Maybe they can help review this? Cheers! Carsonbot |
0ea5767 to
b3fb841
Compare
test failure look related |
b3fb841 to
ddf1d73
Compare
|
It is indeed. The failing test checks if a 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 with |
ddf1d73 to
02d9820
Compare
|
🤔 Let's get that deprecated user out of that fixture first. #41385 |
|
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. |
02d9820 to
e1b93d6
Compare
one more :) |
e1b93d6 to
d6b8605
Compare
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. |
|
I think Drupal stores the routes in the DB. |
|
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? |
|
/cc @alexpott |
|
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 |
d6b8605 to
3396915
Compare
|
Thank you @derrabus. |
|
Thank you for resuming my work. 🙂 |