Log for tique/src/conditional_collector/

• Adapt tique to tantivy 0.15 💬 by Caio 5 years ago

  Two simple changes:
  
   * SegmentLocalId is now SegmentOrd, so `segment_id` labels
     were also updated to `segment_ord`
  
   * DocAddress is now a struct with named members instead of
     a tuple newtype, so the code is changed to construct
     it like `DocAddress{...}` instead of `DocAddress(...)`
  

• Use new DocSet/Scorer API 💬 by Caio 5 years ago

  Introduced on tantivy.git @ e25284ba
  
  This changeset is sufficient, however upstream's f71b04acb introduced
  a `debug_assert!(self.doc() <= target)` for `SegmentPostings::seek`
  that looks overzealous to me.
  
  In release mode all tests pass, but given that lot has changed since
  last I looked I'll be double checking the affected functionality
  prior to letting this go wild.
  

• Add missing docs to exported things 💬 by Caio 6 years ago

  And enable `missing_docs` and `missing_doc_code_examples`
  

• Do not execute assertion-less doc code examples by Caio 6 years ago
• Swap `visit(score, doc)` with `visit(doc, score)` 💬 by Caio 6 years ago

  Aha! I made it backwards to make it easier to output consistently.
  
  The consistency part makes sense, but driving a container with score
  before the item being contained was too confusing.
  

• Expose the topk module internally by Caio 6 years ago
• Add docs for the remaining public items by Caio 6 years ago
• Expose CustomScoreTopCollector via `with_custom_scorer` by Caio 6 years ago
• Use tantivy's CustomScorer trait family instead of DocScorer 💬 by Caio 6 years ago

  Less code mo happy
  

• More documentation work by Caio 6 years ago
• Less unwrapping, more questions 💬 by Caio 6 years ago

  This patch helps rustdoc infer a `main() -> Result<...>` by adding
  an explicit `Ok(())` result at the end of the code block.
  

• Start working on `conditional_collector` docs by Caio 6 years ago
• Rename into{,unsorted}_collection_result 💬 by Caio 6 years ago

  Better than hidden in a comment at least :P
  

• Move logic to detect pagination to CollectionResult 💬 by Caio 6 years ago

  And flatten `items_to_ids` into `render` since it's the only expected
  call site.
  

• Remove DocId restriction from TopKProvider by Caio 6 years ago
• Move merge_many impl to CollectionResult by Caio 6 years ago
• Use `Ord` instead of `PartialOrd` for the doc id 💬 by Caio 6 years ago

  Technically not required, but being stricter for the doc prevents
  the (very unlikely) case of ending up with non-Ord stuff being used
  as a doc (thinking of NaN) which would break sort stability.
  

• Add `top_fast_field` helper method 💬 by Caio 6 years ago

  This patch adds a method to `TopCollector` to convert it to a
  `CustomScoreTopCollector` sorted by a fast field.
  
  We can drive the whole thing via the basic top collector, which
  leads to something kinda cute:
  
      TopCollector::<i64, Ascending, _>::new(10, condition)
          .top_fast_field(field);
  

• Add support for customizing the scores 💬 by Caio 6 years ago

  Kind of a `tique::top_collector::custom_score` copy pasta with cleaned
  up trait requirements and added support for type-based ordering.
  

• Make CheckCondition<T> aware of the order 💬 by Caio 6 years ago

  This looks totally like a wart and I think I'd prefer a more explicit
  provider-driven checker trait.
  
  I'll try to further encode it in the type, but I think I won't be
  able to make it easy to hold. Essentially, I'd need to move the condition
  trait into the provider, which would force it to be a struct holding
  _something_ (a `PhantomData` marker, likely) which might make it
  difficult to infer the type.
  

• Use `cmp` instead of `partial_cmp` 💬 by Caio 6 years ago

  That was the whole point of implementing Ord for Scored...
  

• Move order-aware functionality into a separate module 💬 by Caio 6 years ago

  This patch moves the `OrderedCollector` (and family) into a new
  module. Since I'll be going through all the code inside the
  `top_collector` mod, I'm taking the opportunity to clean up
  a bit the interfaces.
  
  This has helped me in seeing a weakness in removing specialized
  types from the CollectionResult: I can't simply submit a result
  item as a sort condition for pagination since it's necessary
  to know how to compare them.
  
  I'll follow up trying to add types back in, but now I'm not as
  confident that this is a very polish-able turd :-(