[Prev] Thread [Next]  |  [Prev] Date [Next]

Re: Design decision on ticket #13223 Igor Sobreira Wed Feb 22 06:01:39 2012

On Wednesday, February 22, 2012 2:34:38 AM UTC-2, juanpex wrote:
> On Tue, Feb 21, 2012 at 10:55 PM, Thomas Woolford wrote:
>> Any files uploaded when the clone view is submitted will be uploaded on 
>> save and associated with the new object anyway.
> It is perfectly valid for two DB rows to point at the same file because as 
>> soon as that file is re-uploaded it creates a new file instead of 
>> overwriting the old one anyway 
> But this behaviour doesn't represent all cases. In some cases, the users 
> could be want to "clone" in a full copy and a representation of files too 
> and NOT link to
> the pre-existing files of the other/s objects.
Yes, that's what I wanted to say. We can decide that this behavior is fine 
by default, document it, and provide an easy way (with callback and helper 
functions) to allow the user to clone the file on disk.

> This mean that if I change the "origin" object file, the cloned/s objects 
> will change their links too?
> The obviously behaviour will be to copy another file on the server and 
> associate it with this new object and be consistent with the default admin 
> functionality.
> Regards,
> -- 
> juanpex

Igor Sobreira 

You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To view this discussion on the web visit 
To post to this group, send email to [EMAIL PROTECTED]
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at