Hi,
If you provide a BinaryField it's just a matter of time that "hacks" will
start to go out on blogs, the wiki or even django-users to get ImageField
and FileField on the database (there's a hack on this already), maybe it's
99% bad but if those fields are provided inside django it will be much
better than having lots of hackish ways around.
And anyway, there's still a 1% of cases on which it's good design, normally
cases of big applications.
An argument for supporting Image/Field on DB:
Consider a case of multiple frontends with a big big database, having
File and Image fields on filesystem forces you to keep the filesystem in
sync among frontends. Now imagine you upload a file which is i.e. the image
for an article; The article is inserted on the database and the file on the
filesystem. All frontends will **immediatelly** show up the article, but
only one will have the image! unless you start playing around with NFS or
other networked filesystems.
It can also be a bit messy to do Point In Time recoveries, with everything
on the database you can to a nice PTR without any trouble, if there are
things on the filesystem you must make sure both things get recovered to the
same point in time, and it's rare to see filesystems backed up
**permanently** while point in time recoveries in databases (atleast
postgresql) are heavily documented and a good resource for some kind of
applications.
Third case; Imagine having one single directory holding a project but you
run multiple instances of it over different databases (yes, doing tricky
things to settings), having things on the filesystem makes things a bit
harder.
I'm +1 on providing database backed File and Image fields while heavily
discouraging it's use on the documentation by providing clear examples of
the 99% and 1% sides of the thing so users are aware of which storage method
should they choose.
Also +1 on the BinaryField, then atleast if one **really** needs to store
things on DB it could be done :)
Cheers,
Marc
On 3/26/07, Jacob Kaplan-Moss <[EMAIL PROTECTED]> wrote:
>
>
> On 3/26/07, Simon G. <[EMAIL PROTECTED]> wrote:
> > So - if we do want a BinaryField we could use #2417 and make it
> > suitable for larger binary stores (e.g. the VARBINARY used for MySQL
> > has a max length of 255 bytes - perfect for the small bin. chunks
> > wanted in #2417, but not for larger data), and then hook it up to
> > Image/FileFields for #652.
> >
> > An alternate solution is to check in #2417 for small binary chunks,
> > and then hold 652 back until we decide if we want a LargeBinaryField
> > for large binary chunks suitable for file uploads.
>
> +1 on having a BinaryField. I'd actually like to see BinaryField be
> the "larger" binary field, and have a SmallBinaryField alongside for
> databases with those types.
>
> -1 on allowing File/ImageField to be stored in the database. That's
> bad design 99% of the time, and will needlessly complicate file upload
> code.
>
> Jacob
>
> >
>
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to this group, send email to [email protected]
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
-~----------~----~----~----~------~----~------~--~---
