kitserve / php7-compat

Wrapper functions around the deprecated `mysql_*` and `ereg*` functions for use in PHP 7
Apache License 2.0
9 stars 2 forks source link

mysql_connect does not use a globally shared link #4

Open dafuki opened 3 years ago

dafuki commented 3 years ago

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 commented 3 years ago

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 commented 3 years ago

added a pull request

dkloke commented 3 years ago

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 commented 3 years ago

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

dkloke commented 3 years ago

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 : https://github.com/dafuki/php7-compat/commit/a5d94faa1ae986150a7ca601a8d8f97dee8eb5f0. 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 commented 3 years ago

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 commented 2 years ago

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

kdkd commented 2 years ago

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 commented 2 years ago

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.