Field Type Definitions

string

The string field is implemented with Solr's StrField class, indexing each input as one exact, unanalyzed token. No tokenizer or filters are applied, so the entire value - including every character, case and punctuation mark - is preserved verbatim in the index. This makes string ideal for fields where only an exact-match query should succeed, such as unique identifiers, fixed codes or status flags. Because no analysis takes place, sorting and faceting on string fields are extremely fast and unambiguous.

Examples:

• Order ID: ORD-987654
• Serial Number: SN-00012345
• Product Code: PROD-X100
• Status Flag: ACTIVE
• User Identifier: USER_123ABC

Queries must match the complete value exactly. For example:

fq=category:"Electronics"

strings

The strings field is simply the multi-valued variant of StrField, allowing an array of exact tokens to be stored in one field. Each value in the array is treated independently and indexed without any tokenization or normalization, preserving case and punctuation exactly as inserted. This is perfect for tag lists, user roles or any situation in which a record holds multiple discrete labels and you need to filter or facet on any one of them. Querying strings fields is as simple as checking for the presence of the exact token in the set.

Examples:

• Tags: ["solr","search","security","log","alerts"]
• User Roles: ["admin","editor","viewer","analyst","guest"]
• Categories: ["malware","phishing","ransomware","spyware","adware"]
• Features: ["encryption","compression","replication","backup","monitoring"]
• Alert Types: ["info","warning","critical","error","debug"]

text_general

The text_general field uses Solr's TextField class with a StandardTokenizerFactory to break text at whitespace and punctuation, followed by a LowerCaseFilterFactory to normalize all tokens to lowercase. No stopword or synonym filters are applied, so every term - common or rare - is retained in normalized form. This setup provides case-insensitive full-text search capability, improving recall by matching different capitalizations of the same word while still indexing every token. It is well suited for searching log messages, alert descriptions or any free-form text where simple tokenization plus lowercase normalization gives the best balance of precision and recall.

Examples:

• Log Message: The Quick Brown Fox jumps over the lazy dog.
• Error Description: Error: Connection timed out after 5000ms.
• Debug Entry: DEBUG: Variable x has unexpected null value.
• User Comment: User reported issue with login flow on mobile.
• Alert Details: High CPU usage detected on server-01 during peak hours.

boolean

The boolean field is backed by Solr's BoolField class and stores a single true/false value (or equivalently 1/0) with no analysis or tokenization. Inputs beginning with “1”, “t” or “T” are interpreted as true; everything else is false. Because it's stored as a native bit, boolean fields support extremely fast filtering and faceting on binary flags such as isEncrypted or isCritical. Its simplicity also keeps index size minimal and query execution very efficient.

Examples:

• Is Encrypted: true
• Has Attachment: false
• Is Active User: true
• Email Verified: false
• Two-Factor Enabled: true

booleans

The booleans field extends BoolField into a multi-valued form, allowing a document to carry an array of independent true/false flags. Each entry is indexed separately without any additional processing, so you can filter on any individual flag with minimal overhead. This is useful for capturing multiple binary attributes per record - such as a set of pass/fail compliance checks - while retaining the performance benefits of native boolean storage.

Examples:

• Compliance Checks: [true,false,true,false,true]
• Alert Flags: [false,true,false,true,false]
• Feature Toggles: [true,true,false,false,true]
• Policy Violations: [false,false,true,true,false]
• Service Statuses: [true,true,true,false,true]

pint

The pint field employs Solr's IntPointField class to index 32-bit signed integers as Lucene BKD “dimensional points,” providing highly efficient numeric range queries and exact-match searches on integer values with no tokenization. DocValues are enabled by default, offering fast sorting and faceting on fields like event severity or inventory counts. This design makes pint ideal for any integer metric where range filtering or exact matching is required.

Examples:

• Event Severity: 3
• Login Count: 150
• Error Code: 404
• Retry Attempts: 5
• Priority Level: 1

pints

The pints field is the multi-valued counterpart to IntPointField, storing arrays of 32-bit integers where each value is indexed as a point for efficient range filtering and sorting. This allows a single document to represent multiple count-based metrics - such as several event counters - while still benefiting from BKD-tree numeric indexing.

Examples:

• Available Sizes: [6,7,8,9,10]
• Error Codes: [100,200,301,404,500]
• Retry Attempts per Stage: [1,2,3,2,1]
• Version Numbers: [1,2,3,4,5]
• Bucket Counts: [10,20,30,40,50]

pfloat

The pfloat field uses Solr's FloatPointField class to store single-precision (32-bit) floating-point values as BKD points, enabling precise range filtering and sorting on decimal data without any tokenization or analysis. It is perfect for fields like risk scores or sensor measurements where numeric precision and query speed are both critical.

Examples:

• Risk Score: 4.5
• CPU Load: 0.75
• Memory Usage (%): 65.2
• Temperature (°C): 22.8
• Disk I/O (MB/s): 120.4

