Others have covered the main points. Some additional thoughts:
1. While it's true that Doctrine has Table classes rather than Peer
classes, you can continue to follow the convention of putting static
methods in the Table classes if you feel like it, and this will save
you some time. You can also write non-static methods, which is handy
because you can create a query conveniently with $this->createQuery().
If you take that approach, the calling code should use
Doctrine::getTable('modelClassName')->getAllWiggles() to call those
methods, rather than modelClassNameTable::getAllWiggles().
2. In most ways writing queries with Doctrine cascading methods and/or
DQL is vastly less annoying than working with the Criteria class.
However you can nest Criteria objects deeply if you need to, as
combinations of ORs and ANDs. Doctrine has addWhere(), but doesn't
allow you to make a complex tree that translates to parentheses in the
final SQL.
On the other hand, Doctrine doesn't HAVE to do that, because you can
just write DQL:
Doctrine_Query::create()->from('modelClassName m')->where('m.x < ? AND
(m.y < ? OR m.name = ?), array(50, 100, "Bob"));
Still, if you are building up query criteria by calling several
methods that you reuse in a variety of queries, and simply ANDing or
ORing all of the clauses together without nesting is not sufficient
for you, then you have to build DQL strings by concatenation. In
practice I find this is very rarely necessary.
Another annoyance is that while Doctrine does have addWhereIn() for
easily building an IN query (such as checking whether the ID is one of
a list of IDs), it does not have a convenient way to build an IN
clause deep inside a complex DQL query that requires parentheses like
the one above. So you occasionally do have to write something like:
'm.x < ? AND (m.y < ? OR m.id IN (' . implode(", ", $myIds) . '))';
Which leaves something to be desired. Propel criteria are good at that
one, at least once you get comfortable understanding (and typing) a
nested tree of them.
However Doctrine's superior support for joining tables in complex ways
often eliminates the need for IN clauses.
One more note about writing IN clauses that everybody seems to miss...
if $myids is an empty list, MySQL will produce a syntax error. "Empty
equals evil and scary and different" is an annoying property that both
MySQL and PHP tend to display in many situations. Simply skipping the
IN clause completely would always match everything, when of course you
should match nothing. A simple and correct workaround is to replace
the entire IN clause with FALSE when the list is empty.
Come to think of it, Doctrine itself contains this bug in its
implementation of _processWhereIn(). It correctly detects the
situation where MySQL would generate an error, but then incorrectly
returns nothing rather than FALSE, which is not correct. [Runs off to
report that]
--
Tom Boutell
P'unk Avenue
215 755 1330
punkave.com
window.punkave.com
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"symfony users" 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-users?hl=en
-~----------~----~----~----~------~----~------~--~---
