[DC-980] Moving all ALTERS queries to the end of generated sql file (task build-sql) Created: 04/Mar/11  Updated: 04/Mar/11

Status: Open
Project: Doctrine 1
Component/s: Cli, Schema Files
Affects Version/s: None
Fix Version/s: None

Type: Improvement Priority: Critical
Reporter: Sergey Eremenko Assignee: Jonathan H. Wage
Resolution: Unresolved Votes: 0
Labels: None

Attachments: File Export.php    

 Description   

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 Created: 21/Nov/10  Updated: 21/Nov/10

Status: Open
Project: Doctrine 1
Component/s: Cli
Affects Version/s: 1.2.3
Fix Version/s: None

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

Windows Vista 32bit, Apache 2.2.14, PHP 5.3.1


Attachments: Text File DC-935.patch    

 Description   

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 = )



 Comments   
Comment by Brandon Evans [ 21/Nov/10 ]

Added the proper proposed code this time and also attached patch with better naming.





[DC-865] Models that extend a baseclass other than Doctrine_Record treat that baseclass as if it were a model Created: 11/Sep/10  Updated: 11/Sep/10

Status: Open
Project: Doctrine 1
Component/s: Cli, Import/Export
Affects Version/s: 1.2.3
Fix Version/s: None

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

XP Windows


Attachments: Text File DC_865_fix.patch    

 Description   

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



 Comments   
Comment by will ferrer [ 11/Sep/10 ]

Here is the patch





[DC-981] Class prefix isn't being appended when importing data Created: 04/Mar/11  Updated: 04/Mar/11

Status: Open
Project: Doctrine 1
Component/s: Cli
Affects Version/s: 1.2.3
Fix Version/s: None

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


 Description   

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 Created: 14/Dec/09  Updated: 14/Dec/09

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

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


 Description   

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.



 Comments   
Comment by Jonathan H. Wage [ 14/Dec/09 ]

You can use the bit operator with this attribute.

http://www.doctrine-project.org/documentation/manual/1_2/en/configuration#exporting

Comment by Lukas Kahwe [ 14/Dec/09 ]

in that case the bug is bogus .. however the docs should probably make it clear that there are other export modes available, then illustrated atm.





[DC-741] Sort of Migration Class Problem With More Than 9 Classes Created: 16/Jun/10  Updated: 24/Aug/10

Status: Open
Project: Doctrine 1
Component/s: Cli
Affects Version/s: 1.2.2
Fix Version/s: 1.2.4

Type: Bug Priority: Major
Reporter: Dolly Aswin Harahap Assignee: Jonathan H. Wage
Resolution: Unresolved Votes: 0
Labels: None
Environment:

Ubuntu 10.04, PHP 5.3.2, Doctrine 1.2.2


Attachments: Text File DC-741.patch    

 Description   

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.



 Comments   
Comment by Dolly Aswin Harahap [ 16/Jun/10 ]

Here I attach patch to fix this issue. Please check it.

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

I am not able to produce the error, things are always in the correct order. I added a test here: http://trac.doctrine-project.org/changeset/7683

Can you help me with how to reproduce the error?





Generated at Wed Apr 16 17:21:36 UTC 2014 using JIRA 5.2.7#850-sha1:b2af0c8dc8537b36121c6a579fabbdf79fc919e5.