[DC-674] NULL Dates are translated to '0000-00-00' after upgrading to 1.2.2 Created: 10/May/10  Updated: 06/Oct/10

Status: Open
Project: Doctrine 1
Component/s: Behaviors
Affects Version/s: 1.2.1, 1.2.2
Fix Version/s: 1.2.1, 1.2.2

Type: Bug Priority: Critical
Reporter: Ville Itämaa Assignee: Jonathan H. Wage
Resolution: Unresolved Votes: 0
Labels: None
Environment:

Zend Framework, Ubuntu 9.10, MySQL



 Description   

Once the upgrade was done from Doctrine 1.2.1 to 1.2.2 we discovered that date related issues started to appear.
With dates that are persisted in DB as NULL are translated to "0000-00-00" when retrieved from DB. This has occurred in multiple places and is quite worrying as there is a lot of dates in our project. This means that everywhere in our codebase where we check a datevalue in our Models is NULL we need also to check for the string literal "0000-00-00".

 Comments   
Comment by Jonathan H. Wage [ 10/May/10 ]

Are you able to reproduce this in a test case?

Comment by Ville Itämaa [ 11/May/10 ]

We reverted to Doctrine 1.2.1 after realising the bug to confirm it was Doctrine 1.2.2 that was the cause for the problem. And as a result the records with NULL dates in the DB became NULL in the Models.
But when using Doctrine 1.2.2, the NULL dates became '0000-00-00' in the Models.
I don't have any other way to reproduce this error.

Comment by Jonathan H. Wage [ 11/May/10 ]

Were you able to identity which changeset it was? You can read about creating test cases here http://www.doctrine-project.org/documentation/manual/1_2/en/unit-testing

So far I am not able to reproduce the error you described.

Comment by Jonathan H. Wage [ 08/Jun/10 ]

I'd like to fix this. Did you ever figure out which changeset introduced the issue? I've been trying to figure it out myself.

Comment by Roland Huszti [ 06/Oct/10 ]

With 1.2.3 this works for me fine with both TIMESTAMP and DATE fields.

YAML

        date_of_birth:
            type: date

BASE MODEL

        $this->hasColumn('date_of_birth', 'date', null, array(
             'type' => 'date',

             // try these two
             // 'notnull' => false,
             // 'default' => null
         ));

YAML

        exported_at:
            type: timestamp(25)
            notnull: false
            default: null

            # in this model I have everything to make sure it accepts and defaults to NULL

BASE MODEL

        $this->hasColumn('exported_at', 'timestamp', 25, array(
             'type' => 'timestamp',
             'notnull' => false,
             'length' => '25',
             ));

You may try adding these to your YAML and (base) models

YAML

    fieldname:
         . . .
        notnull: false
        default: null

BASE MODEL

        $this->hasColumn('fieldname', . . .
             . . .
             'notnull' => false, // <<<<<<<
             // 'default' => null, // <<< maybe, probably not needed
             ));

I hope it helps.




[DC-553] issue when changing the connection inside Doctrine_Query::preQuery() on a model using a behavior Created: 08/Mar/10  Updated: 19/Jul/10

Status: Open
Project: Doctrine 1
Component/s: Behaviors
Affects Version/s: None
Fix Version/s: 1.2.1

Type: Bug Priority: Major
Reporter: Lukas Kahwe Assignee: Jonathan H. Wage
Resolution: Unresolved Votes: 0
Labels: None


 Description   

We were following:
http://www.doctrine-project.org/documentation/cookbook/1_1/en/master-and-slave-connections

class MyQuery extends Doctrine_Query
{
// Since php doesn't support late static binding in 5.2 we need to override
// this method to instantiate a new MyQuery instead of Doctrine_Query
public static function create($conn = null)

{ return new MyQuery($conn); }

public function preQuery()
{
// If this is a select query then set connection to one of the slaves
if ($this->getType() == Doctrine_Query::SELECT)

{ $this->_conn = Doctrine_Manager::getInstance()->getConnection('slave_' . rand(1, 4)); // All other queries are writes so they need to go to the master }

else

{ $this->_conn = Doctrine_Manager::getInstance()->getConnection('master'); }

}
}

However we are actually forcing all queries after the first access to the master to be run against the master (including selects). Note the example should probably be changed to use setConnection(). However even when using setConnection() it seems like changing the connection can cause issues when running a select on a model with a behavior (in our case we were using i18n). Therefore we believe there is some issue that is caused through the event system, because otherwise queries work just fine even when changing the connection as per the above described code.

We managed to fix things, by not setting the connection explicitly and instead simply using setCurrentConnection('master'), so the bug does not affect us anymore. However this seems to indicate some issues deep inside the event-behavior-template code.

