Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Support for database other than mongodb #1

Open
dsuppiger opened this issue May 17, 2014 · 5 comments
Open

Support for database other than mongodb #1

dsuppiger opened this issue May 17, 2014 · 5 comments

Comments

@dsuppiger
Copy link
Contributor

Are there any plans to support other databases? I'm writing an application using Redis and need to add user management. Now I would like to implement Redis support for userman but want to discuss the approach. The most straightforward option would be to turn the UserManController into an interface and then implement various concrete classes for each supported db. The UserManSettings would need to be extended with some additional properties (e.g. databaseIndex for Redis).

@s-ludwig
Copy link
Member

No concrete plans, yet, but this would be a welcome change. I think the interface suggestion is the quickest way to add support right now. I'm currently investigating in a DB abstraction, which would be ideal for this (dotter), but it's still in the experimentation phase.

As for the UserManSettings, I'd say that a single databaseURL field would be ideal (the databaseName field could then be deprecated). This would have the advantage that the MongoDB server (or cluster) and various other parameters could also be configured. For Redis, it would look like "redis://localhost:6379/0".

@dsuppiger
Copy link
Contributor Author

The databaseURL is a good idea. So I'll do it this way then. A db abstraction layer would definitely be great although tricky with NoSQL.

@s-ludwig
Copy link
Member

Yeah, the abstraction layer will definitely have to be limited to simple operations (at least at first), so there would still be at least some DB specific code.

@dsuppiger
Copy link
Contributor Author

How would you handle the entity abstraction (User, AuthInfo, Group)? Currently they have properties with BSON types like BsonObjectID and BsonDate for easy (de)serialization which is mongodb specific. So far I came up with the following two options:

  1. Use the 'BSON classes' in an intermediate step and map them to more generic classes (with e.g. string id) to be exposed by the API?
  2. Implement UDAs to make the vibe.d BSON module treat properties with e.g. the attribute @("BsonObjectID") accordingly.

How would you go about it?

@dsuppiger
Copy link
Contributor Author

I've discovered the serialization customization methods and implemented those.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants