Failure: test_find_by_datetime

[al-the-x]

Per Travis build 35:

1) ActiveRecordFindTest::test_find_by_datetime
Failed asserting that null is not null.

[Rican7]

This seems to be a Travis issue, as my local test environment shows this test as passing.
Any insight, @al-the-x ?

[al-the-x]

Are you testing against all the database types? From the Travis run, it's not clear where the error is occurring... Might be one of those date formatting bugs reported for SQLite or MySQL that's causing the problems.

[Rican7]

Yea, here's my testing env:

PHP Version => 5.4.14

PDO

PDO support => enabled
PDO drivers => mysql, pgsql, sqlite

pdo_mysql

PDO Driver for MySQL => enabled
Client API version => 5.5.30

Directive => Local Value => Master Value
pdo_mysql.default_socket => /var/lib/mysql/mysql.sock => /var/lib/mysql/mysql.sock

pdo_pgsql

PDO Driver for PostgreSQL => enabled
PostgreSQL(libpq) Version => 8.4.13
Module version => 1.0.2
Revision =>  $Id$

pdo_sqlite

PDO Driver for SQLite 3.x => enabled
SQLite Library => 3.6.20

$ mysql --version
mysql  Ver 14.14 Distrib 5.5.30, for Linux (x86_64) using readline 5.1

$ postgres --version
postgres (PostgreSQL) 8.4.13

[koenpunt]

Same here:

$ php --version
PHP 5.4.14-1~precise+1 (cli) (built: Apr 11 2013 17:09:50)
Copyright (c) 1997-2013 The PHP Group
Zend Engine v2.4.0, Copyright (c) 1998-2013 Zend Technologies
    with Xdebug v2.2.1, Copyright (c) 2002-2012, by Derick Rethans

$ php -i | grep -i PDO
Additional .ini files parsed => /etc/php5/cli/conf.d/10-pdo.ini,
/etc/php5/cli/conf.d/20-pdo_mysql.ini,
/etc/php5/cli/conf.d/20-pdo_pgsql.ini,
/etc/php5/cli/conf.d/20-pdo_sqlite.ini,
PDO
PDO support => enabled
PDO drivers => mysql, pgsql, sqlite
pdo_mysql
PDO Driver for MySQL => enabled
pdo_mysql.default_socket => /var/run/mysqld/mysqld.sock => /var/run/mysqld/mysqld.sock
pdo_pgsql
PDO Driver for PostgreSQL => enabled
pdo_sqlite
PDO Driver for SQLite 3.x => enabled

$ mysql --version
mysql  Ver 14.14 Distrib 5.5.29, for debian-linux-gnu (x86_64) using readline 6.2

$ psql --version
psql (PostgreSQL) 9.2.2

$ phpunit -c phpunit.xml test/
(Logging SQL queries disabled, PEAR::Log not found.)
PHPUnit 3.7.19 by Sebastian Bergmann.

Configuration read from /private/shares/projects/php-activerecord/phpunit.xml

...............................................................  63 / 734 (  8%)
............................................................... 126 / 734 ( 17%)
............................................................... 189 / 734 ( 25%)
............................................................... 252 / 734 ( 34%)
............................................................... 315 / 734 ( 42%)
...............................................SSSSSSSSSSSSSSSS 378 / 734 ( 51%)
SSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSS.............................. 441 / 734 ( 60%)
............................................................... 504 / 734 ( 68%)
............................................................... 567 / 734 ( 77%)
............................................................... 630 / 734 ( 85%)
............................................................... 693 / 734 ( 94%)
.........................................

Time: 45 seconds, Memory: 24.00Mb

OK, but incomplete or skipped tests!
Tests: 734, Assertions: 1324, Skipped: 49.

[al-the-x]

Hmm, I wonder if PHP is configured properly with the timezone on Travis...? I bet everyone else in here has set date.timezeone in php.ini like me...?

[Rican7]

@al-the-x Ah! That sounds like what it is!
Yea, I have mine set. It must not be correctly set on Travis.
How do we get access to change that? Or can you?

[al-the-x]

Let's get some context for discussion:

1) ActiveRecordFindTest::test_find_by_datetime
Failed asserting that null is not null.
/home/travis/build/kla/php-activerecord/test/helpers/SnakeCase_PHPUnit_Framework_TestCase.php:9
/home/travis/build/kla/php-activerecord/test/ActiveRecordFindTest.php:459
/home/travis/build/kla/php-activerecord/test/ActiveRecordFindTest.php:459

        // ActiveRecordFindTest.php:452-461
    public function test_find_by_datetime()
    {
        $now = new DateTime();
        $arnow = new ActiveRecord\DateTime();
        $arnow->setTimestamp($now->getTimestamp());

        Author::find(1)->update_attribute('created_at',$now);
        $this->assert_not_null(Author::find_by_created_at($now));
        $this->assert_not_null(Author::find_by_created_at($arnow));
    }

Failure is at 459:

        $this->assert_not_null(Author::find_by_created_at($now));

What's different about how update_attribute() operates with a PHP DateTime object than how it operates with ActiveRecord\DateTime...? (mostly thinking out loud here, but answers are welcomed)

[koenpunt]

I don't have a timezone set in my php.ini, but yes I also think is has to do with the date and time configuration on travis.

[al-the-x]

        // Model.php:450-457 in public function assign_attribute($name, $value)
        // convert php's \DateTime to ours
        if ($value instanceof \DateTime)
            $value = new DateTime($value->format('Y-m-d H:i:s T'));

        // make sure DateTime values know what model they belong to so
        // dirty stuff works when calling set methods on the DateTime object
        if ($value instanceof DateTime)
            $value->attribute_of($this,$name);

Note how the date format is hard-coded... Love that.

[al-the-x]

@Rican7 @koenpunt Might be easier to set with a PHPUnit flag or just ini_set()... Just a thought.

[koenpunt]

@al-the-x Probably should use the adapters default, which was introduced here: #302

[al-the-x]

@koenpunt Agreed, or ActiveRecord\DateTime::$DEFAULT_FORMAT...

[al-the-x]

Wow, trying to run on my local produces a segfault. Not cool.

[al-the-x]

Love that BSD. Running on my Ubuntu dev server, I also get no failures... WTF?

[al-the-x]

Turned on query logging (by installing PEAR::Log) in the hopes that seeing the SQL executed would help:

2013-04-26 20:00:26 ident [info] UPDATE `authors` SET `updated_at`=?, `created_at`=? WHERE `author_id`=?
2013-04-26 20:00:26 ident [info] SELECT * FROM `authors` WHERE `created_at`=? LIMIT 0,1

Super not helpful.

[Rican7]

@al-the-x Yea... summa dat PDO prepare statement logging. :/

[al-the-x]

Re notes on 6ec4a44, I commented out the failing test, which reduced the log line count, indicating to me that both assertions were running, even when the first assertion failed. Let's see if Travis chokes on both assertions...

[al-the-x]

It doesn't make me happy, but it gets us to green for the moment. Let's open a separate ticket for figuring this out (someday) and call this one done...

[Rican7]

Nice work, @al-the-x. Unfortunately you didn't figure it out necessarily, but we have a better understanding and a way to pass the tests in Travis.

We'll just have to re-attack this somehow in #307.
Anyway, great work. And thank you. :)