lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Michael McCandless" <luc...@mikemccandless.com>
Subject Re: Payload API
Date Mon, 19 Nov 2007 16:38:00 GMT

"Yonik Seeley" <yonik@apache.org> wrote:
> On Nov 18, 2007 1:19 PM, Michael McCandless <lucene@mikemccandless.com>
> wrote:
> > "Michael Busch" <buschmic@gmail.com> wrote:
> > > Oh and Yonik, I think in addition we'd also need a payloadOffset member?
> >
> > Oh yes, we need offset too.
> 
> I was trying to save another member, and thought that the offset had
> fewer uses than the length.

Ahh good point.

> A related API question is whether we would do a copy into the Token
> (like for termBuffer), or if the byte[] payload would be simply
> referenced (not copied). If it is simply referenced, then we minimally
> need to define when the contents of the byte[] may be changed (i.e.
> can the payload setter re-use the same byte[] and change the contents
> for successive tokens).
> 
> If we opt to treat payload like termBuffer and copy the bytes, then we
> need no offset member.

I think I'd lean towards leaving payload "by reference"?

In general payloads might be fairly long, and, I'm guessing it'll be
quite a bit less common to edit a payload's bytes than it is to edit
the termBuffer's characters?

Leaving it by reference would save one extra copy.

If we do that then I think the contract (which was should spell out in
the javadocs) is that it's safe to change the byte[] when next()
is called again?  Meaning it's the caller's (of next()) job to persist
the byte[] somewhere else, if it needs to.

Mike

---------------------------------------------------------------------
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