Purging older revisions from SQL database
This is related to my other post about migrating SQL data, but using a different approach.
I am about to deploy a project for a client. My database is now 263 MB and it has a lot of revision data from the initial design process. I need a way to purge all revisions except the current ones from the database.
Here is an old KB article at http://www.sitefinity.com/devnet/kb/sitefinity-3-x/how-to-reduce-the-project-database-size.aspx, but it applies to 3.x and I am running 5.x. In fact, none of the mentioned tables exist in my schema.
Bottom line: how can I purge all previous revisions? Can it be done directly through SQL?
Indeed... I recently launched a new site, and this was a real hassle to do manually.
I'd like to be able to have a clear & reset utility that purged all previous versions and reset the currently published version to V1.0
Launching a site where the only available revision is V87.0 just raises lots of questions, and makes me look like a goose -- yeah, I probably am a goose for needing that many revisions to get it right, but the customer doesn't need to know that - LOL.
Here is some sample code which you can run to purge the revision history for all pages for a given time period.
hello, except the method above, still have the SQL method similar to 3.x?
I had to create a User Control that had a button on it and two settings. The settings were how many pages to leave and how old a page has to be before being purged. I then added the User Control to the Modules bar and now the User clicks on the button every now and then to purge old pages. The code is a modification of the above. Works fine and it does cut the size nicely when deleting loads. An automatic feature though would be very helpful.
We have strict retention guidelines that dictate the length of time a page must be kept before it is destroyed. It would be nice to get the script working so that any page or revision would be purged if, for example, it has not been published within the past year. Is this something others need also, or is that angle unique?
My requirement is that I want to delete frontend page revisions older than a variable date, and prevent the last published version from ever being deleted. I'm posting the code below, which seems to work fine for me; perhaps someone finds it handy. As this is quite a powerful feature which can seriously mess things up, I would also like to ask if the code is doing this in a safe manner.
Of course I've made sure that only Administrators can activate this function.
I would recommend this free module - Wipe Deleted Versions Module
It allows you to wipe old version data using a nice UI, instead of using SQL queries to delete records directly from the database.
Any chance we are going to see a maintance module in 7.1+ roadmap.
I just had a database outgrow the space. Some pages had 140 history versions.
It really would be nice if you could set the number of max history versions to be saved.
Revision history settings are not scheduled for the 7.0 but there is logged a feature request in our Feedback portal, you could vote it. Most required features are scheduled with priority for development.
For the time being the database could be cleared by using the proposed solution in that forum post.
That feature request was submitted in 2010! It's a valid request, one that would be beneficial for all website owners. It's time to implement!
Its not the oldest feature request or the once who make the most sense or the once needed by clients the most that get on the roadmap.
It's like google indexing. Everyone tells you how it works but no one really knows :-)
Sure hope to see that in before 8.0 is planned.
Yeah, we've been over this so many times now, that I've pretty much given up thinking Telerik are in any way interested in a feedback system that works.
But to vent about it one last time... honestly, who spends their time browsing such a site, in the hope that there is something there you consider worthy of voting for? It's a crazy notion that such a dysfunctional process is the basis for implementing changes.
At the very least, Telerik should take a leaf from the book of companies like GFI and implement a weekly email update to registered subscribers:
Sitefinity Ideas - This Week in Ideas & Feedback Portal
That way, people get sent a list of new/updated ideas posted during the last week, and can see at a glance if there is something there that they should vote for, rather than the current process of relying on people to visit the site in their "spare" time, and assume they'll stumble over someone else's idea and vote on it.
I was just reading the GFI ideas update this morning, and voted on one of them. I would never in a million years, have visited their ideas website, and searched for this, but when they told me about it... hey, that's a good idea, I'll vote for that!
+1 to that approach. It would be a major improvement. The number of votes would then at least reflect the actual interest of users.
As I also said, I think that should be the very LEAST Telerik provide, in implementing a working feedback/ideas/tracking portal.
I'd actually like to see it go much further, providing weekly updates on all items (e.g. bugs, requests, ideas, etc) for both new and changed status. i.e. what's new, what's confirmed, what's scheduled, what's fixed/implemented, what's trending, etc - with subscription options to various categories.
The point is, that without a weekly notification service, there is no reasonable way to know what is (or more likely isn't) happening on this portal, and it should be painfully obvious to even the most casual of observers, that a system reliant on people visiting a site and trawling through a database, in the hope of finding an idea/bug/etc that happens to meet their own problem description, is totally unrealistic and simply won't work. It actually looks more like lip-service than any real interest in feedback and user input.
Clearly, this is not a solution to all shortcomings of the feedback/ideas/tracking portal, and I don't imagine that there is any perfect system for finding reported bugs etc, but at least it gives users a heads-up on current activity, which is more than we have now.
You can take the weekly internal builds to see what has been fixed.
I don't think that the feedback system would work. There are so many open issues and such little that seem to be worked on.
The only thing that would help is to focus 80% on bug fixing for the next three verions to cut the number down. No there are so many that you would not know where to start
It feels like one of those simulation games where your population grows faster then you can produce food for them.
Great thing come with 7.0 and again I am sure by the time we reach 8.0 we will see some more major improvements for us and our clients.