[rt-users] Dump all except tickets+attachments?

[Jeff Blaine]

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
>