Doctrine Project

[DC-980] Moving all ALTERS queries to the end of generated sql file (task build-sql)

Fri, 4 Mar 2011 06:42:03 +0000

Actual in case of using multi database configuration and foreign keys between them.

Now build-sql task generates SQL query for database by database in alphabetical order. It's ugly when we have multidatabase configuration and foreign keys between their tables. It's impossible to do 'import-sql' without errors beucase foreign keys constrains to nonexisting tables are in next database in order.

I have added some code to strings 1176-...

[DC-935] Doctrine_Task_BuildAllReload does not call generate-models-from-yaml

Sun, 21 Nov 2010 21:35:56 +0000

Doctrine_Task_BuildAllReload never calls generate models-from-yaml. This does not coincide with the logic of Doctrine_Task_BuildAll and Doctrine_Task_BuildAllLoad.

BuildAllReload suggests that it will be building all (everything) and then reloading the database.
But instead it only rebuilds the database and loads data

Doctrine 1.2.3 - BuildAllReload.php

public function __construct($dispatcher = null)
    {
        parent::__construct($dispatcher);

        $this->rebuildDb = new Doctrine_Task_RebuildDb($this->dispatcher);
        $this->loadData = new Doctrine_Task_LoadData($this->dispatcher);
        
        $this->requiredArguments = array_merge($this->requiredArguments, $this->rebuildDb->requiredArguments, $this->loadData->requiredArguments);
        $this->optionalArguments = array_merge($this->optionalArguments, $this->rebuildDb->optionalArguments, $this->loadData->optionalArguments);
    }
    
    public function execute()
    {
        $this->rebuildDb->setArguments($this->getArguments());
        $this->rebuildDb->execute();
        
        $this->loadData->setArguments($this->getArguments());
        $this->loadData->execute();
    }

Instead, I think it would be more efficient and understanding to follow the same logic as build-all and build-all-load by calling drop-db and build-all-load.

Proposed - BuildAllReload.php

public function __construct($dispatcher = null)
    {
        parent::__construct($dispatcher);

        $this->dropDb = new Doctrine_Task_DropDb($this->dispatcher);
        
        $this->buildAllLoad = new Doctrine_Task_BuildAllLoad($this->dispatcher);
        
        $this->requiredArguments = array_merge($this->requiredArguments, $this->dropDb->requiredArguments, $this->buildAllLoad->requiredArguments);
        $this->optionalArguments = array_merge($this->optionalArguments, $this->dropDb->optionalArguments, $this->buildAllLoad->optionalArguments);
    }
    
    public function execute()
    {
        $this->dropDb->setArguments($this->getArguments());
        $this->dropDb->execute();
        
        $this->buildAllLoad->setArguments($this->getArguments());
        $this->buildAllLoad->execute();
    }

I attached a patch with the above changes... I got a little lost in the test area for Doctrine_CLI, so that is not included = )

[DC-865] Models that extend a baseclass other than Doctrine_Record treat that baseclass as if it were a model

Sat, 11 Sep 2010 19:47:56 +0000

We recently made an extended version of Docrtine_Record which has some functionality that is specific to our project and we switched all our models to use this baseclass by setting the cli option: generate_models_options:baseClassName

We found that when we rebuilt our db this base class was being treated as it were a model (even though its an abstract class). This was causing some errors during our build and a table based on the name of the baseclass was being created.

I tracked the problem down to line 310 of Doctrine_Table where the do loop was only breaking for a class named "Doctrine_Record".

It seemed to make more sense to me to have this loop break for any abstract class, so I copied the technique used to check for abstract classes from Doctrine_Core Line 798. This broke a lot of tests however so due to time constraints I went with a simpler fix – instead I just changed the code that checks if the class is named "Doctrine_Record" to be a regular expression that checks to see if the class name starts with "Doctrine_Record" optionally followed by an underscore + more text in the class name.

This has fixed my issue and should let people make extensions of doctrine record which they can use as a baseclass provided that their class names indicate that they are extending Doctrine_Record.

The only problem I can see arising from this if some users have made models that they have named starting with "Doctrine_Record", but that seems like it would be an odd thing to do so this probably it won't be an issue.

I could however look more closely into detecting abstract classes if this would make my changes significantly more useful.

Please see attached patch.

Will Ferrer

[DC-981] Class prefix isn't being appended when importing data

Fri, 4 Mar 2011 08:23:40 +0000

Configuration:

Doctrine_Manager::getInstance()->setAttribute(Doctrine_Core::ATTR_MODEL_CLASS_PREFIX, 'Foo_');

Schema:

Bar:
columns:
baz: int

Fixtures:

Bar:
Bar_1:
baz: 1

Error on importing data: "Couldn't find class Bar."

Doctrine should use Foo_Bar class for Bar model instead Bar class.

[DC-357] setting "Doctrine_Core::ATTR_EXPORT" to "Doctrine_Core::EXPORT_TABLES" prevents i18n table creation

Mon, 14 Dec 2009 16:51:11 +0000

When I try to prevent foreign key creation (because I am using a mix of MyISAM and InnoDB tables) using the given attribute, I notice that all the translation tables are also not getting created.

[DC-741] Sort of Migration Class Problem With More Than 9 Classes

Tue, 24 Aug 2010 12:30:40 +0000

I have problem when do a migration with more than 9 classes. (Version1, Version2, Version3, ..., Version10)

php doctrine-cli.php migrate 10

When migration class lower than 10, migration well done.
The migration always return another class, not Version10.

I have do a simple research, and found the problem is on the sort of the class name.
It use SORT_NUMERIC, and it is not suitable to sort them.

So, I change the sort method to Natural Sort, to fix this issue.