When after_save isn't after the save....

rubyonrails-talk
#1

I have a Production model, which represents a farmer's crop. After
create (via after_save) I call a method that creates one or more
Supply models, which represent a week of anticipated product harvest.
After each of those are created, a class method gets called that tries
to match each new Supply with outstanding orders for the same time
period. If a match is made, a transaction (an Exchange model acting as
the join record) is created and it adjusts the quantities in both the
Supply and Order models.

Well, it ain't working. I mean, it almost does, but after_save filter
seems to be calling methods during the transaction, not after the
commit. The quantity updates on the Supply and Order models are
getting blown away. It seems I was mislead by the name of
"after_save".

before_save doesn't work because the id for the Production hasn't been
assigned and the relationships can't be set then.

First, are my observations about after_save and the transaction
correct? Second, is there another callback filter I should be using
instead, one that happens after the transaction? Or is my design
suspect? Recommendations welcome.

Thanks! :slight_smile:

#2

FYI: I'm using rails 3.0.0.rc + ruby 1.8.7 + sqlite3 for dev, postgre
for prod.

#3

I have a Production model, which represents a farmer's crop. After
create (via after_save) I call a method that creates one or more
Supply models, which represent a week of anticipated product harvest.
After each of those are created, a class method gets called that tries
to match each new Supply with outstanding orders for the same time
period. If a match is made, a transaction (an Exchange model acting as
the join record) is created and it adjusts the quantities in both the
Supply and Order models.

Well, it ain't working. I mean, it almost does, but after_save filter
seems to be calling methods during the transaction, not after the
commit. The quantity updates on the Supply and Order models are
getting blown away. It seems I was mislead by the name of
"after_save".

before_save doesn't work because the id for the Production hasn't been
assigned and the relationships can't be set then.

First, are my observations about after_save and the transaction
correct? Second, is there another callback filter I should be using
instead, one that happens after the transaction? Or is my design
suspect? Recommendations welcome.

the entirety of before_save, save, after_save is run in a single
transaction. I don't understand why this is causing you a problem
though - could you elaborate.

Fred

#4

Thanks, Fred. I think you've helped me out before. I appreciate your
effort.

I've put the relevant code here: http://pastie.org/1100297

So you know what's happening, the farmer creates a Production, which
creates one or more Supplies, which may create one or more Exchanges
if there are any Demands that match the Supply.

