Well, in older versions of the driver I remember that it was possible to use untyped collections, which just worked with BsonDocument.
I have had this issue several times now that I’d like to implement a generic solution for common issues which require me to collect a set of for example FilterDefinitions without generic context.
For example I’d like to update multiple entities which are of similiar schema (ensured through some interfaces). The code to update these is always the same, various checks and other logic happening. In the end I generate a list of Update statements that all change a specific entity type. But since this code should be used to also work on other entity types, I cannot use generics in a meaningful way.
I can outsource the logic which generates my filter definitions and update definitions, but since these have no non-generic base class, I cannot use them in a non-generic context.
Why was this changed? Is there a way around? All I need is a non-generic base. Having all classes typed is a huge issue for a lot of cases I’ve had so far. We’re working a lot with dynamic data structures and in this case we have plenty of issues with this typing. We basically have to implement the same code for every single entity type as we cannot go with a generic (ironically inverse) approach here.
So any workaround? Any reason why this was changed? Any way it’s considerable in the future to have untyped base classes instead of “abstract Class” bases?
Thanks!
Hi, @Manuel_Eisenschink,
Thank you for your question. If I am understanding correctly, you are wondering why we require a generic type argument for a collection. For example:
var collection = db.GetCollection<Person>("people");
In particular you want to work with untyped data or you don’t care about the particular type and would like to call db.GetCollection("people") instead.
While our 1.X API allowed non-generic access to collections, we chose a different API for 2.X. We still support untyped access to collections via:
var collection = db.GetCollection<BsonDocument>("people");
You can create filter and update definitions using BsonDocument as well.
var filter = Builders<BsonDocument>.Filter.Empty;
If using BsonDocument as your generic type parameter doesn’t work for your use case, please provide some sample code to illustrate what you are attempting to accomplish so that we can discuss further.
Sincerely,
James
Hi James,
I am aware that untyped data access is possible with BsonDocument as type. The problem in my case is, that generics come with certain constraints when writing dynamic code. What I’d require is that I can work with typed classes but execute them untyped.
A good example is the ArrayFilterDefintion class. It’s the only class I found that has a non-generic base class. So I can create a typed instance i.e. ArrayFilterDefinition<MySpecificClass> and cast it to it’s base class. The driver doesn’t care about the generic anymore. This way I can write very dynamic methods which get their input from more specific methods that know their entity type they’re working on.
I certainly see the benefits of generics, but it’d be great if it was still possible to use non-generic variants they derive from. So far this is only possible for ArrayFilterDefintion which puzzles me why exactly there this schema was not continued.
Is there any reason for this? Probably complexity handling things, but since you started with this approach in V1, I guess some of the work was already done. Having non-generic base classes would definetly give greater flexibility.