Re: [rt-users] request for feedback on a patch for RT 3.6.4
Kenneth, don't you know that sending unrelated things to a thread on mailing lists is very bad habit. Sorry, but I ignore this mail as it has nothing to do with the patch. On 8/3/07, Kenneth Crocker <[EMAIL PROTECTED]> wrote: > Ruslan, > > > We just installed 3.6.4 in our test environment and have found a few > problems with the Query: > > 1) Although "OwnerName" appears as a field to display, it is not > included into the choices for a sort. "Custom.Owner" doesn't work worth > a [EMAIL PROTECTED]&^%. > 2) The "highly-touted" sort by custom field feature doesn't work, At > ALL. > 3) When deleting fields from the default display of choices, we must > do > so one field at a time. Very time-consuming and ANNOYING! Why can't we > just highlight the ones we want to delete (like the ones we choose to > add from the left side) and do it in one swell foop (he he). > > On Reminders; we think it would be REALLY convenient for Reminders to > automatically resolve if the ticket they are linked to gets resolved. > Actually, we can't think of a reason to NOT have done this in the origin > design. > > So, other than having to re-login the first time we try to do > something > after the initial sign on, AND the above-mentioned problems with query, > we like it just fine (come on in! The water is just "iineee" > - an old Cosby joke). > Are there any fixes (for any of the above) about ready to implement? > > > Kenn > LBNL > > Ruslan Zakirov wrote: > > Hi, brave users of RT 3.6.4. > > > > In the mentioned version of RT I changed SQL queries we generate to > > searches tickets by watchers(requestors, cc or admicc). Logic of those > > queries is better now. However, I've broken performance of queries > > like "Requestor = 'X' OR Owner = 'Y'", "Requestor = X OR Status = 'Y'" > > and most probably other where condition on watcher is joined with > > another condition using OR aggregator. > > > > We have two ways to fix the problem. I sent one patch already to the > > list, but we really need more feedback (positive or negative) to make > > right choice, so I post it again. > > > > Please do the following steps to collect feedback I need. > > 1) build a query (see above) in the query builder using sane values > > for your setup > > 2) execute search and wait for results, we expect it to be very slow, > > so you shouldn't wait to much > > 3) apply the patch > > cd /opt/rt3; > > cat /path/to/the/patch | patch -p0 > > 4) stop and start web server > > 5) try search again > > > > Send feedback. People who know how to deal with slow-logs, explain are > > more than welcome to send additional info, but even if you don't know > > how to deal with those it's ok, just send description of the system > > behavior and wallclock timings. > > > > 6) revert patch > > cat /path/to/the/patch | patch -p0 -R > > 7) stop and start web server > > > > > > > > > > > > > > ___ > > http://lists.bestpractical.com/cgi-bin/mailman/listinfo/rt-users > > > > Community help: http://wiki.bestpractical.com > > Commercial support: [EMAIL PROTECTED] > > > > > > Discover RT's hidden secrets with RT Essentials from O'Reilly Media. > > Buy a copy at http://rtbook.bestpractical.com > ___ > http://lists.bestpractical.com/cgi-bin/mailman/listinfo/rt-users > > Community help: http://wiki.bestpractical.com > Commercial support: [EMAIL PROTECTED] > > > Discover RT's hidden secrets with RT Essentials from O'Reilly Media. > Buy a copy at http://rtbook.bestpractical.com > -- Best regards, Ruslan. ___ http://lists.bestpractical.com/cgi-bin/mailman/listinfo/rt-users Community help: http://wiki.bestpractical.com Commercial support: [EMAIL PROTECTED] Discover RT's hidden secrets with RT Essentials from O'Reilly Media. Buy a copy at http://rtbook.bestpractical.com
Re: [rt-users] request for feedback on a patch for RT 3.6.4
Rus; Just applied the patch a query similar to the below: - before the patch I stopped it after 3 minutes no results, - after the patch it returned the correct results within seconds .. Regards; Roy James Moseley wrote: ( Status = 'new' OR Status = 'open' ) AND ( Cc.Name = 'user' OR AdminCc.Name = 'user' ) After applying the patch, the same search takes 1 second. This with a database of around 14,000 tickets. James Moseley "Ruslan Zakirov" <[EMAIL PROTECTED] l.com> To Sent by: "RT users" rt-users-bounces@ lists.bestpractic cc al.com Subject [rt-users] request for feedback on 08/03/2007 11:25 a patch for RT 3.6.4 AM Hi, brave users of RT 3.6.4. In the mentioned version of RT I changed SQL queries we generate to searches tickets by watchers(requestors, cc or admicc). Logic of those queries is better now. However, I've broken performance of queries like "Requestor = 'X' OR Owner = 'Y'", "Requestor = X OR Status = 'Y'" and most probably other where condition on watcher is joined with another condition using OR aggregator. We have two ways to fix the problem. I sent one patch already to the list, but we really need more feedback (positive or negative) to make right choice, so I post it again. Please do the following steps to collect feedback I need. 1) build a query (see above) in the query builder using sane values for your setup 2) execute search and wait for results, we expect it to be very slow, so you shouldn't wait to much 3) apply the patch cd /opt/rt3; cat /path/to/the/patch | patch -p0 4) stop and start web server 5) try search again Send feedback. People who know how to deal with slow-logs, explain are more than welcome to send additional info, but even if you don't know how to deal with those it's ok, just send description of the system behavior and wallclock timings. 6) revert patch cat /path/to/the/patch | patch -p0 -R 7) stop and start web server -- Best regards, Ruslan. (See attached file: 3.6-searches_by_watchers_performance_fix.patch) ___ http://lists.bestpractical.com/cgi-bin/mailman/listinfo/rt-users Community help: http://wiki.bestpractical.com Commercial support: [EMAIL PROTECTED] Discover RT's hidden secrets with RT Essentials from O'Reilly Media. Buy a copy at http://rtbook.bestpractical.com ___ http://lists.bestpractical.com/cgi-bin/mailman/listinfo/rt-users Community help: http://wiki.bestpractical.com Commercial support: [EMAIL PROTECTED] Discover RT's hidden secrets with RT Essentials from O'Reilly Media. Buy a copy at http://rtbook.bestpractical.com ___ http://lists.bestpractical.com/cgi-bin/mailman/listinfo/rt-users Community help: http://wiki.bestpractical.com Commercial support: [EMAIL PROTECTED] Discover RT's hidden secrets with RT Essentials from O'Reilly Media. Buy a copy at http://rtbook.bestpractical.com
Re: [rt-users] request for feedback on a patch for RT 3.6.4
Ruslan, We just installed 3.6.4 in our test environment and have found a few problems with the Query: 1) Although "OwnerName" appears as a field to display, it is not included into the choices for a sort. "Custom.Owner" doesn't work worth a [EMAIL PROTECTED]&^%. 2) The "highly-touted" sort by custom field feature doesn't work, At ALL. 3) When deleting fields from the default display of choices, we must do so one field at a time. Very time-consuming and ANNOYING! Why can't we just highlight the ones we want to delete (like the ones we choose to add from the left side) and do it in one swell foop (he he). On Reminders; we think it would be REALLY convenient for Reminders to automatically resolve if the ticket they are linked to gets resolved. Actually, we can't think of a reason to NOT have done this in the origin design. So, other than having to re-login the first time we try to do something after the initial sign on, AND the above-mentioned problems with query, we like it just fine (come on in! The water is just "iineee" - an old Cosby joke). Are there any fixes (for any of the above) about ready to implement? Kenn LBNL Ruslan Zakirov wrote: Hi, brave users of RT 3.6.4. In the mentioned version of RT I changed SQL queries we generate to searches tickets by watchers(requestors, cc or admicc). Logic of those queries is better now. However, I've broken performance of queries like "Requestor = 'X' OR Owner = 'Y'", "Requestor = X OR Status = 'Y'" and most probably other where condition on watcher is joined with another condition using OR aggregator. We have two ways to fix the problem. I sent one patch already to the list, but we really need more feedback (positive or negative) to make right choice, so I post it again. Please do the following steps to collect feedback I need. 1) build a query (see above) in the query builder using sane values for your setup 2) execute search and wait for results, we expect it to be very slow, so you shouldn't wait to much 3) apply the patch cd /opt/rt3; cat /path/to/the/patch | patch -p0 4) stop and start web server 5) try search again Send feedback. People who know how to deal with slow-logs, explain are more than welcome to send additional info, but even if you don't know how to deal with those it's ok, just send description of the system behavior and wallclock timings. 6) revert patch cat /path/to/the/patch | patch -p0 -R 7) stop and start web server ___ http://lists.bestpractical.com/cgi-bin/mailman/listinfo/rt-users Community help: http://wiki.bestpractical.com Commercial support: [EMAIL PROTECTED] Discover RT's hidden secrets with RT Essentials from O'Reilly Media. Buy a copy at http://rtbook.bestpractical.com ___ http://lists.bestpractical.com/cgi-bin/mailman/listinfo/rt-users Community help: http://wiki.bestpractical.com Commercial support: [EMAIL PROTECTED] Discover RT's hidden secrets with RT Essentials from O'Reilly Media. Buy a copy at http://rtbook.bestpractical.com
Re: [rt-users] request for feedback on a patch for RT 3.6.4
For me, this patch has worked perfectly. Right after my upgrade to 3.6.4, I had posted to this list regarding search timeouts when using AdminCC or CC searches, but got no response. Eventually, other folks started to have the same problem and as it turns out, it's only when using the 'OR' aggregator. It would have helped to have posted the actual search, I agree. Anyway, here's an example search that after four minutes timed out *before* the patch was applied: ( Status = 'new' OR Status = 'open' ) AND ( Cc.Name = 'user' OR AdminCc.Name = 'user' ) After applying the patch, the same search takes 1 second. This with a database of around 14,000 tickets. James Moseley "Ruslan Zakirov" <[EMAIL PROTECTED] l.com> To Sent by: "RT users" rt-users-bounces@ lists.bestpractic cc al.com Subject [rt-users] request for feedback on 08/03/2007 11:25 a patch for RT 3.6.4 AM Hi, brave users of RT 3.6.4. In the mentioned version of RT I changed SQL queries we generate to searches tickets by watchers(requestors, cc or admicc). Logic of those queries is better now. However, I've broken performance of queries like "Requestor = 'X' OR Owner = 'Y'", "Requestor = X OR Status = 'Y'" and most probably other where condition on watcher is joined with another condition using OR aggregator. We have two ways to fix the problem. I sent one patch already to the list, but we really need more feedback (positive or negative) to make right choice, so I post it again. Please do the following steps to collect feedback I need. 1) build a query (see above) in the query builder using sane values for your setup 2) execute search and wait for results, we expect it to be very slow, so you shouldn't wait to much 3) apply the patch cd /opt/rt3; cat /path/to/the/patch | patch -p0 4) stop and start web server 5) try search again Send feedback. People who know how to deal with slow-logs, explain are more than welcome to send additional info, but even if you don't know how to deal with those it's ok, just send description of the system behavior and wallclock timings. 6) revert patch cat /path/to/the/patch | patch -p0 -R 7) stop and start web server -- Best regards, Ruslan. (See attached file: 3.6-searches_by_watchers_performance_fix.patch) ___ http://lists.bestpractical.com/cgi-bin/mailman/listinfo/rt-users Community help: http://wiki.bestpractical.com Commercial support: [EMAIL PROTECTED] Discover RT's hidden secrets with RT Essentials from O'Reilly Media. Buy a copy at http://rtbook.bestpractical.com 3.6-searches_by_watchers_performance_fix.patch Description: Binary data ___ http://lists.bestpractical.com/cgi-bin/mailman/listinfo/rt-users Community help: http://wiki.bestpractical.com Commercial support: [EMAIL PROTECTED] Discover RT's hidden secrets with RT Essentials from O'Reilly Media. Buy a copy at http://rtbook.bestpractical.com
[rt-users] request for feedback on a patch for RT 3.6.4
Hi, brave users of RT 3.6.4.
In the mentioned version of RT I changed SQL queries we generate to
searches tickets by watchers(requestors, cc or admicc). Logic of those
queries is better now. However, I've broken performance of queries
like "Requestor = 'X' OR Owner = 'Y'", "Requestor = X OR Status = 'Y'"
and most probably other where condition on watcher is joined with
another condition using OR aggregator.
We have two ways to fix the problem. I sent one patch already to the
list, but we really need more feedback (positive or negative) to make
right choice, so I post it again.
Please do the following steps to collect feedback I need.
1) build a query (see above) in the query builder using sane values
for your setup
2) execute search and wait for results, we expect it to be very slow,
so you shouldn't wait to much
3) apply the patch
cd /opt/rt3;
cat /path/to/the/patch | patch -p0
4) stop and start web server
5) try search again
Send feedback. People who know how to deal with slow-logs, explain are
more than welcome to send additional info, but even if you don't know
how to deal with those it's ok, just send description of the system
behavior and wallclock timings.
6) revert patch
cat /path/to/the/patch | patch -p0 -R
7) stop and start web server
--
Best regards, Ruslan.
=== lib/RT/Tickets_Overlay.pm
==
--- lib/RT/Tickets_Overlay.pm (revision 5413)
+++ lib/RT/Tickets_Overlay.pm (local)
@@ -854,6 +854,8 @@
$self->_OpenParen;
if ( $op =~ /^IS(?: NOT)?$/ ) {
my $group_members = $self->_GroupMembersJoin( GroupsAlias => $groups );
+# to avoid joining the table Users into the query, we just join GM
+# and make sure we don't match records where group is member of itself
$self->SUPER::Limit(
LEFTJOIN => $group_members,
FIELD => 'GroupId',
@@ -954,16 +956,26 @@
);
}
-$self->_SQLLimit(
-ALIAS => $users,
-FIELD => $rest{SUBKEY},
-VALUE => $value,
-OPERATOR => $op,
-CASESENSITIVE => 0,
+# we join users table without adding some join condition between tables,
+# the only conditions we have are conditions on the table iteslf,
+# for example Users.EmailAddress = 'x'. We should add this condition to
+# the top level of the query and bundle it with another similar conditions,
+# for example "Users.EmailAddress = 'x' OR Users.EmailAddress = 'Y'".
+# To achive this goal we use own SUBCLAUSE for conditions on the users table.
+$self->SUPER::Limit(
%rest,
+SUBCLAUSE => '_sql_u_watchers_'. $users,
+ALIAS => $users,
+FIELD => $rest{'SUBKEY'},
+VALUE => $value,
+OPERATOR=> $op,
+CASESENSITIVE => 0,
);
+# A condition which ties Users and Groups (role groups) is a left join condition
+# of CachedGroupMembers table. To get correct results of the query we check
+# if there are matches in CGM table or not using 'cgm.id IS NOT NULL'.
$self->_SQLLimit(
-ENTRYAGGREGATOR => 'AND',
+%rest,
ALIAS => $group_members,
FIELD => 'id',
OPERATOR=> 'IS NOT',
___
http://lists.bestpractical.com/cgi-bin/mailman/listinfo/rt-users
Community help: http://wiki.bestpractical.com
Commercial support: [EMAIL PROTECTED]
Discover RT's hidden secrets with RT Essentials from O'Reilly Media.
Buy a copy at http://rtbook.bestpractical.com
