lucene-solr-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Simon Peter Nicholls <si...@mintsource.org>
Subject Re: acts_as_solr
Date Mon, 18 Sep 2006 08:45:17 GMT
Additionally, we should mock out for testing reasons, e.g. in file  
test/mocks/test/acts_as_solr.rb:

require "#{File.dirname(__FILE__)}/../../../vendor/plugins/ 
acts_as_solr/lib/acts_as_solr.rb"

module SolrMixin #:nodoc:

	module Acts #:nodoc:

		module ARSolr #:nodoc:

			module InstanceMethods #:nodoc:

				def solr_save #:nodoc:

				end
				
				def solr_destroy #:nodoc:

				end
				
			end
			
		end#module ARSolr

	end#module Acts

end#module SolrMixin

ClassMethod find_by_solr is the tricky case, but could be handled by  
various means, from specifying mock return collections, through using  
Procs, to using Solr (or even Ferret) as a local test engine if query  
*absolutely* needs testing. Solr interface seems simple enough that  
mocking return values is fine though.

Any thoughts?

Simon

On 17 Sep 2006, at 17:29, Simon Peter Nicholls wrote:

> I had a play around with acts_as_solr today (thanks Yonik for the  
> pointer). Had to fiddle around for a while to set up the  
> schema.xml, (I'm totally new to Solr), but it worked well.
>
> Well, I'm far from RoR savvy (new to Ruby/Rails also), but  
> concerning the commit question, probably using an around_filter to  
> extend the transaction scope would be best. That way, migrations,  
> script/console, & other ways to directly use model will still work  
> using auto-commit. I'll have a stab to keep the ball rolling.
>
> Add filter in from from plugin:
>
> ActionController::Base.around_filter SolrFilter.new
>
> With something like this pseudocode:
>
> class SolrFilter
> 	def before
> 		disable solr commit for request
> 	end
>
> 	def after
> 		solr commit
> 	end
> end
>
> (and check if commit needed within save callback of course)
>
> Anyway, acts_as_solr is looking good, thanks!
>
> Simon
>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>
>> I think Ruby is very fertile ground for Solr to pick up
>> users/developers right now.
>>
>
> I fully agree.  Ferret is coming along very nicely as well, which  
> is wonderful for pure Rubyists that don't need the additional  
> dependency, skill set to manage, and different environment that  
> Solr would require.  But Solr really shines for all its caching and  
> index management, so I'm sure there will be many RoR folks that  
> will embrace Solr.
>
>
>> Getting into some little details, it looks like a commit (which
>> actualy does an optimize) is done on every .save, right?
>>
>
> That's true.  I'm not sure how one would avoid doing a commit for  
> a .save.  There isn't, as far as I know, broader granularity for  
> database operations.  An optimize wouldn't be necessary, but  
> certainly swapping over the searcher would be desired after a save.
>
>
>> I also notice that the commit is asynchronous... so one could do a
>> save, then do an immediate search and not see the changes yet, right?
>>
>
> That is true.  But holding up a save for a new IndexSearcher would  
> be a big hit, at least in my application that currently takes 30+  
> seconds of warming up before a new searcher is ready.
>
>
>> I don't know anything about RoR and ActiveRecord, but hopefully there
>> is some way to avoid a commit on every operation.
>>
>
> It could certainly be made more manual such that a developer would  
> need to code in when a commit happens.  I'm not currently sure what  
> other options there would be for it to be automatic but not done  
> for every .save.  Within a RoR application, one could code in a  
> <commit/> a controller after_filter such that it would occur at the  
> end of an HTTP request by the browser.  Any RoR savvy folks have  
> suggestions on this?
>
> 	Erik


Mime
View raw message