lucene-dev mailing list archives

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

"Yonik Seeley" <> wrote:
> On Nov 18, 2007 1:19 PM, Michael McCandless <>
> wrote:
> > "Michael Busch" <> 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.


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

View raw message