Re: [jug-discussion] Searching large object graphs
Richard Hightower wrote: I agree. But what best are you talking about. The best technical solution or the best business solution. The best business solution is not always the best technical solution. (Mounting high horse...) Engineering is about tradeoffs: budget, time, beer... Actually I just threw beer in there for fun. I will continue to focus on good enough technical solution to fit the customers need. Actually, I will continue to play with technology that I am interested in and telling the customer it is the best business solution (just kidding). I will bile all technology I don't understand (if I don't understand it... How can it be good?) Sorry I was channeling the bile blog :) I interpret best to mean the most comprehensive, extensible solution possible. Good is therefore something that works reasonably well for the purpose to which you are putting it. Simple as possible but no simpler. - Drew -- +-+ Drew Davidson | OGNL Technology +-+ | Email: [EMAIL PROTECTED] / |Web: http://www.ognl.org / |Vox: (520) 531-1966 |Fax: (520) 531-1965\ | Mobile: (520) 405-2967 \ +-+ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [jug-discussion] Searching large object graphs
Rick and Drew have it right, a long time ago in a galaxy far away, I attended the Xerox Professional selling course and the one thing important I learned was that people make the buying decision on three things, (1) the first solution they find for a problem, (2) the lowest percieved risk solution to their problem or (3) the best solution to their problem and in that order. The higher the cost the higher the percieved risk, the newer the higher the percieved risk, etc. If you pull a lot of doors and have low prices you win a lot of business and best doesn't matter. Ollie -Original Message- From: Richard Hightower [EMAIL PROTECTED] Date: Wed, 29 Dec 2004 20:48:50 To:jug-discussion@tucson-jug.org Subject: RE: [jug-discussion] Searching large object graphs I agree. But what best are you talking about. The best technical solution or the best business solution. The best business solution is not always the best technical solution. (Mounting high horse...) Engineering is about tradeoffs: budget, time, beer... Actually I just threw beer in there for fun. I will continue to focus on good enough technical solution to fit the customers need. Actually, I will continue to play with technology that I am interested in and telling the customer it is the best business solution (just kidding). I will bile all technology I don't understand (if I don't understand it... How can it be good?) Sorry I was channeling the bile blog :) BTW Did I mention that OGNL Rocks?! DREW ROCKS! I got to get back to work! Later. On a lighter note my wireless keyboard and mouse went south I got the new Microsoft one with all of the bells and whistles. It works, and my keyboard has 25 extra keys Oh well... It won't make me type faster or procrastinate any less. -Original Message- From: Drew Davidson [mailto:[EMAIL PROTECTED] Sent: Wednesday, December 29, 2004 10:23 PM To: jug-discussion@tucson-jug.org Subject: Re: [jug-discussion] Searching large object graphs Richard Hightower wrote: 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. The best is the enemy of the good. Words to live by in contracting. 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. On a related note, Rick is now in the process of growing a second head because of the increased signal strength. - Drew -- +-+ Drew Davidson | OGNL Technology +-+ | Email: [EMAIL PROTECTED] / |Web: http://www.ognl.org / |Vox: (520) 531-1966 |Fax: (520) 531-1965\ | Mobile: (520) 405-2967 \ +-+ - 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] Mike Oliver CTO, Alarius Systems LLC Las Vegas, Nevada USA Sent using my BlackBerry 6510 from Nextel
Re: [jug-discussion] Searching large object graphs
On Dec 30, 2004, at 11:58 AM, [EMAIL PROTECTED] wrote: O... Ok, that seems like fun (I know I am sick, but truth is I have time to kill at home for next week and a half) But we should also have different kinds of common data, like a few hundred complete personal records, a few books/blogs, etc. We could also see a difference between memory resident ODB structure and RDB structure. For implementation time we should also try one technology we are familiar with and one we are not; as implementation time is inversely proportional to prior knowledge of the method used to implement. Perhaps I can get more practice at Lucene. You're getting pretty carried away here! I am after simplicity - meeting what Tim's original question was about, nothing more. From what you just said, and what you say later, it sounds like you're expanding the requirements dramatically. I'm in if Tim wants to write a few unit tests that candidate implementations should turn green. Also, am I the only one who has to deal with the Trak Everything Objects? I ask because a few hundred tuples in a record is not uncommon. It is also not uncommon to have them related to a few dozen other entities each of which may have 25-50 tuples. And the users come up with wacky searches like I want to know every person who has ever been on a south phoenix construction project with Tim after he became a lead. I know there are some scary smart people on this list (I am not necessarily on of them) and I would love to see some good code. This vastly changes the landscape. This sounds like the job for an RDF engine (Kowari is the one I hear the most about). I'm not interested in building a mega catch-all kinda in-memory object store. Tim had one concrete example, and I said Lucene looked perfect for it. Lucene is awesome, but its not the end solution for every conceivable scenario. If Tim's use cases are along the lines of the example he provided then I'm up for making whatever unit tests he comes up with pass with a Lucene implementation under the covers. Erik - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [jug-discussion] Searching large object graphs
I must also agree. I will create another example, let us say you need to get from point A to point B a mile away. Is it better to walk or drive. Well drive of course. But if you do not have a car, or know how to drive, and can not wait for a cab then your stuck walking. It takes ME less time to build a good enough solution then it doze to learn how to build a best solution. Particularly if the issue is complex and must be understood by many people who will need to modify and maintain the code latter. That and I have this really obnoxious drive to keep my code as pure J2EE as possible. But by the same token I will use some black box stuff to save time (Reisn), but I hate to do it. From a business side if I give a presentation that says I can give you a search engine that will return a very good result in 45 seconds for $500.00 or I can give you something that will return all results in two seconds and display them in a categorized fashion for $5000.00, they will usually choose the first solution. So I am not saying other technologies are bad I am just saying I prefer to hand code searches for the large OODB I deal with. And there is no way I could beat Lucene, I just could implement something faster by hand then to lean and implement Lucene. Now if I had to do a fresh implementation more often, or had need for its power, then I would make the investment. However, for the occasional search though a few, large, memory resident objects I could do it with an acceptable speed variance. Also Richard said he did not have time to read my email, so I find it odd that he would have time to learn a whole new tech? Their by going back to my J2EE code by hand thing being easier Shrug, perhaps I absorb O'Reily significantly slower then he. But then again I like hand coding J2EE and I wish I could learn more about really hard core system stuff like what else can I do with the robot, or how can I get system idle times, or capture a desktop, etc. But so far all I have found are J-C++ black box hacks that are seriously system dependent and I do not care to mess with that (Again not say Lucene or any other for mention tech is that way, just to show where I am coming from and that I like hand coding). And since I some how feel this is becoming a flame (could just bee the cold fogy morning that makes me feel that way) I will back off, as my suggestion does not seem to have been taken as some words from the devil. Again, could just be the weather, are I could just be miss reading SO I apologize, If I misunderstood the original question and passed a solution that you all think is really off the wall. Which is why I offered a really short Hey, I think I have this wrong, so here is the short version of what I feel answer. Well back to work :) Accounting not programming :) I shall keep my novice opinons top my self for a while :) On Thu, 30 Dec 2004, Drew Davidson wrote: Richard Hightower wrote: I agree. But what best are you talking about. The best technical solution or the best business solution. The best business solution is not always the best technical solution. (Mounting high horse...) Engineering is about tradeoffs: budget, time, beer... Actually I just threw beer in there for fun. I will continue to focus on good enough technical solution to fit the customers need. Actually, I will continue to play with technology that I am interested in and telling the customer it is the best business solution (just kidding). I will bile all technology I don't understand (if I don't understand it... How can it be good?) Sorry I was channeling the bile blog :) I interpret best to mean the most comprehensive, extensible solution possible. Good is therefore something that works reasonably well for the purpose to which you are putting it. Simple as possible but no simpler. - Drew -- +-+ Drew Davidson | OGNL Technology +-+ | Email: [EMAIL PROTECTED] / |Web: http://www.ognl.org / |Vox: (520) 531-1966 |Fax: (520) 531-1965\ | Mobile: (520) 405-2967 \ +-+ - 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]
Re: [jug-discussion] Searching large object graphs
Ahh, looking back on it I did read it as a more general problem (their I go again reading way to much into things) Yes, I will agree your suggestion is very good one On Thu, 30 Dec 2004, Erik Hatcher wrote: On Dec 30, 2004, at 11:58 AM, [EMAIL PROTECTED] wrote: O... Ok, that seems like fun (I know I am sick, but truth is I have time to kill at home for next week and a half) But we should also have different kinds of common data, like a few hundred complete personal records, a few books/blogs, etc. We could also see a difference between memory resident ODB structure and RDB structure. For implementation time we should also try one technology we are familiar with and one we are not; as implementation time is inversely proportional to prior knowledge of the method used to implement. Perhaps I can get more practice at Lucene. You're getting pretty carried away here! I am after simplicity - meeting what Tim's original question was about, nothing more. From what you just said, and what you say later, it sounds like you're expanding the requirements dramatically. I'm in if Tim wants to write a few unit tests that candidate implementations should turn green. Also, am I the only one who has to deal with the Trak Everything Objects? I ask because a few hundred tuples in a record is not uncommon. It is also not uncommon to have them related to a few dozen other entities each of which may have 25-50 tuples. And the users come up with wacky searches like I want to know every person who has ever been on a south phoenix construction project with Tim after he became a lead. I know there are some scary smart people on this list (I am not necessarily on of them) and I would love to see some good code. This vastly changes the landscape. This sounds like the job for an RDF engine (Kowari is the one I hear the most about). I'm not interested in building a mega catch-all kinda in-memory object store. Tim had one concrete example, and I said Lucene looked perfect for it. Lucene is awesome, but its not the end solution for every conceivable scenario. If Tim's use cases are along the lines of the example he provided then I'm up for making whatever unit tests he comes up with pass with a Lucene implementation under the covers. Erik - 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]
RE: [jug-discussion] Searching large object graphs
Oh my, I must have heard differently, I knew you were challenged and it had something to do with small, but I was way off base...;-) Michael Oliver CTO Alarius Systems LLC 3325 N. Nellis Blvd, #1 Las Vegas, NV 89115 Phone:(702)643-7425 Fax:(520)844-1036 *Note new email changed from [EMAIL PROTECTED] -Original Message- From: Tim Colson [mailto:[EMAIL PROTECTED] Sent: Wednesday, December 29, 2004 1:15 PM To: jug-discussion@tucson-jug.org Subject: RE: [jug-discussion] Searching large object graphs But why not just use bean objects to a backend DB. Well, howabout because I explicitly posed the question as just assume for a moment that RAM is cheap and you decided to load 100K objects into memory instead of I have a lot of data...what kind of thingy should I store it in... oh, and please reply with small words because I am developmentally challenged. Maybe that's why. ;-) that matter hand write the old incremental sort and sorted search routines. Apparently I wasn't clear -- I want to search using multiple criteria with wildcards/booleans on multiple fields, and on data in contained objects. Mostly I'd rather not waste time re-inventing wheels, and [usually] the folks on the list provide interesting food for thought. I won't bother with the flame-bait about overly complex and airguns. Cheers, Tim 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]
RE: [jug-discussion] Searching large object graphs
Beware of any email that begin with the words Not to be Trite You can feel a big wall of Trite flame coming around the corner. :) -Original Message- From: Tim Colson [mailto:[EMAIL PROTECTED] Sent: Wednesday, December 29, 2004 4:15 PM To: jug-discussion@tucson-jug.org Subject: RE: [jug-discussion] Searching large object graphs But why not just use bean objects to a backend DB. Well, howabout because I explicitly posed the question as just assume for a moment that RAM is cheap and you decided to load 100K objects into memory instead of I have a lot of data...what kind of thingy should I store it in... oh, and please reply with small words because I am developmentally challenged. Maybe that's why. ;-) that matter hand write the old incremental sort and sorted search routines. Apparently I wasn't clear -- I want to search using multiple criteria with wildcards/booleans on multiple fields, and on data in contained objects. Mostly I'd rather not waste time re-inventing wheels, and [usually] the folks on the list provide interesting food for thought. I won't bother with the flame-bait about overly complex and airguns. Cheers, Tim 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]
RE: [jug-discussion] Searching large object graphs
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]
Re: [jug-discussion] Searching large object graphs
Richard Hightower wrote: 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. The best is the enemy of the good. Words to live by in contracting. 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. On a related note, Rick is now in the process of growing a second head because of the increased signal strength. - Drew -- +-+ Drew Davidson | OGNL Technology +-+ | Email: [EMAIL PROTECTED] / |Web: http://www.ognl.org / |Vox: (520) 531-1966 |Fax: (520) 531-1965\ | Mobile: (520) 405-2967 \ +-+ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [jug-discussion] Searching large object graphs
I agree. But what best are you talking about. The best technical solution or the best business solution. The best business solution is not always the best technical solution. (Mounting high horse...) Engineering is about tradeoffs: budget, time, beer... Actually I just threw beer in there for fun. I will continue to focus on good enough technical solution to fit the customers need. Actually, I will continue to play with technology that I am interested in and telling the customer it is the best business solution (just kidding). I will bile all technology I don't understand (if I don't understand it... How can it be good?) Sorry I was channeling the bile blog :) BTW Did I mention that OGNL Rocks?! DREW ROCKS! I got to get back to work! Later. On a lighter note my wireless keyboard and mouse went south I got the new Microsoft one with all of the bells and whistles. It works, and my keyboard has 25 extra keys Oh well... It won't make me type faster or procrastinate any less. -Original Message- From: Drew Davidson [mailto:[EMAIL PROTECTED] Sent: Wednesday, December 29, 2004 10:23 PM To: jug-discussion@tucson-jug.org Subject: Re: [jug-discussion] Searching large object graphs Richard Hightower wrote: 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. The best is the enemy of the good. Words to live by in contracting. 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. On a related note, Rick is now in the process of growing a second head because of the increased signal strength. - Drew -- +-+ Drew Davidson | OGNL Technology +-+ | Email: [EMAIL PROTECTED] / |Web: http://www.ognl.org / |Vox: (520) 531-1966 |Fax: (520) 531-1965\ | Mobile: (520) 405-2967 \ +-+ - 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]
RE: [jug-discussion] Searching large object graphs
The best is the enemy of the good. U... E I just realized that you were agreeing with me. Scratch almost everything I said DOH! I am lezdexic. -Original Message- From: Drew Davidson [mailto:[EMAIL PROTECTED] Sent: Wednesday, December 29, 2004 10:23 PM To: jug-discussion@tucson-jug.org Subject: Re: [jug-discussion] Searching large object graphs Richard Hightower wrote: 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. The best is the enemy of the good. Words to live by in contracting. 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. On a related note, Rick is now in the process of growing a second head because of the increased signal strength. - Drew -- +-+ Drew Davidson | OGNL Technology +-+ | Email: [EMAIL PROTECTED] / |Web: http://www.ognl.org / |Vox: (520) 531-1966 |Fax: (520) 531-1965\ | Mobile: (520) 405-2967 \ +-+ - 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]
Re: [jug-discussion] Searching large object graphs
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]
[jug-discussion] JavaOne CALL FOR PAPERS, was RE: [jug-discussion] Searching large object graphs
Hey Erik et al. I am glad to hear your Lucene in Action book is going to the printers. I will order a copy ASAP. BTW JavaOne 2005 is doing a call for papers. I was thinking about signing up. You should think about it too. (The year I got accepted, I submitted 5 presentations, and they choose one b/c someone called in sick. The called me last minute. I spoke on XDoclet making EJB CMP/CMR easier. Shudder... Brrr...) I plan on being in town (Tucson) for the next six weeks or so (plans subject to change). I am writing some articles for IBM and starting a book for O'Rielly for my down time (Drew and I are working on it together). Sorry I missed you in VA. I wanted to get together the last week, but my schedule got crazy. When are you coming to Tucson? I better get to work. There is no persecution like staring at a blank page. BTW are there any Eclipse plugin/SWT experts in Tucson? that would not mind traveling a bit to LA -Original Message- From: Erik Hatcher [mailto:[EMAIL PROTECTED] Sent: Thursday, December 23, 2004 3:05 AM To: jug-discussion@tucson-jug.org Subject: Re: [jug-discussion] Searching large object graphs 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]
[jug-discussion] Searching large object graphs
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]
Re: [jug-discussion] Searching large object graphs
OGNL Nick --- Tim Colson [EMAIL PROTECTED] 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]
