lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From robert engels <reng...@ix.netcom.com>
Subject Re: [jira] Commented: (LUCENE-671) Hashtable based Document
Date Thu, 14 Sep 2006 20:13:19 GMT
Doug is not talking about java serialization, he is talking about  
general serialization used to store a Document in an Index.

On Sep 14, 2006, at 3:00 PM, Karl Wettin (JIRA) wrote:

>     [ http://issues.apache.org/jira/browse/LUCENE-671? 
> page=comments#action_12434791 ]
>
> Karl Wettin commented on LUCENE-671:
> ------------------------------------
>
>
> 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.
>
>> Hashtable based Document
>> ------------------------
>>
>>                 Key: LUCENE-671
>>                 URL: http://issues.apache.org/jira/browse/LUCENE-671
>>             Project: Lucene - Java
>>          Issue Type: Improvement
>>          Components: Index, Search
>>    Affects Versions: 2.0.0, 1.9
>>            Reporter: Chris
>>            Priority: Minor
>>         Attachments: HashDocument.java, TestBenchDocuments.java
>>
>>
>> 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.
>
> -- 
> This message is automatically generated by JIRA.
> -
> If you think it was sent incorrectly contact one of the  
> administrators: http://issues.apache.org/jira/secure/ 
> Administrators.jspa
> -
> For more information on JIRA, see: http://www.atlassian.com/ 
> software/jira
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: java-dev-unsubscribe@lucene.apache.org
> For additional commands, e-mail: java-dev-help@lucene.apache.org
>


---------------------------------------------------------------------
To unsubscribe, e-mail: java-dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: java-dev-help@lucene.apache.org


Mime
View raw message