pfloats

The pfloats field is the multi-valued form of FloatPointField, indexing each float in the array independently as a point. This supports efficient querying and faceting over multiple decimal measurements - such as a series of risk scores or sensor readings - attached to a single document.

Examples:

• Temperature Readings: [18.6,19.2,20.0,21.5,22.1]
• Response Times (ms): [10.5,12.3,9.8,11.0,10.1]
• Risk Scores: [3.2,4.5,2.8,5.0,4.1]
• Load Averages: [0.5,0.7,0.9,0.6,0.8]
• Packet Loss (%): [0.1,0.2,0.0,0.3,0.1]

plong

The plong field is built on Solr's LongPointField class to index 64-bit signed integers as BKD points, allowing extremely fast range queries and exact matching on large numeric values like timestamps or high-precision counters. With DocValues enabled, plong fields also support rapid sorting and faceting on large-scale numeric data.

Examples:

• Event Timestamp (ms): 1625097600000
• Unique Counter: 9007199254740992
• Session Duration (ms): 3600000
• Byte Offset: 10485760
• Total Requests: 1234567890123

plongs

The plongs field is the multi-valued variant of LongPointField, storing arrays of 64-bit integers so that a document can carry multiple large numeric values - such as multiple event timestamps - while preserving the performance of dimensional-point indexing for range queries and sorting.

Examples:

• Session Start/End: [1625097600000,1625184000000]
• Checkpoint Timestamps: [1625000000000,1625100000000,1625150000000,1625170000000,1625180000000]
• Window Boundaries: [1609459200000,1612137600000,1614556800000,1617235200000,1619827200000]
• Backup Dates (ms): [1622505600000,1625097600000,1627776000000,1630454400000,1633046400000]
• Milestone Timestamps: [1620000000000,1622500000000,1625000000000,1627500000000,1630000000000]

pdouble

The pdouble field leverages Solr's DoublePointField to index double-precision (64-bit) floating-point numbers as BKD points, delivering high-accuracy range searches and sorting on values like financial rates or scientific measurements with no tokenization. This field type is designed for use cases demanding maximum fractional precision.

Examples:

• Scientific Measurement: 0.00000012345
• Currency Rate: 0.8392912371
• Precision Factor: 1.23456789012345
• Statistical Value: 2.718281828459045
• Probability: 0.000000000123456

pdoubles

The pdoubles field is the multi-valued counterpart of DoublePointField, indexing each 64-bit float in an array independently. It allows efficient querying, sorting, and faceting across multiple high-precision readings - for example, several currency rates or measurement values - within a single document.

Examples:

• Exchange Rates: [1.234567891234,0.987654321098,1.000000000123,0.750000000456,1.500000000789]
• Scientific Series: [0.000123456789,0.000987654321,0.001234567890,0.000456789012,0.000654321098]
• Measurement Set: [12.345678901234,23.456789012345,34.567890123456,45.678901234567,56.789012345678]
• Financial Indicators: [0.123456789012,0.234567890123,0.345678901234,0.456789012345,0.567890123456]
• High-Precision Logs: [123456.789012,234567.890123,345678.901234,456789.012345,567890.123456]

pdate

The pdate field uses Solr's DatePointField class to parse ISO-8601 date/time strings (YYYY-MM-DDThh:mm:ssZ) into numeric BKD points with millisecond precision, enabling rapid date-range queries and support for date-math expressions like NOW-7DAY or NOW/DAY+1MONTH, all without any tokenizer. It is ideal for event timestamps, release dates, or any time-based data requiring dynamic filtering.

Examples:

• Event Timestamp: 2025-04-18T15:30:00Z
• Release Date: 1995-12-31T23:59:59.999Z
• User Registration: 2024-08-01T09:15:30Z
• Certificate Expiry: 2026-01-15T00:00:00Z
• Scheduled Maintenance: 2025-05-01T02:00:00Z

pdates

The pdates field is the multi-valued form of DatePointField, storing arrays of ISO-8601 timestamps so a document can include multiple date/time values - such as login histories or scheduled events - while still benefiting from efficient range and relative-date filtering via date-math support.

Examples:

• Release History: ["2025-01-01T00:00:00Z","2025-06-30T12:00:00Z","2025-12-31T23:59:59Z"]
• Login Timestamps: ["2025-04-17T08:15:00Z","2025-04-18T07:45:00Z","2025-04-19T12:00:00Z"]
• Backup Schedule: ["2025-04-01T00:00:00Z","2025-04-08T00:00:00Z","2025-04-15T00:00:00Z"]
• Audit Trail: ["2025-03-01T10:00:00Z","2025-03-15T10:00:00Z","2025-04-01T10:00:00Z"]
• Version Deployments: ["2025-02-01T05:00:00Z","2025-03-01T05:00:00Z","2025-04-01T05:00:00Z"]