[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