Is this project dead?

[PetrPospisil]

This project has long live pullrequests and issues not addressed by authors.

Is this project dead? Are there any plans for this library in the future?

Thx.

[jakedenyer]

Would really love to know the answer to this. I have a current implementation and would love a heads up if this project wont be receiving any updates so I can plan ahead!

[vigouredelaruse]

if it's not dead it's been shagged out after a particular long squawk since 2015. if true this is of course a drag, because shards and dynamic scale database use cases aren't going away

[jakedenyer]

crickets...

[thomasvdb]

We created a support ticket at Microsoft with a similar question and this was their response:

"[...] there isn’t any active work planned for the Elastic Client library. It is open-sourced now, and you can definitely build your own.
Support will treat that like any other application connecting to Azure SQL Database."

[alexmg]

This seems strange given the integration of shard map manager with CREATE EXTERNAL DATA SOURCE. If users are building their own version of the library what will ensure compatibility with the existing elastic query support in Azure SQL Database? There are no details on what is expected to be in the shard map manager database for this feature to work.

The fact that the library has not been upgraded to Microsoft.Data.SqlClient even though the community is attempting to contribute this is very disappointing. The official documentation encourages users to build multitenant SaaS application using Elastic Pools on Azure SQL Database but the primary library for doing this targets .NET Framework and has been left for dead.

[vigouredelaruse]

i'm pretty sure that today i would not recommend use of this library, in favour of a tenant shard implementation fronted by an entity retrieval endpoint per tenant microservice. the microservice is free to connect to the physical db from a vendor of choice via whatever tenant sharding mechanism the service provider prefers/implements.

but it's a horizontally scalable microservice.

this is based on the fact that a multitenant saas type app will also likely have a tenant cache, which is on the same code path as the shard map operations.

in this scenario one can see engineering based reasons for the benign neglect obvious in this repo