Set sorting field types to 64 bit long #279
Conversation
bbimber
force-pushed
the
23.4_fb_sortingLongFix
branch
from
42eaa90
to
3875d63
Compare
|
@hextraza: this seems fine, but one question. if we're going to treat every int field like a long (which is what i think this does), should the DISCVRseq code index every INT as a LONG: https://github.com/BimberLab/DISCVRSeq/blob/dc81abc6b8e9ae2936415145c7d76dccdca6f2e9/src/main/java/com/github/discvrseq/walkers/VcfToLuceneIndexer.java#L443. If I understand it, we are indexing genomicPosition as LONG, but everything else as INT |
|
Also, we should target 23.11 so we can deploy to mGAP now. |
the line targets numericQueryParserFields which is only used to look up the type of sorting fields-- all sorting fields are indexed as 64 bit long in DiscvrSeq. actual values displayed in the table are all parsed as ints, instead. if we wanted to display genomicPosition it'd have to be parsed in the API as a long instead of as an int, but it isn't a value displayed on the client side afaik I can rebase this on 23.11. |
Co-authored-by: Adam Rauch <[email protected]> Co-authored-by: Josh Eckels <[email protected]>
* Add LRUQueryCache * Custom query caching policy * Query strategy works on BooleanQuery with MatchAllDocs predicate * Use proper Cache and add action to report cache info * Improve handling of lucene cache * Add code to cache the first page of each mGAP JBrowse session * Add logging and clear cache prior to adding default query --------- Co-authored-by: Sebastian Benjamin <[email protected]> Co-authored-by: bbimber <[email protected]>
Bumps [braces](https://github.com/micromatch/braces) from 3.0.2 to 3.0.3. - [Changelog](https://github.com/micromatch/braces/blob/master/CHANGELOG.md) - [Commits](micromatch/braces@3.0.2...3.0.3) --- updated-dependencies: - dependency-name: braces dependency-type: indirect ... Signed-off-by: dependabot[bot] <[email protected]>
…abKeyModules into 23.4_fb_sortingLongFix
No description provided.