Doctrine Project

[DC-1050] Doctrine_Relation_ForeignKey ignores ATTR_COLL_KEY attribute

Wed, 7 Mar 2012 13:02:40 +0000

Doctrine_Relation_ForeignKey::fetchRelatedFor() executes the following code at line 70:

$coll = $this->getTable()~~>getConnection()~~>query($dql, $id);
$related = $coll[0];

As you can see it accesses the first element by using index "0" in $coll and hence ignores a modified ATTR_COLL_KEY-setting, for instance:

$this->setAttribute(Doctrine_Core::ATTR_COLL_KEY, 'id');

Fortunately I had two models (ForeignA and ForeignB) in my project which both have an one-to-one relation to a third model (Main). That helped me finding this bug which causes the following strange behavior:

// program 1:

$m = new Main();
$m->name = 'M1';
$m->setForeignA(new ForeignA()); // has ATTR_COLL_KEY changed to 'id'
$m->setForeignB(new ForeignB());
$m->save();

// program 2:

$m = Doctrine_Core::getTable('M1')->findOneBy('name', 'M1');
$m->getForeignA()->exists(); // false
$m->getForeignB()->exists(); // true

-------------------------

The big problem about this issue is that behavior is inconsistent. If you don't split the example above into two separate programs/processes you won't have problems, since Doctrine accesses the reference which was stored when calling save().

You will get into trouble using functional tests in Symfony. Since there is only a single process for all requests I wasn't able to reproduce a problem caused by this bug which appeared in the production environment.

-------------------------

Edit:

Doctrine_Connection::queryOne() is affected as well!

A solution is to replace

$coll = $this->getTable()~~>getConnection()~~>query($dql, $id);
$related = $coll[0];

$related = $this->getTable()~~>getConnection()~~>query($dql, $id)->getFirst();

[DC-903] Make Doctrine_Record_UnknownPropertyException error more descriptive

Thu, 28 Oct 2010 14:46:49 +0000

If I have a Doctrine object and I try something like $book->getNonexistantThing(), I always get an error like this:
PHP Fatal error: Class 'Doctrine_Record_UnknownPropertyException' not found in /home/jason/projects/mcif/lib/vendor/symfony/lib/plugins/sfDoctrinePlugin/lib/vendor/doctrine/Doctrine/Record/Filter/Standard.php on line 55

It makes it hard to track down the source of the error. Why not have the error include the offending method call?

[DC-949] (patch)allow Native floats and double precision field types for MySQL, Oracle, Pgsql

Thu, 9 Dec 2010 18:53:19 +0000

This creates a new attribute constant Doctrine_Core::ATTR_USE_NATIVE_FLOAT and Doctrine_Core::ATTR_USE_NATIVE_DOUBLE. This will allow the setting of attributes of use_native_float = true and use_native_double = true. With these set to true in MySQL of the generated sql will no longer Make FLOAT(18,2) and will make it just FLOAT that is a true floating point the same thing with DOUBLE except it is now a true double precision floating point.

Proper adjustments are also made to MySQL, Oracle and Postgresql to use native floating point declarations to define both single and double precision floating point data types.

I have attached a patch to fix the floating point field types.

[DC-383] Migrations not respecting ATTR_TBLNAME_FORMAT

Fri, 28 May 2010 06:13:28 +0000

I am using Doctrine 1.2.1 and Migrations don't appear to respect Doctrine::ATTR_TBLNAME_FORMAT when creating or dropping tables. This means while models create/drop tables with prefixes migrations don't. Also the migration_version table is created without the prefix too even though it was apparently fixed in ~~DC-245~~.

I haven't tested but it also probably means other attributes like Doctrine::ATTR_IDXNAME_FORMAT and Doctrine::ATTR_SEQNAME_FORMAT are not obeyed either which makes things a little confusing knowing when to care for prefixes or not.

[DC-388] Conservative loading not working

Wed, 27 Jan 2010 23:53:07 +0000

Apparently, when setting Doctrine::MODEL_LOADING_CONSERVATIVE things like Doctrine_Core::createTablesFromModels() don't work. Have to enable aggressive model loading. This has been confirmed on the doctrine-user mailing list.