The Exchange is supposed to decrement the "available" variable in both
the Supply and Demand models (the "quantity" variable doesn't change).

On exchange.rb#18 where the debugger stops, the values of
demand.available and supply.available have been correctly decremented.
After I let the code continue, they are back to their original values.

Thanks again.

#5

Thanks, Fred. I think you've helped me out before. I appreciate your
effort.

I've put the relevant code here:http://pastie.org/1100297

So you know what's happening, the farmer creates a Production, which
creates one or more Supplies, which may create one or more Exchanges
if there are any Demands that match the Supply.

The Exchange is supposed to decrement the "available" variable in both
the Supply and Demand models (the "quantity" variable doesn't change).

On exchange.rb#18 where the debugger stops, the values of
demand.available and supply.available have been correctly decremented.
After I let the code continue, they are back to their original values.

You don't seem to be saving the demand or supply objects after you
modify them in that after_save. Are you doing that somewhere else?

Fred

#6

It doesn't look your saving the supply & semand objects you're
modifying. Are you doing that somewhere else?

Fred

#7

IAmNan wrote:

I've put the relevant code here: http://pastie.org/1100297

So you know what's happening, the farmer creates a Production, which
creates one or more Supplies, which may create one or more Exchanges
if there are any Demands that match the Supply.

The Exchange is supposed to decrement the "available" variable in both
the Supply and Demand models (the "quantity" variable doesn't change).

On exchange.rb#18 where the debugger stops, the values of
demand.available and supply.available have been correctly decremented.
After I let the code continue, they are back to their original values.

Maybe what you're trying to do is a bit too complex for use in
after_save. Maybe it should instead be done using a transaction. I'm not
100% sure, but worth a try:

http://api.rubyonrails.org/classes/ActiveRecord/Transactions/ClassMethods.html

#8

Thanks Fred and Robert and anyone else who has read this!

I've had some more time to look at this and it appears there is no way
in rails to modify a parent model's attributes from a child model
during a transaction. I wrote a basic app to test it out.

Assume Parent has_many Children and Child belongs_to Parent. Also,
Parent has a before_save filter (we'll look at what it does in a
moment). Child also has a before_filter that updates an attribute in
it's Parent.

Version 1: In one example, the Parent's before_save filter *builds*
three Children. Because it is a "build" and not a new or create, the
child objects are saved when the parent is saved. In this case, the
child's change to its parent attribute just disappears, although the
Child is successfully instantiated. http://pastie.org/1106223

Version 2: Okay, then I tried the same thing, this time using create
instead of build in the Parent's before_save filter. That generates an
error, "You cannot call create unless the parent is saved." Which
makes sense.

Version 3: Same as Version 1, but make the Parent's filter after_save.
In this case, the before_filter of the children is never called (and
same result if the Child's filter is changed to an after_save, it just
isn't called).

Version 4: Same as Version 1, but remove the callback in the child and
just call that method directly from the parent immediately after the
build. You get a "undefined method" from the Child's method because
the parent is nil at this point.

Version 5: Like Version 4, but uses after_save instead of before_save.
The results are just like Version 1, the Child's method is called,
changes to the Parent aren't saved, but the children are saved.

In these examples, I used
  Parent.create
and
  p=Parent.new
  p.save
and get the same results each time. The results are also in the pastie
(http://pastie.org/1106223).

So, if there are limitations on what you can do in a callback filter,
we should probably documented it somewhere. However, I might even
call it a bug. What do you think?

d.

#9

So, if there are limitations on what you can do in a callback filter,
we should probably documented it somewhere. However, I might even
call it a bug. What do you think?

Doesn't sound like anything to do with callbacks to me. I think the
root of the problem is that there are multiple instances of parent in
memory - the one you created explicitly, and the ones loaded from the
database when you call parent from the child object. Although they
refer to the same row in the database, they are distinct in memory
objects (if you inspect the value of parent it should change). There's
a plugin (parental_control) that goes someway to fixing this by adding
trunk (not in rails 2.3.x if my memory is correct)

Fred

#10

If you really want callbacks after commit, you might try
http://github.com/freelancing-god/after_commit

- D

#11

Thanks Fred and Danny. Fred thanks for the explanation. As mentioned,
I am using Rails 3 and both I have them both native. I go from few
options to several. Maybe I can clean up my code a little now.
Sweet! :slight_smile:

I totally wouldn't have expected your explanation, Fred, but I see now
it's right. I am struggling to think of a case where I would want two
instances of the same object in memory since it would lead to a race
condition most of the time. Hence, I am also wondering why :inverse_of
isn't the default behavior. Maybe it's performance. Rhetorical, you
don't need to answer those as I'll check them out in my own time.

Thanks again.

#12

Thanks Fred and Danny. Fred thanks for the explanation. As mentioned,
I am using Rails 3 and both I have them both native. I go from few
options to several. Maybe I can clean up my code a little now.
Sweet! :slight_smile:

I totally wouldn't have expected your explanation, Fred, but I see now
it's right. I am struggling to think of a case where I would want two
instances of the same object in memory since it would lead to a race
condition most of the time. Hence, I am also wondering why :inverse_of
isn't the default behavior. Maybe it's performance. Rhetorical, you
don't need to answer those as I'll check them out in my own time.

Inverse_of isn't automatic because in the non trivial cases it may not
be obvious which associations are the inverse of which. Having
multiple copies of an object in memory is generally undesirable (eg
data mapper doesn;t do this), but is not particularly easy to change
(especially if backwards compatibility is a concern).

Fred

More Resources

Keep up to date with Rails on Twitter and This Week in Rails

Policies: Conduct, License, Maintenance, Security, Trademarks