Hashtable based Document

• Key: LUCENE-671
• Type: Improvement
• Status: Resolved
• Resolution: Won't Fix
• Priority: Minor
• Assignee: Unassigned
• Reporter: Chris
• Component/s: Index, Search
• Affects Version/s: 1.9, 2.0.0

Description

I've attached a Document based on a hashtable and a performance test case. It performs better in most cases (all but enumeration by my measurement), but likely uses a larger memory footprint. The Document testcase will fail since it accesses the "fields" variable directly and gets confused when it's not the list it expected it to be.

If nothing else we would be interested in at least being able to extend Document, which is currently declared final. (Anyone know the performance gains on declaring a class final?) Currently we have to maintain a copy of lucene which has methods and classes definalized and overriden.

There are other classes as well that could be declared non-final (Fieldable comes to mind) since it's possible to make changes for project specific situations in those aswell but that's off-topic.

Comments

[Chris]

After some digging: http://www-128.ibm.com/developerworks/java/library/j-jtp1029.html

If these classes are declared final for performance, it might be worth reconsidering. I know of at least one other development group that has to maintain their own lucene tree for the same reason. (Both of us have had to make changes in FieldsWriter to store extra information about the field)

re: (Fieldable comes to mind)
Yup I meant field, and I'll look into Abstract Field, thanks Mike.

[Doug Cutting]

The final declaration is not for performance. It is to keep folks from thinking, if they subclass Document, that instances of their subclass will be returned to them in search results. To make Documents fully-subclassible one would need to make their serialization extensible.

[Karl Wettin]

Cutting:
> To make Documents fully-subclassible one would need to make their serialization extensible.

I find this a bit strange considering RAMDirectory was not made serializable until a few months ago.. But then it might just have been something preemptive. Or perhaps people serialize documents without adding them to the index? That too sounds quite fishy.

I'm all for definalizing Term and Document as this is something required for my issue 550 index.

> It is to keep folks from thinking, if they subclass Document, that instances of their subclass will be returned to them in search results. To make Documents fully-subclassible one would need to make their serialization extensible.

Ahhh, that makes sense to me, and I think providing a method for informing the rest of lucene which versions of various classes to use is probably more trouble than it's worth. We'll just maintain our own tree then.

Thanks