Mysqli extension to make your life easier (feedback request)

I recently updated my EMysqli package on Github to offer better functionality. The premise of the package is to output a version of a parameterized query with the bound arguments injected into the query string which will facilitate easier debugging, logging, etc.

I created this project in response to a request I received on it’s sister project (E_PDOStatement), which provides the same functionality for the PDO extension.

Feedback Request

I don’t have any production quality code for working using the mysqli extension though (all of my work uses PDO), so it’s hard for me to come up with any actual, relevant situations to test my extension. Any feedback you can give will be greatly appreciated.

Thanks!

2 Likes

i only had a slight look on it, but for beeing a debugging tool, i would prefer to somehow have a separate function that calculates this on demand, so this is not run everytime in production mode.

1 Like

On the first glance it looks good.

As a feedback for both wrappers I would suggest to add support for NULL values. Your current implementation will make empty strings out of NULL values while both APIs will keep them NULL in the query. I created pull requests for this improvement.

For the PDO branch there is an edge case when the interpolated query could fail where original query runs flawless. For example,

$conn->setAttribute( PDO::ATTR_EMULATE_PREPARES, false );
$stmt = $pdo->prepare('SELECT * FROM table LIMIT ?, ?');
$stmt->execute([0, 10]);

this code snippet would work while interpolated query will fail.I cannot think of the immediate solution that is not ugly though.

I’m not sure I understand this. The package does have the ability to generate the query string without executing the query against the database (via the interpolateQuery method). Is this what you were referring to?

Thanks so much for your pull request. I’ve merged it in. That was definitely not a situation I had thought about.

I’ve come across the LIMIT situation in our production environment in the past, but I’m not sure the best way to go about handling this. I have thought of a few options:

  • Trying to add contextual awareness to the replacement, e.g. looking for a LIMIT clause immediately preceding the placeholder (or a comma, then an integer, then a LIMIT immediately preceding the placeholder for the second value)
  • Removing the quotes if the value resolves to an integer

Both of these options seem ugly and hacky at best, or unreliable and buggy at worst. If you come up with any input, I’m happy to hear it.

Thanks again for your input! This is why I love open source!

This topic was automatically closed 91 days after the last reply. New replies are no longer allowed.