jeme commented on issue #763: URL: https://github.com/apache/lucenenet/issues/763#issuecomment-1322649394
> I really don't see how you can do it without breaking all the components. > even with partial classes, the async operations should seep from the ground basic operations (Lucene.Net.Store.DataOutput) all the way up to the public api. As I said, making it all the way up to `IndexWriter.UpdateDocumentAsync(...)` I am having a hard time believing can be done without running into trouble as well, however for replication purposes, working with Lucene on the lover levels (DataInputs/DataOutputs) does actually not look to hard, In an OPTION-B scenario it might even be easier that I initially thought as it's actually only the DataInput/DataOutput that needs additions in partial classes for now to lift the async operations into the replication code. Here I did run into some classes which raises a question from a efficiency perspective. E.g. InputStreamDataInput that takes a Stream in it's constructor and immediately wraps that stream in a BinaryReader but I can't see for what reason. If the concern is that the underlying stream is not buffered, then perhaps a BufferedStream would be more appropriate. The Java version takes a InputStream in the constructor and just uses that as is, so I am not sure why this differs. (At least for the Java version I currently have checked out) For OPTION-A which I would point to for now (due to priorities) the Directory classes has to be mirrored as well to return these new implementations. -- 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: dev-unsubscr...@lucenenet.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
