jackylee-ch opened a new pull request, #9823:
URL: https://github.com/apache/paimon/pull/9823

   ### Purpose
   
   `capPqM`'s Javadoc requires `pq.m` to be `> 0 && <= dimension`; the body 
checked only the upper bound, so `lumina.encoding.pq.m = 0` reached the native 
trainer instead of failing here. Javadoc and clamp both arrived in `410e1267b` 
(#7330), so the two bounds were never deliberately different — the upper one 
keeps clamping because tightening it would break tables that build today.
   
   ### Open question
   
   If the native trainer reads `pq.m = 0` as "auto", such indexes exist, and 
since `toLuminaOptions()` is also on the read path 
(`LuminaVectorGlobalIndexReader:253`, `:377`) this would fail their searches 
too. `lumina-jni` is external; can anyone confirm?
   
   ### Tests
   
   `LuminaVectorOptionsTest#testEncodingPqMBounds` (`capPqM` had no coverage). 
Reverting the fix:
   
   ```
   Expecting code to raise a throwable.
   ```
   
   Written with Claude Code; verification is mine.
   


-- 
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: [email protected]

For queries about this service, please contact Infrastructure at:
[email protected]

Reply via email to