I'm working on my first Symfony 1.2 project. I am fetching 1.2 via svn
externals and it is up to date right now. I'm using Propel.
I've spotted two things that would qualify as bugs, one fairly minor,
and one removed feature I'm not sure has been documented as an issue
for upgrading users.
1. If you don't have a schema.yml file for the main project and don't
have any plugins yet either (because you didn't realize they have to
be activated in 1.2... not a bug, it's documented, I just hadn't found
it yet), you get an inscrutable error message:
./symfony propel:build-all-load
I confirm that I want to overwrite my database, and then it fails like so:
PHP Notice: Undefined variable: ret in
/Users/boutell/Sites/punkave/projects/simplesite/lib/vendor/symfony/lib/plugins/sfPropelPlugin/lib/task/sfPropelInsertSqlTask.class.php
on line 130
When I look at the code, I can see that this will occur if the $sqls
array is empty. It would be better to test for an empty $sqls array
and output a fatal error. Or just succeed quietly for consistency
reasons (it makes it easier to use this task in an automated series of
tasks, and there's nothing strictly wrong with asking to load
nothing).
Note that this error does not occur if you do this sequence:
./symfony propel:build-model
./symfony propel:data-load
However I had an unrelated problem with propel:data-load (read on).
2. The propel:data-load
Unable to open PDO connection [wrapped: SQLSTATE[42000] [1049] Unknown
database '##project_name##']
When I inspect config/databases.yml I find that it has a placeholder
variable, ##project_name##, inserted as the dbname. I guess this is
supposed to get substituted with the actual project name but that does
not happen.
I edited config/databases.yml to make the database name explicit, and
then propel-load-data ran without error.
This seems like a big bug to me, big enough that it's possible I'm
missing a simpler explanation?
3. If I try to use the shorthand syntax in my schema.yml file:
propel:
foo:
bar varchar(100)
Which was accepted by 1.0, things do not go well.
When I use propel:build-all-load, I get this error:
PHP Fatal error: Cannot unset string offsets in
/Users/boutell/Sites/punkave/projects/simplesite/lib/vendor/symfony/lib/plugins/sfPropelPlugin/lib/addon/sfPropelDatabaseSchema.class.php
on line 134
That code looks like this:
$phpName = sfInflector::camelize($table);
if (isset($table_params['_attributes']))
{
$table_attributes = $table_params['_attributes'];
unset($table_params['_attributes']); <--- offending line
As it turns out this happens because $table_params is a string
(because I used the shorthand syntax and just specified the type
rather than creating an associative array of parameters, type being
among them).
PHP 5.2.6 (at least?) has the following obnoxious behavior:
?php
$foo = "bar";
echo(isset($foo['baz']));
unset($foo['baz']);
?>
Outputs "1..." and THEN it produces the fatal error about unsetting a
string offset.
But looking more closely at the code it looks like support for the old
shorthand syntax has been removed in 1.2 (1.1?). I don't see any
attempt to implement it.
It would make sense to at least have something like:
if (!is_array($table_params))
{
error_message_here;
}
To warn users of the old syntax that it has gone away.
When I use the more complete syntax:
propel:
foo:
bar:
type: varchar(100)
propel:build-all-load succeeds for that table.
--
Tom Boutell
www.punkave.com
www.boutell.com
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"symfony developers" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/symfony-devs?hl=en
-~----------~----~----~----~------~----~------~--~---
