NYCPHP Meetup

NYPHP.org

[nycphp-talk] Templating engines

Ajai Khattri ajai at bitblit.net
Fri Jan 18 13:00:02 EST 2008


On Thu, 17 Jan 2008, Paul Houle wrote:

>     Symfony/Propel fails seriously,  however,  when it comes to database 
> maintainability. 

Which is why I mentioned Doctrine...

>     You're left high and dry if you do things the "symfony" way of 
> writing your schema files and building a database from that.  Want to do 
> something simple like add a column?  There's no way to do it other than 
> to make a change in the schema and ~then~ make a change in the database.

True, there are no "migrations-like" features like RoR. But Doctrine 
does...

>     Things get really hairy when you install a plugin or two...  I used 
> sf_comment to add comments to this site:
> 
> http://spoonriveranthology.net/spoon/river/
> 
>     I followed the install instructions for sf_comment and found that 
> the build scripts trashed my database.  Symfony plug-ins are based on 
> the assumption that you design the database,  build the site out and 
> never change it.

We've used a bunch of plugins without problems so far.

> (i) if you don't follow certain (unwritten) conventions in how your 
> tables and columns are named,  Propel might build weird database 
> bindings or might build database bindings that don't compile.

A lot of frameworks have database conventions (again, cf. with RoR) and 
some people will hate it and some love it. BTW, I think symfony's use of 
YAML for database schema is a bit restrictive. (We've been using the XML 
format instead).

> (ii) I'm not entirely happy with how foreign keys work,  at least with a 
> mysql back end.  Foreign keys get imported in the schema,  almost 
> correctly,  if you're running an innodb database,  but not if you're 
> running myisam (which doesn't keep the metadata.)  It would be really 
> nice to have a place to keep hints about foreign keys that get merged 
> with fresh info from the database schema.

Yeah, we switched to InnoDB for all our projects.

> Doctrine?  On paper doctrine looks great.  The migration mechanism looks 
> promising and so does the query language.  In practice,  documentation 
> is lacking.

I think Guilherme answered some of your points about Doctrine.

> to deliver some real functionality in a few hours...  I can either get 
> the job done with Propel,  where I'm up on the learning curve,  or I 
> could mess around for twice as long to get it working with Doctrine...  
> Only to find that I did it my own way rather than a standardized 
> framework way.

On this point I kinda agree with you though Im optimistic that Doctrine 
will improve with time.


-- 
Aj.





More information about the talk mailing list