Field rev_text_id is being retired as part of MCR Schema Migration.
Remove references to this field from the Postgres search queries.
Bug: T198341
Change-Id: Id3cbf853aacc06709f441a93248b55943097cd11
This should be handled internally by SearchEngine implementations.
Bug: T198860
Change-Id: Ifbfd0fcb81fcacf5228bd2ffcac7b80fca872b2a
Depends-On: I7d4ff9498fa1f4ea66835c634b8931f4c29993fb
The plan is to convert these methods into final, considering
it a removal under the deprecation policy. By making entry
points into the search engine final we provide a guaranteed
point where generic handling can be applied to all search engines.
The first use case for this generic handling is pushing pagination
via overfetch into the SearchEngine class instead of re-implementing
an overfetch in individual parts of the code that perform searches.
Change-Id: I3426d6a2f32d8b368b044b154e1cb70dac007c62
It looks like there is something missing after the last statement
Also remove some other empty lines at begin of functions, ifs or loops
while at these files
Change-Id: Ib00b5cfd31ca4dcd0c32ce33754d3c80bae70641
I searched for /\$(\S+) = (.+?\(.*?\);)\n.*?\$\1\[/, ignored
everything involving isset(), unset() or array assigments, then
skimmed through the remaining results and changed things where they
made sense. These changes were not automated, so please review them.
Change-Id: Ib37b4c66fc57648470f151ad412210b3629c2538
When a page is updated under PostgreSQL, there is code to
de-index all but the most recent version of the page. But
when a page is moved, it was accidentally de-indexing the
most recent version as well, because rev_text_id is not
incremented in that case. A simple tweak to the SQL
fixes that.
I added code to the update script to find pages
previously corrupted by this problem and reindex them.
Bug: 66650
Change-Id: I52e1bbbd8592be5e7c7383c225e6b4c19bbe5b9e
DatabaseBase::query() already passes the value returned by the
database driver (usually an object or resource for SELECT queries)
through $db->resultObject(). There is no need to pass it through
the method a second time to get a ResultWrapper.
Change-Id: I5d34ab2bffb7f236d2f824b4ef0e8670f89d4599
Otherwise, multiple calls to searchQuery() would accumulate search
terms. searchTerms[] is defined in SearchEngine so we can't just get
rid of it altogether.
Change-Id: Iddbb3920e3a9d5849c99fe90d2d725d16019b51d
Scores are an internal metric that should not be exposed to
users, plus most backends fail to even support it.
Removes PostgresSearch*-specific result classes as they're not
needed anymore.
Change-Id: I00acaabad0565b9a5b3524c992feea366eb74bcc
Only worked for Postgres, and only worked halfway at that. Result
sets could be false for many reasons. No results, bad query, database
went to Mars. We shouldn't assume they're always "too many results."
Leave it up to the normal query error logging and move on.
Change-Id: Ieddd163e440ae54b152541d727c1afdbc4ab4fbd
SqlSearchResultSet basically handles all of the work in a DB-agnostic
manner. Remove specific implementations for MySQL, Mssql and Sqlite
Change-Id: Iae3fd5cc40dfbc50917be73d7ace668681e4148a
Whenever a new revision is added, a deferred update gets enqueued.
When it is fired, it clears the searchable text from all earlier
revisions for the article. This becomes very slow for articles
with long revision histories, as it re-clears the textvector even
when it has already been cleared by earlier actions. This leads to
very high load in the database for runs of importDump.php
This patch improves this situation by adding a condition to the WHERE
clause such that it does not update rows in which the textvector
is already NULL.
PostgreSQL cannot automatically remove such degenerate updates
in general because the updated rows must be locked and have their
transaction markers increased. However, in this particular case
those things are unimportant.
This change improves the performance of importDump.php on a
wiki with long revision histories by 7 fold, and moves the
major bottleneck from the database to PHP. It might also
improve the performance of ordinary page edits, but that
was not tested.
There are more improvements that could be made here. For example,
a partial index or expression index could make it so that already
cleared rows do not have to be visited at all. Or the deferred
update mechanism could have a notion of "idempotency" so that many
indentical updates enqueued during bulk loading would be condensed
to only a single execution. However, this change is very much
simpler and is sufficient to shift the bottleneck elsewhere.
Change-Id: I458603767c6a86425010d02ffc1f8079c4b3c9a0
Swapped some "$var type" to "type $var" or added missing types
before the $var. Changed some other types to match the more common
spelling. Makes beginning of some text in captial.
Change-Id: Ifbb1da2a6278b0bde2a6f6ce2e7bd383ee3fb28a
Always include redirects. Search results are worse without them
and MWSearch has never respected this option anyway.
Change-Id: I0ebe321a3b14e7960aa98e3225dc5a19ba916e7d
There's a lot in the base search implementations that is specific
to the database backed search. This starts moving some of that out
into a shared base class for those.
For starters, let's not grab a connection to the slave DB for
every single search for backends unless they need it.
Change-Id: Ib66696841eea901e04b21dd309784af889a45ab1
And added/removed spaces around some other tokens,
like +, -, *, /, <, >, =, !
Fixed windows newline style
Change-Id: I0b9c8c408f3f6bfc0d685a074d7ec468fb848fc8
* Removed spaces around array index
* Removed double spaces or added spaces to begin or end of function
calls, method signature, conditions or foreachs
* Added braces to one-line ifs
* Changed multi line conditions to one line conditions
* Realigned some arrays
Change-Id: Ia04d2a99d663b07101013c2d53b3b2e872fd9cc3
Doxygen expects parameter types to come before the
parameter name in @param tags. Used a quick regex
to switch everything around where possible. This
only fixes cases where a primitve variable (or a
primitive followed by other types) is the variable
type. Other cases will need to be fixed manually.
Change-Id: Ic59fd20856eb0489d70f3469a56ebce0efb3db13
* NOTE: this commit removes any semblence of tsearch compatibility with pre-8.3 PostgreSQL
* Make new-installer work against PostgreSQL
* Remove SearchPostgres.php's call to pg_fetch_result. I think this is the only one outside of the vestigtial old installer code.
