Page MenuHomePhabricator

Implement ngram search for File objects
ClosedPublic

Authored by amckinley on Apr 17 2017, 7:14 PM.
Tags
None
Referenced Files
F14015593: D17702.id42610.diff
Sun, Nov 3, 9:51 PM
F14013818: D17702.id.diff
Sat, Nov 2, 4:00 PM
F13993742: D17702.id42609.diff
Wed, Oct 23, 1:08 AM
F13982746: D17702.id.diff
Sun, Oct 20, 1:40 AM
F13974808: D17702.diff
Oct 18 2024, 7:29 AM
Unknown Object (File)
Oct 13 2024, 6:37 PM
Unknown Object (File)
Oct 1 2024, 9:22 PM
Unknown Object (File)
Sep 14 2024, 1:15 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.