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
-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
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,
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
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
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
: [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
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
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.
] 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
-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
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
? 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
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
14 matches
Mail list logo
