mysql_connect does not use a globally shared link

[dafuki]

mysql_connect does not use a globally shared link.
I needed to switch some sites to mysql_pconnect.
Is there a reason for mysql_conect to not create a global $link var?
This does not replicate the mysql_connect behavior of older php versions, was wondering if it is on purpose.

[kitserve]

No, this wasn't intentional. Good catch! If you're able to come up with a fix, that would be great. Otherwise I'll take a look when I get the chance - bit overloaded with other tasks at the moment.

[dafuki]

added a pull request

[dkloke]

Thank you for this useful and convenient library.

I used the following patch to mysql_connect to mimic the behavior of mysql_pconnect, which only sets the first new link to the global convenience link:

//		return mysqli_connect( $server, $user, $password );

		$link = mysqli_connect( $server, $user, $password );

		global $_php7_compat_global_db_link; // should be at beginning of proc
		if( !$_php7_compat_global_db_link ) $_php7_compat_global_db_link = $link;

		return $link;

[dafuki]

could you comment on why this works better than my fix? I'm curious

[dkloke]

I needed to add it to get some legacy code to work, I can't justify it beyond that. I just copied the current mysql_pconnect() behavior and that worked for my case.

I briefly pondered the $new_link problem but couldn't find an easy agnostic solution. As far as I can tell, mysqli_connect() returns a new $link->thread_id every time it's called, whereas mysql_connect() reuses similar resource id connections unless forced with $new_link.

I suppose one could hash $server, $user, and $password values in parallel with $_php7_compat_global_db_link to eliminate redundant connections, but this compromise security.

If the legacy code being made compatible is already managing multiple links explicitly, $_php7_compat_global_db_link should (?) be superfluous (but not unsafe) for those cases, because $_php7_compat_global_db_link only fills in for unspecified $link parameters.

I didn't initially see your proposed change here : dafuki@a5d94fa. I would say that new lines 67-71 aren't necessary because $link is never used before being changed, just keep old line 67.

It may be more similar to legacy PHP-Mysql behavior to unconditionally replace $_php7_compat_global_db_link every time a new connection is made, because PHP-Mysql uses the most recent connection for operations where $link is unspecified. This could forgive sloppy but otherwise working code.

&& !$new_link is correct but perhaps unforgiving of code that needlessly set $new_link to true for an otherwise single connection later used as implied default.

I have not written PHP in a long time and may be overthinking kindness to poor legacy code.

[dafuki]

I'm trying to make sure I'm getting you right (not feeling well atm), but if there is no use of new_link, it's probably not a perfect match for the legacy function.
We could try and see the actual code logic for the mysql_connect function in the C sources. Might fix the dilemma.
The code between 67-71 is to avoid creating a global variable when it is not needed. But I didn't get the chance to test the code, and still can't.
👍 for the comment

[kitserve]

I haven't forgotten about this issue, but unfortunately I've also not had time to fix it yet.

[kdkd]

I submitted pull request #7 just to get mysql_connect() working as well as mysql_pconnect() does, but I believe you're correct that the actual legacy mysql extension's behavior is slightly different. In my case it didn't matter though.

[kitserve]

Thanks for this fix. I'm leaving the issue open to remind myself to review it in more depth when (if?) I get the chance. For now the proposed changes sound like a good compromise if they allow most existing code to work without modification.