Splitting this bit off from #721436: Remove magical fairy saving of cruft from user_save(). In user_save(), when saving a new user, we do a user_load() only to get information we already know. This cuts 300 off the 1,300 database hits I'm seeing when using devel generated to create 100 users.
Patch is entirely by Moshe, this is just a re-roll. If the tests all pass then it should be RTBC.
| Comment | File | Size | Author |
|---|---|---|---|
| #14 | user-data.patch | 816 bytes | mfb |
| #11 | bogus_user_loads.patch | 1.64 KB | catch |
| #8 | bogus_user_loads.patch | 1.09 KB | catch |
| #3 | bogus_user_loads.patch | 1.09 KB | catch |
| user_save.patch | 888 bytes | catch |
Comments
Comment #1
moshe weitzman commentedtake your pick. catch and i split patch author and reviewer roles on this.
Comment #2
moshe weitzman commentedComment #3
catchI opened a separate issue for #745702: Remove duff user_load() when new users are created but turns out the test failures there disappear when these patches are combined. So here's both together - all the failing tests pass locally for me.
Comment #4
moshe weitzman commentedWell that works out nicely. RTBC.
Comment #5
mikeryanDitto - in my performance testing, this slims down user_save() to the point where the heavy hitter time-wise is the db_next_id() call.
Comment #6
catch#3: bogus_user_loads.patch queued for re-testing.
Comment #8
catchRe-rolled.
Comment #9
moshe weitzman commentedComment #11
catchFixing test failures, which also happens to fix chx's complaint with the user->data patch.
Comment #12
moshe weitzman commentedComment #13
dries commentedCommitted to CVS HEAD. Thanks.
Comment #14
mfbThis is broken: Now there is nothing to unserialize user->data so it gets more and more serialized each time you save a profile category page.
If we don't unserialize $user->data here when the user is being saved, then we need to unserialize it earlier, like when the user is being loaded.
Although maybe there should be something in the base entity controller to automatically unserialize any serialized schema fields on load?
Comment #15
mfbMight as well see if this passes tests. Although this is pretty lame, $user->data ends up getting unserialized twice in a row by drupal_unpack() and unserialize()
Comment #16
catchMoving this back to fixed, dealt with in #721436: Remove magical fairy saving of cruft from user_save().
Comment #17
catch