There are significant bugs listed for the BulkExecutor, including a continuing issue with failure to operate with any version of Microsoft.Azure.DocumentDB (#577) other than 2.1.3. see also: in issue 32 - Azure/azure-cosmosdb-bulkexector-dotnet-getting-started
Open Sourcing the Bulk Executor would allow the developer community, who is using / depending on the Bulk Executor, to assist the MS developers keep up with the latest versions of the Microsoft.Azure.DocumentDB library.
Currently we are in DLL hell, if we use the BulkExecutor, we need to carefully control all other dependencies to CosmosDB Client library in all referenced project libraries. This is getting harder and harder to do.
If you guys don't have the hours to fix it, please allow us, the developer community, to assist you. If I were still on Twitter, I'd go hit up @scottgu
@matthewacme The plan is to onboard it on our current open source effort, so, as you mention, all the developer community can benefit and contribute 馃槃
@abinav2307 Do you have any extra comment or advice for dependency handling on the Bulk Executor that might help?
I'm very interested in this as well. Particularly, getting a new branch of BulkExecutor working on the v3 .NET client. After prototyping with both clients, v3 is a far more approachable SDK. I like the direction MS has taken; just wish these libraries were all open sourced already.
Any update on this? Having the bulk executer stuck on version 2.1.3 for the cosmos db core library is essentially preventing us from using it.
Our plan it make "Bulk API" first class part of V3 SDK. Shortly we will have a preview.
Most helpful comment
@matthewacme The plan is to onboard it on our current open source effort, so, as you mention, all the developer community can benefit and contribute 馃槃
@abinav2307 Do you have any extra comment or advice for dependency handling on the Bulk Executor that might help?