I added this before I followed up to this thread with
"Don't try this (dump partial DB and transfer):

http://requesttracker.wikia.com/wiki/Shredder
==============================================================
Shred ALL TICKETS

WARNING WARNING WARNING: If for some reason you want to reset your entire RT instance's TICKETS AND TICKET DATA ONLY (and keep Scrips, Custom Fields, etc), you could do something like the following. This was useful for me when I wanted to take our production RT instance and duplicate it onto a development box but not have the huge database full of tickets and ticket-related data.

Bourne shell syntax is shown below:

cd /tmp
while :
do
date
SHREDDED=`rt-shredder --plugin "Tickets=query,id > 0;limit,100" --force --sqldump foo.sql 2>&1 | grep RT::Ticket | wc -l`
echo "Shredded roughly $SHREDDED tickets."
sleep 3 # let the system get a breath
rm -f foo.sql # we don't care about restoring what we shredded in this case
if [ $SHREDDED -eq 0 ]; then
    break
fi
done
==============================================================

On 8/18/2011 8:02 AM, Chr. von Stuckrad wrote:
On Wed, 17 Aug 2011, Darren Spruell wrote:

into an error to the effect of too many tickets specified by the
shredder resulting in too long of a GET request URI length for the
server. I concluded that shredding that many tickets from the UI
wasn't going to work and there must be a better way. Is this right, or

I lately had exactly the same problem, and the conclusion was:
Either to learn how to shred 'inside the Database' (without
the mason-code) or to restrict each shred-call to a few hundred
selected tickets. The shredder seems to create a long URI and
so the standard limits of URIs (from concatenating the call and
lots of ticket-numbers) seem unavoidable.

We simply ignored the old tickets, hoping for a solution
to pop up somewhere, before the next cycle. Alas we see
4.* now and have 3.* running, and still no idea ...

Would it be possible to 'translate' the shredders algorithm
from mason-code directly to 'some SQL dialect' or at least
to translate 'shredding one ticket completely in SQL'?
(Or is that impossible, because the contents and links of
a ticket can not be analyzed that way, and really need
'perlcode', to follow and decide what to shred?)

Stucki

--------
RT Training Sessions (http://bestpractical.com/services/training.html)
*  Chicago, IL, USA  September 26 & 27, 2011
*  San Francisco, CA, USA  October 18 & 19, 2011
*  Washington DC, USA  October 31 & November 1, 2011
*  Melbourne VIC, Australia  November 28 & 29, 2011
*  Barcelona, Spain  November 28 & 29, 2011

Reply via email to