Log

• Prepare for 0.2.0 release by Caio 5 years ago
• Regenerate README 💬 by Caio 5 years ago

  `cargo readme > README.markdown`
  

• Document `tique::topterms` by Caio 5 years ago
• Ensure fields are `text` with frequencies by Caio 5 years ago
• Swap `visit(score, doc)` with `visit(doc, score)` 💬 by Caio 5 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.
  

• Initial TopTerms implementation 💬 by Caio 5 years ago

  TopTerms reads the index and extracts the most relevant terms in a
  given document or any arbitrary text input. You can use it to build
  keywords for your documents or, more interestingly, use the result
  as a query to find similar documents.
  
  It's pretty much a reimplementation of Lucene's MoreLikeThis. I don't
  particularly like this approach in prod (too many knobs, dependency on
  the index to formulate a query), but it yields pretty good results
  with little effort.
  
  Ref: https://lucene.apache.org/core/8_4_1/queries/org/apache/lucene/queries/mlt/MoreLikeThis.html
  

• Expose the topk module internally by Caio 5 years ago
• Cleanly report code generation errors by Caio 5 years ago
• Make the README badges clickable by Caio 5 years ago
• Integrate with the new `cantine_derive` traits by Caio 5 years ago
• Update Cargo.lock by Caio 5 years ago
• Move Filterable::Schema::try_from out of TryFrom by Caio 5 years ago
• Use less clash-able names for the generated types by Caio 5 years ago
• Map Filter-related stuff into the Filterable trait 💬 by Caio 5 years ago

  I'm quite unhappy about the `<Type as Filterable>::Query` thinger
  to disambiguate the very unambiguous associated type, but I don't
  think I'll be able to get rid of it.
  

• Rename `Feature*` to `Aggregable*` 💬 by Caio 5 years ago

  I'm still missing something about lifetimes (perhaps just practice?) for
  I can't seem to be able to rephrase all this into something that would
  allow both owned and borrowed types- I mean, without inverting the
  control and making the API terribly annoying to use...
  

• Simplify FeatureCollector type 💬 by Caio 5 years ago

  This patch adds a `Feature` restriction to the `FeatureCollector`
  struct to make things simpler. A smaller turbofish in pubic methods
  is always nice.
  

• Use a simpler Feature trait 💬 by Caio 5 years ago

  Flattening it all solves the "how to expose the generated structs"
  problem and simplifies the code by a *lot*.
  
  Besides, the previous incantation with support for multiple query
  types was cute and all, but useless in practice: a custom query means
  implementing business logic, and the main purpose purpose of this
  thing is avoiding that.
  

• More realistic AggregationQuery integration test by Caio 5 years ago
• Split FilterQuery and AggregationQuery proc macros by Caio 5 years ago
• Stop generating custom collector code 💬 by Caio 5 years ago

  It works! My only gripe is that this new API loses the ability to
  use an embedded database (say, a hashmap) to read the metadata
  since it requires static lifetimes everywhere.
  
  I'm focusing on bytes fast fields, so requiring ownership is fine
  for now. It would be nice to implement `Feature<Query> for &Input`
  and use the same collector code tho, so we'll see...
  

• Make FeatureCollector public by Caio 5 years ago
• Extract FeatureForSegment trait by Caio 5 years ago
• Extract FeatureForDoc trait by Caio 5 years ago
• First stab at a generic feature aggregator 💬 by Caio 5 years ago

  A `Feature<Query, Aggregator>` gives me a very simple way of moving
  the collection logic outwards, so now I can have arbitrary Queries
  and keep reusing the collector code.
  
  It's still unclear to me how to expose the generated query and result
  structs without hard-coding some prefix/suffix to the input name, so
  here's to hope and dreams :beer:
  

• Update running instructions by Caio 5 years ago
• Initialize the logger by Caio 5 years ago
• Update Cargo.lock by Caio 5 years ago
• Read options solely from `std::env` 💬 by Caio 5 years ago

  StructOpt + clap are great and all, but I drive everything with
  environment variables in production already and am more comfortable
  with the language, so spending extra compilation time for the sake
  of a cute CLI interface is not worth it anymore.
  
  My 2013 CPU is thankful. Now my biggest gripe WRT build is that
  `tantivy` pulls `failure` which implies a build dependency on GCC
  for the sake of stacktraces... So xbuild for ARM is a bit annoying.
  

• Remove bin/check 💬 by Caio 5 years ago

  I now trust the moving parts. If things get more complex I'll
  add checksums to the storage instead of ad hoc checking.
  

• Swap homepage and repository values 💬 by Caio 5 years ago

  From looking at the rendered output on crates.io/docs.rs, I think
  that's a better definition for each