Closed cheng93 closed 1 year ago
Looks like it is working as designed (it needs to find the object type from the EDM type). Ok to submit a PR to support the custom namespace.
@BlaiseD I don't believe it does
https://github.com/cheng93/AutoMapper.OData/blob/odata-namespace/ApiController.cs
With EnableQuery and ProjectTo, using namespace works.
With GetQueryAsync
, it does not work.
Also I believe that OData namespace != EDM namespace
Also is it possible to leave the issue open and maybe tag it as a feature request/enhancement?
Someone can pick it up and implement it.
If it remains closed, then it is unlikely this will happen
@cheng93 - the exception here is thrown because it cannot match the EDM type with a loaded type.
I think to reopen, the issue should be clearer about what underlying logic is missing - other than that "EnableQuery and ProjectTo work" i.e. what's the alternative logic.
Make sense?
Ok, I suppose the issue is that having a custom OData namespace should not affect matching an edm type with a CLR type. These should be defined by the automapper mappings
http://localhost:5238/odata/categories?$expand=Products expand by itself works too, so I think that implies it has found the CLR type (ProductModel)
however adding the filter, causes the exception which is wierd, as the CLR type is already known
Almost. In most cases the type is known from the initial TModel
type e.g. expand by itself. The filter helper calls GetClrType
using the EDM type when it does not know the type.
I think a fix will involve passing a type to every GetXXXFilterPart
meaning GetClrType
will become obsolete.
Not quite obsolete - it will still be needed for constants - just not for members of the initial TModel
,
The exception at the bottom is found
Sample
https://github.com/cheng93/AutoMapper.OData/tree/odata-namespace https://github.com/cheng93/AutoMapper.OData/blob/odata-namespace/Program.cs#L28 (causes the issue)
http://localhost:5238/odata/categories?$expand=Products($filter=ProductId%20eq%201)