ImageField upload_to keyword could get a id wildcard

[Michel Thadeu Sabchuk]

Hi guys!

I thinking on the possibility to put the id of object on the path
where a image will be uploaded. Ex:

class Test(models.Model):
image = models.ImageField(upload_to='path/%Y/%m/%d/%(id)d')

This way I can preserve the file name untouched and can be sure will
have a unique filename. I want to do a function to return miniatures
of images on certain formats but reather than resize the image each
requisition, I rezise once and store a cache on the same directory of
the image. Having id on the path should help me.

What do you think?

Thanks!

[doug.na...@gmail.com]

I think this is a good Idea, and even better one would be to have it
use a related field name, so that any other field can be used, not
just the PK or ID.
I have an implementation that is no where near as useful (as it does
not support pattern replacement) called RelatedFileField (could
easilly be extended to RelatedImageField):

https://svn.python.org/conference/django/trunk/pycon/schedule/models.py

There is a bug in this implementation in that:
1. it assumes it is a foreign key relation
2. it used "%0.3d" to construct the string

this was done because I needed something working immediately and did
not have time to construct the general use code. I was under the gun
to get the file upload stuff working ASAP at the time.

example use:

file = RelatedFileField(upload_to=settings.EVENT_UPLOAD_TO,
related_field='event',
valid_extensions=EXTENSIONS)

this is for the PyCon uploaded materials and release form.

-Doug

[doug.na...@gmail.com]

Clarification:
I threw together my response really fast and it does not really get
the discussion started on this, and I did not mean to recommend my
extension implementation; just the opposite, it sucks.

Lets try this again.

I like your Idea allot and have had to do some questionable extensions
to FileField to get similar functionality.
I would like to see the ability to use more than just 'id' in the
string pattern so that it could be replaced with any other field on
the model.
having the key 'pk' supported would be nice, but only if its easy to
do (which i do not think it is in this instance).

Foreign keys and other data types could be an issue. It would be up to
the developer to use the proper % type. "%(field)s" for instance which
could call the __str__ method of the attribute, which might be a
ForeignKey. I would not expect "%(foreignkey)d" to get the ID for that
field. I would expect a TypeError exception as happens when you do
"%d" % ("foo").
I don't like notations which expose the internal _id name munging
(i.e. '%(field_id)d') but that could be a good way of getting the id
instead of the string representation of foreign keys..
'%(field.id)d' has the problem of potentially causing an extra query
to the database for no good reason, and opens the door for things like
'%(foo.bar.bing)'
I would NOT recommend doing the '_' tricks here.

One major reason for having the ability to specify another FK field
(id in particular) is so that you can have add on models and maintain
REST.
For example:

class SomethingWithImages(models.Model):
name = models.CharField(...)
...

class AttachedImage(models.Model):
name = models.CharField(...)
attached_to = models.ForeignKey(SomethingWithImages)
uploaded = models.DateTimeField(auto_add_now=True) # I know this
is being replaced...
edited = models.DateTimeField(auto_now=true)
height = models.IntegerField()
width = models.IntegerField()
image = models.ImageField(upload_to=REST_BASE+"/%(attached_to)d"
height='height', width='width')

This just seems to make sense to me.

-Doug

On Apr 17, 2:54 pm, "doug.napole...@gmail.com"