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
on 2008-10-31 16:13
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.