Wierd FileField behavior

[DrKayBee]

Hi,
I have a simple profile model which includes the option to upload a
File (FileField) and a photograph (ImageField). These two fields show
somewhat undesirable behavior:

(1) Let's say I create a profile and upload a photo through the admin.
(2) My member view page shows my photo and other profile details.
(3) Then let's say I go back to change something in my address field.
The filefield correctly shows the "current file" which I uploaded in
(1). I make no other changes and hit Save
(4) I reload my member view page. Now the link to my photograph is
broken.. (photo doesn't exist)
(5) I go back into admin and find there's no photograph associated
with my profile.

Why does it do this? Is there no way to fix this? Am I doing something
wrong? Do I need to upload a file to the database and have it only
store a FilePathField? Is there a workaround?

Thanks

[timc3]

Show us the code for your view. But are you sending through the files
in the POST each time?

[Erwin Elling]

On Feb 2, 11:29 pm, timc3 <t...@timc3.com> wrote:
> Show us the code for your view. But are you sending through the files
> in the POST each time?

It's probably not DrKayBee's view that's causing problems. Seems like
it's the admin views.
I have the same problem with a model with two filefields:
When I edit and save instances of the model and leave the filefields
unchanged, they are saved as blank.
It seems that the empty input fields for files in the admin form
overwrite the file that was elready entered?

Erwin

[Erwin Elling]

On Feb 3, 12:10 pm, Erwin Elling <erwinell...@gmail.com> wrote:
> It's probably not DrKayBee's view that's causing problems. Seems like
> it's the adminviews.

This was on the latest svn revision (9807).
I went back to 9781 (which was still on my system for a previous
project) and the problem seems not to exist here. Haven't had the time
to dig into this any further, but maybe this helps someone else.

[Erwin Elling]

> I went back to 9781 (which was still on my system for a previous
> project) and the problem seems not to exist here. Haven't had the time
> to dig into this any further, but maybe this helps someone else.

Sorry, made a mistake; On 9781 the problem is still there.
On 9084 (also quite randomly chosen) it seems to be allright.

[Ramiro Morales]

Revision 9766 introduced some changes related to file fields, can
you try to refine your tests and see if it is the one that broke
things in your case and report back please?

--
Ramiro Morales

[thanhduclee]

Cool, you saved my life

On Feb 3, 10:50 pm, Ramiro Morales <cra...@gmail.com> wrote:

[Erwin Elling]

> Revision 9766 introduced some changes related to file fields, can
> you try to refine your tests and see if it is the one that broke
> things in your case and report back please?

I tried both 9765 and 9766.
Indeed, in 9765 I don't come accross the problems mentioned. In 9766 I
do.

Files that were changed between these versions (by Jacob):
db/models/fields/files.py
core/files/base.py

I can't dig into this any deeper atm, but hope I've pinpointed the
problem somewhat...

Erwin

[numshub]

> I tried both 9765 and 9766.
> Indeed, in 9765 I don't come accross the problems mentioned. In 9766 I
> do.
>
> Files that were changed between these versions (by Jacob):
> db/models/fields/files.py
> core/files/base.py
>

> Erwin

I have the same problem too.
9765 works fine. 9766 doesn't.
I'm going to have a look at the above files to find out.

Pierpaolo

[numshub]

Had a look at diff from 9765 and 9766.
I think thata changes in release 9766 in db/models/fields/files.py
somewhow broke admin site.
9766 address ticket #10044 allowing direct assignment of File object.
It extends FileField model capability so I think we should focus to
solve the issue on admin site instead of rolling back to 9765.
Maybe a custom FileField to be used in admin?

Pierpaolo