-
Notifications
You must be signed in to change notification settings - Fork 1
Good question. Solr has made full text indexing and faceted search interfaces simple to use and develop. A growing ecosystem has appeared around Solr to integrate into any number of applications, including Drupal and Wordpress and there are plenty of applications that function really as a UI to Solr.
The problem is that a lot of people use fairly cheap shared web hosting (or VPSes) to serve their content and the cost of upgrading to something that allows them to run a Java application server is prohibitive, especially if their scale is small (adding search to their blog or CMS, for example) or their needs modest. Since CheapSkate is Ruby/Rack based app, it’s fairly easy to deploy on most major web hosting packages.
No, not really. If you are looking for Solr, use Solr. If you are looking for something that uses a Lucene-like query syntax, is HTTP-based, provides faceting and plugs into your Solr-backed application, but can’t, for whatever reason, use Solr, CheapSkate might be a reasonable alternative.
No. CheapSkate is being developed for needs that specifically arise (feature X is needed for application Y), so it will most likely only be a subset of functionality that Solr provides. Also, given that CheapSkate is really being reverse-engineered from copying the behavior of a working Solr instance, some naive assumptions may prevail.
Ideally, CheapSkate would have been written in PHP using Zend_Search_Lucene to lower the barrier of entry even more. I am a Ruby developer, however. This started as a proof of concept (since I wasn’t sure if it was even feasible) and I can only invest so much time in this. If anybody is interested in porting CheapSkate to PHP, please do and let me know!
Also the prevalence of mod_rails/Passenger makes this less of an issue.
Yeah… Given that this (as stated above) started out as an experiment, there were no specs initially and when it came time to add them was unclear as to how they would really work. Any guidance would be appreciated.
Pretty well, as long as your faceted result sets stay under around 15,000 hits. Any advice welcome for improving faceting performance over larger results sets.
Unfortunately, no, since they don’t allow writing to the filesystem (see: http://docs.heroku.com/constraints#read-only-filesystem).
Submit a ticket explaining the application and what isn’t working and we’ll try to fix it (within reason).
Any similarities are entirely coincidental.
- JSON
- Ruby
It hasn’t come up.
- SearchHandler/StandardRequestHandler
- Dismax (although see the question associated with this)
- MoreLikeThis
If the standard search results are not meeting your needs, and you’re able to explain the difference between dismax and standard search, we could possibly implement something.
Right now only facets. Highlighting would be fairly trivial (since it’s built into Ferret). SpellCheckComponent would be nice, but I’m not sure how it would work, offhand.