4 ms·

Doctrine 2 also often spends 10x the time on post-processing the data from the database as it does actually making the database calls itself (it's not fixable w

by joesmo 10y ago

Doctrine 2 also often spends 10x the time on post-processing the data from the database as it does actually making the database calls itself (it's not fixable without dropping to straight SQL out of the ORM). Its query language is atrocious and unnecessary. Their ideas of joins and internals are absolutely horrific. The boilerplate is 1/3 of my app. But even if it was the perfect piece of code (it's exactly the opposite: total and utter shit), I'm not going to slow down all my DB queries 10x for anything, not to mention the incredibly slow development speed of now having two query languages and a million wrong ways of making simple queries and no ways of making proper advanced queries. Everything with Doctrine takes many times longer than with straight SQL even after years of working with it. I have yet to find an ORM that doesn't have egregious failings like Doctrine 2. It is inherent in the stupid concept of ORMs that implementations fail. See: http://solnic.eu/2015/09/18/ditch-your-orm.html http://solnic.eu/2015/09/18/ditch-your-orm.html http://seldo.com/weblog/2011/06/15/orm_is_an_antipattern http://seldo.com/weblog/2011/06/15/orm_is_an_antipattern and most importantly, see benchmarks for ORMs like Doctrine and observe their destructive effects on programmer productivity.

codedokode 10y ago
I agree, Doctrine has performance problems. I did some microbenchmarks too. But you could try to optimize (or write your own custom) mapping code, or maybe you could load less entities or write a better ORM. Sometimes you have to use SQL queries too (when the result of a query cannot be mapped to entities). The "SQL and arrays" approach is much worse and doesn't scale. Without ORM and classes you will get undocumented JSON trees (or arrays) passed around. > http://solnic.eu/2015/09/18/ditch-your-orm.html http://solnic.eu/2015/09/18/ditch-your-orm.html It seems to me that author wants to replace complex approach (OOP and ORM) with even more complex one. So instead of having one object representing an entity we can have ten objects representing the entity at different moments in time. So we have to find out which one is the latest. And we will need even more memory to keep them. He writes: > There is no User but it’s very likely there is SignupUser. And soon there will be LoginUser, GuestUser, ProfileEditUser, UserForReport and others. And a bunch of methods to convert between them. I don't understand what is the problem with mutable entities. They are supposed to be mutable. I never had problems because of functions modifying arguments given to them. I don't believe functional programming can be use instead of OOP. Can you represent a DOM tree, collection of GUI widgets, a graph of related database entitites, a form with validation rules with functional programming? You will just end up emulating classes and objects. The author probably just likes the idealized concept and did not try to apply it to a real world application (but if anyone did it would be interesting to see the code). I also took a look at Ruby Object Mapper he mentions in a post and don't really like it. It uses arrays (that are called ROM::Struct there) a lot and I don't see much functional programming there. I also have read this article http://seldo.com/weblog/2011/06/15/orm_is_an_antipattern http://seldo.com/weblog/2011/06/15/orm_is_an_antipattern and I partially disagree with the conclusion. Using key-value storage instead of a database is generally bad idea. It doesn't solve "N + 1 queries" problem, it doesn't provide foreign keys (and often transactions), and you have to write messy custom code instead of shorter and better readable SQL query (example: https://www.kchodorow.com/blog/wp-content/uploads/2011/12/SQL-to-MongoDB2.jpg https://www.kchodorow.com/blog/wp-content/uploads/2011/12/SQ... ).
- throwanem 10y ago
  > And soon there will be LoginUser, GuestUser, ProfileEditUser, UserForReport and others You...really can't think in any paradigm other than object-oriented everything, can you? I mean I guess it works for you and that's great but please stop you're really scaring me now.

by joesmo 10y ago

codedokode 10y ago

I agree, Doctrine has performance problems. I did some microbenchmarks too. But you could try to optimize (or write your own custom) mapping code, or maybe you could load less entities or write a better ORM. Sometimes you have to use SQL queries too (when the result of a query cannot be mapped to entities). The "SQL and arrays" approach is much worse and doesn't scale. Without ORM and classes you will get undocumented JSON trees (or arrays) passed around. > http://solnic.eu/2015/09/18/ditch-your-orm.html http://solnic.eu/2015/09/18/ditch-your-orm.html It seems to me that author wants to replace complex approach (OOP and ORM) with even more complex one. So instead of having one object representing an entity we can have ten objects representing the entity at different moments in time. So we have to find out which one is the latest. And we will need even more memory to keep them. He writes: > There is no User but it’s very likely there is SignupUser. And soon there will be LoginUser, GuestUser, ProfileEditUser, UserForReport and others. And a bunch of methods to convert between them. I don't understand what is the problem with mutable entities. They are supposed to be mutable. I never had problems because of functions modifying arguments given to them. I don't believe functional programming can be use instead of OOP. Can you represent a DOM tree, collection of GUI widgets, a graph of related database entitites, a form with validation rules with functional programming? You will just end up emulating classes and objects. The author probably just likes the idealized concept and did not try to apply it to a real world application (but if anyone did it would be interesting to see the code). I also took a look at Ruby Object Mapper he mentions in a post and don't really like it. It uses arrays (that are called ROM::Struct there) a lot and I don't see much functional programming there. I also have read this article http://seldo.com/weblog/2011/06/15/orm_is_an_antipattern http://seldo.com/weblog/2011/06/15/orm_is_an_antipattern and I partially disagree with the conclusion. Using key-value storage instead of a database is generally bad idea. It doesn't solve "N + 1 queries" problem, it doesn't provide foreign keys (and often transactions), and you have to write messy custom code instead of shorter and better readable SQL query (example: https://www.kchodorow.com/blog/wp-content/uploads/2011/12/SQL-to-MongoDB2.jpg https://www.kchodorow.com/blog/wp-content/uploads/2011/12/SQ... ).

throwanem 10y ago
> And soon there will be LoginUser, GuestUser, ProfileEditUser, UserForReport and others You...really can't think in any paradigm other than object-oriented everything, can you? I mean I guess it works for you and that's great but please stop you're really scaring me now.