Listing.html, # of tickets\

If the ->Count is done after the ->_DoSearch method is called by internal
code, however (say by pulling out the first row), it will report
exactly how many rows are in the current result set. The reason
for the disparity is that doing a whole bunch of selects just to get counts
turns the rest of the system into molasses :confused:
I’m currently investigating some changes in the architecture for 2.2 that will
significantly improve the performance of all this stuff and get ->Count to be
more accurate as a happy side-benefit.

-jOn Tue, Apr 16, 2002 at 08:41:55PM +0200, Bruce Campbell wrote:

On Tue, 16 Apr 2002, Matt Disney wrote:

I’ve tried to add a line to the header of
$RTPath/WebRT/html/Search/Listing.html so that it displays the number
of tickets resulting from the query:

<& /Elements/Header, Title => “Search Results: “.$session{‘tickets’}->Count().” Tickets”, Refresh => $session{‘tickets_refresh_interval’} &>

->Count essentially changes the SQL query from:

select field.field.field from (etc)
to
select count(id) from (etc)

If a Limit statement is applied (which is how the 50 per page stuff does),
count is faithfully reporting how many rows would be returned :wink:

I’m not entirely sure this is a bug exactly, I’m just wanting to know
if anyone has suggestions on how I might go about accumulating the
total number of tickets for a search.

Depending on your installation, I’d be rather careful (repeating rather
broad searches just to get a count on each new page is ugly), however
storing the total results in the %session, and checking that you haven’t
already gotten a total result for the current search would be nifty.


Bruce Campbell RIPE
Systems/Network Engineer NCC
www.ripe.net - PGP562C8B1B Operations


rt-devel mailing list
rt-devel@lists.fsck.com
http://lists.fsck.com/mailman/listinfo/rt-devel

http://www.bestpractical.com/products/rt – Trouble Ticketing. Free.

Ok, so doing a Count is basically just another select. I didn’t realize
that. That would explain why I couldn’t figure out what was going on,
because I was thinking about it all wrong.

Thanks for the responses on that.

It sounds like I’m going to have to use Count one way or the other,
though, if I want to see the total number of tickets. At least that’s
the easiest way, if not the most performance-sensitive. In your
opinions, how would one go about accumulating the Count for different
Limits? Sorry if that’s dense of me. Would it be better of me to
actually extend Tickets or Tickets::Count instead of trying to do it in
Mason?

I’m weighing my options, and none of them seem exactly what I’d like
to do… but this total number of tickets stuff is pretty important
to us.

Let me know if you think of anything or have opinions on the matter.

Thanks again,
Matt

Jesse Vincent writes:

Have a look at /Elements/QuickSearch and how it’s doing things.On Tue, Apr 16, 2002 at 02:55:40PM -0500, Matt Disney wrote:

Ok, so doing a Count is basically just another select. I didn’t realize
that. That would explain why I couldn’t figure out what was going on,
because I was thinking about it all wrong.

Thanks for the responses on that.

It sounds like I’m going to have to use Count one way or the other,
though, if I want to see the total number of tickets. At least that’s
the easiest way, if not the most performance-sensitive. In your
opinions, how would one go about accumulating the Count for different
Limits? Sorry if that’s dense of me. Would it be better of me to
actually extend Tickets or Tickets::Count instead of trying to do it in
Mason?

I’m weighing my options, and none of them seem exactly what I’d like
to do… but this total number of tickets stuff is pretty important
to us.

Let me know if you think of anything or have opinions on the matter.

Thanks again,
Matt

Jesse Vincent writes:

If the ->Count is done after the ->_DoSearch method is called by internal
code, however (say by pulling out the first row), it will report
exactly how many rows are in the current result set. The reason
for the disparity is that doing a whole bunch of selects just to get counts
turns the rest of the system into molasses :confused:
I’m currently investigating some changes in the architecture for 2.2 that will
significantly improve the performance of all this stuff and get ->Count to be
more accurate as a happy side-benefit.

-j

On Tue, Apr 16, 2002 at 08:41:55PM +0200, Bruce Campbell wrote:

On Tue, 16 Apr 2002, Matt Disney wrote:

I’ve tried to add a line to the header of
$RTPath/WebRT/html/Search/Listing.html so that it displays the number
of tickets resulting from the query:

<& /Elements/Header, Title => “Search Results: “.$session{‘tickets’}->Coun
t().” Tickets”, Refresh => $session{‘tickets_refresh_interval’} &>

->Count essentially changes the SQL query from:

select field.field.field from (etc)
to
select count(id) from (etc)

If a Limit statement is applied (which is how the 50 per page stuff does),
count is faithfully reporting how many rows would be returned :wink:

I’m not entirely sure this is a bug exactly, I’m just wanting to know
if anyone has suggestions on how I might go about accumulating the
total number of tickets for a search.

Depending on your installation, I’d be rather careful (repeating rather
broad searches just to get a count on each new page is ugly), however
storing the total results in the %session, and checking that you haven’t
already gotten a total result for the current search would be nifty.


Bruce Campbell RIPE
Systems/Network Engineer NCC
www.ripe.net - PGP562C8B1B Operations


rt-devel mailing list
rt-devel@lists.fsck.com
http://lists.fsck.com/mailman/listinfo/rt-devel


http://www.bestpractical.com/products/rt – Trouble Ticketing. Free.


rt-devel mailing list
rt-devel@lists.fsck.com
http://lists.fsck.com/mailman/listinfo/rt-devel


rt-devel mailing list
rt-devel@lists.fsck.com
http://lists.fsck.com/mailman/listinfo/rt-devel

http://www.bestpractical.com/products/rt – Trouble Ticketing. Free.