Incorrect value returned by a queryFactory Execute method on MySQL UPDATE query

[kamiles]

In 1.5.3 queryFactory class has been modified. The problem is that Execute function returns a different value for a successful MySQL UPDATE query than it did in 1.5.1.

Let's take a look at the following piece of code:

Line 266-269 includes\classes\db\mysql\query_factory.php

      if (FALSE === $zp_db_resource){
        $obj = null;
        return true;
      }

Essentially variable $zp_db_resource stores mysqli_query function result. Quoting PHP manual "Returns FALSE on failure". Why is that function returning boolean true when the actual query execution failed?

For a comparison in 1.5.1 it looked like this:

Line 230-233 includes\classes\db\mysql\query_factory.php

      if(!is_resource($zp_db_resource)){
        $obj = null;
        return true;
      }

Here it is only checked whether $zp_db_resource is not a resource.

On a successful UPDATE query this function will return boolean true in 1.5.1. In 1.5.3 it won't. Instead it will return a queryFactory object:

Line 293 includes\classes\db\mysql\query_factory.php

      return($obj);

Is that how it is supposed to work or is that a bug?

[mc12345678]

So the answer about if this is how it is supposed to work is a little bit of a non-issue. The significant difference is that instead of providing a TRUE as a result of an UPDATE as well as a few other query types, now a successful query (or one that returns an error of 1141) will be included in the $obj as well as other information such as EOF... Upon return of the successful query an if test of the result (with no comparison) will result in action being taken as if true. If it is necessary to identify whether the actual value of the result (ie., if the value === TRUE or is some other response), then inspection of the returned $obj would be necessary.

Can't think of any suggested programming code that previously tested the response against being equal to true (== TRUE or === TRUE) as part of the comparison as examples within the ZC code tend to test against the result in different ways, ie isset() or RecordCount(), etc...

It is a slight difference in how the code as a whole operates; however, what problem(s) have been encountered with it?

Regarding the return as FALSE aspect of the mysql_query function, in both ZC 1.5.1 and 1.5.3, if the return value was FALSE and any error besides 1141 resulted, then the code would stop and an error log generated provided that the dieOnErrors variable within the class would provide a true result.. This happens just before the code snippets that were provided.

The only thing I see as an issue though is that function connect appears to set this value to a non-existent value.. Ie.,

    $this->dieOnErrors = $dieOnErrors;

Where $dieOnErrors is not provided to the function. There is also the fact that $zp_real in the call to the connect (I believe this was maintained for "compatibility"), but that variable is not used in the connect function...

So it appears if I understand the localized flow correctly that the set_errors function will not activate when the Execute command comes across an error unless the dieOnErrors variable is modified outside of the query_factory.php file which is set to true inside includes/init_includes/init_database.php after the connect to the database has been performed. (Not sure of the sequence of loading to identify that issue.)

[kamiles]

It is a slight difference in how the code as a whole operates; however, what problem(s) have been encountered with it?

That slight difference is the problem. I haven't found any info regarding that change. That's why I started this topic. A client reported a problem with one of the modules. It turns out that boolean TRUE (=== TRUE) comparison was used on an UPDATE query result. That obviously doesn't work on 1.5.3 causing some issues. You can imagine that this might be a problem when you have a bunch of different modules coded by the same person and dozens of clients using them. It's not only a matter of inspecting and fixing the code, but also updating these modules on client sites.

I'm still curious why has this change been made.