I think the error makes sense with update_columns and not with
update_attributes. Since the former is essentially a pass through to the
database, and the database would raise an error without any columns to
update, I'd expect an error when the method is used that way as well.
On Thursday, May 7, 2
Yes. It is raised by `update_all(attributes)`.
On Thu, May 7, 2015 at 3:19 PM Xavier Noria wrote:
> It makes sense to me, you get passed a hash with the attributes to update,
> which could be none.
>
> This is a no-op edge-case similar to append an empty list to a list, etc.,
> and could have us
This behavior was added at https://github.com/rails/rails/pull/7133.
Also don't assume that `update_attributes` and `update_columns` are
analogues. The later is dealing directly with the database without any kind
of interaction with the object instance, so they will behaves differently
in a lot of
And what happen if users expect N to be between 1 and and we
silently do nothing when 0 is sent to these methods?
In my opinion if you don't have changes to be made in the database, just
don't call the method.
On Thu, May 7, 2015 at 2:47 PM Michael Mahemoff wrote:
> Bah I mean "N is between 0
It makes sense to me, you get passed a hash with the attributes to update,
which could be none.
This is a no-op edge-case similar to append an empty list to a list, etc.,
and could have use cases where the hash is built programatically.
The implementation generally uses iterators, which is the no
Bah I mean "N is between 0 and " (rather than 1 and ).
On Thursday, 7 May 2015 18:46:51 UTC+1, Michael Mahemoff wrote:
>
> Basically because http://en.wikipedia.org/wiki/Null_Object_pattern. It's
> often the case that systems have to deal with "N" possible changes, where N
> is between 0 and 1.
Basically because http://en.wikipedia.org/wiki/Null_Object_pattern. It's
often the case that systems have to deal with "N" possible changes, where N
is between 0 and 1. e.g. I might have a procedure to gradually build up a
list of things to change, starting with {} and appending to it if certain
Are not both cases invalid input? Why should we accept empty hashes?
On Thu, May 7, 2015 at 2:14 PM Michael Mahemoff wrote:
> The following will return an error:
>
> > Post.first.update_columns({})
> ArgumentError: Empty list of attributes to change
>
> I think that's surprising, because
The following will return an error:
> Post.first.update_columns({})
ArgumentError: Empty list of attributes to change
I think that's surprising, because I see update_columns as an analogue to
update_attributes, just without callbacks happening. An empty hash for the
latter is fine:
I'm :-1: on all file based YML config. :+1: on env based config.
Either way, I would suggest writing it up as a gem to get some real world
feedback.
---Richard Schneeman
http://www.schneems.com
On Tue, May 5, 2015 at 1:00 PM, Kyle Rippey wrote:
> I was considering creating a pull request
10 matches
Mail list logo
