Moving attachment to new record?

[GreenAsJade]

How can I "move" an attachment from one record to another?

Right now my app has lots of Things with has_attached_file

I'm at the point where some of these need to be changed into
OtherThings.

This means creating new OtherThings, and having them take on ownership
of the attached file, then deleting the original Thing.

Unfortunately, I can't figure an easy way to do this. I *can* figure
out how to make a new OtherThing get set up so that it has the same
attached file as a given Thing.
(just a matter of copying the few attributes needed).

However, I can't see how to safely delete the old Thing without this
causing the attached file to be deleted.

Can I somehow "undo" the effect of "has_attached_file" for a
particular record, so that when I delete that record, the attachment
is not deleted?

Thanks!

[kenny....@gmail.com]

I've done this on my project

o = OtherThing.new
o.file = old_thing.file
o.save!
old_thing.destroy

The new object will have the file. And the old objects file will be removed
Sent from my Verizon Wireless BlackBerry

-----Original Message-----
From: GreenAsJade <martin.j...@gmail.com>

Date: Wed, 27 May 2009 18:03:27
To: Paperclip Plugin<papercli...@googlegroups.com>
Subject: Moving attachment to new record?

[GreenAsJade]

Thanks heaps for the fast reply.

> And the old objects file will be removed

This looks like it would copy the file, physically, is that right?

I was looking for a way that would not touch the file at all (just
end up with the new record pointing exactly at the old one), but
actually there's no reason why this has to be the case.

However... will it work with :storage=>s3 ?

Thanks again!

Martin

[GreenAsJade]

On May 28, 10:35 am, kenny.ortm...@gmail.com wrote:
> I've done this on my project
>
> o = OtherThing.new
> o.file = old_thing.file
> o.save!
> old_thing.destroy
>
> The new object will have the file. And the old objects file will be removed

Actually, I don't really understand how this will work.

The underlying file name for the attached file is going to be
the same for both o (the new thing) and old_thing, right?

So old_thing.destroy is going to delete it's version of the file,
which will happen to also be o's version of the file: suddenly
o will find itself pointing at nothing.

At least, this seems like how it will happen with the S3 storage back
end?

It does give me the clue to use old_thing.delete, though :)

[kenny....@gmail.com]

I don't know what the s3 backend does. Sorry I couldn't help more.
Do you have a development environment yo could test it out on?

Sent from my Verizon Wireless BlackBerry

-----Original Message-----
From: GreenAsJade <martin.j...@gmail.com>

Date: Thu, 28 May 2009 03:04:16
To: Paperclip Plugin<papercli...@googlegroups.com>
Subject: Re: Moving attachment to new record?

[Jonathan Yurek]

Not necessarily. Often people will change the path at which files are
stored to include the class name, which would differentiate
attachments of different classes. If you simply changed the path at
which the OtherThing is storing the file, then deleting the Thing will
delete the old copy of the file.

Alternatively, you could simply remove the has_attached_file
declaration from Thing, move and delete what you need to, and then put
it back. That would definitely prevent any of Paperclip's auto-
deleting from working.

--
Jonathan Yurek, Founder and CTO
thoughtbot, inc.
organic brains. digital solutions.

617.482.1300 x114
http://www.thoughtbot.com/

[GreenAsJade]

In retrospect that's an "obviously good" suggestion - to always have
the path include the class name!!

I do have an environment to test it, of course, but I feel more
comfortable knowing "the theory" of "why" something is going to work
or not. Especially when there's the potential for deleting 3000
Things, 3GB, of painstakingly uploaded data, by accident :O

One item that hadn't occured to me is that it sounds like

o.file = old_thing.file

will do a copy on S3. This I hadn't realised, is good to know (will
have to try it!)

Thanks again!

[GreenAsJade]

Unless I'm mistaken,

o.file = old_thing.file

is downloading the file from S3 then uploading it back again?

This is no so good, for 3GB of attachments... back to the
drawingboard...

Martin

[Kennon Ballou]

Why don't you just then copy the files manually and/or assign the
file_file_name and file_content_type attributes?

| Kennon Ballou
| Angry Turnip, Inc.
| Email: ken...@angryturnip.com
| AIM: kennon42 * ICQ: 5042686 * MSN: kennon...@hotmail.com

[GreenAsJade]

On May 29, 4:41 pm, Kennon Ballou <ken...@angryturnip.com> wrote:
> Why don't you just then copy the files manually and/or assign the
> file_file_name and file_content_type attributes?

Thanks, this is what I've concluded I will do.

It it's a bit "nasty" reaching into the implementation of paperclip,
but I guess what I'm trying to do isn't supported, so I'll have to!

I've started to think that paperclip should warn, or somefink, if
someone does a copy a la

new.file = old.file

and the target location for the file is the same.

Because otherwise someone goes and does

old.destroy

and *poof* no file for new.

Either that or reference counting....

Martin

[Jonathan Yurek]

That's a good point. I'm not sure how detectable that is, though. I
suppose I can detect if the assigned file is an Attachment (which is
being done anyway) and then check the paths against each other.

Really though, I'm skeptical how common this really is. The situations
where that would be the case are few, as if you're not scoping your
directories by class and attachment name (or not class name and your
attachment is named the same), then you'd need the IDs to collide. How
often would that happen? I'd say that if you have paths that aren't
unique enough for this, you'll likely have problems anyway, right?

[GreenAsJade]

The situation that caused it for me was two things lining up:

1) I don't have the class name in the path
2) I am *moving* attachments from an old class to a new one.

It's point #2 that _guarantees_ that the ID will collide: it's the
same
attachment, going to a new owner. And hence it's not the case that
this "will
have problems anyway" - the IDs are generally unique, it's just that
one
has to transfer from one owner to another.

I think that this circumstance would fall in the category of "quite
conceivable,
if rather infrequent".

I don't think that the sequence of thinking and implementation that
led
me to this point is too "far out" or "unexpected"?

Martin.