Closed cwbrandsdal closed 4 years ago
Assuming it's a simple upgrade of nuget packages, I don't see a problem. I'll look at it shortly.
it looks like there are a number of API changes to accomodate. This will take some time. I also notice that Lucene.net 4.8 is only currently available in a beta
Are you planning on updating the code for 4.8? I am planning to move a Lucene.net 4.8.0 app to Azure soon and would like to know if I will be able use this code soon. Thanks for the work you have done so far.
Hi @mgmiles, I would like to update to 4.8, but the lucene API has changed quite a bit. I could do with some guidance on how to implement the directory.
Anything new on this?
Lucene.NET 4.8 is still just in Beta - up to Beta 5 at the moment - but perhaps there would still be value in getting AzureDirectory upgraded. Even working with the Beta would allows transitioning to target netstandard2.0
as well.
AzureDirectory / Lucene.NET 3.0.x are the last libraries in our projects that are not available yet for netstandard2.0
(other than the Lucene's beta).
Did someone manage to port this?
Yes, checkout my latest PR (#32), this is confirmed working with Azure Storage however some compromises had to be made until someone addresses them - namely, I got rid of the caching mechanism.
@paviad @richorama Are there any plans to create a NuGet package from the latest commit on master, e.g. as a beta? That would make it much easier to try it out on .NET Core. Thanks!
A couple of items as initial feedback:
netstandard2.0
instead of netcoreapp3.0
. Otherwise this puts quite a limit on how this package can be used@paviad can you please explain the use of the caching mechanism and the implications of it not being there? thanks!
The caching stores on the local filesystem files from the cache, that's what it does, but it uses an API of old Lucene which I could not find in the new Lucene...
On Wed, Sep 18, 2019 at 12:09 PM yohsii notifications@github.com wrote:
@paviad https://github.com/paviad can you please explain the use of the caching mechanism and the implications of it not being there? thanks!
— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/azure-contrib/AzureDirectory/issues/27?email_source=notifications&email_token=AAJNV2D7ZKOLQDE764BBGS3QKHV3LA5CNFSM4DYZRSE2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD67MEDA#issuecomment-532595212, or mute the thread https://github.com/notifications/unsubscribe-auth/AAJNV2C7C6LSFE6EZSUA7OTQKHV3LANCNFSM4DYZRSEQ .
@paviad thanks for quick response. so if i understand correctly, azure directory is supposed to write to azure blob but also to a local directory which you can pass in as an argument to the constructor and reads are done from this local directory. is this local directory what you are referring to as the cache? if so, how is performance affected now that you don't have the local directory and instead are reading everything from an azure blob only?
thanks again
I'm happy to publish this to nuget, give me a few days to get some time to do it...
I did not analyze performance, but it seems to be "pretty good" - the API which are missing involve getting the last modified time for a blob to determine if cache needs to be refreshed for it.
On Wed, Sep 18, 2019 at 4:58 PM yohsii notifications@github.com wrote:
@paviad https://github.com/paviad thanks for quick response. so if i understand correctly, azure directory is supposed to write to azure blob but also to a local directory which you can pass in as an argument to the constructor and reads are done from this local directory. is this local directory what you are referring to as the cache? if so, how is performance affected now that you don't have the local directory and instead are reading everything from an azure blob only?
thanks again
— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/azure-contrib/AzureDirectory/issues/27?email_source=notifications&email_token=AAJNV2DXLGEZLAM24VSNG23QKIXXRA5CNFSM4DYZRSE2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD7AE6PY#issuecomment-532696895, or mute the thread https://github.com/notifications/unsubscribe-auth/AAJNV2BTEGPKQKNKNQMMSGDQKIXXRANCNFSM4DYZRSEQ .
@paviad yes the missing FileModified() method is annoying but i've made a work around based on your new code and the original including the cache. it's building against .net standard 2.0 now i just need to run the tests and maybe test it in my personal project to see if it holds up. i'll let you know how it goes and hopefully if it works we get to keep the cache
@richorama @paviad i've submitted a pull request
There are some changes to the constructor of Azure directory. It now requires a file path for the cache directory and doesn't support ram directory. If you're running the tests don't forget to pass in a valid path
i've also created SyncDirectory which offers another strategy for using Lucene.Net with Azure.
@richorama any chance you can checkout PR #33, it would be good to get things integrated and have this out on nuget
see #34
@richorama thanks, good work getting the tests working
Is there any way to upgrade this project to work with the Lucene.Net 4.8.0?