Attachment_fu: loading objects w/ attachments in batch?

Using the (very nifty) attachment_fu plugin. It would be very
convenient if I could batch-load a lot of my model objects that have
attachments, instead of having to load them interactively via a web

Experimented with calling uploaded_data= directly, but didn’t work,
and I’m not sure that’s the right route. Any suggestions?



Not sure if this is what you’re after or not. We have some scenarios
in which we create files (reports) on the webserver in response to a
user request and then save them on the server using an attachment_fu-
based model. It’s similar in that we’re creating the model with a
file but avoiding the interactive part.

It was as simple as setting .temp_path. Note that this works
for us because we’re storing objects in the file system rather than
the DB/S3. temp_path is mixed in for file system storage; not sure
about the others.

Hmm, that might work. Will investigate.



Aha. seems to provide a way to do this
(in the middle of a discourse about duck typing…)


Actually, having followed a suggestion in the comments to that blog
entry, there’s even an easier way (below, ImageMetadata is my class
that has_attachment):


Mime::Type.register “image/gif”, :gif
=> [“gif”]

t =‘db/seed-data//tile-samples/bippy2.gif’, Mime::GIF)
=> #<ActionController::TestUploadedFile:0xb70358d8
@original_filename=“bippy2.gif”, @content_type=#<Mime::Type:0xb7039974
@synonyms=[], @symbol=:gif, @string=“image/gif”>, @tempfile=#<File:/

m =
=> #<ImageMetadata id: nil, size: nil, content_type: nil, filename:
nil, height: nil, width: nil, parent_id: nil, thumbnail: nil,
property_value_id: nil, created_at: nil, updated_at: nil>

m.uploaded_data = t
=> #<ActionController::TestUploadedFile:0xb70358d8
@original_filename=“bippy2.gif”, @content_type=#<Mime::Type:0xb7039974
@synonyms=[], @symbol=:gif, @string=“image/gif”>, @tempfile=#<File:/
=> true

Seems like sorta a pain that you have to explicitly set the mime type,
but hey, small price to pay…


This forum is not affiliated to the Ruby language, Ruby on Rails framework, nor any Ruby applications discussed here.

| Privacy Policy | Terms of Service | Remote Ruby Jobs