Wouldn’t it make sense to freeze the array object that is returned by ActiveRecord when you have an array in Postgres? That would prevent accidentally changing the array and forgetting to mark it as dirty. The point being that changing the array does not register with AR and so it is not saved to DB upon calling save.
If that is true, the solution would be to properly mark the object as dirty when the array changes, not freeze the array. Why should this data type behave differently than all the others?
That would mean monkey-patching the Array instance that is returned or wrapping it (and also doing that if something new is assigned). I’m not against it, but I think the general consensus is to avoid stuff like that in core Rails.
I don’t see why that’s true. It would be simple enough to use a proper OO solution, such as writing a class that has the same interface as an Array but tracks changes, or to extend Array instances with a module that does the same.
I remember there was some discussion at some point in time about doing something like that and it was dismissed for some reason, but I could be wrong. Of course that would be ideal, to track the dirty state. On the other hand freezing the array is much easier and less complex to implement so it could at least be the first step, if we want to see it in Rails any time soon. I think we do need something, because right now it’s really prone to user error. HStore also has this issue I think.
Don’t get me wrong I think wrapping the array is the better long-term solution, if it’s done the right way, but since it’s a bit more complex it might take longer to get it upstream.
In general, the Rails philosophy is “trust that the developer knows what they’re doing”, not “hide all the sharp bits because somebody might get hurt”. Don’t expect the framework to keep you from shooting yourself in the foot, write tests that verify you are aiming in the right direction.
–Matt Jones