[Missing <summary> documentation for "N:Lucene.Net.Documents"]

Classes

	Class	Description
	AbstractField
	CompressionTools	Simple utility class providing static methods to compress and decompress binary data for stored fields. This class uses java.util.zip.Deflater and Inflater classes to compress and decompress, which is the same format previously used by the now deprecated Field.Store.COMPRESS.
	DateField	Obsolete. Provides support for converting dates to strings and vice-versa. The strings are structured so that lexicographic sorting orders by date, which makes them suitable for use as field values and search terms. Note that this class saves dates with millisecond granularity, which is bad for {@link TermRangeQuery} and {@link PrefixQuery}, as those queries are expanded to a BooleanQuery with a potentially large number of terms when searching. Thus you might want to use {@link DateTools} instead. Note: dates before 1970 cannot be used, and therefore cannot be indexed when using this class. See {@link DateTools} for an alternative without such a limitation. Another approach is {@link NumericUtils}, which provides a sortable binary representation (prefix encoded) of numeric values, which date/time are. For indexing a {@link Date} or {@link Calendar}, just get the unix timestamp as CopyC# long using {@link Date#getTime} or {@link Calendar#getTimeInMillis} and index this as a numeric value with {@link NumericField} and use {@link NumericRangeQuery} to query it.
	DateTools	Provides support for converting dates to strings and vice-versa. The strings are structured so that lexicographic sorting orders them by date, which makes them suitable for use as field values and search terms. This class also helps you to limit the resolution of your dates. Do not save dates with a finer resolution than you really need, as then RangeQuery and PrefixQuery will require more memory and become slower. Compared to {@link DateField} the strings generated by the methods in this class take slightly more space, unless your selected resolution is set to CopyC# Resolution.DAY or lower. Another approach is {@link NumericUtils}, which provides a sortable binary representation (prefix encoded) of numeric values, which date/time are. For indexing a {@link Date} or {@link Calendar}, just get the unix timestamp as CopyC# long using {@link Date#getTime} or {@link Calendar#getTimeInMillis} and index this as a numeric value with {@link NumericField} and use {@link NumericRangeQuery} to query it.
	DateTools..::..Resolution	Specifies the time granularity.
	Document	Documents are the unit of indexing and search. A Document is a set of fields. Each field has a name and a textual value. A field may be {@link Fieldable#IsStored() stored} with the document, in which case it is returned with search hits on the document. Thus each document should typically contain one or more stored fields which uniquely identify it. Note that fields which are not {@link Fieldable#IsStored() stored} are not available in documents retrieved from the index, e.g. with {@link ScoreDoc#doc}, {@link Searcher#Doc(int)} or {@link IndexReader#Document(int)}.
	Field	A field is a section of a Document. Each field has two parts, a name and a value. Values may be free text, provided as a String or as a Reader, or they may be atomic keywords, which are not further processed. Such keywords may be used to represent dates, urls, etc. Fields are optionally stored in the index, so that they may be returned with hits on the document.
	Field..::..Index	Specifies whether and how a field should be indexed.
	Field..::..Store	Specifies whether and how a field should be stored.
	Field..::..TermVector	Specifies whether and how a field should have term vectors.
	FieldSelectorResult	Provides information about what should be done with this Field
	LoadFirstFieldSelector	Load the First field and break. See {@link FieldSelectorResult#LOAD_AND_BREAK}
	MapFieldSelector	A {@link FieldSelector} based on a Map of field names to {@link FieldSelectorResult}s
	NumberTools	Obsolete. Provides support for converting longs to Strings, and back again. The strings are structured so that lexicographic sorting order is preserved. That is, if l1 is less than l2 for any two longs l1 and l2, then NumberTools.longToString(l1) is lexicographically less than NumberTools.longToString(l2). (Similarly for "greater than" and "equals".) This class handles all long values (unlike {@link Lucene.Net.Documents.DateField}).
	NumericField	This class provides a {@link Field} that enables indexing of numeric values for efficient range filtering and sorting. Here's an example usage, adding an int value: document.add(new NumericField(name).setIntValue(value)); For optimal performance, re-use the CopyC# NumericField and {@link Document} instance for more than one document: NumericField field = new NumericField(name); Document document = new Document(); document.add(field); for(all documents) { ... field.setIntValue(value) writer.addDocument(document); ... } The java native types CopyC# int , CopyC# long , CopyC# float and CopyC# double are directly supported. However, any value that can be converted into these native types can also be indexed. For example, date/time values represented by a {@link java.util.Date} can be translated into a long value using the {@link java.util.Date#getTime} method. If you don't need millisecond precision, you can quantize the value, either by dividing the result of {@link java.util.Date#getTime} or using the separate getters (for year, month, etc.) to construct an CopyC# int or CopyC# long value. To perform range querying or filtering against a CopyC# NumericField , use {@link NumericRangeQuery} or {@link NumericRangeFilter}. To sort according to a CopyC# NumericField , use the normal numeric sort types, eg {@link SortField#INT} (note that {@link SortField#AUTO} will not work with these fields). CopyC# NumericField values can also be loaded directly from {@link FieldCache}. By default, a CopyC# NumericField 's value is not stored but is indexed for range filtering and sorting. You can use the {@link #NumericField(String,Field.Store,boolean)} constructor if you need to change these defaults. You may add the same field name as a CopyC# NumericField to the same document more than once. Range querying and filtering will be the logical OR of all values; so a range query will hit all documents that have at least one value in the range. However sort behavior is not defined. If you need to sort, you should separately index a single-valued CopyC# NumericField . A CopyC# NumericField will consume somewhat more disk space in the index than an ordinary single-valued field. However, for a typical index that includes substantial textual content per document, this increase will likely be in the noise. Within Lucene, each numeric value is indexed as a trie structure, where each term is logically assigned to larger and larger pre-defined brackets (which are simply lower-precision representations of the value). The step size between each successive bracket is called the CopyC# precisionStep , measured in bits. Smaller CopyC# precisionStep values result in larger number of brackets, which consumes more disk space in the index but may result in faster range search performance. The default value, 4, was selected for a reasonable tradeoff of disk space consumption versus performance. You can use the expert constructor {@link #NumericField(String,int,Field.Store,boolean)} if you'd like to change the value. Note that you must also specify a congruent value when creating {@link NumericRangeQuery} or {@link NumericRangeFilter}. For low cardinality fields larger precision steps are good. If the cardinality is < 100, it is fair to use {@link Integer#MAX_VALUE}, which produces one term per value. For more information on the internals of numeric trie indexing, including the CopyC# precisionStep configuration, see {@link NumericRangeQuery}. The format of indexed values is described in {@link NumericUtils}. If you only need to sort by numeric value, and never run range querying/filtering, you can index using a CopyC# precisionStep of {@link Integer#MAX_VALUE}. This will minimize disk space consumed. More advanced users can instead use {@link NumericTokenStream} directly, when indexing numbers. This class is a wrapper around this token stream type for easier, more intuitive usage. NOTE: This class is only used during indexing. When retrieving the stored field value from a {@link Document} instance after search, you will get a conventional {@link Fieldable} instance where the numeric values are returned as {@link String}s (according to CopyC# toString(value) of the used data type). NOTE: This API is experimental and might change in incompatible ways in the next release.
	SetBasedFieldSelector	Declare what fields to load normally and what fields to load lazily

Interfaces

	Interface	Description
	Fieldable	Synonymous with {@link Field}. WARNING: This interface may change within minor versions, despite Lucene's backward compatibility requirements. This means new methods may be added from version to version. This change only affects the Fieldable API; other backwards compatibility promises remain intact. For example, Lucene can still read and write indices created within the same major version.
	FieldSelector	Similar to a {@link java.io.FileFilter}, the FieldSelector allows one to make decisions about what Fields get loaded on a {@link Document} by {@link Lucene.Net.Index.IndexReader#Document(int,Lucene.Net.Documents.FieldSelector)}