Remove session from factorydefault or start it when creating instance

[Jurigag]

Right now having session service in Phalcon\Di\FactoryDefault is pointless, because you need to start session instance anyway to make it working properly. So you need to have code like this anyway:

$di->setShared('session', function() {
    $session= new Phalcon\Session\Adapter\Files();
    $session->start(); // this is required pretty much to make session things working properly, including persistent
    return $session
});

If you don't have this and you are using just session from FactoryDefault then it won't work properly because it's not started until you will start it by accessing this service and executing start method. Like value after doing $session->set() will be not available right now when using session from FactoryDefault in other request.

Or we could change it to just start session on instance construction.

This is somehow related issue - #12918

[sergeyklay]

Actually, as you can see, we just use "connect" approach in many adapters if they does not connected yet. So what do you think about check session status? IMO we can remove session from factory default in 4.x branch only.

[Jurigag]

To make it working and as a bugfix for now for phalcon 3 - fine. But in phalcon 4 to avoid overhead better just remove it from factory default.

[sergeyklay]

Cc: @phalcon/framework-team

[Jurigag]

Also i would consider thinking about for example memcache adapters and other - do we really need to do

let memcache = this->_memcache;

if typeof memcache != "object" {
	this->_connect();
	let memcache = this->_memcache;
}

In every single method? Why just not call _connect one time in __construct?

[sergeyklay]

Refs: #10530

[niden]

Removing it from 4.x is the best option.

[Jurigag]

@dschissler well i think you can have calls like call method also when setting service in di in some other syntax right? So loading from some format is good idea. Im just talking about session service, not other things - that right now, current one in FactoryDefault is useless - because you need to START session anyway, and to start it you need to call session method yourself, so most people will just set session service themself or you could get existing one from FactoryDefault and just call start method. Other idea is to just start session after creating class.

[micheleangioni]

Hi,
IMHO after almost 2 months the Phalcon Team should take a decision, not leaving this issue open since it's quite important.

Is this the expected behavior, which will cause breaking a lot of Phalcon projects upon updating to 3.2 without BC notice in documentation, or Phalcon should start a session by itself on instance construction?

I would prefer the second option, with Phalcon starting a session on instance construction, however let's just take a decision and fix or close this issue :)

Thanks! :)

[micheleangioni]

Really? So an issue introduced in 3.2 will be fixed in 4.0? That's at least weird, it should be fixed in 3.2.x if the current behavior is not what it's intended to be.

[micheleangioni]

Semver has been broken introducing a BC from 3.1 to 3.2, which is forbidden by semver. IF we want to FIX this, 3.2.x should be used to revert the BC.
THEN, if we want to confirm the BC because we think it's needed (I would rather confirm the fix, i.e. starting a session on instance construction), it should be introduced in 4.0.

[micheleangioni]

See #12918 , I got the same fatal error as I updated Phalcon from 3.1 to 3.2 in a small side Project.
I agree with Jurigag's opinion (if you are not starting a PHP session then it's not good and it's ok that an error arises), but still we have a BC since there was no error in 3.1. The proposed solution (starting a session on instance construction) seems to me to be the best thing to do in 3.2.x to fix the BC.

About 4.0 we should think whether remove the session start on instance construction. IMHO, I would leave that also in 4.0.

[virgofx]

Vote for pure removal in Phalcon v4

[Jurigag]

@micheleangioni well actually it wasn't due to 3.1 > 3.2 really, it was change in zephir which is causing this error. Right now zephie checks if certain superglobal exists, and if not you have error like this. I think it's better to remove session service in phalcon 4, first people will need to choose their adapter and second they will need to actually start it.

[micheleangioni]

@Jurigag ok, understood. It seems a honest approach.

[Jurigag]

@dschissler i think this idea with StatefulServiceInterface is cool, so any class impelemting when resolving service will start it. @sergeyklay

[niden]

Addressed