In #3548971: Replace PHP soft-deprecated __sleep()/__wakeup() with __serialize()/__unserialize() we're replacing some (soft) deprecated magic methods.
Instead of updating / replacing Query::__wakeup() and ::__sleep() we should deprecate and remove them.
public function __wakeup(): void {
$this->connection = Database::getConnection($this->connectionTarget, $this->connectionKey);
}
This reattaches an unserialized query to whatever connection currently exists, and there's no guarantee that's going to work / make sense.
It's inconsistent with Connection, which already refuses serialization (see \Drupal\Core\Database\Connection::__sleep), and with PDO, which does not support it.
This would effectively finish off #2463321: Serializing the database connection is dangerous and error-prone, make it unserializable again.
Issue fork drupal-3625895
Show commands
Start within a Git clone of the project using the version control instructions.
Or, if you do not have SSH keys set up on git.drupalcode.org:
- 3625895-11.x-deprecation
changes, plain diff MR !17239
- 3625895-deprecate-and-remove
changes, plain diff MR !17240
Comments
Comment #2
mcdruid commentedComment #5
mcdruid commentedIf these land, we should update #3548971: Replace PHP soft-deprecated __sleep()/__wakeup() with __serialize()/__unserialize().
The test suite seems to confirm that nothing in core does the roundtrip except for the one test that specifically does only that.
Comment #6
mcdruid commentedJust noting that I should have named the branches more carefully:
Comment #7
longwaveThis looks good to me. Serializing a query object makes no sense and as the deprecation/removal proves nothing is using this in core anyway.
Comment #8
jesus_md commentedReviewed https://git.drupalcode.org/project/drupal/-/merge_requests/17239 on 11.4.5 with PHP 8.5.5, and the deprecation looks right to me
Comment #9
ghost of drupal pastQuestion: do magic methods need the deprecation dance? You shouldn't call anything with an underscore anyways and doubleplus shouldn't call a magic method ever.
This shouldn't hold up sending this in, if it's controversial a followup could do the removal already in 11 if such consensus can be reached but I don't think it should be controversial.
I would love if I didn't need to deal with query serializing.
Comment #10
mcdruid commentedI think it makes sense to do the deprecation in case anyone is relying on this in contrib or custom code.
I won't miss this when it's gone though :)
Comment #11
mondrakeI'm afraid the 11.5+12 window is over, drats. Isn't this 12.1+13 material now.
Comment #12
catchI think as security hardening we should get this in during the beta, we're very likely to release a beta2 anyway.
Comment #17
catchOn #9 I would be more tempted to try to do the hard break if it was three months ago at the beginning of the 11.5.x cycle, this close to beta (technically after the window closed) I think people might be more reasonably annoyed if we break something, and also it would require more thought and messaging etc. so committed/pushed to main/12.0.x/11.x/11.5.x with the deprecation version in 11.x
I do think we should do the hard break in 12.0.0 so that this is gone as soon as possible.
Comment #19
ghost of drupal pastThanks for the thoughtful release managing.