1
0
Fork 0
mirror of https://we.phorge.it/source/phorge.git synced 2024-11-28 17:52:43 +01:00
Commit graph

7 commits

Author SHA1 Message Date
epriestley
09c8af4de0 Upgrade phabricator to libphutil v2
Summary: Mechanical changes from D2588. No "Class.php" moves yet.

Test Plan: See D2588.

Reviewers: vrana, btrahan, jungejason

Reviewed By: vrana

CC: aran

Maniphest Tasks: T1103

Differential Revision: https://secure.phabricator.com/D2591
2012-05-30 14:26:29 -07:00
epriestley
d0af617818 Add "final" to (almost) everything else
Summary: Last of the big final patches. Left a few debatable classes (12 out of about 400) that I'll deal with individually eventually.

Test Plan: Ran testEverythingImplemented.

Reviewers: btrahan

Reviewed By: btrahan

CC: aran, epriestley

Maniphest Tasks: T795

Differential Revision: https://secure.phabricator.com/D1881
2012-03-13 16:21:04 -07:00
epriestley
a5f8846f47 Use a unique random key to identify queries, not a sequential ID
Summary:
We save search information and then redirect to a "/search/<query_id>/" URI in
order to make search URIs short and bookmarkable, and save query data for
analysis/improvement of search results.

Currently, there's a vague object enumeration security issue with using
sequential IDs to identify searches, where non-admins can see searches other
users have performed. This isn't really too concerning but we lose nothing by
using random keys from a large ID space instead.

  - Drop 'authorPHID', which was unused anyway, so searches can not be
personally identified, even by admins.
  - Identify searches by random hash keys, not sequential IDs.
  - Map old queries' keys to their IDs so we don't break any existing bookmarked
URIs.

Test Plan: Ran several searches, got redirected to URIs with random hashes from
a large ID space rather than sequential integers.

Reviewers: arice, btrahan

Reviewed By: arice

CC: aran, epriestley

Differential Revision: https://secure.phabricator.com/D1587
2012-02-07 14:58:46 -08:00
epriestley
4bec2579d5 Some documentation updates. 2011-09-14 08:02:31 -07:00
epriestley
b8e08f34f7 Provide an indirection layer between documents and the search engine
Summary:
In preparation for adding another search engine (see T355):

  - Rename "executor" to "engine".
  - Move all engine-specific operations into the engine. Specifically, this
means that indexing moves out of the document store and into the engine (it was
sort of silly where it was before).
  - Split choice of an engine into an overridable "selector" class, a base API,
and a concrete MySQL implementation (just like storage engine selection).
  - Make all callers go through the indirection layer.

The default selector just unconditionally selects the MySQL engine, but now
(with D786) I can build an Elastic Search engine and you guys can build a
multi-target engine if you want and I don't get there fast enough.

Test Plan:
  - Created a new document (task).
  - Searched for and found it.
  - Viewed index reconstruction.

Reviewed By: jungejason
Reviewers: jungejason, amckinley, tuomaspelkonen, aran
CC: aran, jungejason, epriestley
Differential Revision: 788
2011-08-08 11:43:05 -07:00
epriestley
505c82236d Improve search functionality.
Summary:

Test Plan:

Reviewers:

CC:
2011-02-18 17:16:00 -08:00
epriestley
147d2e2e3d Rought cut of search.
Summary: Botched this pretty badly in git so we'll see how much I broke. :/

Test Plan:

Reviewers:

CC:
2011-02-14 15:34:20 -08:00