lucene-java-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Halácsy Péter <halacsy.pe...@axelero.com>
Subject RE: Objects as search results
Date Thu, 04 Apr 2002 21:46:41 GMT
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>


Mime
View raw message