If we were to use the File content-type to upload video - or any large file really - is there any way of turning off the revision history in order to save space in the database?
My concern is that the database could grow potentially very large even when the video content itself is unchanged.
Or is there a better way of achieving what I want to do?
We’ve tried one solution to this problem (and rejected), and we’re considering another.
We wrote an extension implemented on the File field so that when a user uploaded the item, it was stored in the filesystem instead of the database. The name of the file system object was contentid-revisionid. I forget the details of publishing the item out. You still ended up with all revisions eating up space, so you’re just shifting the burden from your database to your filesystem. In the end, this one-off configuration didn’t seem worth the maintenance of the extension.
Our other idea is to run a scheduled process that will remove all revisions of the content item with the exception of the current public revision, and the previous public revision. This is mostly done with SQL code on the backend. We haven’t implemented it, but it’s been a recurring topic of conversation since day 1 (3 years ago).
If anyone has other suggestions, please contribute.
What if you simply used the “create promotable version” whenever the video or content changed?
Not sure I follow. Are you saying that there’s a way of having no versions while we change the title and other parameters? And then, when we change the video content, somehow creating one?
The promotable version option replaces the content item with a completely new item after the publish date occurs which causes the old item to be removed from the database. If you didn’t want to store any versions at all, I would just use the promotable version for all changes. If you wanted to keep revisions for some of the content I would look into creating another content type (e.g. “video description”) and linking the video content items to the other content items with a manual or auto slot. This would allow you to use the promotable version option on video content changes and use the regular versioning on the other content type.
I was under the impression that the promotable version just replaces the item in all the relationships…The item that it replaces is still in the database (available via “community content” view)…just not in any “folder”. Of course this is the standard implementation, and you may have written an extension or such to change the default behavior.
The default behavior is as Jitendra noted - the item is left in the db.
After the item is published, couldn’t you then just purge the old version?
We use your extension which you were kind enough to share on the forum. It actually seems to only create a new copy of the file if you upload one, if you just make changes to text it doesn’t create new copy of the file. This is perfect you get to make content changes with revisions and also upload new binary items also with revisions but only when necessary. I am guessing it wouldn’t take much to modify the extensions to only keep a single copy of the file.
IMHO the file system is the best place for binary files it is much better suited to handling them. It would be ideal if CM System had the ability to offload large binary data to the file system Out of the box
The issue resolution with large amounts of binary data (documents, hi-res images, video, zip or other proprietary packages) is really not in the matter of where you will store it to be managed by Percussion WCMS - it doesn’t matter - file system or DB, you will need huge storage space to store it (repository mode) as well as huge storage space to serve it to the web. In case with video - there a re many more issues with that including but not limited to bandwidth utilization, streaming etc.
We all discuss that Percussion suppose to do this and that about it, but reality is - it is your company media storage and delivery strategy has to be fixed. Remember any WCMS system (any - not just Percussion) is just that: Web CMS to manage web content metadata and some lightweight content - it is NOT a Document Management nor it is a sufficient Digital Asset Management solution. Your solution should be in adapting the architecture to new business and marketing requirements with regards to multimedia strategy.
All you are trying to achieve is doable in even better ways, just need to think “outside the box”.
- your video, in addition to taking space in DB (or file) repository used by CMS, when published, needs additional storage space and hosted on the regular web server (some do use the file server) not optimized for video streaming, nor fast or distributed network like CDN.
- However you can achieve much better results if you utilize CDN or any specific Video Hosting cloud service (cheaper than hosting it on your own) to store and manage your videos, utilize Percussion Web Services to grab all metadata available as RSS or xml provided by that cloud service, including url’s to the file itself, streaming service, player, thumb image etc. map and load it into the CMS, manage all this metadata in CMS, add any additional metadata , description, captions etc., relate to any content piece in CMS, and finally publish it - all while really utilizing the url’s loaded from the cloud - so all you manage is metadata and content relationship, not storing the files in CMS nor on the web server at all. You “kill two birds with one stone” here - storing your video in one place, already optimized for hosting video as well as not blowing you DB or filesystem out of proportion that comes with all revisions and db log files that within time may require x10’s (if not more) amount of storage you really need to store the video.
BTW - this was successfully done for several clients, so I’m not just “blabbering” here
Hope this helps.