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 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.
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.
On Friday, 14 March 2014 09:32:05 UTC-4, Jan Brdo wrote:
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 J.