[CSHARP-699] Support ADO.Net Created: 10/Mar/13  Updated: 11/Mar/19  Resolved: 06/Apr/15

Status: Closed
Project: C# Driver
Component/s: Feature Request
Affects Version/s: None
Fix Version/s: None

Type: New Feature Priority: Major - P3
Reporter: Alexander Nagy Assignee: Unassigned
Resolution: Won't Fix Votes: 1
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

Most existing .Net code is written on top of the NHibernate or EntityFramework ORMs. In many cases customers do not have source level access to various components that are built on top of these ORMs, or the engineering resources to migrate them to MongoDB, but would like to consolidate DB technologies.

Consider that this would be a strategic advantage for MongoDB, as most .Net CMSes are all build on top of one of the two ORMs.

While Mongo doesn't support joins, most ADO.Net functionality could be implemented, and even pseudo joins on the client could in theory be possible (perhaps enabled with a configuration switch?).

ADO.Net is relatively low level (no high level semantics like joins), so it is possible to implement a provider, and there is copious example code on the Internet for this. The most curious part is the IDbCommand interface and CommandText property, this would require some mapping of SQL to MongoQuery language or Mongo's LINQ implementation; once again there is source code on the Internet for doing this.

Providing this would suddenly open up the entire world of .Net interop and use-scenarios with MongoDB. It would make MongoDB an pseudo-turn-key replacement for MySql, PostGRE, and MsSQL.

Please consider it.

References -

Implementing a .NET Framework Data Provider: http://msdn.microsoft.com/en-us/library/4ksaf9z5%28v=vs.71%29.aspx

ADO.NET: Building a Custom Data Provider for Use with the .NET Data Access Framework: http://msdn.microsoft.com/en-us/magazine/cc301611.aspx

Parsing SQL into LINQ: http://www.codeproject.com/Articles/43678/Dynamically-evaluated-SQL-LINQ-queries



 Comments   
Comment by Robert Stam [ 21/Mar/13 ]

Thanks for an interesting suggestion. If we do embark on such an effort it would be a separate project from the driver itself (and would be built on top of the driver).

Will leave the JIRA ticket open for now to keep track of the suggestion.

Generated at Wed Feb 07 21:37:35 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.