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?