Forum: Ruby on Rails before_save gotcha

Announcement (2017-05-07): www.ruby-forum.com is now read-only since I unfortunately do not have the time to support and maintain the forum any more. Please see rubyonrails.org/community and ruby-lang.org/en/community for other Rails- und Ruby-related community platforms.
Pawel S. (Guest)
on 2006-02-10 22:46
(Received via mailing list)
Is it will known and accepted that before_save triggers should return
true? I didn't notice this before but now I see it in the
documentation.

Here is what I'm doing in my model:

  def before_save
    if self.has_album?
      self.visible = self.album.visible?
    end
  end

That results in the expected result when album.visible? is true - but
not when it is false. To make it work correctly, I have to explicitly
return true at the end.

  def before_save
    if self.has_album?
      self.visible = self.album.visible?
    end
    true
  end

Is that what I am supposed to do? It feels so wrong and C-like.. is
there a better way?

-Pawel
Marcel Molina Jr. (Guest)
on 2006-02-10 22:50
(Received via mailing list)
On Fri, Feb 10, 2006 at 12:46:18PM -0800, Pawel S. wrote:
> Is it will known and accepted that before_save triggers should return
> true? I didn't notice this before but now I see it in the
> documentation.

It is not that they should return true, it is that they should *not*
return
false.

Returning nil or any boolean true value is fine, but the request chain
will
be halted if a before_filter returns false.

marcel
Pawel S. (Guest)
on 2006-02-10 23:02
(Received via mailing list)
On 2/10/06, Marcel Molina Jr. <removed_email_address@domain.invalid> wrote:
> On Fri, Feb 10, 2006 at 12:46:18PM -0800, Pawel S. wrote:
> > Is it will known and accepted that before_save triggers should return
> > true? I didn't notice this before but now I see it in the
> > documentation.
>
> It is not that they should return true, it is that they should *not* return
> false.

Yes - sorry, I worded that unclearly. In my head, anything not false is
true. :)

Still, it's easy to accidentally return false when updating boolean
fields like that - it took me a while to track down too. I'm afraid I
may start putting a true at the end of all of my trigger callbacks out
of sheer paranoia!

-Pawel
Joe M. (Guest)
on 2006-02-10 23:06
(Received via mailing list)
>not false is true.
true

I had too...its Friday :)
Marcel Molina Jr. (Guest)
on 2006-02-10 23:12
(Received via mailing list)
On Fri, Feb 10, 2006 at 01:01:18PM -0800, Pawel S. wrote:
>
> Still, it's easy to accidentally return false when updating boolean
> fields like that - it took me a while to track down too. I'm afraid I
> may start putting a true at the end of all of my trigger callbacks out
> of sheer paranoia!

You should always be able to know if an expression is going to return
nil or
false in the case that it is boolean false. Usually it will return nil
unless
you explicitly implement something to return false or are using
operators
like ! or && that result in true or false. So, no need to be paranoid.
Just
be mindful. Your functional tests will catch you if you slip up and the
development log will indicate if a before_filter halted the filter
chain.

marcel
This topic is locked and can not be replied to.