I took a brief look at the code: I may be missing something but it appears there may be a logic difference in the conservative vs. aggressive model loading method. Aggressive loading uses require_once on all files in the model directory and tries to determine the name of the class inside the file (by doing a difference on the loaded classes). This logic makes sense since the class and file name do not have to match.

However, conservative loading just tries to calculate the class name and store it in an array for later loading by the autoloader. This means there is a huge logic difference in behaviour between these two loading methods since the model class files actually must differ depending on case (specifically, the model class file name must follow a specific format to match the actual class name) otherwise the autoload array will never know the correct name of the class.

I would also like to comment that overall, require_once is a poor choice for performance reasons, it's vastly slower than include_once, but overall the logic should better be adjusted to use plain include (if possible), for performance reasons.

[DC-834] When altering an existing column PGSQL can't convert to SERIAL for autoincrement

Wed, 18 Aug 2010 12:36:45 +0000

If you have an existing column Postgresql won't allow you to use the type SERIAL for altering the column.

First create a column cat_id on category of integer type. Then run the following migration:

migration.php

    public function up()
    {
        $this->changeColumn('category', 'cat_id', 'integer', '4', array(
             'unsigned' => '',
             'primary' => '1',
             'autoincrement' => '1',
             ));
    }

Instead of using type SERIAL doctrine would have to simply alter the column then add a sequence on it's own.

[DC-852] CLONE -Fix returned type value : SQL integers to PHP integers when getting a value from the database.

Thu, 2 Sep 2010 08:11:23 +0000

Hi Jon,

I have a request for you to improve Doctrine. When declaring a column as an integer, it seems that Doctrine returns a string when getting the value of that column. For example, if I have a "status" column, which can take 0, 1 or 2 as its value, Doctrine will return these values as string, which is not really logical and returning the good PHP type is the goal of an ORM. I'm fond of the triple equal symbol to test a value and I did not understand why this did not work at start :

// in my myModel class
class myModel extends Doctrine_Record
{
const STATUS_VALIDATED = 1;

public function isValidated()

{ return self::STATUS_VALIDATED === $this->getStatus(); }

}

That's why getStatus() gives me a string instead of an integer, whereas the column is declared as an integer in my schema. I'm forced to cast myself the returned value of getStatus() in my model.

[DC-1006] Custom geometric query error with orderBy

Sun, 22 May 2011 19:41:17 +0000

Mi Doctrine_Query with this Geometric Query fails with orderBy , but with where works.

$distance = "glength(linestringfromwkb(linestring(GeomFromText('POINT( ".$object->getLatitude()." ".$object->getLongitude() .")'),l.point))) "

This works:
SomeObjectTable::getInstance()~~>createQuery()~~>where($distance.' < ?',0.05 )

But this one fails at version 1.2.4, with older version was working.
SomeObjectTable::getInstance()~~>createQuery()~~>where($distance.' < ?',0.05 )->orderBy($distance)

Well the problem is at line 74 of OrderBy.php :
$componentAlias = implode('.', $e);

the rendered query in the distance has some ".", for example:
POINT( -34.470829 -58.5286102)

then the after line 74 in OrderBy tries to search por '58' class.

I manually added to DataDict in Mysql.php the POINT datatype (this fix solve me the problem in older versions of Doctrine).

[DC-418] Inherited models creating NOT NULL restrictions on their parents

Mon, 11 Jan 2010 18:19:57 +0000

to reproduce, create the yaml included in sample.yaml (Note the not-null columns in each subclass)

if you try to save an OnlineProduct without setting copyright_year, or if you create a print_product without setting website_branding_id, then you will get a not null error.
Inherited tables should be able to set their own NOT NULL columns without affecting other tables in the inheritance tree (should be handled in the preSave() method? or is there another mechanism?)

[DC-710] doctrine:build-model does not create phpdoc for doctrine builtin attributes (sluggable, timestampable, id)

Tue, 8 Jun 2010 09:51:21 +0000

When defining a table with actAs attributes (Timestampable, Sluggable, ...) doctrine creates columns in the database and corresponding attributes in the model classes, but the PHPDOC in the model classes does not include getters and setters for these "automatic" attributes.
This is unconvenient when using an IDE as the getter are not present in the auto completion.

The enhancement would be to add the appropriate phpdoc @property tags so that symfony can generate all the @method tags.

see http://trac.symfony-project.org/ticket/8711

Thank you

Kevin Hatry