Details
-
Improvement
-
Resolution: Unresolved
-
Unknown
-
None
-
None
-
None
-
None
Description
The current implementation of mongo driver's LINQ provider throws an `ExpressionNotSupportedException` when it fails to find a built-in translator for a LINQ expression it encounters.
Has there been any consideration to allowing users of the library to provide their own custom translators in order to open up support to other use cases that are not implemented by the library?
I'm currently working on a library which implements BSON serialization of geometry types defined by `NetTopologySuite`
`NetTopologySuite` has been chosen by EF Core as the standard for defining geometry types and it provides packages which add serialization and LINQ support for it.
For example the following model and query are automatically serialized and translated into a database query.
using NetTopologySuite.Geometries; |
|
|
public class Model |
{
|
public Point Location { get; init; } = default!; |
}
|
|
|
...
|
|
|
queryable.Where(m => m.Location.Within(new Polygon(new LinearRing(new Coordinate[] { new(0, 1), new(0, -1), new(1, -1), new(1, 1), new(0, 1), })))); |
In projects following Onion Architecture, using `NetTopologySuite` allows for decoupling Domain models from the persistence layer, allowing for the database technology to be swapped out without changes to the Domain layer.
On top of that HotChocolate which implements GraphQL for .NET have built-in support for translating GraphQL queries like the following one into a LINQ expression which uses `NetTopologySuite`
query Models {
|
models(where: {
|
location: {
|
within: {
|
geometry: {
|
type: Polygon,
|
coordinates: [
|
[
|
[20 20], |
[140 20], |
[120 100], |
[20 100 ], |
[20 20] |
]
|
]
|
}
|
}
|
}
|
}){
|
location {
|
coordinates
|
}
|
}
|
}
|
translates to:
queryable.Where(m => m.Location.Within(new Polygon(new LinearRing(new Coordinate[] { new(20, 20), new(140, 20), new(120, 100), new(20, 100), new(20, 20) })))); |
Put together, it can be very powerful and removes a lot of the boilerplate code required in order to make geospatial queries directly from the frontend all the way to Mongo or SQL server, all while maintaing separation and decoupling between different layers of the application.
Currently, we're in the process of migrating from SQL Server to MongoDB and having the option to leave our Domain logic mostly untouched and for our frontend's GraphQL queries to continue working with minimal changes is very appealing.
With the help of MongoDB.NetTopologySuite.Serialization library that I'm writing and the ability to extend current LINQ provider implementation, that can make our migration a lot easier.
Is this something that has been given consideration, and would you be open to accepting a PR if I have a crack and introducing extensibility points in the code?