Piotr Solnica

For those unaware, this project was previously called Lotus. I think this is being upvoted because it was mentioned in the recently popular solnic[0] blog post. [0] http://solnic.eu/2016/05/22/my-time-with-rails-is-up.html

Not too Java-y, but too "DataMapper-y" for most Rails devs, I think (the pattern, not the ORM - the Ruby DataMapper ORM implements the ActiveRecord pattern, though DataMapper 2 actually finally will implement DataMapper) EDIT: This is an interesting overview of where DataMapper 2 is going as a parallel to your example: http://solnic.eu/2012/01/10/ruby-datamapper-status.html

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 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…

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://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.

Rails used as intended can be a real pain to upgrade, I agree. Recently I have been developing applications in the "thin-model, thin-controller, with a service layer and external API wrappers" style, as espoused by Gary Bernhardt [1] and others [2] [3] [4] [5]. I upgraded to the latest Rails this morning on one app, and apart from swapping the Money gem to use the git repository, until they have a new version out with compatible dependency, it went smoothly. All the specs and acceptance tests passing with no alteration required. [1] https://github.com/garybernhardt/sucks-rocks [2] http://jamesgolick.com/2010/3/14/crazy-heretical-and-awesome-the-way-i… [3] http://objectsonrails.com/ [4] http://solnic.eu/2011/08/01/making-activerecord-models-thin.html [5] https://www.youtube.com/watch?v=CGN4RFkhH2M