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 -- Christoph von Stuckrad * * |nickname |Mail <[email protected]> \ Freie Universitaet Berlin |/_*|'stucki' |Tel(Mo.,Mi.):+49 30 838-75 459| Mathematik & Informatik EDV |\ *|if online| (Di,Do,Fr):+49 30 77 39 6600| Takustr. 9 / 14195 Berlin * * |on IRCnet|Fax(home): +49 30 77 39 6601/ -------- 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
