I've found that if I clear the cache in the rescue section
instead:

  p.class.connection.clear_query_cache

it still works, and this feels like a better place to do this,
since I'm pretty sure the issue is that rolling back the
transaction is what causes the cache and the live database to
get out of sync.

So what I'm wondering now is, is this a rails problem or is
it a problem with me misunderstanding something?  From my
admittedly ignorant perspective, it seems like a cache
clear would always be a good thing to automatically do after
a transaction rollback.

        -glenn

Glenn Little wrote:
> I've got a situation where at least on the surface it appears I'm
> the victim of some aggressive caching.  I've got something like:
> 
> Child belongs_to :parent
> 
> I have a method in Parent
> 
> def special_children
> list = []
> Child.find_all_by_applicant_id(self.id).each do |c|
>   <do some calculating and picking and choosing, and
>    build up "list" as we go>
> end
> return list
> end
> 
> I also explicitly do *not* want to have an association available that
> just returns all children, thus no has_many in the Parent definition.
> 
> My problem is that there are times when I do something like:
> 
> p = Parent.find(<blah>)
> # may already have children, but add more...
> c = Child.new(params)
> 
> begin
> Parent.transaction do
>   c.parent = p
>   p.save!
>   c.save!
>   if (some set of conditions)
>     raise "no can do"
>   end
> end
> rescue
> do something with p.special_children
> end
> 
> But in the rescue, special_children includes the new child that never 
> actually was saved.  It's not in the database.
> 
> Parent.clear_association_cache does not help, I think because 
> Parent.special_children is not really an association.
> 
> The *only* thing I've had work so far is to add
> 
>  ActiveRecord::Base.connection.clear_query_cache
> 
> to my special_children method.
> 
> My question is, is that really an acceptable fix?  Feels like using
> a howitzer to swat a mosquito.
> 
> I'm on the very edge of understanding here, so if anyone sees a cleaner
> alternate approach, I'd love to hear it.  I think my special_children
> logic may be a bit much to be able to just stuff into a :conditions
> clause in a has_many, but I haven't pushed too hard on that yet.
> 
> Thanks in advance...
> 
>     -glenn

--~--~---------~--~----~------------~-------~--~----~
SD Ruby mailing list
[email protected]
http://groups.google.com/group/sdruby
-~----------~----~----~----~------~----~------~--~---

Reply via email to