Doctrine Lead Developer explains my WTFs – part 2
Školení, která pořádám 
The first part covered the data retrieval, this part is about the second Doctrine 2 tutorial covering the data storage. Again, look at the video first or you would probably not understand what the conversation is about.
1. One select for each insert
Benjamin: Number of queries in save Article can be brought to one single INSERT by using $em->getReference() instead of $em->find().
Jakub: Thank you for pointing this, I didn't know about getReference. The number of queries will not be one (no SELECTs, three INSERTs), but it's OK.
2. No error for wrong reference
Benjamin: $em->find() returns NULL if no result was found. This is described in the API docs.
Jakub: getReference solves this too.
4. No error for invalid data
Benjamin: Setting the string length to high does not fail on MySQL because you are not in strict mode. You should call SET sql_mode = 'STRICT_ALL_TABLES' or set this in MySQL server to get errors instead of warnings on out of range inserts. We don't want to duplicate the error reporting of the databases because its very expensive to do all the time.
Jakub: In my point of view - if Doctrine has this information then it should utilize it somehow and do not depend on the database layer. For example SQLite could not report this issue at all.
Benjamin: Its just too expensive to always check the string length on updates, even if we know it. The database already does that for you and there is no real difference between getting some validation or a PDO exception. Since we don't know if the developer knows the string length himself for sure (then automatic validation would be useless) or doesn't know it (user input) we don't try to make a guess that is expensive.
5. Manual locking and transaction handling for incrementing a column
Benjamin: For the low level access to transactions we want to support an AUTOCOMMIT=NO mode in a next release that opens a transaction right after connection and always after each commit.
6. One query for each loop iteration
Benjamin: You should use DQL to set all visits to 0. Query: $em->createQuery("UPDATE Article a SET a.visits = 0")->execute().
Jakub: I know, DQL again. However if I choose such a complex library as Doctrine is, I really don't want to use this low-level stuff.
Benjamin: DQL is not low-level, its an abstraction over SQL. :-) I know you would disagree, but your abstraction fails on complex requirements where as DQL can solve almost all of them. Its more complex to learn, but on the other side resembles SQL more, which is easier for developers with SQL knowledge to understand. Furthermore I wouldn't suggest to someone who doesnt know SQL to use an ORM like Doctrine or Propel. You have to be very well aware what the abstraction is actually doing for you, otherwise you end up with a performance nightmare anyways and the abstraction doesn't do you any good.
Jakub: Can you please describe some example of complex requirement where NotORM syntax is not sufficient?
7. Auto-generated code for proxy
Benjamin: We clearly document that proxies are generated. You can generate them manually and not have Doctrine do it on runtime.
Jakub: And I still don't want any generated code in my project and I surely don't want to write this code by myself.
Benjamin: I hate that we have to generate this code myself, i'd rather have PHP allow to modify core object methods such as Ruby does. However we plan to implement two methods that don't generate the code (visibily) for you, one ugly approach using eval for development and one approach using Streamwrappers and relying on APC to cache only the PHP bytecode of the generated code.
Comments
sidik:
Well, as I still see all the pointing to DQL, I have to ask... Why should I use Doctrine, if in the end, I still have to write down SQL?I know that some stuff simply can't be generated but Jakubs examples are pretty simple, nothing complicated. And yet, he's pointed to use DQL. So, what is the difference between using plain SQL and using Doctrine?
Ondřej Mirtes:
The decision-making to use/not to use Doctrine is not about if you want to write SQL queries or not. It's about an approach how to write apps in PHP. If you want to use pure OOP, Doctrine will manage saving your objects to the database and returning them in the same state for you - that's called persistence.
NotORM is at much lower level layer - it just generates SQL queries for you.
Ondřej Mirtes: jirka d.:
I dont really understand the BIG advantage of using Doctrine...I see only problems, some of them noted by Jakub. Yes, NotORM maybe much lower level layer, but it can handle complex things with no problems absolutely smoothly (or if you thing that handling 20+ related tables with 10000+ records) and the logic behind seems to be clear to people that didnt work with NotORM before.The bad thing about NotORM is just one - bad name IMHO...:)
Diskuse je zrušena z důvodu spamu.
© 2005-2024 