Jorge, good points.  I should not have been so quick to dismiss saving
images in the database.

Now that I'm thinking of it, many filesystems have an upper limit on
how many files a directory can hold (for FAT32, EXT2, and HFS that's
2^16 or about 64 thousand files), so that's definitely something to
watch out for if you're hosting a huge site with lots of people
uploading files.  Before you hit that limit though, it would start
getting really expensive in terms of cpu and i/o time to iterate
through all the filenames.

I should mention that to Ian Bicking's credit, the 'filename
uniqueness' problem (preventing people from overwriting existing files)
is solved in his example by saving the filename in a database record,
and naming the filesystem file using the ID of the database record.

chalgf, is this helping you?

-ian

On Nov 19, 3:06 pm, Jorge Godoy <[EMAIL PROTECTED]> wrote:
> "Ian Charnas" <[EMAIL PROTECTED]> writes:
> > yeah!  Glad to hear it.  I know this doesn't exactly answer your
> > question, but I would strongly recommend *not* storing the images in
> > the database.  There is a really cool way to modify your model using
> > "magic attributes" so that uploaded files *look* like they are stored
> > in the database, but are actually stored on the filesystem.  This lets
> > you use all the common image editing libraries (like PIL) with fewer
> > headaches!  Check out Ian Bicking's excellent documentation:
> >http://www.sqlobject.org/SQLObject.html#adding-magic-attributes-prope...Things
> > to consider when deciding where to store images:
>
>        - database size
>        - filename uniqueness
>        - ammount of images
>        - filesystem type (some are not optimized to scan thousands of images)
>        - backup (!!!!)
>        - integration with other systems
> 
> --
> Jorge Godoy      <[EMAIL PROTECTED]>


--~--~---------~--~----~------------~-------~--~----~
 You received this message because you are subscribed to the Google Groups 
"TurboGears" 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/turbogears?hl=en
-~----------~----~----~----~------~----~------~--~---

Reply via email to