lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Grant Ingersoll <>
Subject Re: [jira] Commented: (LUCENE-609) Lazy field loading breaks backward compat
Date Thu, 22 Jun 2006 11:54:37 GMT
It doesn't subclass Field b/c I didn't want to deal with the 
constructors (Field does not have an empty constructor) and everything 
and I didn't think LazyField should be exposed publicly at the API 
level.  It is not something you want people instantiating ever b/c then 
they will try to add them to a Document on indexing and I don't think 
that is appropriate.  To me, all I wanted to make sure of is that the 
thing coming out of FieldsReader contained a valid field (lower case f 
intentional), hence the new interface.

Also, I think if you look back in the archives, there was a lot of 
discussion on how to do this, so that may help inform this discussion 
(search for subject "Lazy Field Loading")

As for getField versus getFieldable, I think getField should be 
deprecated and a note put on it not to use it if you are using the new 
FieldSelector mechanism otherwise a class cast exception will occur.


Chris Hostetter wrote:
> : I was assuming it would be changed so that LazyField extended Field.
> in which case we wouldn't really need a LazyDocument class .. Document
> could be used (and could contain LazyField's directly)
> I don't know why LazyField doesn't subclass Field ... but i assume there's
> a good reason (becuaes it looks like a lot of work went in to extracting a
> bunch of logic into a new abstract super class)
> -Hoss
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:


Grant Ingersoll 
Sr. Software Engineer 
Center for Natural Language Processing 
Syracuse University 
School of Information Studies 
335 Hinds Hall 
Syracuse, NY 13244 
Voice:  315-443-5484 
Fax: 315-443-6886 

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message