[rt-devel] Users::WhoHaveRight and Sybase

[Audley, Christopher]

I had the where GroupId = NULL in there just as a lazy way to ensure valid SQL even when the array of groups was undefined or empty.  It seemed harmless enough, GroupId in GroupMembers is 'NOT NULL', although its not in CachedGroupMembers, it seemed unlikely this would ever cause a false match.

I wan't sure if you'd want a subquery inside of Users->WhoHaveRight, so I just through this together assuming it would be revised before accepted.

Cheers
Chris

-----Original Message-----
From: Jesse Vincent [mailto:jesse at bestpractical.com]
Sent: Monday, June 30, 2003 3:06 PM
To: Audley, Christopher
Cc: rt-devel at lists.fsck.com
Subject: Re: [rt-devel] Users::WhoHaveRight and Sybase

On Wed, Jun 25, 2003 at 02:46:02PM -0400, Audley, Christopher wrote:
> 
> Using this split query, we get access times down to less than 300ms.  I've attached the local/lib/RT/Users_Local.pm, local/lib/RT/Groups_Local.pm and local/html/Elements/SelectOwner that we are using, I'm curious if this method improves access times with other database engines.

I've finally had time to review this and test it against the test suite.
A slightly different version of this patch will be in the first 3.0.4
pre-release. Specifically, I've rewritten Users->WhoHaveRight to use the
new split routines rather than doing the "big" query, which means that
there are no changes needed for the SelectOwner component. I've also
cleaned things up a little bit and added a bit more flowthrough of
options. But it should be checked in in a matter of minutes.

Specifically, I rewrote Users->WhoAreInGroups to use the SearchBuilder
query building API, rather than to hand construct SQL queries. I note
that you were allowing it to find cases where the GroupId was NULL. Is
there a specific reason for this?


Thanks for the investigative work on this one and your patience while I
found time to check it out.

	-j


> 
> Chris





-- 
http://www.bestpractical.com/rt  -- Trouble Ticketing. Free.