Zend Db

[Simon Paulger]

Hi,

I have started integrating some db work with ZF2 Zend Db. I am using the Mysqli driver and have found a defect within php/mysql in which it causes the php environment to crash. Details are available here: https://bugs.php.net/bug.php?id=47928 on the bug report but basically, you can't use certain field types. I am using a longtext, which causes this crash. The php bug has been closed as not a bug with php, yet I am running MySQL 5.5, which is much higher than the version in the bug report and I would have thought this would have been resolved if it is a bug in MySQL. I am using php 5.3.11 on the web server and 5.3.3 in Zend Studio. Both have this issue when performing the query.

Has anyone had any success using a longtext field with mysqli in ZF2? Should ZF2 be updated to support/work around this issue?

I've also found a bug in the Adapter class. The query method validates the $parametersOrQueryMode parameter, throwing an exception if you pass a ParameterContainer. Yet the exception message states that the parameter is not of an appropriate type, one of which is ParameterContainer. I am assuming that either the exception message is wrong, or the object type should be permitted.

Regards,

Simon

[ralphschindler]

Hey Simon,

> you can't use certain field types. I am using a longtext, which causes
> this crash. The php bug has been closed as not a bug with php, yet I am
> running MySQL 5.5, which is much higher than the version in the bug
> report and I would have thought this would have been resolved if it is a
> bug in MySQL. I am using php 5.3.11 on the web server and 5.3.3 in Zend
> Studio. Both have this issue when performing the query.
>
> Has anyone had any success using a longtext field with mysqli in ZF2?
> Should ZF2 be updated to support/work around this issue?

Have you tried the same code with the mysqlnd driver for Mysqli? I
suspect you won't see a crash as the crash you're seeing now is in the
libmysqlclient.so.

> I've also found a bug in the Adapter class. The query method validates
> the $parametersOrQueryMode parameter, throwing an exception if you pass
> a ParameterContainer. Yet the exception message states that the
> parameter is not of an appropriate type, one of which
> is ParameterContainer. I am assuming that either the exception message

I will look into this, I am working on Mysqli this week.

-ralph

[Simon Paulger]

Hi Ralph,

Thanks for the tip; using Mysqlnd worked. I was expecting to have to recompile php, but on my Fedora PC it was a convenient drop in replacement for the existing php-mysql rpm.

Now that I have this working, I have also found another scenario that you might consider a bug.

If I use the code:

$stmt = $dbadapter->createStatement('select ...');

$results = $stmt->execute();

if (count($results) > 0) {

  // do something

} else {

  // do something else

}

I have found that the number of rows within the Mysqli resource object wrapped by the resultsets & mysql result datasource classes doesn't get populated until after the first record is retrieved. As a result, the above code is always running into the else as count is always null.

Thanks for your help

Regards,

Simon

On 15 May 2012 15:55, Ralph Schindler <[hidden email]> wrote:

Hey Simon,

you can't use certain field types. I am using a longtext, which causes
this crash. The php bug has been closed as not a bug with php, yet I am
running MySQL 5.5, which is much higher than the version in the bug
report and I would have thought this would have been resolved if it is a
bug in MySQL. I am using php 5.3.11 on the web server and 5.3.3 in Zend
Studio. Both have this issue when performing the query.

Has anyone had any success using a longtext field with mysqli in ZF2?
Should ZF2 be updated to support/work around this issue?

Have you tried the same code with the mysqlnd driver for Mysqli? I suspect you won't see a crash as the crash you're seeing now is in the libmysqlclient.so.

I've also found a bug in the Adapter class. The query method validates
the $parametersOrQueryMode parameter, throwing an exception if you pass
a ParameterContainer. Yet the exception message states that the
parameter is not of an appropriate type, one of which
is ParameterContainer. I am assuming that either the exception message

I will look into this, I am working on Mysqli this week.

-ralph

[ralphschindler]

Hey Simon,

> $stmt = $dbadapter->createStatement('select ...');
> $results = $stmt->execute();
>
> if (count($results) > 0) {
>    // do something
> } else {
>    // do something else
> }
>
>
> I have found that the number of rows within the Mysqli resource object
> wrapped by the resultsets & mysql result datasource classes doesn't get
> populated until after the first record is retrieved. As a result, the

Actually, the number of rows should always return 0, as by default
mysqli returns an unbuffered result set.

I have already implemented (in my branch) a buffer() method that can be
called before iteration of an unbuffered result set that will make it a
buffered result set.  This will then allow you to get the actual count
of rows at the cost of some memory.  This should be in master by end of
week.

-ralph

[Tomáš Fejfar]

Shouldn't the call be automatic upon calling of count()? It doesn't make any sense to me that it return 0. It should either issue an exception that you can't count unbuffered query or make it buffered. If you need the count (which is why you call the method) you'll have to make it buffered after all ;)

On Wed, May 16, 2012 at 4:01 PM, Ralph Schindler <[hidden email]> wrote:

Hey Simon,

$stmt = $dbadapter->createStatement('select ...');
$results = $stmt->execute();

if (count($results) > 0) {
  // do something
} else {
  // do something else
}


I have found that the number of rows within the Mysqli resource object
wrapped by the resultsets & mysql result datasource classes doesn't get
populated until after the first record is retrieved. As a result, the

Actually, the number of rows should always return 0, as by default mysqli returns an unbuffered result set.

I have already implemented (in my branch) a buffer() method that can be called before iteration of an unbuffered result set that will make it a buffered result set.  This will then allow you to get the actual count of rows at the cost of some memory.  This should be in master by end of week.

-ralph

[ralphschindler]

Hey guys,

That's not what I meant, sorry - I can be more clear:

> Shouldn't the call be automatic upon calling of count()? It doesn't make

count() calls ->num_rows of mysqli which should always return 0 for
unbuffered results; not that count() should return 0.

> any sense to me that it return 0. It should either issue an exception
> that you can't count unbuffered query or make it buffered. If you need

In the case where you're using an unbuffered statement result, you'll
get an exception.  This will indicate that the developer now needs to
make a decision: to buffer, or not.

buffer() is now part of the ResultInterface, so you can call it on any
result (abstractly, after all for most results, it will have no effect).

> the count (which is why you call the method) you'll have to make it
> buffered after all ;)

Right, but the idea is that it should be opt-in.  The great win for
mysqli is that by default it gives you unbuffered result sets which,
IMO, is one of the only reasons to use it over PDO, particularly in
cases where large result sets, and memory are top concerns.

-ralph