Log

• [maven-release-plugin] prepare release 0.0.2 by Caio 7 years ago
• Bump gula-bom to 0.0.2 by Caio 7 years ago
• [maven-release-plugin] prepare for next development iteration by Caio 7 years ago
• [maven-release-plugin] prepare release 0.0.1 by Caio 7 years ago
• Merge branch 'casserole-split' 💬 by Caio 7 years ago

  Move everything related to Spring Boot to a separate project.
  
  This is a follow-up of the `dropped-multi-module` branch, moving forward
  with the idea of splitting the repositories and having a parent pom
  to control shared dependencies.
  
  Shared build configurations now live at `gula-bom.git`; The Web UI lives
  at `casserole.git`.
  

• Make the Loader not care about cerberus.properties by Caio 7 years ago
• Use a parent pom so I don't repeat myself too much by Caio 7 years ago
• Remove (now) unused test resources by Caio 7 years ago
• Make maven plugin versions explicit by Caio 7 years ago
• Remove leftover resources by Caio 7 years ago
• Configure maven-release-plugin for a git-based release 💬 by Caio 7 years ago

  This, by the way, is the only sane way of using this plugin with git
  in my opinion: I get to keep control of everything, nothing is
  even pushed without my consent.
  

• Package a test jar with a useable Util class by Caio 7 years ago
• Bump dependency versions 💬 by Caio 7 years ago

  Nothing notable in the changelogs.
  

• Cleanup/adapt pom.xml 💬 by Caio 7 years ago

  Drop everything spring-boot, add back what the parent was pulling
  for us automatically.
  

• Remove everything co.caio.cerberus.boot 💬 by Caio 7 years ago

  Moved to casserole.git that will use this project as a dependency.
  

• Merge branch 'multi-field' 💬 by Caio 7 years ago

  Findings from final performance testing:
  
  * We produce a lot less garbage (attributed to the changes to
    renderRecipes() and removal of the SearchResultRecipe abstraction
    mostly): from ~9Gb to ~7Gb in the 5 minute stress test
  
  * Performance degradation is of about 15% after warmup (still
    just using very frequent term, not organic search queries)
  
  I'm not super happy about sacrificing performance, but the ranked
  results are a lot better now and since my tests are on a very
  weak CPU (1.3GHz), I go for it.
  

• Drop support for similarity() queries 💬 by Caio 7 years ago

  This is- like many of the other features I've dropped recently- unused
  since dropping the PWA. I'll revisit this once I'm happy with the
  base ranking and find a decent way to expose this.
  

• Automated code format run by Caio 7 years ago
• Drop FulltextQueryParserTest 💬 by Caio 7 years ago

  These tests are silly and were written mostly to verify my understanding
  of the SimpleQueryParser. I trust it now :-)
  
  If this grows fancier I might revisit testing it, but right now the
  lucene tests are more than enough.
  

• Experiment with multi-field querying 💬 by Caio 7 years ago

  This patch changes how we index/search: instead of having a
  field with name+ingredients+instructions we now store each
  field separately.
  
  This allows the searcher to care about each field differently:
  we say that matching on name or ingredients is very important
  (weight=1), but matching on instructions not so much (weight=0.5).
  
  There's a (poorly measured) performance penalty of about 25% for
  queries - I expect (unverified) this is more pronounced when
  using terms that match many documents (words like: until, salt,
  recipe, chicken, etc) as it means that what once cost N now
  costs 3N (one for each field being looked at) and all that entails
  cache-wise.
  
  One interesting thing (to me :P) is that the index size got
  significantly smaller (~20%) and I expected the size to remain
  somewhat the same. This means that I should (at least) brush up
  on how lucene stores stuff for thinking about this become more
  important as the data size grows.
  
  I like the new ranked results, so I'll probably keep it if further
  tests don't flag anything weird.
  

• Make the final index leaner 💬 by Caio 7 years ago

  Now that we don't fetch metadata from lucene we can drop every
  stored field that isn't the ID. Since we dropped about 2M strings
  from the index (every crawlUrl is unique, every name is tokenized),
  we got a nice reduction in size :-)
  
  444M    tmp/lucene
  607M    tmp/old.1551378107521.lucene
  
  This patch also only stores diet_$name scores if they are non-zero,
  which also helps reducing the index size, but most of these will
  return when I'm done with the classifier. Even if I set an indexing
  threshold (I mean, makes no sense to store a diet_$name score bellow
  any score that I allow querying for)
  

• Remove unused/leftover Recipe.keywords() by Caio 7 years ago
• Remove the SearchResultRecipe abstraction 💬 by Caio 7 years ago

  One more thing that can go away after dropping the PWA \o/
  
  Since we have the concept of a metadata database and a search engine,
  the searcher can always only return a list of ids that matched the
  search.
  

• Disallow browsing after the 30th page 💬 by Caio 7 years ago

  ...I daresay anything after the first few pages is useless unless
  you're a robot.
  

• The default is NOT displaying counts now 💬 by Caio 7 years ago

  This patch removes redundant calls to `.showCounts(false)`
  

• Bugfix: Selected # is wrong when a diet is selected 💬 by Caio 7 years ago

  And, as predicted, this starts to bite me. I'll tread on regardless,
  a less error-prone version is not worth the effort yet.
  

• Update to Tablier 0.2.3 💬 by Caio 7 years ago

  Error pages now look like Index. No more ZeroResults pages.
  
  This patch contains whitespace changes, the `-w` switch should show
  how trivial it actually really is.
  

• Make sure the q= param restrictions work by Caio 7 years ago
• Merge branch 'search-cleanup' by Caio 7 years ago
• Reinstate the query-length minimum requirement 💬 by Caio 7 years ago

  As a proper business logic that doesn't leak into the model this time.