Re: "It seems easier to re-invent a full-text search engine? I'd be way impressed if you could beat Lucene!"
I agree with Erik. I don't have time to read your long email let alone implement a full-text search engine. I can't think of a single client that would rather have me beat my laptop with a rock, then rent a pneumatic hammer and destroy it in several efficient seconds. On a lighter note.... I just learned all about DocBook. And.... More importantly, I've got my wireless signal going all the way to my mobile-mini office. Belkin Pre-N Wireless Router covers my whole 5 acre lot with a strong signal with a lot of bandwidth. My laptop can pick up a signal on the complete 5 acres with its new Pre-N Wireless NIC. Belkin rocks.... Linksys stinks. I just remembered that Cisco is a client of mine... Hmmm.... Linksys is not as good. I am sure it will be better in the next release.... How is that? -----Original Message----- From: Erik Hatcher [mailto:[EMAIL PROTECTED] Sent: Wednesday, December 29, 2004 8:41 PM To: jug-discussion@tucson-jug.org Subject: Re: [jug-discussion] Searching large object graphs On Dec 29, 2004, at 3:12 PM, [EMAIL PROTECTED] wrote: > Not to be Trite... But why not just use bean objects to a backend DB. > Or for > that matter hand write the old incremental sort and sorted search > routines. If it is all in memory then you should be able hand write > an index system capable of running through thousands of records in a > fraction of a second... Just seems easier... It seems easier to re-invent a full-text search engine? I'd be way impressed if you could beat Lucene! Given the example query Tim provided, you'd be able to do this using Lucene in only a handful of lines of code. Erik > On Thu, 23 Dec 2004, Erik Hatcher wrote: > >> Lucene!!!! >> >> The query would be this "name:olson OR email:olson" if you indexed >> that information into separate fields. A common technique is to >> index all data you want queryable also into an aggregate field in >> which case the query could simply be "olson". >> >> The full source code to Lucene in Action is at >> http://www.manning.com/hatcher2 - the ebook is available. The >> physical book is shipping from the printers as we speak (UPS tracking >> says I should have gotten my batch yesterday, but it'll be today it >> seems). >> http://www.lucenebook.com will go live within the week searching >> *inside* the book as well as a blog system I'm setting up. >> >> Erik >> >> On Dec 22, 2004, at 10:27 PM, Tim Colson wrote: >> >>> So just assume for a moment that RAM is cheap and you decided to >>> load 100K objects into memory. Assume those objects were >>> "Employees"... you can imagine the fields would be the usual >>> suspects. Assume each employee is associated with a profile that is >>> another object, which is composed of a bunch of other data objects. >>> >>> What would you use to find/select objects like "Name or email foo >>> matches >>> *olson* " ? >>> >>> Some possibilities: >>> http://jakarta.apache.org/commons/jxpath/ >>> >>> Some of the stuff inside Commons: >>> http://jakarta.apache.org/commons/collections/ >>> >>> Lucene indexes >>> http://jakarta.apache.org/lucene/docs/ >>> >>> >>> Others? >>> >>> Tim >>> >>> -------------------------------------------------------------------- >>> - To unsubscribe, e-mail: [EMAIL PROTECTED] >>> For additional commands, e-mail: [EMAIL PROTECTED] >> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: [EMAIL PROTECTED] >> For additional commands, e-mail: [EMAIL PROTECTED] >> >> > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
