@Tobion done

@Tobion updated the UPGRADE-3.0.md file.

👍

ping @symfony/deciders

Can we in a way provide a smoother upgrade path (ie. by offering a deprecation message in Symfony 2.8)?

I agree. I think we should create a new class for this and deprecate the old class. We already messed this up in 2.6 with the newPdoSessionHandler and then had to add theLegacyPdoSessionHandler quickly after to help ease the upgrade path. That - like everything else we do - will give them at least on version where they can migrate from the old to the new. If we did that, this would be merged into 2.8, which again, is consistent with all our other features (no new features inonly 3.0).

I agree is would be nicer. But how would we name the new PdoSessionHandler? If the name sucks, we have to change the name again in 3.0 which will not make the upgrade easier.

@Tobion ha, so true - we don't want something likeTheNewPdoSessionHandler :).

And I'm really not sure - I think about this question a lot, but I don't know a good, global answer. How aboutPdoExpirySessionHandler in this case? I realize it's a slippery slope (would future changes make an ever-longer name?), but I don't think we can plan for that, and we need some way to introduce this improvement in 2.8 without the BC break.

Is there a necessity of removing thesess_time andsess_lifetime columns ? I don't think so.

Since thissess_expiry column needs to be added for performance reasons on "large production websites", it's a pity that we have to break session databases this way.

For a smoother migration path, I would create a feature flag to enable the extrasess_expiry column.
sess_time andsess_lifetime columns get always filled and you can still enable/disable the feature anytime and re-run the SQL query to populate thesess_expiry column.

IMO the only factible way to introduce this in 2.8 is the idea proposed by@GromNaN. What do you think? If all agree, i can make the necessary changes.

I think@GromNaN's idea would certainly work, though we'd need to have a lot of if statements inside the class to use different queries. But we could deprecate theold way and remove it in 3.0 (meaning only 1 version would need to have all these ugly if statements). But yea, I would like to fix this - other than the BC part, it sounds like a great win!

Ok, i will work on this.

@dosten you rock :)

I think the index on the expiry column is really necessary for high loads:#15020 (comment)

I'm not a database expert, if someone knows how to create an index in mysql, sqlite, pgsql, oci or sqlsrv.. help is welcome :)

@dosten the syntax is SQL standard :https://dev.mysql.com/doc/refman/5.0/en/create-index.html

CREATEINDEXidx_sess_expiryON session (sess_expiry);

Closing this because i'm going to create another PR over the 2.8 branch.

no news about this?