New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Separate index/store document APIs take 2? #12142
Comments
I want the additional type-safety of things like Field classes that users use, but I think at a high-level, Document/Field api is good and intuitive model for end users. So I'm not sure about the value of introducing different apis or more separation. I don't agree with all the methods on Document today that pretend to offer map-like access but are really linear time searches through a list though, I would support deprecating all those. |
As far as what gets constructed by the "default" / "easy" stored fields visitor, i do think that one should be a Map and not conflated with Document used for indexing. |
Honestly i think a big challenge is naming. Last time we tried this, the name was |
The issue in my mind is that
+1 |
yeah and just to clarify at high-level: Indexing Time:
retrieval time:
|
I feel, that this discussion is close to my comment #10374 (comment) |
Description
As @rmuir managed to make me look into reducing the amount of guessing we're doing in our document API, I think that a requirement for doing it right will be to split our index and store document APIs. Currently,
Document
andIndexableField
are trying to cover both, which creates a confusing API.For the store API, I wonder if we still need a Document abstraction. Maybe we could return a simple
List<StoredValue>
and push the work on users to convert it into a map if they want to be able to access fields by name. This is something that is easy to do with Java streams nowadays.For the index API, I'd like to model
IndexableField
according to how it's getting consumed byIndexingChain
. Something like:I haven't thought much about it but I'm curious to hear thoughts.
The text was updated successfully, but these errors were encountered: