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.
Benjamin: Number of queries in save Article can be brought to one single
INSERT by using
$em->getReference() instead of
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.
NULL if no result was found. This is described in the API docs.
getReference solves this too.
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.
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.
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?
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.