jnicklas/carrierwave-mongoid — Issue #23: Mongoid 2.3 and its dirty module
Author: did
Created: 2011-12-06 19:30:31+00:00
State: open

I noticed a (tiny) bug when I tried to update an instance of a model whose the related uploader had a custom store_dir based on a field from the model itself.

````ruby
module Locomotive
class ThemeAssetUploader < ::CarrierWave::Uploader::Base

def store_dir
self.build_store_dir('sites', model.site_id, 'theme', model.folder)
end

....
end

class ThemeAsset
...
mount_uploader :source, ThemeAssetUploader, :mount_on => :source_filename
...
end
````

So, if I modify the folder field of an existing instance, the previous file is not deleted. Actually, that's not my issue because the workaround is this case is to call source_filename_will_change! before validating the model.

Except that source_filename_will_change! from Mongoid does not have the same behaviour as the one in AR. Thus, even if you call xxx_will_change!, xxx_changed? won't be true unless you modify its value directly.

The reason behind this behavior is that mongoid still compares the current value and the previous one when calling xxx_changed?. AR instead just checks if the attribute is included in the hash of modified attributes (will_change! puts the attribute in this hash).

Right now, I don't have time to figure out a nice way to solve this. And to be honest, I think that has to be fixed in mongoid.

Anyway, what I came up with in order to force the will_change! stuff is the following line:

````ruby
my_theme_asset.changed_attributes[:source_filename] = nil
````

At least, the problem has been tracked down.
thanks

Did