After skimming the “What’s New” posts for several Rails versions without finding anything worth jumping at, it was time to upgrade. While JSON enhancements (fixes) are the driving reason for the move, there certainly are a few “nice to haves” that I’ve been looking forward to checking out.
Unfortunately, one of the things I’ve been looking forward to completely falls flat in my book… Partial Updates (to some extent: Dirty Objects).
When I first read the paragraph-blurb about this addition I was pretty impressed and was looking forward to seeing how it was implemented. I was much less impressed when I got my head under the hood. Relying totally on use of ActiveRecord setter methods is a pretty big fail in my book. Tracking down every place that a field is edited “in place” to specially flag it (xyz_will_change) is completely unreasonable and maintaining that rule going forward is an annoyance that I just don’t need.
I played with several ways of attempting to set flags when changes were “likely” (ex: when getters were used) or always flagging “likely to be edited in place” attributes (ex: serialized fields) but just was ending up with lots of additional complexity, reduced reliability, and basically voiding out any gained efficiency.
Having this enabled by default (apparently the plan) is just plain confusing: Seems much more reasonable to enabled this when you know it’s going to benefit you. I also don’t like that it adds another question for a new developer to ask (or get tripped up on) when joining a project. I really don’t want to have to read every line of the new guys code for the first three months to make sure that he’s sticking to the rules (and setting up tests to verify it explicitly).
Null values are now flagged as such instead of just being blank, like they would look if they were… uh… blank. This is a good thing – it also tripped me up for a bit.
It seems eager loading has been changed a bit. Statements that used to result in :include items being joined right into a single large query now (may) result in several smaller statements.
Does it make queries more efficient? Probably.
Does it increase db traffic? Probably.
Is it a bad thing? Probably Not (overall).
Is it a bad thing that stuff that worked before doesn’t? Yeah, that’s annoying.
My specific problem is on an association defined with a :select => “distinct labels.*”. I played around a bit with potential changes down in the AR guts but in the end (unfortunately) I ended up basically tricking it into running it as a single statement. It’s not at all difficult to make it happen but it’s also not at all straightforward – and I hate it when the framework makes me write a big comment.
For me, I added an :order to my find that would make it order by something in a different table, which scares the thing into running a single statement. Ideally, I’d like to have something explicit (maybe on the association but more likely on the find itself) that would allow an optional param to say “run this as one statement”. That would let someone reading the code clearly see what’s going on – instead of wondering (or more likely: not noticing) that I’m ordering by some pointless field.
Not nearly as bad as I had expected. Felt good to get some deprecated stuff fixed and get some of my old TODOs out of there in the process. Also good to have it (almost) over with and to, at least temporarily,have caught up with the Joneses.