Vocabulary timeout when searching for a person (in +editstatus, +reassign and @@popup-window)

It appears to expire because of:

/srv/launchpad.ubuntu.com/staging/launchpad/lib/canonical/launchpad/templates/bugtask-edit.pt
Line 33, Column 12
Expression: <PathExpr standard:'view/update|nothing'>

RequestExpired: (("SELECT Person.id, Person.defaultrenewalperiod, Person.postcode, Person.subscriptionpolicy, Person.teamowner, Person.merged, Person.displayname, Person.password, Person.name, Person.familyname, Person.datecreated, Person.calendar, Person.teamdescription, Person.givenname, Person.country, Person.addressline2, Person.addressline1, Person.city, Person.emblem, Person.hackergotchi, Person.phone, Person.defaultmembershipperiod, Person.timezone, Person.province, Person.karma, Person.organization, Person.homepage_content FROM Person WHERE ((Person.name = 'admins') AND (Person.merged IS NULL)) ORDER BY displayname, familyname, givenname, name",), {})

This is something of a strange query, hmmm.

I also get (whatever it may be) OOPS-S26. The query I pasted above takes nothing to run on staging's psql prompt and returns only one row.

Another one:
RequestExpired: (('SELECT EmailAddress.id, EmailAddress.status, EmailAddress.person, EmailAddress.email FROM EmailAddress WHERE ((EmailAddress.person = 98) AND (EmailAddress.status = 4)) ORDER BY email',), {})

This also runs immediately. I think we are bombing on something else..

> I also get (whatever it may be) OOPS-S26. The query I pasted above takes
> nothing to run on staging's psql prompt and returns only one row.
>
> Another one:
> RequestExpired: (('SELECT EmailAddress.id, EmailAddress.status, EmailAddress.person, EmailAddress.email FROM EmailAddress WHERE ((EmailAddress.person = 98) AND (EmailAddress.status = 4)) ORDER BY email',), {})
>
> This also runs immediately. I think we are bombing on something else..

This is the query that gets the preferred email of one of the persons/teams
whose name/email matched the text you entered. In case of Matthew (not sure if
yours is the same), this query (and some others) had to be executed almost
1400 times, so that's probably what causes the problem.

The problem here is that the vocabulary is dumb enough to try and fetch all
the results from the database and put that in a selectbox. What we need to do,
IMO, is to ask the user to try a search using the popup window, as that has a
batched list and thus won't time out.

On Tue, Dec 06, 2005 at 08:48:05PM -0000, Guilherme Salgado wrote:
> This is the query that gets the preferred email of one of the persons/teams
> whose name/email matched the text you entered. In case of Matthew (not sure if
> yours is the same), this query (and some others) had to be executed almost
> 1400 times, so that's probably what causes the problem.

I suspect we could work around this by using an SQL view (because we
could be doing a single query), though the end-result would still be
ghastly because, simply put, there are too many results matching that.

We need a UI answer to that part of the problem -- Matthew?

We could list a small number of results and then say (511 other
matches...). We could also try and display a "best selection" -- one
criterium could be "people that belong to the team that owns the product
or distro". However, I have no suggestion on how to handle the UI for
selecting somebody from the "other matches" group. :-(

The minimum needed to fix this bug is to remove the select entirely (canonical/widgets/popup.py), forcing people to use the popup search if they don't know the Person.name. I didn't think this through obviously when I added this feature.

> The minimum needed to fix this bug is to remove the select entirely
> (canonical/widgets/popup.py), forcing people to use the popup search if
> they don't know the Person.name. I didn't think this through obviously
> when I added this feature.

Isn't this the fix for bug 2045 too?

But I like that feature /so much/. Isn't there a good compromise we can reach that isn't the minimum?

I've been thinking about how zillions of results would work for SuggestionSearchControl. In general, I think the ten most likely results should be returned, followed by a disabled "1359 more..." item. And when searching for people, the most likely results are those with the most karma. The same approaches can be used for the current <select>.

Well, there are other criteria for "most likely matches". For instance, if the person is an owner (or a member of a team which is an owner) of a target of one of the tasks listed, they are quite likely to be who you want to assign to.

Christian Reis wrote:
> Public bug report changed:
> https://launchpad.net/malone/bugs/5415
>
> Comment:
> Well, there are other criteria for "most likely matches". For instance,
> if the person is an owner (or a member of a team which is an owner) of a
> target of one of the tasks listed, they are quite likely to be who you
> want to assign to.
>

I like the idea of just shoving a 'LIMIT 10' in the query somewhere,
possibly with an 11th item 'More...' with javascript magic to launch the
popup search.

The query could be tweaked to return items in 'most likely first' where that
makes sense.

--
Stuart Bishop <email address hidden> http://www.canonical.com/
Canonical Ltd. http://www.ubuntu.com/

Nominating for oops as this is a toplagger.

This may be resolved or minimized when bug 2045 gets fixed.

This is now much better, and I am unable to get timeouts when doing most searches.

However, you can still reliably time out when searching for "a". I think this is now just a matter of issuing some gnarly COUNT(*) queries, as you can see from OOPS-62B222

It could also be that these queries are the tip of the iceberg and that once they succeed a huge number of smaller queries will be issued, which will eventually time out as well.

To reproduce, try reassigning to "b" -- not "a", because unfortunately, there is now somebody that picked that name!

I just tried reproducing this with several one-letter searches, but didn't get any timeouts. Should we consider this resolved?