Skip to content
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

Drop more usages of Serializable #30286

Merged
merged 1 commit into from Mar 4, 2019

Conversation

Projects
None yet
7 participants
@nicolas-grekas
Copy link
Member

commented Feb 18, 2019

Q A
Branch? master
Bug fix? no
New feature? no
BC breaks? no
Deprecations? yes
Tests pass? yes
Fixed tickets -
License MIT
Doc PR -

When the serialized payload of some class is used for ephemeral needs, my proposal here is to drop implementing Serializable and provide a deprecation layer based on __sleep to still call the serialize/unserialize methods. This means that at the behavior level, we provide BC, and at the payload level, we don't.

That leaves us with only two "not ephemeral" use cases:

  • Route and CompilerRoute instances are serialized by Drupal. We'd better not break such existing payloads without being sure it's ok for Drupal (ping @alexpott). My proposal in this PR is to schedule the BC break for Symfony 5, and ask Drupal (and others) to add a check in their unserialization logic so that they are able to recompile the cached list of routes if unserialize fails due to this change. They could alternatively implement Serializable on their own, without calling parent::(un)serialize().
  • TokenInterface from Security - for this one, I have no idea yet, except either plan for breaking BC at the payload level (which would mean invalidating all sessions when moving to SF5) - or create a new interface if we think breaking sessions is not reasonable. For now, I've kept using Serializable, which could be also fine keeping if we mark the corresponding method final to force

WDYT?

@OskarStark

This comment has been minimized.

Copy link
Contributor

commented Feb 18, 2019

Typo:
This leaves us WITH....

@nicolas-grekas nicolas-grekas force-pushed the nicolas-grekas:drop-more-serializable branch from ec32e2d to 6162229 Feb 18, 2019

@alexpott

This comment has been minimized.

Copy link
Contributor

commented Feb 19, 2019

Drupal extends CompilerRoute and overrides both ::serialize and ::unserialize. We can rebuild our router so the change to the payload should be okay.

@nicolas-grekas

This comment has been minimized.

Copy link
Member Author

commented Feb 19, 2019

@alexpott thanks, then the plan for Drupal should be to stop calling parent::serialize()/unserialize() asap and explicitly declare implements \Serializable. Then you'd preserve full forward and backward compat.

Show resolved Hide resolved UPGRADE-5.0.md Outdated

@nicolas-grekas nicolas-grekas force-pushed the nicolas-grekas:drop-more-serializable branch 3 times, most recently from 37674f1 to 66b50bf Feb 20, 2019

@fabpot
Copy link
Member

left a comment

I would remove the possibility to serialize a Kernel as I don't see (anymore) the use cases.

@nicolas-grekas nicolas-grekas force-pushed the nicolas-grekas:drop-more-serializable branch 3 times, most recently from 966d44a to 856ae9f Feb 21, 2019

@nicolas-grekas

This comment has been minimized.

Copy link
Member Author

commented Feb 23, 2019

I would remove the possibility to serialize a Kernel as I don't see (anymore) the use cases.

Actually, that's not possible: the kernel is serialized in FrameworkBundle for insulated tests, see

$kernel = var_export(serialize($this->kernel), true);

@fabpot

fabpot approved these changes Mar 4, 2019

@nicolas-grekas nicolas-grekas force-pushed the nicolas-grekas:drop-more-serializable branch from 856ae9f to 05d6475 Mar 4, 2019

@fabpot

This comment has been minimized.

Copy link
Member

commented Mar 4, 2019

Thank you @nicolas-grekas.

@fabpot fabpot merged commit 05d6475 into symfony:master Mar 4, 2019

2 of 3 checks passed

continuous-integration/travis-ci/pr The Travis CI build is in progress
Details
continuous-integration/appveyor/pr AppVeyor build succeeded
Details
fabbot.io Your code looks good.
Details

fabpot added a commit that referenced this pull request Mar 4, 2019

feature #30286 Drop more usages of Serializable (nicolas-grekas)
This PR was merged into the 4.3-dev branch.

Discussion
----------

Drop more usages of Serializable

| Q             | A
| ------------- | ---
| Branch?       | master
| Bug fix?      | no
| New feature?  | no
| BC breaks?    | no
| Deprecations? | yes
| Tests pass?   | yes
| Fixed tickets | -
| License       | MIT
| Doc PR        | -

When the serialized payload of some class is used for ephemeral needs, my proposal here is to drop implementing `Serializable` and provide a deprecation layer based on `__sleep` to still call the `serialize`/`unserialize` methods. This means that at the behavior level, we provide BC, and at the payload level, we don't.

That leaves us with only two "not ephemeral" use cases:
- `Route` and `CompilerRoute` instances are serialized by Drupal. We'd better not break such existing payloads without being sure it's ok for Drupal (ping @alexpott). My proposal in this PR is to schedule the BC break for Symfony 5, and ask Drupal (and others) to add a check in their unserialization logic so that they are able to recompile the cached list of routes if unserialize fails due to this change. They could alternatively implement `Serializable` on their own, without calling `parent::(un)serialize()`.
- `TokenInterface` from `Security` - for this one, I have no idea yet, except either plan for breaking BC at the payload level (which would mean invalidating all sessions when moving to SF5) - or create a new interface if we think breaking sessions is not reasonable. For now, I've kept using `Serializable`, which could be also fine keeping if we mark the corresponding method `final` to force

WDYT?

Commits
-------

05d6475 Drop more usages of Serializable

@nicolas-grekas nicolas-grekas deleted the nicolas-grekas:drop-more-serializable branch Mar 4, 2019

@nicolas-grekas nicolas-grekas modified the milestones: next, 4.3 Apr 30, 2019

@fabpot fabpot referenced this pull request May 9, 2019

Merged

Release v4.3.0-BETA1 #31435

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.