David Balmain wrote: >> If that's the case then it's doable to create this type of search, but >> it would make more sense to modify ferret to support this type of query. > > I don't see a way to add this feature cleanly. It is just as easy for > you to do iterate through all the results yourself. Besides, you still > haven't explained why you can't add all Pages to each Book document? > As I said, the field length limit isn't an issue. This would be the > best way to solve this problem.
There is no reason why I couldn't. I was just trying to figure out a way to avoid it. The big drawback to indexing all the pages onto a single field in book would mean I'd have to pick a size of the field up front that could be the maximum. I don't have a lot of data yet, but I tried running some tests. A 94 chapter book it's somewhere around of 100,000. But that's a smaller book. It's just something you have to watch closely which I was trying to avoid is all. Right now your right the best approach is to store it twice. > In my suggested database approach the search would be the equivalent > of a simple SQL join query. By adding a feature like this to > acts_as_ferret you'll need to pull all the matching page ids out of > the index and peform a much slower SQL query for all books that > include those page ids. I'm not sure it is feasible but I'll leave > that decision to the acts_as_ferret developers. The best solution is > definitely to index all the pages with the book document, even if it > means indexing each page twice. I was thinking it would be more like a SQL union. In other words the query didn't have to match the Book document in order to be included. It just had to match the Page object to be included. For example, say I have a book title of Lucene in Action, but you'd expect a query "java" would pull that one back. Java is probably mentioned in the text of that book. I sort of saw it as a multi_index query, since aaf maps the objects that way, where you'd first query Book Documents, then query the Page documents. Instead of adding those Page documents to the resulting array. They would only add a new entry if there was a Book not already there. I suppose I could do that in Ruby, but it just seems like it might be more optimized if ferret understood this type of relationship since it is already iterating over this already. -- Posted via http://www.ruby-forum.com/. _______________________________________________ Ferret-talk mailing list Ferret-talk@rubyforge.org http://rubyforge.org/mailman/listinfo/ferret-talk
