On 5/30/06, ycoci0 gmail.com <ycoci0gmail.com> wrote:
>
> Hi all,
>
> I had a previous post on this issue which I did not get
very many
> answers to. In particular, I did not have many
responses those who may
> be more directly involved with the development of this
great Framework
> (or maybe more appropriately the Admin extension of it?
which is such a
> feature that for all practical purposes it may well be
seen as core to
> the Framework.)
>
> The default behaviour is for Admin not to overwrite a
file with a newer
> one posted with the same name, i.e. if I upload a file
called ycoci.jpg
> to a folder which contains an older version of the same
file, the newer
> one will be renamed wthin an underscore,ycoci_.jpg.
>
> I would like to know why this is handled in this way,
as find it very
> unintuitive (There many well be a very valid reason for
handling things
> in this way? However, it seems to me that the natural
thing to do is
> to rename the older file with the underscore then
delete it, before
> posting the newer file with the original name).
>
> I have developed a very workable web project with
Django 0.91, but this
> behaviour is causing me real grief, as I now have loads
of files on
> disc that are not being used, which is a huge waste of
disc space and
> one part of my project depends on files preserving
their names.
>
I agree - mostly. If the new file is to replace the old
file, then why
should the link to the file constantly change? Consider this
example:
I have a PDF document called example.pdf. On occasion, I may
need to
make a edit or correction to this document. However, I still
want to
point my users to example.pdf, not example_.pdf or
example__.pdf. The
current behavior doesn't seem to fit the
never-changing-URLs
philosophy.
To compound the situation, suppose example.pdf is an
attachment to a
world editable wiki page where anyone could upload an
updated version
of the pdf. Just as the wiki page may have built in history
to undue
malicious changes to the page, I would want that same
functionality
for the attachments. It would then make sense to have older
versions
of the file renamed with a timestamp (i.e.:
example_20060530121302.pdf, or example_20060402.pdf) while
the newest
version maintains the original name (example.pdf). If
someone tries to
maliciously overwrite the file, then the older (good)
version could
simply be renamed to remove the timestamp.
However, unlike Y-coci suggests, I would not want the older
version to
be deleted by default. If the older version is the one being
renamed
either with a underscore, a timestamp or some other means
(not the
current behavior) then a simple cron job could be run on
occasion to
clean out older versions leaving the most recent in tact and
keeping
the waste of disk space to a minimum.
I would propose an additional setting to address this.
Perhaps
something like DUPLICATE_FILE_SUFIX = '_'. One could then
set it to
datetime.datetime.now() or anything else s/he pleases. Of
course, the
code would still need to be altered to rename the old file
rather than
the new one.
> I would be grateful for any suggestions as to how I can
get around this
> limitation.
You could try to override django's default behavior. The
code can be
found at django/db/models/base.py on about line 300 in the
function
_save_FIELD_file(). Rather than altering the core code, it
may be
possible to redefine that function in your model much as you
would the
save() function. Of course, I haven't tried it myself, but
don't see
why it wouldn't work. If you get some code that works, post
it to the
wiki as your not the first person to request that.
On further contemplation and after reviewing the code in
_save_FIELD_file(), it occured to me that the current
implementation
is for a simpler use case than I was first considering.
Using the wiki
senario again: Let's say I have an attachment to Page1
named
example.pdf. Another user creates Page2 and adds an
attachment
example.pdf. The new file should not overwrite the old file
so the
underscore is appended making Page2's attachement
example_.pdf. If you
want something more complex you need to add it yourself,
which
shouldn't be to diffucult. Although, I will say having the
DUPLICATE_FILE_SUFIX setting by default would be nice.
>
> Thanks and Best,
>
> Y-coci
>
>
> >
>
--
----
Waylan Limberg
waylangmail.com
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the
Google Groups "Django users" group.
To post to this group, send email to django-usersgooglegroups.com
To unsubscribe from this group, send email to
django-users-unsubscribegooglegroups.com
For more options, visit this group at http://gr
oups.google.com/group/django-users
-~----------~----~----~----~------~----~------~--~---
|