rmuir commented on PR #16847:
URL: https://github.com/apache/lucene/pull/16847#issuecomment-6244052541
Hi @jimczi, I think it is a good idea and thanks for prototyping. It is
gonna be messy either way due to the nature of the change, so it helps to see.
The biggest concern I have, is the user-facing API. I think just adding the
new `long` methods to `IndexReader`, whilst keeping the old `int`-based methods
is a bit confusing to the end-user and error-prone. Adding numeric safety
checks such as `toIntExact` is a good thing but I'm guessing most users would
not hit that in their tests.
So I'm wondering, how messy would it be if the `int`-based methods were
instead moved to `LeafReader`? The methods on `IndexReader` would just support
`long`. Although it is "breaking" to the user-code, I think it would "break"
users in the best possible way: they'd have full compile-time safety to fix
their code.
```java
/**
* Returns the number of documents in this index.
*
* <p><b>NOTE</b>: This operation may run in O(maxDoc). Implementations
that can't return this
* number in constant-time should cache it.
*/
public abstract long numDocs();
/**
* Returns one greater than the largest possible document number.
*/
public abstract long maxDoc();
```
So for most users that are just searching documents, the compiler would
guide them to change `int`'s to `long`'s and then their app would work as
expected, but with the 2^31 limit removed.
For users that are doing per-segment stuff (e.g. custom components /
datastructures), they'd also have a compile-time break and they'd have in
LeafReader the `int`-based methods to help ensure safety (maybe think of a new
name such as maxLeafDoc() or whatever).
I think this might be one of those cases where a clear break would help the
user, if we do it correctly.
Please note: this is just highly theoretical idea as I haven't tried it out
or anything to see if the API would be viable in this way.
--
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]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
