Log

• Make CheckCondition<T> aware of the order 💬 by Caio 4 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 4 years ago

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

• Move order-aware functionality into a separate module 💬 by Caio 4 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 :-(
  

• Remove `Scored` knowledge from `CollectionResult` 💬 by Caio 4 years ago

  No functional changes
  

• Add tests for the specialized topks 💬 by Caio 4 years ago

  It feels like I may now be able drop `Scored` from the API
  

• OrderedCollector: Support Descending ordering 💬 by Caio 4 years ago

  There we go, a fully working conditional top collector. Now it's a
  matter of outlining the {Custom,Tweaked}Collector code and we're
  gold.
  

• Start working on a order-aware typed collector 💬 by Caio 4 years ago

  Having to do the `Reverse` dance only to flip the scores again when
  collecting in ascending order was bothering me more than it probably
  should. This patch starts sketching what ultimately become something
  like this:
  
      OrderedCollector::<Score, topk::Descending, _>::with_limit(10, true);
  
  Meaning: you control the order via the type instead of creating a
  custom scorer/tweaker that flips the score before collecting. Whilst
  the motivation for this is purely cosmetic, it sounds like it should
  be faster for very hot loops (far from my use-case of ~1M docs)
  
  This is the 3rd time I'm attempting this and looks like I'll finally
  be able to pull it off :tada:
  

• Add a more detail to the walkthrough by Caio 4 years ago
• Merge branch 'asc_enum' by Caio 4 years ago
• List possible sort values in /info by Caio 4 years ago
• Flatten `ascending` into the sort enum by Caio 4 years ago
• Thoroughly test sort, pagination and ordering 💬 by Caio 4 years ago

  The manual wiring that is required to map search parameters to
  the proper collectors makes me very uneasy, so to combat it
  this patch stress tests a lot: for every sort and every order,
  it paginates the result-set ensuring that the ordering is
  correct.
  

• Use `Option<After>` instead of having `After::Start` 💬 by Caio 4 years ago

  The main motivation of this is dropping the very awkward `is_start` /
  `INVALID_RECIPE_ID` thingers. The result is some convoluted code that
  I'm having a really hard time expressing as traits.
  
  I think my problem is that in order to decide which collector to use
  we need to look at 3 things: Sort, After and Order. It looks like if
  I flatten order into the sort enum (so, doubling the sort enum size),
  things will at least read more easily, so I'll try that soon.
  

• Leverage `AsPaginator` to drop `topk_fast_field` 💬 by Caio 4 years ago

  With the new AsPaginator trait the `topk_fast_field` method is actually
  quite simple, so this patch simply inlines it on the `search` method
  

• Extract `topk_fast_field<T>` from `topk_T` methods 💬 by Caio 4 years ago

  A couple less (cosmetic) macros now. The After type might need
  some more involved changes to get rid of the rest.
  

• Extract rendering logic to a method 💬 by Caio 4 years ago

  I might be able to do the same for `Paginator`, which should finally
  allow me to get rid of most of the macros I'm using to avoid talking
  to the type system.
  

• Use `iter` instead of `into_iter` [clippy] by Caio 4 years ago
• Update Cargo.lock by Caio 4 years ago
• Mention `sort` restrictions by Caio 4 years ago
• Use a Result type for SearchCursor::from_bytes by Caio 4 years ago
• Switch to quickcheck 💬 by Caio 4 years ago

  I expected to have my property tests to start failing on
  3049519e6, left a `todo!()` note for it but the failure never
  happened and it sneaked past me until now.
  
  The culprit was a bad test: `no_crash_with_properly_sized_junk`
  relies on the framework providing a properly sized input and the
  decoder (correctly) discards things with wrong size - when the
  payload length changed to 34 I expected this to crash, but
  naturally it didn't.
  
  A proper fix would have been to adjust `uniform32` to `uniform34`
  and assert the length against a constant, but `proptest` doesn't
  ship with support for larger arrays and I'm not keen on copy
  pasting a bunch of code just for creating my own strategy.
  
  Instead, I switch to `quickcheck` that I'm already familiar with
  and allows for quick input discard in my case.
  
  Now the test actually fails :-)
  

• Add a simple API walk-through by Caio 4 years ago
• Strict derived Query types deserialization by Caio 4 years ago
• Add a more information about tique::top_collector by Caio 4 years ago
• Add support for ascending relevance ordering by Caio 4 years ago
• Add support for modifying the original score 💬 by Caio 4 years ago

  This is pretty much a copy pasta from custom_score.rs, the difference
  is that instead of using `Fn(DocId) -> T` it uses `Fn(DocId,Score) -> T`
  
  Essentially the same as tantivy's, with the added support for conditions.
  

• Add types back to cursors 💬 by Caio 4 years ago

  This patch starts adding the type information to the cursors. This
  information is"lost" by containing everything as (u64,u64), so we
  add it back by making cursor types enums.
  
  The price I'm paying is an added byte for the type tag (mapping to
  an enum member) which leads to 2 extra characters in the base64
  SearchCursor representation.
  

• Reorganize top_collector::fastfield by Caio 4 years ago
• Update README by Caio 4 years ago
• Add (partial) support for ascending sort 💬 by Caio 4 years ago

  Now this works for everything fast-field. A new collector will be
  needed for reversing `Sort::Relevance`