This project has moved. For the latest updates, please go here.

Setting collection name dynamically

Sep 11, 2013 at 12:13 AM
I like MongoRepository - very simple facade on top of MongoDB. Thanks for creating it!

I have one feature request - the ability to set the collection name dynamically as opposed to getting it from the type name or CollectionNameAttribute.

The scenario is to define a single Entity class (e.g. with one CollectionNameAttribute) but be able to have the MongoRepository connect it to different collections based on the environment (development, staging, etc).

Currently the only workaround (aside from hacking the code :-)) appears to be to use different URLs for the different environments - however this involves setting up multiple MongoDB instances (or using multiple MongoLab/MongoHQ instances), which may be appropriate to separate production from other environments, but seems like overkill for different dev/test environments.

The fix appears to be super-simple - e.g. add a constructor for overriding the collection name.

Sep 11, 2013 at 8:54 AM
Thanks for the feedback, I'll look into it.
Sep 11, 2013 at 9:38 AM
There's one little issue: there already is a ctor for MongoRepository (and MongoRepositoryManager) with one string argument: the connectionstring. I don't want to break existing implementations (although, there's no way to get out under this one I'm afraid, suggestions are welcome!) so that means that I'll have to add overloads.

These are the current constructor overloads for MongoRepository:
public MongoRepository()
public MongoRepository(string connectionString)
public MongoRepository(MongoUrl url)
And that would become:
public MongoRepository()
public MongoRepository(string connectionString)
public MongoRepository(string connectionString, string collectionName)
public MongoRepository(MongoUrl url)
public MongoRepository(MongoUrl url, string collectionName)
It ain't exactly pretty IMHO. Do you have any suggestions for a better solution?

I did implement this already (see commit 28343) so you can try it out. Do note that this version does break backwards compatibility because of the switch to IEntity<T> (see commit 28146 and discussion "Id as int!")
Sep 12, 2013 at 8:40 AM
Edited Sep 12, 2013 at 8:40 AM
Just what I needed!!!!


Nice to have been implemented yesterday...