-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
I’ve just put RT 3.4.2 into production and have noticed something
interesting. One of the tickets that had been created earlier is no
longer in the database! At least it can’t be accessed via RT. Yet other
tickets with higher numbers are there. I have not done anything directly
against the (MySQL) database (such as run RTShredder) that would have
removed the ticket.
Any idea how this can occur? It’s possible that the ticket was marked
with status ‘deleted’, but it shouldn’t be gone from the database.
As it happens, this messes up one of my perl scripts, that displays all
tickets with status ‘deleted’ in a range of ticket numbers, but stops as
soon as a ticket can’t be loaded, on the assumption that this means I’ve
passed the largest ticket number currently in RT. It would be nice if I
could continue to rely on that assumption, at least as long as I don’t
intentionally remove tickets from the database.
Thanks.
Mike
Mike Friedman System and Network Security
mikef@ack.Berkeley.EDU 2484 Shattuck Avenue
1-510-642-1410 University of California at Berkeley
http://ack.Berkeley.EDU/~mikef http://security.berkeley.edu
-----BEGIN PGP SIGNATURE-----
Version: PGP 6.5.8
iQA+AwUBQ4s7Y60bf1iNr4mCEQLOngCYgGRS87I8yLEx0BCU6qxF6tJV5wCgz1lI
I5m6Wk3F8kUs5f18V2W1U2k=
=xPZD
-----END PGP SIGNATURE-----
I don’t understand your problem, but
- you can’t search deleted tickets by id
- you can view it by #id
- 3.4.3 has patch that allows you to get deleted tickets from script.On 11/28/05, Mike Friedman mikef@ack.berkeley.edu wrote:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
I’ve just put RT 3.4.2 into production and have noticed something
interesting. One of the tickets that had been created earlier is no
longer in the database! At least it can’t be accessed via RT. Yet other
tickets with higher numbers are there. I have not done anything directly
against the (MySQL) database (such as run RTShredder) that would have
removed the ticket.
Any idea how this can occur? It’s possible that the ticket was marked
with status ‘deleted’, but it shouldn’t be gone from the database.
As it happens, this messes up one of my perl scripts, that displays all
tickets with status ‘deleted’ in a range of ticket numbers, but stops as
soon as a ticket can’t be loaded, on the assumption that this means I’ve
passed the largest ticket number currently in RT. It would be nice if I
could continue to rely on that assumption, at least as long as I don’t
intentionally remove tickets from the database.
Thanks.
Mike
Mike Friedman System and Network Security
mikef@ack.Berkeley.EDU 2484 Shattuck Avenue
1-510-642-1410 University of California at Berkeley
http://ack.Berkeley.EDU/~mikef http://security.berkeley.edu
-----BEGIN PGP SIGNATURE-----
Version: PGP 6.5.8
iQA+AwUBQ4s7Y60bf1iNr4mCEQLOngCYgGRS87I8yLEx0BCU6qxF6tJV5wCgz1lI
I5m6Wk3F8kUs5f18V2W1U2k=
=xPZD
-----END PGP SIGNATURE-----
The rt-users Archives
Be sure to check out the RT Wiki at http://wiki.bestpractical.com
Download a free sample chapter of RT Essentials from O’Reilly Media at http://rtbook.bestpractical.com
WE’RE COMING TO YOUR TOWN SOON - RT Training in Amsterdam, Boston and
San Francisco - Find out more at http://bestpractical.com/services/training.html
Best regards, Ruslan.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1On Wed, 30 Nov 2005 at 16:46 (+0300), Ruslan Zakirov wrote:
I don’t understand your problem, but
- you can’t search deleted tickets by id
- you can view it by #id
- 3.4.3 has patch that allows you to get deleted tickets from script.
Ruslan,
First of all, the script I have to list deleted tickets uses the RT API
and just does a Load of each ticket by ID in a loop. And this does work.
But the problem is that certain tickets can’t be loaded by ID, either from
my script or from the web interface. In the latter case, I get the
message ‘Can’t load ticket nnnn …’. The ticket really seems to be gone.
Yet greater ticket numbers continue to be created in the db, so that’s why
I can’t understand where those missing tickets went. I’ve thus far found
at least a couple of ‘gaps’ in my RT’s ticket sequencing, i.e., ticket
numbers that simply can’t be loaded. I assume those tickets existed at
one point, or else later ticket numbers wouldn’t have been assigned by RT.
What could cause tickets to just disappear, or at least not be able to be
loaded?
Mike
Mike Friedman System and Network Security
mikef@ack.Berkeley.EDU 2484 Shattuck Avenue
1-510-642-1410 University of California at Berkeley
http://ack.Berkeley.EDU/~mikef http://security.berkeley.edu
-----BEGIN PGP SIGNATURE-----
Version: PGP 6.5.8
iQA+AwUBQ43RT60bf1iNr4mCEQKzZACgvO+b5hntSSR4JQDIcxRsPJB5598Al3g6
dyExYma9EM6noTOYfnIaMBk=
=vA3V
-----END PGP SIGNATURE-----
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1On Thu, 1 Dec 2005 at 10:20 (+0300), Ruslan Zakirov wrote:
DB transactions! You couldn’t assume that ID sequences is without gaps
even if you don’t delete anything.
Ruslan,
Aha! I guess this was my misunderstanding (or oversight). I had been
assuming that when you use the Load method on an ID number, it always
meant a ticket number. But clearly that’s not right, since all kinds of
objects in RT have ID numbers.
So, now I really would like to know (as I asked in a more recent posting)
if there’s a way, using the API, to determine the highest ticket ID that
has been assigned thus far. My script (which displays all deleted tickets
in a range of ticket numbers) can ignore the IDs that don’t load as
tickets, but I’d like to know when to stop searching when the specified
range is all existing tickets: I would stop when I reached the first ID
greater than or equal to the last ticket ID assigned.
I’m trying to reduce my log traffic by minimizing the number of ticket
Load failures that get logged when I run this script. So I don’t want to
just keep going up to some arbitrarily large number.
Thanks again.
Mike
Mike Friedman System and Network Security
mikef@ack.Berkeley.EDU 2484 Shattuck Avenue
1-510-642-1410 University of California at Berkeley
http://ack.Berkeley.EDU/~mikef http://security.berkeley.edu
-----BEGIN PGP SIGNATURE-----
Version: PGP 6.5.8
iQA/AwUBQ48rzq0bf1iNr4mCEQLnzgCffbmNqCSMkivzldX3b8YjoeXgfTkAoOZg
GHR/l7oPLdaCcEPHaI9loSvr
=cf09
-----END PGP SIGNATURE-----