Re: acts_as_solr

[Simon Peter Nicholls <si...@mintsource.org>]

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

Re: acts_as_solr

[Simon Peter Nicholls <si...@mintsource.org>]

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