That would delete all the records and should take care of removing the related tables too provided the relationship is CASCADE DELETE and not CASCADE SET NULL. If the relationship is CASCADE SET NULL then you are leaving redundant data behind which may be perfectly valid in normal operation but probably not while repeatedly running the import scripts.

Unfortunately that way wouldn’t result in the index being reset which may not always matter, but if as per my first point you have id specific import logic then subsequent attempts would likely not work as anticipated.

Many thanks.

Chris.

The problem with ./symfony doctrine:build –all –and-load; ./symfony cc is that it is completely nukes the database and loads everything from scratch so you have to have fixtures defined for all your data. In my case I was working on importing data for a few tables and someone else was working on other parts of the system so this was not appropriate.

Using truncate in the way I have mentioned meant I could get my data import tasks to only clean out the tables which I needed to work with whilst leaving the rest of the system intact, usable by the other person and avoiding possible loss of data due to records not being in the fixtures.yml (added or edited via the administration pages but not converted back in to the fixtures.yml)

In addition, the trouble with doing all the data in fixtures.yml is that it is not particularly client friendly. For a developer, it is probably no harder to maintain the fixtures.yml or a equivalent CSV file but I find that the client typically prefers something they can easily visualise, hence why I was importing using a CSV file (which the client was constantly updating and I was re-importing) rather than using a fixtures.yml. That said, there is nothing wrong with using a fixtures.yml to do the same job.

I hope this clears up why I was using truncate and a CSV in this manner.

Many Thanks.

Chris

./symfony doctrine:build –all –and-load; ./symfony cc

This way you only have to maintain the schema.yml and fixtures.yml.

Or didn’t I understand the main point?

Thank you for the clarification. I’ve updated $doctrine to $dbh to help avoid confusion with this example.

Many Thanks.

Chris Shennan

$doctrine = Doctrine_Manager::getInstance()->getCurrentConnection()->getDbh();

is a PDO-Object (in most cases), so the naming of the variable ($doctrine) could lead to confussion.

I’ve started using these recently and although I’ve found there are a few things you need to remember when using them they work really well and really reduces the problems when applying database changes from development to test to live servers.

Trunkating all tables in phpMyAdmin was driving me crazy. I saved myself some typing by separating the query with ;

TRUNCATE TABLE Article; TRUNCATE TABLE User; …