Hi Tom,

I'll take a look at your first point. I'm not sure many people will be
running propel-build-all-load if they don't have any schema files...

Your second point has been fixed in SVN.

To your third point, it looks like you're missing a colon:

propel:
  foo:
    bar varchar(100)

Should be...

propel:
  foo:
    bar: varchar(100)

Thanks,
Kris

On Nov 7, 11:08 am, "Tom Boutell" <[EMAIL PROTECTED]> wrote:
> 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/plu 
> gins/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/plu 
> gins/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.comwww.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
-~----------~----~----~----~------~----~------~--~---

Reply via email to