Products

Solutions

Resources

Partners

Community

Blog

About

QA

Ideas Test

New Community Website

Ordinarily, you'd be at the right spot, but we've recently launched a brand new community website... For the community, by the community.

Yay... Take Me to the Community!

Welcome to the DNN Community Forums, your preferred source of online community support for all things related to DNN.
In order to participate you must be a registered DNNizen

HomeHomeArchived Discus...Archived Discus...Developing Under Previous Versions of .NETDeveloping Under Previous Versions of .NETASP.Net 2.0ASP.Net 2.0Image storage strategies...Image storage strategies...
Previous
 
Next
New Post
4/22/2008 8:43 AM
 

I'm somewhat new to DNN. I'm working on a module that will look something like a myspace profile.  To do this I'll need to have a profile image. What are the image storage strategies in DNN? I've seen some posts/articles that advocate putting the images in the Database. That sounds insane to me for any number of reasons.

Are there any established ideas in place for storing images to a folder and handling renaming/indexing? I figure someone's already thought this through.

Any ideas / suggestions would be welcome.

ED

 
New Post
4/22/2008 10:06 AM
 

nearly all modules store the images in the file system due to performance and database costs. There are methods for upload and renaming included in the FilesysteUtility class.


Cheers from Germany,
Sebastian Leupold

dnnWerk - The DotNetNuke Experts   German Spoken DotNetNuke User Group

Speed up your DNN Websites with TurboDNN
 
New Post
4/22/2008 6:27 PM
 

Thank you Sebastion. I'll take a look at that.

Does anyone know of any articles/posts that discuss strategies concerning this topic. Up to this point I've had a heck of a time interfacing with the documentation for DNN... Not that I'm disparaging the project. But, much of the documentation seems to reference older versions and it isn't always clear enough for this simplton to understand.

Any insights would be greatly appreciated,

ED

 
New Post
4/22/2008 7:20 PM
 

I would agree that storage of images as blob data in the database is insane for both storage space requirements and performance. You'll find that most if not all modules simply store either a folder/filename or fileid in the database and the actual image file in the file system. Beyond that, there are a wide variety of approaches to renaming/resizing/auto-thumbnailing files on upload, controlling upload folders and upload rights, and keeping the database reference insync with the actual image files.

You might like to take a look at my Image Editor Control found in the DNN Forge/CodePlex. Although the module itself could be used for image upload and display, it was built primarily to demonstrate the underlying server control and its many option settings. If you are looking to create your own image handling and storage routines, you will find the source code of interest as it includes methods for image file upload and processing using GDI+, dynamic image preview using a generic HttpHandler, image resize and thumbnailing, generation of unique image file names, storage and retrieval to and from secure database storage, Octree palette optimization for gif image formats, and client-side javascript/MS AJAX drag-handle specification of the cropping rectangle.


Bill, WESNet Designs
Team Lead - DotNetNuke Gallery Module Project (Not Actively Being Developed)
Extensions Forge Projects . . .
Current: UserExport, ContentDeJour, ePrayer, DNN NewsTicker, By Invitation
Coming Soon: FRBO-For Rent By Owner
 
New Post
4/24/2008 2:28 PM
 

William Severance wrote

I would agree that storage of images as blob data in the database is insane for both storage space requirements and performance. You'll find that most if not all modules simply store either a folder/filename or fileid in the database and the actual image file in the file system. Beyond that, there are a wide variety of approaches to renaming/resizing/auto-thumbnailing files on upload, controlling upload folders and upload rights, and keeping the database reference insync with the actual image files.

Saying that it's insane is a bit misleading.  If you are doing it, but not caching the files you need to retrieve regularly, then that's insane.  For those of us who feel storing anything site specific in the actual file system is invalid for disaster recovery reasons, database storage is the logical answer.  I can't stand it that I have to back up both the database and some parts of the DNN installation folder on the server.  It's messy and requires 2 different procedures to make sure you get everything.  I should be able to throw a copy of DNN somewhere, restore the database, and we're back.  Mind you, we are a bit unique I think in the DNN world as we use continuous integration to actually do our production deployments for us, so it does pose some difficulty.

 
Previous
 
Next
HomeHomeArchived Discus...Archived Discus...Developing Under Previous Versions of .NETDeveloping Under Previous Versions of .NETASP.Net 2.0ASP.Net 2.0Image storage strategies...Image storage strategies...


These Forums are dedicated to discussion of DNN Platform and Evoq Solutions.

For the benefit of the community and to protect the integrity of the ecosystem, please observe the following posting guidelines:

  1. No Advertising. This includes promotion of commercial and non-commercial products or services which are not directly related to DNN.
  2. No vendor trolling / poaching. If someone posts about a vendor issue, allow the vendor or other customers to respond. Any post that looks like trolling / poaching will be removed.
  3. Discussion or promotion of DNN Platform product releases under a different brand name are strictly prohibited.
  4. No Flaming or Trolling.
  5. No Profanity, Racism, or Prejudice.
  6. Site Moderators have the final word on approving / removing a thread or post or comment.
  7. English language posting only, please.
What is Liquid Content?
Find Out
What is Liquid Content?
Find Out
What is Liquid Content?
Find Out