[CSHARP-864] BsonDocumentWrapper BsonType is Document but AsBsonDocument throws Created: 30/Nov/13 Updated: 02/Apr/15 Resolved: 04/Dec/13 |
|
| Status: | Closed |
| Project: | C# Driver |
| Component/s: | None |
| Affects Version/s: | 1.8.3 |
| Fix Version/s: | 1.9 |
| Type: | Bug | Priority: | Minor - P4 |
| Reporter: | Roman Kuzmin | Assignee: | Robert Stam |
| Resolution: | Done | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Description |
|
My application analyses various documents created by the driver, including query and update documents from builders. I noticed the following problem. I was assuming that if BsonValue.BsonType is Document then it is valid to call AsBsonDocument on it. This is not true for BsonDocumentWrapper - its type is Document (set in the constructor) but AsBsonDocument is not overridden and throws "Cannot cast ...". Update builder Pull(query) creates such a wrapper, for example. If BsonDocumentWrapper wraps a document then AsBsonDocument should get this document. Otherwise it should not set its BsonType to Document or even be called a document wrapper. Currently an application dealing with generic documents, including created by the driver, has to perform checks for BsonDocumentWrapper type explicitly and unwrap it. This is neither effective nor natural, especially taking into account that BsonDocumentWrapper, I think, is mostly designed for internal driver needs. |
| Comments |
| Comment by Robert Stam [ 04/Dec/13 ] | |||||
|
We backported the changes to BsonDocumentWrapper from 2.0 to 1.9. A BsonDocumentWrapper is now a subclass of BsonDocument. If all that ever happens with it is that it gets serialized that can happen very efficiently. The minute you try to do anything with it (i.e. accessing it like a BsonDocument) it gets materialized by serializing the object that is being wrapped. From that point on it is treated as if it were a regular BsonDocument. All of the logic of intercepting BsonDocument method calls and materializing the BsonDocument on demand is in the new MaterializedOnDemandBsonDocument class, which is also the base class for LazyBsonDocument. So the class hierarchy is:
| |||||
| Comment by Githook User [ 04/Dec/13 ] | |||||
|
Author: {u'username': u'rstam', u'name': u'rstam', u'email': u'robert@10gen.com'}Message: | |||||
| Comment by Robert Stam [ 30/Nov/13 ] | |||||
|
Thanks for reporting this Roman. We have addressed this already in the 2.0 branch. We will look into the feasibility of backporting the fix to 1.9. |