On 12/24/05, Robert Wittams <[EMAIL PROTECTED]> wrote:
> * FileField becomes a descriptor (before other fields), and is
> assignable, and able to be passed in the constructor. The things which
> can be assigned will at least include a structure that can be made out
> of the request, in   eg
> { 'name': 'blah'
>   'content' : 'binary string' }

Passed into which constructor? Could you paste some example code of
your proposal?

> * The file is only saved to its "final location" when the object is
> saved. Basically, the field listens for save events on objects of its
> containing class, and does the save. Before this, the file must be saved
> to a temporary location. This will allow the file to persist between
> requests, eg on validation errors, etc.

I like the idea that admin users wouldn't have to reupload a file
after validation errors -- but the temporary location on the
filesystem makes me uncomfortable:

   * It introduces the problem of having to clear out the directory.

   * It introduces another setting (TEMP_FILE_DIR or whatever).

   * I'm always wary of saving data from the public Internet to a
server's filesystem, unless it's absolutely necessary.

> The temporary location is a slight issue. My current thinking is :
> a temporary location is a directory. It contains two subdirectories, eg
> 0 and 1.
> We first use the 0 directory. Then after n minutes, we use the 1
> directory. After another n minutes, we use the 0 directory again,
> deleting its current contents. This means that any temporary file will
> live for at least n minutes and at most 2n minutes, (as long as requests
> are still being made).

So if Admin User A uploads a file just before the 0-to-1 switch and
has validation errors, and Admin User B uploads a file after the
0-to-1 switch, then Admin User A's file will be gone. Seems like an
unavoidable race condition.

> ManyToManyField
> ---------------
>
> This is another wierd one. Similarly to above, it needs to be passable
> in the constructor, and only be set when the object saves, for
> manipulators not to need any hacks.

Could you explain further why this is necessary, and could you give
code examples of how manipulator syntax would change?

Adrian

--
Adrian Holovaty
holovaty.com | djangoproject.com | chicagocrime.org

Reply via email to