2010-12-13 42 views
1

Je stocke actuellement les fichiers téléchargés sur le CMS dans une base de données. Ma question ne demande pas d'alternative à cela. Le problème que j'ai est de servir le fichier du serveur web public.Alternatives à CFContent?

Idéalement, je peux mettre en cache les fichiers sur le serveur Web dans le système de fichiers, mais il y a un problème avec cela. Le système permet de télécharger différents fichiers avec le même nom de fichier, et je ne veux pas mettre en cache les fichiers en utilisant un hachage UUID ou MD5 parce que je veux que l'utilisateur final puisse avoir le nom de fichier dans la boîte de dialogue de sauvegarde.

Les questions que j'ai avec cfcontent sont

  1. Chaque requête à un fichier charge le fichier dans la mémoire, je ne me dérange pas de le faire une fois pour construire le cache. Cfcontent n'autorise pas la segmentation de téléchargement http, de sorte qu'un utilisateur final arrête de télécharger un fichier et essaie ensuite de le reprendre.
  2. Trop de demandes à des fichiers volumineux lieront les demandes simultanées et forceront les demandes de pages normales dans la file d'attente.

P.S. Les fichiers sont stockés dans la base de données car la base de données est la seule forme de communication entre le CMS et le site public.

Répondre

2

Spontanément, je suggère d'utiliser la clé primaire du db comme le nom du répertoire , afin que vous puissiez Conservez les fichiers avec le nom d'origine et stockez-les toujours dans un emplacement unique sur le serveur. Supposons que quelqu'un télécharge document.docx, et que l'ID lui soit assigné. Votre URL pointe vers /content/3/document.docx ou similaire.

+0

Je pense que cela peut être la voie à suivre, pouvez-vous penser à des inconvénients à faire cela? –

+0

Le principal inconvénient est que vous pouvez obtenir une prolifération de répertoire très mauvaise. Si vous pensez qu'il y aura plus de quelques centaines de fichiers, vous pouvez chercher des moyens de grouper, comme/content/# client #/# docuID #/# nom_de_document # –

+0

Le côté positif est que chaque site possède son propre dossier cache , donc pas deux sites vont mêler des fichiers. –

0

Ceci est difficile, comme si vous avez vos images dans la base de données, vous avez besoin d'une sorte de servlet pour les rendre disponibles au navigateur final. Cela signifie qu'à moins que votre base de données ait un moyen d'exposer les images directement à un navigateur, il doit y avoir un traitement en mémoire.

Vous pouvez utiliser cfimage pour l'afficher, mais je suppose qu'il a exactement les mêmes problèmes que ceux que vous avez décrits ci-dessus.

J'avais un quick look on Google, mais je n'ai rien trouvé qui corresponde exactement à vos besoins (ce qui est bizarre, j'aurais pensé qu'il y aurait quelque chose), mais il serait assez facile d'écrire une servlet et de la déployer sur JRUN pour servir des images en utilisant les moyens que vous voulez, en fonction de la qualité de vos connaissances Java.