Flying Sphinx client for Node.js

npm install flying-sphinx
5 downloads in the last week
22 downloads in the last month
h1. Flying Sphinx Client for Node.js

! Status)!:

This is a Node.js client for "": (initially just as a Heroku add-on, but support for other platforms will be added in the future). Consider it a beta at the moment: the functionality's there, though you may need to read the source a little.

Please note that this is not a client for Sphinx itself. Check out "sphinxapi": or "limestone": for talking to Sphinx itself.

h2. Installation

The @flying-sphinx@ package is available via npm:

<pre><code>npm install flying-sphinx</code></pre>

h2. Usage

If you're not familiar with Sphinx, then this isn't the place to start... but once you understand how Sphinx works, there's a few key areas to interact with Flying Sphinx: configuration of Sphinx, processing the indices, and starting up and stopping the daemon.

Authentication credentials are sourced from the environment (FLYING_SPHINX_IDENTIFIER and FLYING_SPHINX_API_KEY) - and these are automatically available through Heroku. If for some reason you wish to run commands locally, then you'll need to make sure those two settings are in place.

h3. Configuration

To get your Sphinx configuration file loaded, you'll need send the file through to Flying Sphinx. This can be done from the command line via Heroku:

<pre><code>$ heroku run flying-sphinx configure /path/to/sphinx.conf</code></pre>

If you have additional configuration files (such as wordforms, stopwords or exceptions), or want to generate your configuration file dynamically, then you can use the following commands through Javascript:

<pre><code>var flyingSphinx = require('flyingSphinx');
var configuration = flyingSphinx.configuration();

configuration.upload('raw configuration');

configuration.uploadSettings('wordforms', 'wordforms.txt', 'file contents');
configuration.uploadSettingsFromFile('wordforms', '/path/to/wordforms.txt');</code></pre>

Make sure any settings file names match what you've set in your configuration file, but don't stress about paths - Flying Sphinx will set them up for you. Settings files must be unique per setting - if you refer to @a.txt@ for wordforms in more than one place, it'll be a single file, not scoped to index.

h3. Processing Indices

Now that Flying Sphinx is aware of your Sphinx configuration, you'll want to get Sphinx processing your data. This can be done over the command line as well:

<pre><code>$ heroku run flying-sphinx index</code></pre>

If you want to process specific indices, just specify them as arguments:

<pre><code>$ heroku run flying-sphinx index article user</code></pre>

This can also be done through code if necessary:

<pre><code>var flyingSphinx = require('flyingSphinx');

@run@ can take two arguments, the first being an array of index names, the second being a callback function to run with the resulting log. They're both optional, but if you just want a callback, specify an empty array for the first argument.

h3. Controlling the Daemon

Again, easy via either the command line or through code:

<pre><code>$ heroku run flying-sphinx start
$ heroku run flying-sphinx stop</code></pre>

<pre><code>var flyingSphinx = require('flyingSphinx');

Both of the javascript methods are asynchronous and can take an optional callback function as an argument.

h3. Convenience Commands

Via the command line, you can also use the @restart@ command (to stop and then start the Sphinx daemon) and the @rebuild@ command (to stop the daemon, process indices, then start the daemon back up).

<pre><code>$ heroku run flying-sphinx restart
$ heroku run flying-sphinx rebuild</code></pre>

h2. Compatibility and Limitations

This library has been built and tested against Node 0.8, but I will happily accept patches for other versions of Node if necessary.

h2. Contributing

Patches are indeed welcome (especially given Node.js is not a framework I'm familiar with at the moment). API documentation will be provided at some point in the future, but generally keep in mind the following:

* The environment is managed via npm.
* Please use the test frameworks as shown by the existing tests - and do write tests.
* Keep your commits in a separate branch.
* Don't mess around with the version number in your branch - this keeps merges easier for me to manage.

h2. Licence

Copyright &copy; 2012 Pat Allan, released under an MIT licence.
npm loves you