Forum: Ruby on Rails polymorphic join, object.destroy issue

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.
Ar C. (Guest)
on 2008-10-31 16:13
My generic routine looks like this:

def update_linked_poly_side(base_side, ids, poly_side)
  # get back the current linked items, and the base part
  # of the polymorphic field names, like 'appllinkable'
  linked, poly_base = self.polymorphic_info base_side
  id_attr = base_side+'_id'
  linked.each do |link|
    linked_model_id = (link.send id_attr).to_s
    link.destroy unless ids.include(linked_model_id)
    ids.delete(linked_model_id)
  end
  ids.each do |id|
    linked.create(blah blah blah - create works fine)
  end
end

The link.destroy works fine for the first link that is currently
linked but isn't in the ids list, but it doesn't work for any
subsequent links that should also be destroyed.

Runtime logging (not in the code above for clarity) reports:
at entry,
  3 appllink objects, ids ["3", "1", "2"] in linked (correct)
  poly_base = 'applinkable' (correct)
  ids = ["", "2"]
  in the linked.each do |link| loop
  it looks for "3" in ids, doesn't find it and logs:
    SQL (0.000694)  BEGIN
    Appllink Destroy (0.000345) DELETE FROM 'appllinks'
      WHERE 'id' = 9
    SQL (0.001159)  COMMIT

  then it looks for "1" in ids, doesn't find it and logs:
    SQL (0.000138)  BEGIN
    SQL (0.000137)  COMMIT

There isn't an issue with the first linked item that is to be deleted,
but there isn't a SQL statement generated for any subsequent items that
should be removed... adding new linked items works just fine (that's in
the ids.each do |id| loop).

Any ideas? Anyone? Oh, and Rails 2.1.0, Ubuntu 8.04, Ruby 1.8.6
Ar C. (Guest)
on 2008-10-31 16:55
Curiouser and curiouser...

I changed the config.cache_store from :mem_cache_store to :file_store,
and the proper SQLs are generated for all the deletes.

Clearly I have some reading up on memcached to do... perhaps this was
tied up in some model caching I wasn't aware that I was doing.
This topic is locked and can not be replied to.