fdb-record-layer icon indicating copy to clipboard operation
fdb-record-layer copied to clipboard

A record-oriented store built on FoundationDB

Results 304 fdb-record-layer issues
Sort by recently updated
recently updated
newest added

…ulti target by records" At this step, we still keep the old `IndexingByRecords` module - used for implementing `buildRange`, `splitIndexBuildRange`, `buildUnbuiltRange`,`buildEndpoints`. Maybe it'll be possible to delete it after implementing...

This PR made the LuceneOptimizedIndexSearcher, however it mistakenly allowed `CollectionTerminatedException` to be propagated to the outside. In the original code, that exception was [properly ignored](https://github.com/FoundationDB/fdb-record-layer/commit/e98cf6aa234563acc7c45e57c3a6f19e22af0a1f#diff-f59fd6db59846daffb972ed37a5e1e7352965c1905e97b1b75c418bef7c61275L112) as suggested in Lucene Docs:...

- fixes a matching problem in `ComputingMatcher` where a join predicate could not be matched because the match was not considered. - change the data access rules in a way...

This allows Cascades to plan QGM plans involving a `group by`, for such a plan Cascades explores part of the search space limited to access path that are compatibly-ordered with...

``` java.lang.IllegalArgumentException: after must be a FieldDoc; got doc=616 score=NaN shardIndex=0 at org.apache.lucene.search.IndexSearcher.searchAfter(IndexSearcher.java:513) at org.apache.lucene.search.IndexSearcher.searchAfter(IndexSearcher.java:489) at com.apple.foundationdb.record.lucene.LuceneRecordCursor.searchForTopDocs(LuceneRecordCursor.java:267) at com.apple.foundationdb.record.lucene.LuceneRecordCursor.maybePerformScan(LuceneRecordCursor.java:231) at com.apple.foundationdb.record.lucene.LuceneRecordCursor.lambda$onNext$1(LuceneRecordCursor.java:185) at java.base/java.util.concurrent.CompletableFuture$AsyncSupply.run(CompletableFuture.java:1700) ```

bug

… of `AND` and `OR` queries and separate / combined Lucene indexes for the clauses' fields. Enhance `planOther` so that intersection of compatibly (meaning, explicitly) ordered scans is attempted. Add...

Follow-on to #1816: Add function key expressions to represent the two built-in sort orders for Lucene searches. Draft because these default keys aren't really suitable most of the time.

After gaining some confidence in the "multi target by records" indexing path, change the code to let the "single target by records" be a private case of one item in...

indexer