I’m still using symfony 1.3 for pet projects, even though I should find the time (maybe first quarter of 2014!) to look at Symfony 2. However as can happen with any framework, today I came across a head-scratcher that took more coffee than expected to fix. Today’s hiccup was with the Propel 1.6 plugin – and I would guess this would be exhibited outside of the symfony CLI also.

OK, so I tend to write my database XML schemas by hand, and I tend to have several, as it is nice to keep each block inside the plugin that is responsible for providing related functionality. Here is the schema I added for a new table:

<?xml version="1.0" encoding="UTF-8"?>
<database>
    <table name="gearman_status">
        <column name="id" type="integer" primaryKey="true" required="true" />
        <column name="job_id" type="varchar" size="50" required="true" />
        <column name="created_at" type="TIMESTAMP" required="true" />
        <column name="result" type="varchar" size="200" />
    </table>
</database>

So I build that, and got the error:

Database "" does not exist.

I soon noticed my mistake: the <database> tag should have “name” and “package” attributes at a minimum. So I fixed those, and rebuilt the database, only to find the same error was being reported. I then cleaned up intermediate XML files in /config (using rm config/generated*xml config/buildtime-conf.xml) and found the error still persisted.

Turns out that the initial bad build modified my database map in data/sql/sqldb.map:

# Sqlfile -> Database map
lib.model.schema.sql=propel
plugins.sfGuardPlugin.lib.model.schema.sql=propel
schema.sql=
plugins.viGearmanSupportPlugin.lib.model.schema.sql=propel

The “schema.sql=” is the line that is causing the error. Once this was removed, all was fine and dandy. Whilst this is reasonably easy to detect with version control software, I wonder whether it could be considered a build bug?