Re:My time with Rails is up
by ryanbrunner on Sunday May 22, 2016 @01:50PM
(#11749516)
That's a totally valid point, but is 100% orthogonal to what's being discussed. Invoking a single command to validate, run callbacks, persist to the database, etc, etc. a model (and the larger argument of whether conflating DB access and persistence logic is a good thing) has nothing to do with whether the object is aware of it's own properties.
They are both critcisms of ActiveRecord, for sure, but quite a bit different in content. One (AR objects not knowing their own properties) feels, at least to me, like an unfortunate early design decision, while the other (encapsulating everything involved with saving a model in a single statement, "magic avoidance" be damned) is very much in line with the core philosophy of ActiveRecord and Rails.
> a single object or an entire object graph must be stored in the database
Hence "the last point" (though you might have caught me mid-edit). I view these as functionally the same problem: not only are you instantiating the object, but it must immediately go to live in the database or it's useless.
But you're right in that it is a philosophical problem. Rails is wrong. =)
There are always pros/cons to any approach one can as easily argue that without AR your code is less DRY as you need to keep your models in sync with your DB schema manually. (I am not a fan of AR either)
You could easily build a unit test that compares the set of exposed properties of your model class with the columns of the table in your test DB.
That's not really a unit test and not really a good idea to do it this way. You'll still have to keep model in sync with schema you'll just know when they diverge.
There's enough context for me to start putting up the horns and cheering, because AR is one of the more persistent boils on my ass when I'm building things in Ruby (because I use Ruby for Ruby, rather than Rails, my frontends are all JavaScript and my services are all Grape). His last point is sufficient to me to demonstrate inadequate separation of concerns--the better design is the one that doesn't require an active database connection to know what fields the object has in it. Answering "how do I build an SOA without every service having a line to every database?" inevitably becomes "don't use ActiveRecord, ever".
What solnic has done with Virtus (which I use in all my projects, it's awesome, he's one of my favorite current Ruby people because of it and I'm sad that he may be leaving) is to return to the novel notion that an object knows what's in it. Dumb data objects are in almost every case a better long-term strategy, and solnic's frustration, if not expressed perfectly, is one that inevitably burns even Rails projects that grow to scale. And while this is a single example of Rails's monolithic nature choking out a lot of the Ruby ecosystem, it's not the only one (see his comments on ActiveSupport).