plv / azbuka Goto Github PK

Currently, Inodes store Tokenizable:

• Directory stores them so that future children can inherit this tokenizer.
• Document stores them because Document is also Tokenizable.

However, this can be roundabout. As my comment in Inode.kt explains:

// TODO:  Storing a Tokenizable in each Directory and Document is a bad idea. It wastes space with no real time benefits
// (esp. if API users may supply a tokenizer that is not a singleton). Also, this can leak if we accidentally keep
// references to a Tokenizable that is also a Document, even after we remove the Document from the DocumentStore.
// I'm crunched for time as of writing this comment, but the smarter thing to do would be to dynamic dispatch
// using a map of some sort.

I wrote FileTracker before introducing the Inode framework, so it still works directly with raw Paths. The code is messier compared to everything else, and untested as well. So, the list of things we need for FileTracker is as follows:

• Refactor to use Inodes instead of raw Paths
• Add support for RENAMED_TO/RENAMED_FROM watch events
• Write tests for FileTracker. Mocking this may be difficult with just JUnit tempDirectory -- using something like jimfs is preferred.
• In IndexManager, refactor the event registration code so that we transact the events received from FileTracker in batches rather than individually. This should provide better safety and keep FileTracker better in sync with InodeStore and TokenIndex

IndexManager has very low test coverage, we should bring that test coverage closer to 100%.