FileField path url dumpdata/loaddata issue

[Ian Ward]

I have a model that includes a FileField with values such as "/media/uploaded/YEAR/MONTH/NAME" (upload_to='%Y/%m').
I upgraded to Django 1.0 beta svn-8457 and switched from using get_filefiledname_size() to filefiedname.size.
Now, this property triggers a SuspiciousOperation exception: When django.core.files.storage.FileSystemStorage.path is called,
it calls safe_join and decides that the leading slash in the file path puts the file outside of the media root directory.

New instances of this model include a leading slash in the path, so this doesn't seem to be a change
to how the file name is stored.

[Ian Ward]

Now, this looks like an export issue. I dumped the models into an XML file from a Postgres database where the file paths looked like:
YEAR/MONTH/NAME. The XML file contains "/media/uploaded/YEAR/MONTH/NAME" and when importing to sqlite the database contains "/media/uploaded/YEAR/MONTH/NAME", causing the problem above.

new instances of the model *do not* contain /media/uploaded/ in the database, it just looked that way from the admin site.

[Collin Grady]

I can't seem to duplicate this - the xml serializer had an old bug where it used get_fieldname_url() instead of just fieldname, but that was fixed (#5574)

with current trunk, I get this on serializing filefields:

<?xml version="1.0" encoding="utf-8"?>
<django-objects version="1.0">
  <object pk="1" model="locked.filetest">
    <field type="FileField" name="test">test/en-NG_.msi</field>
  </object>
</django-objects>

which does not include MEDIA_ROOT or MEDIA_URL

[Ian Ward]

Then it must have been because I was exporting from a version afflicted with that bug. Thanks cgrady.

[Jacob]

Milestone 1.0 deleted