[CSHARP-857] Custom database-less and server-less MongoCollection Created: 30/Oct/13  Updated: 05/Apr/19  Resolved: 25/Mar/19

Status: Closed
Project: C# Driver
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Task Priority: Minor - P4
Reporter: Roman Kuzmin Assignee: Unassigned
Resolution: Done Votes: 0
Labels: question
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

In the PowerShell module Mdbc (https://github.com/nightroman/Mdbc) I am going to introduce in-memory collections (optionally persistent in bson files). For the moment I am using a collection class which is semantically the same as MongoCollection. But it is not derived from it and disadvantages of this are obvious, the code dealing with collections has to be doubled if it is supposed to work with both collection types.

I tried to derive my class from MongoCollection. The MongoCollection's constructor requires a non null MongoDatabase instance which requires a non null server instance. Thus, my code is this:

public class MdbcCollection : MongoCollection
{
     public MdbcCollection()
          : base(
               new MongoDatabase(new MongoServer(new MongoServerSettings()), "name", new MongoDatabaseSettings()),
               "name",
               new MongoCollectionSettings())
     {
     }
}

Thus, it is technically possible to derive and reimplement a collection. The problem is that this scenario requires a MongoDB server running which is not needed for in-memory/file collections. The whole idea is to have an alternative server-less data storage with the same API for small collections for prototyping, application settings, and etc.

So my question is: is there a way to implement a database-less and server-less MongoCollection?

If the answer is no, then one possible solution would be to allow null database in the MongoCollection constructor. Can this be done in one of the future releases?



 Comments   
Comment by Ian Whalen (Inactive) [ 25/Mar/19 ]

nightroman the new CRUD API in the 2.x driver is interface-based.

Comment by Roman Kuzmin [ 06/Nov/13 ]

If you decide to go with IMongoCollection then one more interface will be needed - IMongoCursor because its current constructor is also bound up with a database and a server:

this._database = collection.Database;
this._server = collection.Database.Server;

I started to have doubts about the approach with interfaces. Abstract classes have some advantages in scenarios like this. For example MongoCollection in fact implements a lot of routine methods that does not have to be reimplemented in a child class. So does MongoCursor.

Perhaps special database-less and server-less constructors in existing classes still would do better. It's a little job for rare use cases. As it was proposed before, such constructors can be declared deprecated with a proper message in order to reduce chances of misuse.

Comment by Roman Kuzmin [ 30/Oct/13 ]

For my own use a new class with two implementations will do. But this wont work in some scenarios with "3rd party" tools which use just C# driver API interface (for various reasons). Actually, some of such tools may even know about possible limitations (and check the collection type in special cases).

Comment by Robert Stam [ 30/Oct/13 ]

You would probably be better off defining your own abstract base class or interface outside of the driver that exposes just the methods you need and implementing that twice: once linked to a real MongoCollection and once to some in memory representation.

Trying to fake out an entire MongoCollection implementation seems like overkill. Not to mention that there are probably many MongoCollection methods you cannot reasonably implement (e.g., Aggregate, CreateIndex, Drop, Geo searches, GetStats, Update just to mention a few).

If all you need (and all you can reasonably implement) is a subset of MongoCollection functionality it would be better to define a new interface of your own that has only the features you plan to actually implement both ways.

Comment by Roman Kuzmin [ 30/Oct/13 ]

> Are you also planning on implementing the query language?

Yes, queries and updates will be supported in the same way as for the native MongoCollection, at least gradually. It was not that difficult to compile query and updates from underlying BsonDocument's to Linq expressions and apply them to documents in memory. (What was difficult is to make results the same in some subtle or not documented edge cases.)

> We are hard at work on our next major release which will likely have an interface IMongoCollection.

This is a good news. An interface will solve the issue. I am looking forward to it.

Comment by Craig Wilson [ 30/Oct/13 ]

Roman,
Interesting idea. Are you also planning on implementing the query language? We are hard at work on our next major release which will likely have an interface IMongoCollection. This probably solves all your problems related to the inheritance issue.

Comment by Roman Kuzmin [ 30/Oct/13 ]

On the other hand, this is probably not safe to allow null database in the existing constructor. A better and safer approach would be to add another constructor which accepts just MongoCollectionSettings and no database. Such a constructor even can be declared deprecated with a proper message, so that it will be harder to use it by mistake in a derived class. Is this possible?

Generated at Wed Feb 07 21:38:02 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.