On Aug 8, 8:12 pm, "Jay Parlar" <[EMAIL PROTECTED]> wrote:
> On 8/8/07, John-Scott <[EMAIL PROTECTED]> wrote:
>
>
>
>
>
> > Hello all,
>
> > I'm trying to integrate S3 support into my Django app using
> >http://code.djangoproject.com/wiki/AmazonSimpleStorageServicefor
> > now.
>
> > I would like to improve the code so that it might be officially
> > integrated into Django at some point. The first obvious question: Is
> > this a feature that others would like to see, enough so to warrant
> > having this feature 'baked-in'? Or should I just keep my hacks to
> > myself?
>
> > I want to rewrite the code so that it doesn't subclass FileField, as
> > it currently does, but instead adds or alters the parameters to
> > FileField which can then be inherited by ImageField. Currently, the
> > S3FileField subclasses FileField and then has to duplicate some of the
> > functionality of ImageField, so it's not very DRY. The options I want
> > to add to FileField would determine whether or not the file should be
> > stored on the filesystem (the default) or to S3, plus additional
> > options specific to S3 storage (bucket and key values, etc.). Obviousy
> > this would involve tinkering with Django's models code directly so I
> > want to solicit feedback from the Python/Django pros before I go down
> > this path.
>
> My guess would be that the core team would never accept changes to the
> base fields which add provider (ie. Amazon) specific features. Things
> like that are better left in contrib. I would personally rather have
> an S3FileField.
>
> Of course, if you changed FileFIeld such that you could use it with
> *any* S3-style provider, by passing it the right data (maybe some
> callbacks, or something), that'd be cool.
>
> Jay P.
Thanks for sharing your thoughts.
My initial thought was not so much to radically change how FileField
works (at least not for the end user), but to merely to pass in
arguments that would allow for other storage backends, to decouple the
actual storage mechanism from what is essentially just a varchar
pointer field in the model. My problem with S3FileField (which to be
clear, I did not author) is that it basically duplicates a lot of the
functionality of FileField and ImageField, since it has to play double
duty for image and all other file types.
Any changes to FileField would aim to be 'backwards compatible', so
file system storage would be the default in absence of a declared
backend, but maintain the single required argument 'upload_to'. That
way those using FileField for file system storage could continue doing
so without any modifications necessary. So it might be something as
simple as specifying FileField(upload_to='my-key-prefix-if-
any',storage='S3', bucket='mybucket') so that the pointer ultimately
stored in the database would be something like "my-bucket/my-key-
prefix-if-any/uploaded-file-name.extension" and then Django could
prepend the 'http://s3.amazonaws.com/' to generate the absolute url.
ImageField would just inherit this storage flexibility. Of course to
use S3 as the backend, the user would have to install whatever S3
connection library (whether the 'official' S3.py from Amazon, boto or
perhaps something customized for Django).
For now, I'm not so interested in working with any of Amazon's other
services...so I'm not envisioning an all encompassing Amazon library.
I just want to decouple the actual storage mechanism from the varchar
pointer field so that one can easily choose S3 or db BLOB or whatever
without too much hassle.
Once I've wrapped my head around Django's models code I'll try to give
some concrete code examples.
Thanks again for your thoughts, and the pointer to boto...I'll look
into it.
Cheers,
John-Scott
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/django-developers?hl=en
-~----------~----~----~----~------~----~------~--~---
