uschindler commented on PR #13196: URL: https://github.com/apache/lucene/pull/13196#issuecomment-2015060974
> > ... Additionally, I assume we can have unit tests for NativeAccess directly. Lemme take a quick look at this. > > Dammit! I forgot about how our code is organised. Over in Elasticsearch we added version specific test sets for exactly this reason, so that `test21` could depend upon `java21` (which we call `main21`). For unit tests of NativeAccess, we would need similar. When we implemented the MRJAR part for MMapDirectory and Vectorization, I said: Let's have no extra complexity with tests and just *indirectly* test the code. For MMapDirectory this worked fine, because when the test passes, the implementation of the IndexInput is fine. For vectorization its similar, we have a scalar and a vectorized impl that is compared by tests => also fine. I agree, here it triggers platform specific madvise(). We may add mocks for testing, but I am not sure if it is worth. Maybe the easiest would be to extend IOContext at a later time to return some madvise-like enum as additional abstraction., so the native code just gets a MAdvice enum constant and maps it straight to integers in a simple `Map<MAdvice,Integer>`. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org --------------------------------------------------------------------- To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
