Log

• Update and switch Cargo.lock to new format by Caio 5 years ago
• Use `Ord` instead of `PartialOrd` for the doc id 💬 by Caio 5 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.
  

• "Document" the new `tique::conditional_collector` by Caio 5 years ago
• Merge branch 'typed_topk' by Caio 5 years ago
• Drive the search logic via the new `TopCollector` 💬 by Caio 5 years ago

  This patch switches to the new `conditional_collector` module, which
  has built-in support for changing the order. This means that we need
  a lot less business logic for each possible state (sort, order and
  pagination state) and it all can be expressed via `TopCollector`.
  
  So much nicer now :-) With some polish, `tique::conditional_collector`
  is a good candidate for public release.
  

• Sunset top_collector module 💬 by Caio 5 years ago

  The `conditional_collector` module effectively replaces it. It still
  doesn't contain a `TweakedScoreTopCollector`, but that's simply
  because I don't need it anymore since I'm not modifying scores to
  simulate order change.
  

• Add `top_fast_field` helper method 💬 by Caio 5 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 5 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 5 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 5 years ago

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

• Move order-aware functionality into a separate module 💬 by Caio 5 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 5 years ago

  No functional changes
  

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

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

• OrderedCollector: Support Descending ordering 💬 by Caio 5 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 5 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 5 years ago
• Merge branch 'asc_enum' by Caio 5 years ago
• List possible sort values in /info by Caio 5 years ago
• Flatten `ascending` into the sort enum by Caio 5 years ago
• Thoroughly test sort, pagination and ordering 💬 by Caio 5 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 5 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 5 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 5 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 5 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 5 years ago
• Update Cargo.lock by Caio 5 years ago
• Mention `sort` restrictions by Caio 5 years ago
• Use a Result type for SearchCursor::from_bytes by Caio 5 years ago
• Switch to quickcheck 💬 by Caio 5 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 5 years ago