Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Ability to store Reader / InputStream fields [LUCENE-1206] #2283

Open
asfimport opened this issue Mar 6, 2008 · 2 comments
Open

Ability to store Reader / InputStream fields [LUCENE-1206] #2283

asfimport opened this issue Mar 6, 2008 · 2 comments

Comments

@asfimport
Copy link

In some situations we would like to store the whole text, but the whole text won't always fit in memory so we can't create a String. Likewise for storing binary, it would sometimes be better if we didn't have to read into a byte[] up-front (even when it doesn't use much memory, it increases the number of copies made and adds burden to GC.)

FieldsWriter currently writes the length at the start of the chunks though, so I don't know whether it would be possible to seek back and write the length after writing the data.

It would also be useful to use this in conjunction with compression, both for Reader and InputStream types. And when retrieving the field, it should be possible to create a Reader without reading the entire String into memory up-front.


Migrated from LUCENE-1206 by Trejkaz, updated Mar 02 2013

@asfimport
Copy link
Author

Jan Høydahl (@janhoy) (migrated from JIRA)

This issue has been inactive for more than 4 years. Please close if it's no longer relevant/needed, or bring it up to date if you intend to work on it. SPRING_CLEANING_2013

@asfimport
Copy link
Author

Trejkaz (migrated from JIRA)

I think this would still be useful. The workaround of using a separate database to store larger text and binary stuff has never really sat with me terribly well.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

1 participant