[CSHARP-652] No serializer found for type {0} exception when using "chained" Linq query Created: 21/Dec/12 Updated: 28/Apr/15 Resolved: 28/Apr/15 |
|
| Status: | Closed |
| Project: | C# Driver |
| Component/s: | None |
| Affects Version/s: | 1.7 |
| Fix Version/s: | 2.1 |
| Type: | Bug | Priority: | Major - P3 |
| Reporter: | Joe Enzminger | Assignee: | Unassigned |
| Resolution: | Done | Votes: | 1 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Attachments: |
|
||||||||
| Issue Links: |
|
||||||||
| Epic Link: | Rewrite Linq | ||||||||
| Description |
|
See attached Test. A detailed description of why this is a problem: In our service layer, we have methods that expose IQueryable<IEntity> values. The intent is that other services can uses these to perform more detailed queries. Internal to the service, we query against a collection using the concrete type (GetCollection<Entity>()) and return it as an IQueryable<IEntity>(). Enumerations against this object succeed. However, if we do an additional query against it, we get a serialization exception. |
| Comments |
| Comment by Craig Wilson [ 28/Apr/15 ] |
|
This was fixed as part of |
| Comment by Craig Wilson [ 22/May/13 ] |
|
You can see the releases we have "scheduled" here: https://jira.mongodb.org/browse/CSHARP#selectedTab=com.atlassian.jira.plugin.system.project%3Aversions-panel. I say "scheduled" because it is somewhat arbitrary right now. We are working on major 2.0 release and just don't know what all that currently entails. It is likely that the date for 1.9 will actually be 2.0 and 1.9 will come sooner. I know that doesn't help you much, but it's the best we can do right now. The linked ticket, |
| Comment by Dhireshan Gadiagellan [ 22/May/13 ] |
|
Craig, Where can I find a production release schedule for version 1.9? The package page http://www.nuget.org/packages/mongocsharpdriver/ Thanks |
| Comment by Craig Wilson [ 16/May/13 ] |
|
Joe, |
| Comment by Joe Enzminger [ 27/Mar/13 ] |
|
The serialization details of the interface really shouldn't matter. Even if I cast my original IQueryable<Entity> to IQueryable<IEntity>, my query still maintains a DocumentType of Entity. This is the only type that should matter from a serialization perspective. If I use an IEntity in an expression, it doesn't matter how it is serialized. What matters is how the expression maps to Entity. It doesn't sound like this is something that is going to get fixed, but it is a real shortcoming of the linq implementation (IMHO). I can't expose IQueryable<T> in any of my interfaces without a caveat that the only operations allowed on them things like ToList(), Count(), etc. |
| Comment by Robert Stam [ 22/Mar/13 ] |
|
Since the same interface can be implemented by many classes, and since we configure serialization at the class level, it is entirely possible that the properties of an interface will be serialized differently in the various classes that implement the interface, so we really can't determine anything about how the properties are serialized from the interface alone. |
| Comment by Joe Enzminger [ 22/Mar/13 ] |
|
Looking at it some more, it looks like you are using the serializationInfoHelper not for serialization, but instead to derive ElementNames for queries. While I know you can't deserialize an interface, it can be inspected like any other type. The fix might be to add an additional SerializationProvider that knows how to inspect interfaces (and provide the metadata needed for LINQ, but that throws an exception if you actually try to use the provided serializer for serialization. |
| Comment by Joe Enzminger [ 22/Mar/13 ] |
|
Robert, My grasp of the internals of LINQ isn't the greatest, but I don't think the cast issue was the problem. In the MongoQueryTranslator.Translate() method, you properly select a documentType of Entity (not IEntity). But instead of using this DocumentType for deserialization, you use the type of the variableExpression (which in my test, is just an IEntity e) in the where clause. I would think that you would always be deserializing to the DocumentType, and then casting or projecting to the type in the where clause. I'm a version or two old, but the exception is thrown in PredicateTranslator.cs line 347. |
| Comment by Dhireshan Gadiagellan [ 22/Mar/13 ] |
|
Hi Robert. I am not following. I tried this example in .Net 4. I also upgraded the CS driver an BSon Component to .Net 4.0. It seems to be failing in It looks like if an a user defined Interface is passed to this method, it will not return a serializer. It does not seem to be a casting issue between IQueryable<Entity> and IQuerable<IEntity> Any thoughts? |
| Comment by Robert Stam [ 22/Mar/13 ] |
|
The test code appears to require .NET Framework 4.0. Otherwise it results in a compiler error that IQueryable<Entity> can't be implicitly converted to IQueryable<IEntity>. This implicit conversion is not valid in .NET 3.5 but is valid in .NET 4 (due to covariance). This implicit conversion is most likely that part that is not supported. |
| Comment by Dhireshan Gadiagellan [ 21/Mar/13 ] |
|
I can confirm that this is indeed an issue. I am experiencing the same issue described in Joe Enzminger's initial post. This seems to occur for almost all other linq calls. e.g. Take(xx) .OrderByDescending() etc. If the query in the Attached MongoTests.cs were to change to Hope this helps. |