NYCPHP Meetup

[Paul Houle]

Ajai Khattri wrote:
> On Thu, 17 Jan 2008, paul at devonianfarm.com 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.