Add a default 0 value to the {sessions}.uid database column

I do not see any problems with applying this into code
Good preemptive patch for #335411: Switch to Symfony2-based session handling

Not wanting to hold this up or anything but why dont we truncate the sessions table here? Potentially we are looking at a ginormous amount of data being upgraded ... for no reason.

Edit: except the current session might be worth keeping but even that i would retrieve and save back manually and run truncate. truncate is fast. Or, even, we can just drop the table and recreate it with the new schema.

We should retain the session in current global $user. All others can be deleted, yes.

#6 sounds sane to me. Maybe we could think about keeping only "recently active" sessions, for some definition of recent, but for this update I think "current user only" is fine.

Here's why I thought saving session manually is important: I would be somewhat wary of just keeping session in global $user, it's an update if PHP times out or something you do not necessarily get your session writen and then ... yes, and then what :) ? Well, it's an update so what if the system is in a state where all you can do is rerun update.php and now you can't because you've been logged out. I know, I am paranoid, but the question is, am I paranoid enough :D ?

Yeah, this patch looks pretty straightforward to me.

Can we implement #6 before executing the schema update? I.e.:

global $user;
if ($user->uid) {
  db_delete('sessions')
    ->condition('uid', $user->uid, '<>')
    ->execute();
}

(could also filter by session ID, but not sure whether that makes any difference and whether it wouldn't potentially break HTTP/S sessions during the update and possibly other stuff)

I don't think we have to be paranoid about this update, since at the point the update function is executed, you're in a non-reversible system upgrade state anyway.

That said, depending on the new Symfony session system, we might have to execute this update in the early/special update_fix_whatever() helper functions already - although we could also possibly leave that adjustment to the actual session patch.

And then just a quick adjustment:

+++ b/modules/system/system.install
@@ -3016,6 +3017,20 @@ function system_update_7073() {
+ * Set the {sessions}.uid field default value to 0, making possible a schema
+ * change for the {sessions} table for future Drupal 8 migration.

Can we shorten this to this?

"Change the {sessions}.uid default value to 0."

#1: 1672804-1-session_uid_default_value.patch queued for re-testing.

Looks like this is needs work for the first part of #11.
(also might need rerolled, let's see.)

I don't think this is required anymore. The mentioned issue can relatively easily work around this by making the session changes before the session is bootstrapped, then this isn't a problem?

re-roll as per #14 included feedback from #11.

Lets see what @Berdir says.

postponed as per #16

@jibran, I see you posted a new patch http://drupal.org/node/1672804#comment-6947438 Thanks.
And also that the issue might not be needed anymore and is postponed. This looks good for now, no further work needed until it's unpostponed.

I have a question though, was it really re-rolled because the previous patch did not apply?

If it was, then making a commit locally, or a branch, and then making the changes after it was re-rolled would let you make an interdiff.

If it wasn't re-rolled, then there might be some confusion about what re-rolling means. It's usually: http://drupal.org/patch/reroll

And if a reroll was not needed, then an interdiff is even easier. See: http://drupal.org/node/1488712

For next time. :)

@YesCT as I mentioned above it is a re-roll and some feedback. It was so tiny patch I thought interdiff is not worth it. But thanks for the reminder I'll be careful next time :).

Updated topic with more details for people to understand.