search for: ramdirectori

Hi all, I''ve recently started working with Ferret and I''m getting what seems to be slow searches. I have about 10000 documents in the index, with several fields per document, with some fields having an array of several values that are indexed. I am using a RAMDirectory to store the index for searching. When doing testing, I find that searches are reasonable at around .2 to

Hi There, Is anyone using RAMDirectory as the data store with acts_as_ferret? I would love some pointers on how to configure acts_as_ferret to correctly use RAMDirectory (rather than FSDirectory). Thanks in advance. AC -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/ferret-talk/attachments/20060926/bd1230c5/attachment-0001.html

Hi All, Hope all is going well. I''m having trouble with the following code creating an in memory index reader - it seems to be attempting to read from a file regardless. Here''s the simple code: require ''rubygems'' require ''ferret'' a = Ferret::Index::Index.new r = Ferret::Index::IndexReader.new(nil) Running the code on my OS X machine

I need to reset the ferret index between test runs. It seems like there are a few ways to reset the ferret index. * Deleting the index directory -- is this really bad form? * calling rebuild_index * (any others?) What would y''all recommend? (Sorry, I''m from Texas) Preferably, I''d like a way to reset the index that I can integrate into a selenium test. -David

Hi, I seem to be having trouble updating a doc, ie, deleting then re-adding to the index. The following script demonstrates my issue - I''m sure I''m missing something obvious, but I can''t seem to find the problem. Can someone point out where I am going wrong please ? Regards Neville === require ''rubygems'' require ''ferret'' p

I was having some odd results when working with acts_as_ferret (current trunk), so I decided to test with the current version of ferret to see if I encountered the same problem. I did. Here are the details: installed ferret 0.10.10 on debian sarge with ''sudo gem install ferret'' (btw, same results on OSX) opened up an irb session: irb(main):001:0> require

I''m playing with "updating" docs in my index, and I think I''ve found bug with IndexWriter counting deleted docs. Script and output follow: ===== require ''rubygems'' require ''ferret'' p Ferret::VERSION @doc = {:id => ''44'', :name => ''fred'', :email => ''abc at

Hi new version of ferret and acts as ferret have sorted out the scary glibc *** linked list pointer errors, thank god! New version are good but some searches are still not working. It is mostly the stop words ones. For example the "For Sale/Free/Swap" fails but works when "for" is stripped out. I have read all the recent posts regarding this issue and failed to get it to

Just curious, is there anyway to use memcache with a ferret index? Thanks, Ray -- Posted via http://www.ruby-forum.com/.

Hey all, I''ve just released Ferret version 0.10.2. It is mostly just a bug fix release. The only change is that a highlight method has been added to Ferret::Index::Index. Please try it out and let me know what you think. The big news for this release is that there is also a binary win32 gem included. This is the first time I''ve build a gem like this so please let me know if

Is there a way to tell Ferret (or AAF) to read an entire index into memory, for faster searching? I have small index (3-4 MB) that could be kept in memory. Or does Ferret do that automatically? Thanks, --Paul -- Posted via http://www.ruby-forum.com/.

Hi, I just noticed that Ferret seems to convert every field to a string [ruby code appended for those interested], which has thwarted my attempt to format Dates (to "dd/mm/yyyy") and Floats (to "n.nn") for consumption further down the line based on the class of the field stored. I considered pre-formatting Dates and Floats prior to indexing, which would store the field

Hi, I''m building a web server application using Ferret [thanks so much Dave], Mongrel and Camping which works fine servicing one request at a time, but serialises searches if more than one request arrives, so I''d like some advice please about the best way to use multiple readers and one writer. Some background ... query requests which in my case are always read only, arrive via