search for: bmsoft

Hi and thanks for Ferret! I''m wondering if it would be possible to create a Ferret Win32 gem which includes the c performance code pre-compiled for those of us without a C compiler handy ? Zed Shaw seems to have cracked this particular nut with his Mongrel Win32 gem. Alternately, is there a zip of the Win32 .so Ferret needs that I could download and manually install? Kind Regards

Hi, The following [simplified] query works well, however a variation which includes parenthesis seems to fail, in that it returns hits which should be excluded by the NOT term. This is surprising because in this simple case, the parenthesis shouldn''t change the Boolean evaluation ... any pointers? Working Query: field1:value1 AND NOT field2:value2 Failing Query: field1:value1 AND

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 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

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 David, > Deleted documents don''t get deleted until commit is called Ok, but FYI, my experiments show that #commit doesn''t affect #doc_count, even across ruby sessions. On a different note, I''d like to request a variation of #add_document which returns the doc_id of the document added, as opposed to self. I''m trying to track down an issue with a large

Hi, I have a largish index [700MB] which is updated from time to time, requiring me to close and recreate the Ferret::Search::Searcher to use the latest index. My problem is that the first few searches on the new index are slow [by comparison to before the close/recreate], I''m guessing because the new index is being loaded into RAM by my OS and into Ferret as needed. I''m

Hi, I think I''ve found a Range Query Term parsing bug ... the following term should return names >= ''A'', but instead generates a parsing error Term: name:[A> Message: Nil bounds for range. A range must include either lower bound or an upper bound However, the slightly larger term, name:[AA> works just fine. Any pointers please? Kind Regards Neville

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, I''m confused about managing field boosting ... I have set the :boost for the :name field in my docs to 10, via :boost => 10 Then I performed a search for ''keith'' over all fields via with *:(keith*), expecting a doc with Keith in the :name field to come out on top. But another doc with Keith mentioned in other fields (:comments, :address) scored higher. I

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

Firstly, thanks Dave for all your hard work. Ferret Rocks!, I am just testing 0.11.4.win32 and it seems to work just fine, however the index creation phase of my app is perhaps 3x slower under 0.11.4 vs 0.10.9 Details follow: System: windows xp sp2, index on local hard disk, Ruby 1.8.6 Run #1, Ferret 0.10.9 - Reboot - Build index, 35,000 rows added in 297 seconds - Run #2, Ferret 0.11.4 -

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

Hi, I seem to be having trouble getting more than 10 hits from Index#search_each since upgrading to 0.10.2 (ie, this was working in 0.9.4). Maybe a bug, as the #search_each doesn''t seem to use the options parameter any more ? Thanks, Neville =========================================== require ''rubygems'' require ''ferret'' p Ferret::VERSION idx =

Hi David, >> Otherwise I''m fully committed to getting 0.10 out. >> When it is out, I''d recommend getting it into your >> development app as soon as you can. Any idea of timeframe to a 0.10 alpha release? Kind Regards Neville

Hey guys, Now that the Lucy[1] project has Apache approval and is about to begin, the onus is no longer on Ferret to strive for Lucene compatability. (We''ll be doing that in Lucy). So I''m starting to think about ways to improve Ferret''s API. The first part that needs to be improved is the Document API. It''s annoying having to type all the attributes to

Hi, I just "solved" an issue which I mentioned on this list many moons ago, regarding searches somehow being serialized, such that a long search would cause others to wait noticeably. Anyhow, after coding both :limit and applying homegrown thread time limit monitoring, I discovered that Searcher#search_each uses rb_thread_critical = Qtrue whereas Searcher#search doesn''t. I

> 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!

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

Hi, I have built a simple Camping application which indexes an ODBC datasource using Ferret on startup, then accepts search strings and renders the resulting hit list in HTML, and it works quite nicely. The next step was to alternately render the list in XML for consumption by another application. In Rails, I would simply use Builder in the view to get the job done, and so I did the same in