 Comments   
Comment by Jordi Boggiano [ 08/Mar/10 ]

In case the above post is confusing, note that doing $this->_conn = masterconn worked fine for the INSERT, it just broke when doing a subsequent SELECT of a translateable (I18n behavior) model and its Translation table with the following exception:

Exception (Exception): Unknown relation alias Translation (#0)</h1>thrown in file /Library/WebServer/Documents/liip/infocube/ext/db-doctrine/lib/Doctrine/Relation/Parser.php at line 237
backtrace:
#1 Doctrine_Relation_Parser->getRelation called in file /Library/WebServer/Documents/liip/infocube/ext/db-doctrine/lib/Doctrine/Relation/Parser.php at line 235

Comment by Jonathan H. Wage [ 15/Mar/10 ]

It is hard to understand the issue, can you provide a test case?

Comment by Lukas Kahwe [ 15/Mar/10 ]

We already spend well over 2 hours together on project time to find a work around as noted above and I must admit now our motivation is not so big to dig deeper, especially since we didn't find the cause in this time and have the feeling its pretty impossible to fix without huge risks.

Essentially I think all you need to do to reproduce the issue is use the cookbook code and issue some write query and afterwards do a select on a model that has the translatable behavior. It then gave us the above Exception.

Our code worked slightly different since we did not use a random slave, instead we always used a local slave by default, but the first write and any queries thereafter would get send to the master. The code is public and the diff's show what we had to change to get things working. Note that the slave "localhost" connection was the default connection:
http://fisheye.liip.ch/browse/PUB/okapi2/ext/db-doctrine/trunk/inc/DQ.php?r1=13118&r2=
http://fisheye.liip.ch/browse/PUB/okapi2/ext/db-doctrine/trunk/inc/DR.php?r1=13118&r2=

Comment by Lukas Kahwe [ 17/Jun/10 ]

we thought we had the issue fixed but ran into another issue today. we then noticed that the issue goes away if we just copy the $tables property from the old connection to the new connection. there is a getTables() method, but there is only a addTable() method, would be nice to have a addTables() method that is faster. or maybe a switchFrom() method that accepts the old connection and does whatever it needs to.

And again it would be nice to update the cookbook entry.
Here are our updated Doctrine_Query and Doctrine_Record classes:
http://fisheye.liip.ch/browse/PUB/okapi2/ext/db-doctrine/trunk/inc/DQ.php
http://fisheye.liip.ch/browse/PUB/okapi2/ext/db-doctrine/trunk/inc/DR.php

Comment by Jordi Boggiano [ 19/Jul/10 ]

We just had another funny debugging session related to this. It turns out that the Table objects have a relation to the connection, and if you query a new model that wasn't initialized yet using ->from(), it works because it just gets the current connection passed. However, if you query a new model within a JOIN, then it apparently takes the connection from the related model you're joining from. In our case, the related model was already initialized but had an instance of the old (slave) connection, and so the new model was initialized using the wrong connection, and then the DQL parser exploded trying to resolve relations.

Long story short, adding $table->setConnection($conn); to all tables while switching to the master connection resolved it. The code is updated and you can still view it at the above URLs, or straight in the SVN repo at http://svn.liip.ch/repos/public/okapi2/ext/db-doctrine/trunk/inc/DQ.php




[DC-769] Variable type different for return value from Doctrine_Record->toArray() depending on whether the object is from a select, or a save. Created: 27/Jun/10  Updated: 24/Aug/10

Status: Open
Project: Doctrine 1
Component/s: None
Affects Version/s: 1.2.1
Fix Version/s: 1.2.1, 1.2.2, 1.2.4

Type: Bug Priority: Major
Reporter: Dennis Gearon Assignee: Jonathan H. Wage
Resolution: Unresolved Votes: 0
Labels: None
Environment:

Ubuntu9.10, PHP 5.2.6, Symfony 1.4.1, Postgres8.4


 Description   

With a object that is created via a save(), and the record's primary key is a INT fed by a SEQUENCE, the type of the variable is an INT.

With an object that is hydrated from the database via a SELECT, the record's primary key INT will come back in 'toArray()' as a STRING.

That means that checking for type has to know what context it came from, user, INSERT, or SELECT. Not fun.

This also screws up converting arrays to JSON, 'cause the STRINGS get quotation marks and the INTS do not.

As a general rule, everything FROM the database seems to be strings. Yes, I know, everything 'on the wire' or 'through a socket' comes out as text. And it's a lot faster to leave it that way.

But having the type be different depending on the database operation? Not sure I like that.

 Comments   
Comment by Jonathan H. Wage [ 24/Aug/10 ]

Can you provide a test case so that we can see if we can come up with a patch?




Generated at Wed Jun 19 06:02:23 UTC 2013 using JIRA 5.2.7#850-sha1:b2af0c8dc8537b36121c6a579fabbdf79fc919e5.