[CSHARP-375] Overridden virtual properties are serialized even if the overriding property has the BsonIgnoreAttribute Created: 04/Jan/12 Updated: 02/Apr/15 Resolved: 18/Feb/12 |
|
| Status: | Closed |
| Project: | C# Driver |
| Component/s: | None |
| Affects Version/s: | 1.3.1 |
| Fix Version/s: | 1.4 |
| Type: | Bug | Priority: | Major - P3 |
| Reporter: | Joe Enzminger | Assignee: | Robert Stam |
| Resolution: | Done | Votes: | 0 |
| Labels: | bson | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Environment: |
Windows Server 2008, .NET 4.0 |
||
| Description |
|
public class BaseClass } public class DerivedClass : BaseClass { [BsonIgnore] public override object Property {get;set;} } When saving an instance of DerivedClass, Property will still be serialized to the database. |
| Comments |
| Comment by Robert Stam [ 18/Feb/12 ] | |||||||||||||||||
|
The current implementation of BsonClassMapSerializer is one that at runtime interprets the class map to decide what to do. Your suggestion of using code generation techniques to generate a custom serializer on the fly is one that would result in excellent performance (other than the one time cost of the code generation), but is a major change that would require lots of testing. It's also unclear how much of a performance improvement there would be, and how much it would be worth investing in it, since the current implementation is already fast enough to saturate most network connections. Since the current design by definition uses whatever options are defined for the virtual property in the class where the property is first declared (and ignores any options placed on overridden properties) I'm going to close this ticket as "works as designed". | |||||||||||||||||
| Comment by Joe Enzminger [ 04/Jan/12 ] | |||||||||||||||||
|
Thanks for the workaround. The only thing I don't like about it is that in my actual use case, it forces me to add serialization details to my data model (the base class). I actually don't mind adding that information to the derived class since it is a generated proxy. What I'm thinking about doing is writing a replacement for BsonClassMapSerializer that does two things: 1) Generates a static serialization class for each type - this should have about the same overhead as BsonClassMap on generation and should be quite a bit faster on serialization/deserialization. 2) Uses GetProperties(without DeclaredOnly) to get a list of members to be serialized. This fixes my issue (I think). I think all I need to do is register a custom serializer that calls BsonDefaultSerializer.GetSerializer for a type, and if the returned object is BsonClassMapSerializer, I'll return my serializer instead. Are there any major issues that BsonClassMap was designed to solve that I might step on? | |||||||||||||||||
| Comment by Robert Stam [ 04/Jan/12 ] | |||||||||||||||||
|
Not sure what the ramifications of handling attributes at multiple levels would be. It would likely make things more complicated. Here's a different way of accomplishing the same thing (using the ShouldSerializeXyz feature) that works with the current code:
| |||||||||||||||||
| Comment by Joe Enzminger [ 04/Jan/12 ] | |||||||||||||||||
|
Robert - thanks for the reply. If I added an option to support this pattern, would that be something I could expect could be incorporated into a future release? The use case here is proxy generation and lazy loading (or loading data from other sources for derived classes). In other words, Property may be stored outside of MongoDB in the derived class, and I'd like to not have to waste the storage storing it twice (once in MongoDB, once in the alternate storage) - especially for large objects. Other classes deriving from BaseClass may want to store that property in Mongo, so I can't add the [BsonIgnore] attribute to the base class. | |||||||||||||||||
| Comment by Robert Stam [ 04/Jan/12 ] | |||||||||||||||||
|
This is not supported. The virtual property is considered to belong to the base class and only the serialization options defined there are used. |