out of time
mat brown on programming, politics, cooking, and assorted nerdiness
-
Sunspot 0.0.2 released
CommentsFinally, another release of sunspot, my library for awesome interaction with Solr in Ruby. I haven’t had much time to work on it in the past couple of months, so version 0.0.2 isn’t exactly earth-shattering. The good news is that, starting in a couple of weeks, my employers have me slated to spend much of my workday developing Sunspot, with the goal of putting it into production early this spring. So expect more, and bigger, releases soon.
In the meantime, here’s what’s new:
The
sunspot-solrexecutableAs promised in the README for version 0.0.1, I have made running a solr instance for development less of a hassle. Now all you’ve got to do is:
sunspot-solr startHey, nice. The executable takes two arguments: -p (that’s for port) and -d (that’s for data directory). By default, solr runs on port 8983 and saves the index in your
/tmpdirectory. So if you’re doing anything other than playing around or running tests, definitely make sure to specify that -d option. To play nice with daemons, throw a double-dash before the solr options:sunspot-solr start -- -p 8982 -d data/solr/developmentThe executable takes all the usual daemon commands, such as
sunspot-solr stopto stop it andsunspot-solr runto run in the foreground (this is an especially good idea if solr isn’t starting properly and you’d like to figure out why).The executable is intended for use in development/testing scenarios; if you’re running Sunspot in production (which, frankly, I wouldn’t do yet), you should set up your own standalone Solr instance.
Build searches with Builder objects
Version 0.0.1 of sunspot allowed you to put together a search like this:
search = Sunspot.search(Post) do keywords 'great pizza' with.blog_id 1 endOr like this:
search = Sunspot.search(Post, :keywords => 'great_pizza', :conditions => { :blog_id => 1 })So does version 0.0.2; however, in 0.0.2, the second syntax delegates the interpretation of that args hash to a Builder object (in this case, a Sunspot::StandardBuilder). As well as translating the hash into an actual search (internally accessing the same API that the block DSL does), the builder also holds onto the hash itself, allowing access to the search parameters later on in the game:
search.builder.keywords #=> "great pizza" search.builder.params[:keywords] #=> "great pizza" search.builder.conditions.blog_id #=> 1 search.builder.params[:conditions][:blog_id] #=> 1The idea here is that search parameters passed from other layers of the application - particularly from user input - can be dropped directly into the search builder, and then accessed where needed (in Rails, for instance, the object interface of the builder lends itself to FormBuilder integration; the hash interface makes generating URLs easy).
One thing I’m looking forward to doing in a future release is opening up the builder API for developers to create and use their own builders, allowing easy and clean encapsulation of rules for translating user input into search parameters (we actually use this approach at Patch now with an older home-grown Solr API that doesn’t explicitly support it, and it works well). Anyway, expect to hear more about that.
For the next Sunspot release I’ll be tackling faceting, which is currently the most glaring omission from Sunspot’s support for Solr’s featureset. Further down the line will be ORM (etc.) adapters (expect ActiveRecord, DataMapper, and File objects); plug-ins for Merb and Rails; and more of the builder stuff. I’m also looking into possibly switching Sunspot to run on top of a newer, more actively maintained fork of solr-ruby.
Well anyway check it out if you want:
sudo gem install outoftime-sunspot --source http://gems.github.com
