Page MenuHomePhabricator

Implement ngram search for File objects
ClosedPublic

Authored by amckinley on Apr 17 2017, 7:14 PM.
Tags
None
Referenced Files
F15410685: D17702.id42609.diff
Wed, Mar 19, 8:10 AM
F15399000: D17702.id42576.diff
Mon, Mar 17, 2:22 AM
F15393161: D17702.diff
Sat, Mar 15, 8:08 PM
F15390510: D17702.id42610.diff
Sat, Mar 15, 6:16 AM
F15379950: D17702.id42609.diff
Fri, Mar 14, 12:31 AM
F15374819: D17702.diff
Wed, Mar 12, 8:18 PM
Unknown Object (File)
Mon, Feb 24, 5:46 AM
Unknown Object (File)
Sun, Feb 23, 9:54 PM
Subscribers

Details

Summary

Follows the outline in D15656 for implementing ngram search for names of File objects. Also created FileFullTextEngine, because without implementing PhabricatorFulltextInterface, ./bin/search complains that File is not an indexable type.

Test Plan
  • ran ./bin/storage upgrade to apply the schema change
  • confirmed the presence of a new file_filename_ngrams table
  • added a couple file objects
  • ran bin/search index --type file --force
  • confirmed the presence of rows in file_filename_ngrams
  • did a few keyword searches and saw expected results

Diff Detail

Repository
rP Phabricator
Lint
Lint Not Applicable
Unit
Tests Not Applicable

Event Timeline

resources/sql/autopatches/20170417.files.ngrams.php
5 ↗(On Diff #42576)

Need to remove this unless we want to force a reindex of all documents during storage upgrade.

src/applications/files/search/FileFulltextEngine.php
3 ↗(On Diff #42576)

Not sure if this class needs to exist, but I couldn't force reindexing without implementing PhabricatorFulltextInterface.

Note that this also doesn't clean up ngrams once files are deleted. I'm going to follow along with D14846: Implement basic ngram search for Owners Package names to fix that.

This is right, except that we probably should't implement FulltextInterface or fulltext-index these. bin/search index was written before the ngrams stuff was written, let me see if I can send you a quick patch to let it work without needing fulltext.

The cleanup should happen automatically as a side effect of DestructionEngine, but neither PhabricatorFileTemporaryGarbageCollector nor PhabricatorFileDeleteController use the destruction engine properly (bin/remove destroy will). Swapping those to use a destruction engine should fix the ngrams stuff, maybe as part of T10828.

To use the destruction engine, replace this:

$file->delete();

...with this:

$engine = new PhabricatorDestructionEngine();
$engine->destroyObject($file);

D17704 should fix the bin/search index stuff -- it ended up easier than I thought, assuming it works.

  • removing FileFulltextEngine
  • removing migration to force file reindex
  • update File deletion logic to use DestructionEngine
This revision is now accepted and ready to land.Apr 18 2017, 12:35 AM
This revision was automatically updated to reflect the committed changes.