Ajai Khattri wrote:
On Thu, 17 Jan 2008, [EMAIL PROTECTED] wrote:
Symfony has a mature view system that has caching and other advanced
features (I wish I could say it was as mature in the data access department)
Care to elaborate?
Also, have you played with Doctrine much?
The more I've thought about it, the more I like the basic approach
of Propel. (In fact, today I was working on a data access layer for an
ASP.NET application and ended up building a "Peer" class because needed
some place to stick the static methods associated with a particular
database table.)
Symfony/Propel fails seriously, however, when it comes to database
maintainability.
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.
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.
Now, there is a way out, and that's the strategy of having the
'official' copy of the database schema be in the database and build your
propel schema from that. I've had reasonable results that way, but
have run into two problems:
(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. For
instance, I inherited a database that had a field named 'count'. Maybe
you're not supposed to do that (count is a mysql function) but the
database worked just fine until Propel got involved.
(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.
--------
Doctrine? On paper doctrine looks great. The migration mechanism looks
promising and so does the query language. In practice, documentation
is lacking. For instance,
http://trac.symfony-project.com/wiki/sfDoctrinePlugin1.1
Doesn't say a word about how you configure your database connections or
how you build your model from your schemas. It would be really nice to
have a sample app based on Doctrine that you can install by going down a
checklist. That's how Doctrine fails the maturity test. Every symfony
project I've done in the last few months has been something where I need
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.
_______________________________________________
New York PHP Community Talk Mailing List
http://lists.nyphp.org/mailman/listinfo/talk
NYPHPCon 2006 Presentations Online
http://www.nyphpcon.com
Show Your Participation in New York PHP
http://www.nyphp.org/show_participation.php
