[symfony-users] Re: we are going to convert a site from Propel to Doctrine. What are the pain points?
I agree, DbFinder plugin is brilliant! If you upgrade to propel 1.3 there is little difference in performance between Doctrine and Propel. For me the code insight from Propel is very valuable too. On 27 Apr, 14:42, Crowley szecskames...@gmail.com wrote: Try the sfDbFinder plugin. It has adatpter both for propel and doctrine. And the syntax is similar to Doctrine. On Apr 27, 11:00 am, HiDDeN sombrasdepa...@gmail.com wrote: Why are you changing to Doctrine? It is a bit tricky when doing some things. For example, if you want to write a custom SQL, or if you want to write a Full-Text search, or just work with the backend (because the Doctrine pager is slow...) On Apr 25, 9:16 pm, Alexandru-Emil Lupu gang.al...@gmail.com wrote: I never used Doctrine...but i think the pain will be the Criteria (s) changes. If you have Criterias outside the model (i mean in action...) then it will be a pain in the a** alecs On Sat, Apr 25, 2009 at 9:44 PM, Lawrence Krubner lkrub...@geocities.comwrote: We are going to convert a site from using Propel to using Doctrine. Have others done this? Can you suggest what the pain points are? I haven't looked, but I assume the Doctrine interface is different and therefore we need to crawl through our code changing a lot of method calls. -- I am on twitter:http://twitter.com/alecslupu I am on linkedIn:http://www.linkedin.com/in/alecslupu --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups symfony users group. To post to this group, send email to symfony-users@googlegroups.com To unsubscribe from this group, send email to symfony-users+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/symfony-users?hl=en -~--~~~~--~~--~--~---
[symfony-users] Re: we are going to convert a site from Propel to Doctrine. What are the pain points?
Doctrine is different from Propel in several things - some big (like the schema.yml file format, for example) and some small (like subtle changes in the way Doctrine form fields work when compared to Propel). If your project is big, you have a lot of work coming your way. If you have encapsulated everything perfectly in the MVC model, you'll mostly have to worry about rewriting your Model codes and your Form codes (assuming you're using the 1.2 branch, where forms are isolated in their own classes). This by itself should be a lot of work, depending on the size of your project. However, I'd say your biggest pain would be to go through your Controller layer (your actions) and check if there are any Propel- specific calls there. In the best case scenario, you won't have any direct database queries in your Controller, but you'll still have to update method calls to Peer classes since Doctrine uses a different syntax for its Table classes. Worst case scenario, you'll have direct database queries in your Controllers, and then you'll have not only to translate the calls to the Doctrine syntax but also probably to refactor some code in order to put everything on its proper MVC layer. IMO checking the actions is the worst part, since projects usually have several modules and countless actions - checking and updating one- by-one is really, really boring and error-prone. Good luck! Best Regards, Thiago Campezzi On Apr 25, 3:44 pm, Lawrence Krubner lkrub...@geocities.com wrote: We are going to convert a site from using Propel to using Doctrine. Have others done this? Can you suggest what the pain points are? I haven't looked, but I assume the Doctrine interface is different and therefore we need to crawl through our code changing a lot of method calls. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups symfony users group. To post to this group, send email to symfony-users@googlegroups.com To unsubscribe from this group, send email to symfony-users+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/symfony-users?hl=en -~--~~~~--~~--~--~---
[symfony-users] Re: we are going to convert a site from Propel to Doctrine. What are the pain points?
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 symfony-users@googlegroups.com
To unsubscribe from this group, send email to
symfony-users+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/symfony-users?hl=en
-~--~~~~--~~--~--~---
[symfony-users] Re: we are going to convert a site from Propel to Doctrine. What are the pain points?
On Apr 28, 2009, at 2:27 PM, Tom Boutell wrote:
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.
That's because it is a syntax error according to the SQL-92 standard.
As easy as it is to pick on MySQL, it isn't their fault. This is what
we're stuck with in all dbms that follow SQL-92, for better or worse.
8.4 in predicate
Function
Specify a quantified comparison.
Format
in predicate ::=
row value constructor
[ NOT ] IN in predicate value
in predicate value ::=
table subquery
| left paren in value list right paren
in value list ::=
value expression { comma value expression }...
Notice how an in value list MUST start with a value expression and
a value expression cannot be empty.
IN (false) isn't technically the proper behavior for what you're
looking for. Consider the case: SELECT true WHERE false IN (false).
(Yeah it's a pathological case but something a framework would need to
worry about.) You should be using IN (null) since that shouldn't
match any rows with a standards-compliant DBMS. I know PostgreSQL and
mysql 5 both behave correctly.
--
Jacob Coby
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
symfony users group.
To post to this group, send email to symfony-users@googlegroups.com
To unsubscribe from this group, send email to
symfony-users+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/symfony-users?hl=en
-~--~~~~--~~--~--~---
[symfony-users] Re: we are going to convert a site from Propel to Doctrine. What are the pain points?
Why are you changing to Doctrine? It is a bit tricky when doing some things. For example, if you want to write a custom SQL, or if you want to write a Full-Text search, or just work with the backend (because the Doctrine pager is slow...) On Apr 25, 9:16 pm, Alexandru-Emil Lupu gang.al...@gmail.com wrote: I never used Doctrine...but i think the pain will be the Criteria (s) changes. If you have Criterias outside the model (i mean in action...) then it will be a pain in the a** alecs On Sat, Apr 25, 2009 at 9:44 PM, Lawrence Krubner lkrub...@geocities.comwrote: We are going to convert a site from using Propel to using Doctrine. Have others done this? Can you suggest what the pain points are? I haven't looked, but I assume the Doctrine interface is different and therefore we need to crawl through our code changing a lot of method calls. -- I am on twitter:http://twitter.com/alecslupu I am on linkedIn:http://www.linkedin.com/in/alecslupu --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups symfony users group. To post to this group, send email to symfony-users@googlegroups.com To unsubscribe from this group, send email to symfony-users+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/symfony-users?hl=en -~--~~~~--~~--~--~---
[symfony-users] Re: we are going to convert a site from Propel to Doctrine. What are the pain points?
Try the sfDbFinder plugin. It has adatpter both for propel and doctrine. And the syntax is similar to Doctrine. On Apr 27, 11:00 am, HiDDeN sombrasdepa...@gmail.com wrote: Why are you changing to Doctrine? It is a bit tricky when doing some things. For example, if you want to write a custom SQL, or if you want to write a Full-Text search, or just work with the backend (because the Doctrine pager is slow...) On Apr 25, 9:16 pm, Alexandru-Emil Lupu gang.al...@gmail.com wrote: I never used Doctrine...but i think the pain will be the Criteria (s) changes. If you have Criterias outside the model (i mean in action...) then it will be a pain in the a** alecs On Sat, Apr 25, 2009 at 9:44 PM, Lawrence Krubner lkrub...@geocities.comwrote: We are going to convert a site from using Propel to using Doctrine. Have others done this? Can you suggest what the pain points are? I haven't looked, but I assume the Doctrine interface is different and therefore we need to crawl through our code changing a lot of method calls. -- I am on twitter:http://twitter.com/alecslupu I am on linkedIn:http://www.linkedin.com/in/alecslupu --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups symfony users group. To post to this group, send email to symfony-users@googlegroups.com To unsubscribe from this group, send email to symfony-users+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/symfony-users?hl=en -~--~~~~--~~--~--~---
[symfony-users] Re: we are going to convert a site from Propel to Doctrine. What are the pain points?
I never used Doctrine...but i think the pain will be the Criteria (s) changes. If you have Criterias outside the model (i mean in action...) then it will be a pain in the a** alecs On Sat, Apr 25, 2009 at 9:44 PM, Lawrence Krubner lkrub...@geocities.comwrote: We are going to convert a site from using Propel to using Doctrine. Have others done this? Can you suggest what the pain points are? I haven't looked, but I assume the Doctrine interface is different and therefore we need to crawl through our code changing a lot of method calls. -- I am on twitter: http://twitter.com/alecslupu I am on linkedIn: http://www.linkedin.com/in/alecslupu --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups symfony users group. To post to this group, send email to symfony-users@googlegroups.com To unsubscribe from this group, send email to symfony-users+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/symfony-users?hl=en -~--~~~~--~~--~--~---
