Support for Redis database

[dsuppiger]

As discussed in issue #1 I implemented Redis support by generalizing and abstracting the UserManController and implementing db specific subclasses for both mongodb and redis.

Breaking changes:

• The UserManSettings has now a databaseURL property replacing the databaseName.
• The User and Group properties have changed as follows: BsonObjectID _id is now string id resetCodeExpireTime is now SysTime instead of BsonDate. fromBson and toBson methods have been added to account for this when serializing to BSON.

[s-ludwig]

Thanks! The code looks good so far. The only thing that is a little unclean is the handling of the id field, maybe there is a better abstraction that could be used rather than just relying on toBson. But I don't have spontaneous idea and it can always be improved without breaking backwards compatibility, so that can stay as it is for this pull request.

For the Redis implementation, there are now two new modules, vibe.db.redis.types and vibe.db.redis.idioms, which could be used to make the code shorter and type safe, if you want, you could look into that (especially the RedisObjectCollection would be interesting). The reason I'm mentioning this is that some key names might change when vibe.db.redis.idioms is used, so that it would require some additional DB migration code if the old system was already in use.

[dsuppiger]

Ok, I'll look into types and idioms end of week as I have time.

[dsuppiger]

The redis idioms looks promising and I'm trying to migrate my code to it or at least be forward compatible. So far I've stumbled over two issues:

1. Paging

Have you already considered implementing sorted collections in redis idioms? What about storing the IDs m_allSet in a sorted set instead of an ordinary set and implement some paging functionality? Iterating all elements won't always be viable for large collections. Or should a separate indexing set be maintained in such cases (which will be required anyways for accessing elements by anything other than IDs)?

The UserManController for example has following method (which doesn't seem to be in use though):

abstract void enumerateUsers(int first_user, int max_count, void delegate(ref User usr) del);

2. Object relationships

The User class e.g. has properties which should not be stored into the users hash like the groups and properties arrays and mostly the AuthInfo property. These are relationships to other types like Group and AuthInfo and should be stored in the respective collections. Any sugguestions on how to go about this?

[s-ludwig]

1. Sounds like a good idea. The current bool SUPPORT_ITERATION could be changed into an enum RedisCollectionOptions to add more options, such as a sorted set.
2. What I did in an application using the idioms module was to write a small helper type template that extracted only the plain fields of a struct for storage in a RedisObjectCollection. Another helper function would then take as parameters an instance of this partial struct plus the missing fields and return an instance of the original struct type. With this tool I'd then manually create all relations as separate collections. I think anything more than this would basically be what dotter already tries to accomplish and would be out of the scope of this module.

[s-ludwig]

I'll merge it like it is for now and try to make any breaking database related changes before tagging the next release. The only thing that I'm still thinking about is how to best go about handling IDs without producing allocations - probably using a fixed size struct that is able to hold a BsonObjectID, as well as a long. Thanks for the work so far!