similar to: Undo deletion?

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

I created this analyzer: class DescriptionAnalyzer < Ferret::Analysis::Analyzer def token_stream(field, string) if field == "code" return CodeTokenStream.new(string) else return Ferret::Analysis::Analyzer.new.token_stream(field,string) end end end and created an IndexWriter with it: Ferret::Index::IndexWriter.new(get_index_path,

Some time back in September, [sorry to be so slow], Dave wrote: > When you open an IndexReader on the index it is opened up on > that particular version (or state) of the index. So any > operations on the IndexReader (like searches) will only show > what was in the index at the time you opened it. Any modifications > to the index (usually through and IndexWriter) that occur

require ''rubygems'' require ''ferret'' include Ferret PATH = ''/tmp/ferret_stopwords_test'' index = Index::IndexWriter.new(:path => PATH, :create => true) index.analyzer = Analysis::StandardAnalyzer.new([]) index << {:title => ''a few good men'', :language => ''en''} index.analyzer =

Hey gang, A post on the Rails forum a while back had it sound like you pretty much had to use the Index Readers & Writers if you were going to be potentially accessing an index from more than one process. (i.e. multiple dispatch.fcgi''s, etc) Is this still the case, or does the main Index class do that black magic behind the scenes? =) I was having trouble implementing the

> I should also mention the reason I wouldn''t want > to return the document ID from any IndexWriter method > is that the document ID could become invalid when the > next document is added (if a segment merge is triggered > and deletes exist). At least when using an IndexReader, > the document ID is valid for the life of the reader. Thanks for your detail Dave!

The included test script turned up the following anomolies (run against Ferret 0.10.3, but had same problems with 0.10.2): 1. When the content word is not in the index the inclusion of a wildcard file term causes search_each to throw a segmentation fault. $ ./test.rb zzz file:*.txt query: +content:zzz +file:*.txt ./test.rb:28: [BUG] Segmentation fault ruby 1.8.4 (2005-12-24)

I implemented a "reindex" command which simply creates an IndexWriter with :create => true for a prexisting index. The "reindexing" seems to start out ok, with several thousand docs added, then Ferret throws an exception: IO Error occured: couldn''t rename file "index\_0.tmp" to "index\_0.cfs": <File exists> I guess that _0.cfs is held

Hi, I''m using the StandardAnalyzer to build an index, and passing in Documents that have Fields that contain large tokens (22+ characters) interpersed with normal English words. This seems to cause the IndexWriter to slow to a crawl. Is this a known issue, or am I doing something wrong? If this is a known issue I don''t have any problem just not indexing tokens longer than a

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, I''m using Rails/AAF with Ferret 0.10.11, and my index occasionally (every few weeks, roughly) becomes corrupted. If the index is busted, until I rebuild it our users are unable to save anything. I get errors like the one below, and the save rolls back. My question is, is there any way to catch the error, and continue with the save even if the model isn''t indexed? What

The ferret documentation reports that using the option "key" can affect performance of indexing operations. If the option "key" is used when creating a ferret index, is there a performance hit when creating a new document, or is the performance hit only for updated records? -- Posted via http://www.ruby-forum.com/.

Hi, I keep getting locking errors when updating my index which puzzles me since only one process is supposed to be accessing the index at a time (at least in development mode). I''m using Ferret with Rails (NOT acts_as_ferret, though) and employed an observer to add a new document to the index when a new ActiveRecord is created. I''m not sure if this has any impact on the

If searching multiple indexes with a single searcher is there anyway to identify which index a resulting doc is stored in? i1 = Ferret::I.new i2 = Ferret::I.new i1 << {:id=>1,:text=>"random stuff"} i1.commit reader = Ferret::Index::IndexReader.new([i1.options[:dir],i2.options[:dir]]) searcher = Ferret::Index::IndexSearcher.new(reader) query =

Greetings, I''ve been using ferret with great results now for a while, but in the last week, I''ve been running into some issues. I will occasionally see this message: Exception Message: Lock Error occured at <except.c>:103 in xpop_context Error occured in index.c:5368 - iw_open Couldn''t obtain write lock when opening IndexWriter Which is accompanied by

Anyone ever run into this error message when creating a new FieldInfos? Ferret::Index::FieldInfos.new(:store=>:no) NoMethodError: undefined method `exists?'' for {:store=>:no}:Hash -- Posted via http://www.ruby-forum.com/.

Everything was working fine till last night. This morning I have many errors. I am using acts_as_ferret. Last updated around a month ago on linux. There are two different type of exceptions. I have over 12 exception emails but these are the two distince types. First exception: A EOFError occurred in home#event_info: End-of-File Error occured at <except.c>:79 in xraise Error occured in

Dave, thank you so much for the 0.11 release(s). You have solved many problems for me. As part of my appreciation for your good works, I am offering up for public consideration a silly little class that I wrote. (Code is below.) This class offers a simplified Hash-like interface to (a very restricted subset of) Ferret. Hence I call it FerretHash. FerretHash comes with its very own pet Ferret

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

Hi. While experimenting with the QueryParser to search fields containing only numbers, I discovered that the default Analyzer for IndexWriter differs from QueryParser''s (StandardAnalyzer vs. Analyzer). Is there a reason for this? (Trac ticket is here:) http://ferret.davebalmain.com/trac/ticket/27 seth