[CSHARP-1194] Support for adding Discriminators to a collection Automatically Created: 17/Mar/15 Updated: 20/Jan/16 Resolved: 03/Sep/15 |
|
| Status: | Closed |
| Project: | C# Driver |
| Component/s: | None |
| Affects Version/s: | None |
| Fix Version/s: | 2.1 |
| Type: | New Feature | Priority: | Major - P3 |
| Reporter: | Craig Wilson | Assignee: | Craig Wilson |
| Resolution: | Done | Votes: | 4 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Description |
|
Currently, when using a hierarchy of types (Animal -> Cat, Dog), it is required to always use the base class as the generic type on collection (Animal). That's fine, but if I only want to then work with Cats, I must add the discriminator in manually to every filter. There should be a way to do this automatically. ------------------------ For instance, `db.GetCollection<Animal>("animals").OfType<Cat>();` returns an IFilteredMongoCollection<Cat>, which implements IMongoCollection<Cat>. From here, everything that can be done on a normal collection can be done on this collection, except the discriminator will be added to all filters. |
| Comments |
| Comment by Githook User [ 03/Sep/15 ] | |||||
|
Author: {u'username': u'rstam', u'name': u'rstam', u'email': u'robert@robertstam.org'}Message: | |||||
| Comment by Githook User [ 03/Sep/15 ] | |||||
|
Author: {u'username': u'rstam', u'name': u'rstam', u'email': u'robert@robertstam.org'}Message: | |||||
| Comment by Githook User [ 03/Sep/15 ] | |||||
|
Author: {u'username': u'rstam', u'name': u'rstam', u'email': u'robert@robertstam.org'}Message: | |||||
| Comment by Githook User [ 03/Sep/15 ] | |||||
|
Author: {u'username': u'craiggwilson', u'name': u'Craig Wilson', u'email': u'craiggwilson@gmail.com'}Message: | |||||
| Comment by Robert Stam [ 16/May/15 ] | |||||
|
The problem with the approach of creating a filtered collection is that it doesn't represent at all the reality of what's in the database. Given a variable:
I would expect that it represents a collection that contains Cats. But the database has no such collection. What the database has is a collection of Animals, some of which might be Cats. Furthermore, all operations against such a collection are misleading. For example, given:
I would expect count to be the number of documents stored in the collection. But in the proposed filtered collection implementation that wouldn't be true, it would actually only return the count of the Cats in the collection (by design of course, but it's misleading). Further examples of confusion can arise in queries. For example, the following Find might not return any documents:
Even if the collection has plenty of documents with the name "Spots". It all depends on whether there are any Cats named "Spots", but that important detail is hidden away in a side effect. I think our emphasis should be on making it easier to issue queries against polymorphic collections, not on creating filtered collections that don't correspond to anything that actually exists in reality. It would be far more transparent to simply embrace the notion that certain types of queries imply that the matching documents are of a certain type, and take advantage of that. For example, one could write (where OfType would be a new filter builder method):
In this case, not only is nothing hidden (we immediately see that we are only querying Cats, this is not hidden in some side effect!), but we can take advantage of the type information in the OfType filter to automatically make the result be of type List<Cat> instead of List<Animal>. |