Mailing List Archive: Objects as search results

Here's a topic which to my recollection (surprisingly) hasn't been brought
up: Assuming development in an object-oriented environment, it's a fair
assumption that the eventual target of searching is an object. How are
developers making this happen?

Are all fields of the objects indexed and displayed accordingly (this means
that the Document essentially takes the place of the object for search
results. bad idea IMHO)? Is there some way for the object to be
instantiated, then populated? How are these objects then displayed as search
results?

Here are some comments I have:

a) Documents shouldn't be used for displaying search results. To do so would
be inflexible and limit the type of data displayed as results to the fields
in a document. This means that if you wish to display more information, more
information has to be added to the document. This somewhat violates the
purpose of the document, I think, which is to provide an abstraction of a
atomic collection of searched/indexed fields. You may be able to get away
with it for simple applications, but I don't think it's a good idea.

Ideally, objects should be used to display the results then, since that's
what a result represents. I use Velocity, so this is easy for me. I retrieve
the objects as a collection (somehow), and stuff them into the Context for
rendering.

b) Different types of objects obviously have different types of metadata.
How can the different fields for each object be displayed, when the types of
objects to be indexed aren't fixed? (I use fields and metadata
interchangeably, so metadata is really a collection of fields of an object)

c) I use Torque, so object instantiation and population is a pretty easy
thing. I have no real solution to others, who don't have some kind of O/R
tool of sorts.

I have addressed these points to my satisfaction in a current app, but they
are terribly reliant on a specific combination (Torque and Velocity). I'm
really interested to know how other developers have approached this.

Regards,
Kelvin Tan

Relevanz Pte Ltd
http://www.relevanz.com

180B Bencoolen St.
The Bencoolen, #04-01
S(189648)

Tel: 6238 6229
Fax: 6337 4417

--
To unsubscribe, e-mail: <mailto:lucene-user-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:lucene-user-help@jakarta.apache.org>

I also faced this problem in my project. I store two classes/types of objects in the index: topics and messages (it's a forum search engine).

My very simple object/relation mapping is a class is called LuceneBridge:
public class LuceneBridge {
// Object --> Document mapping
public Document toDocument(Message m) { .. }
public Document toDocument(Topic t) { .. }

public Hit toHit(Document d, float score) {
if(d.getField("type").stringValue().compareTo("topic")) == 0) {
return new TopicHit(d, score);
} else {
return new MessageHit(d, score);
}
}

As you can see I wrap the hits in a new class called Hit. I can wrap some extra logic in TopicHit and MessageHit class (for example to get back Date, int, long values instead of String).

My goal was to package all indexing logic in one class.

peter

> -----Original Message-----
> From: Kelvin Tan [mailto:kelvin@relevanz.com]
> Sent: Thursday, April 04, 2002 4:13 AM
> To: lucene-user@jakarta.apache.org
> Subject: Objects as search results
>
>
> Here's a topic which to my recollection (surprisingly) hasn't
> been brought
> up: Assuming development in an object-oriented environment,
> it's a fair
> assumption that the eventual target of searching is an object. How are
> developers making this happen?
>
> Are all fields of the objects indexed and displayed
> accordingly (this means
> that the Document essentially takes the place of the object for search
> results. bad idea IMHO)? Is there some way for the object to be
> instantiated, then populated? How are these objects then
> displayed as search
> results?
>
> Here are some comments I have:
>
> a) Documents shouldn't be used for displaying search results.
> To do so would
> be inflexible and limit the type of data displayed as results
> to the fields
> in a document. This means that if you wish to display more
> information, more
> information has to be added to the document. This somewhat
> violates the
> purpose of the document, I think, which is to provide an
> abstraction of a
> atomic collection of searched/indexed fields. You may be able
> to get away
> with it for simple applications, but I don't think it's a good idea.
>
> Ideally, objects should be used to display the results then,
> since that's
> what a result represents. I use Velocity, so this is easy for
> me. I retrieve
> the objects as a collection (somehow), and stuff them into
> the Context for
> rendering.
>
> b) Different types of objects obviously have different types
> of metadata.
> How can the different fields for each object be displayed,
> when the types of
> objects to be indexed aren't fixed? (I use fields and metadata
> interchangeably, so metadata is really a collection of fields
> of an object)
>
> c) I use Torque, so object instantiation and population is a
> pretty easy
> thing. I have no real solution to others, who don't have some
> kind of O/R
> tool of sorts.
>
> I have addressed these points to my satisfaction in a current
> app, but they
> are terribly reliant on a specific combination (Torque and
> Velocity). I'm
> really interested to know how other developers have approached this.
>
> Regards,
> Kelvin Tan
>
> Relevanz Pte Ltd
> http://www.relevanz.com
>
> 180B Bencoolen St.
> The Bencoolen, #04-01
> S(189648)
>
> Tel: 6238 6229
> Fax: 6337 4417
>
>
>
> --
> To unsubscribe, e-mail:
> <mailto:lucene-user-unsubscribe@jakarta.apache.org>
> For additional commands, e-mail:
> <mailto:lucene-user-help@jakarta.apache.org>
>
>

--
To unsubscribe, e-mail: <mailto:lucene-user-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:lucene-user-help@jakarta.apache.org>