The least evil choice
Originally posted at 11/27/2010
A while ago I had to make a decision regarding how to approach building the multi tenancy feature for RavenDB. Leaving aside the actual multi tenancy approach, we had an issue in how to allow access to it.
We have the following options for accessing the northwind database:
- /northwind/docs - breaking change, obvious, less work
- /docs?database=northwind - non breaking change, not so obvious, more work
What choice would you take?
If you know what is the choice I made for RavenDB, please don’t answer this post.
Comments
Would take the pragmatic approach and choose /docs/northwind. This way it's still intuitive and from all the documents in the database the url states that the user is only interested in documents from a certain repository.
Disclaimer: I actually don't know any of the urls ravendb is using so this might not be possible.
The answer is obvious (it is the first one), mainly because it was posted here by Ayende to make a point.
I didn't closely followed RavenDB evolution, but, by me, the second choice may introduce querying and maintenance problems (e.g. when using the same code for 2 tenants).
Said it before, will say it again:
"Backwards compatibility will be the end of our civilization"
In that light, make your breaking change, it will be for the better.
I think the first choice is the better one in the long run and since RavenDB is still very young it's totally acceptable that it's breaking. Early adopters should be prepared for some shake downs in the API as the developers try and iron out the details and future roadmap.
I would think the first choice is the better with a default of going to the first database if one isn't specified.
This way only those people with multiple databases get the breaking changes and they'll be the ones asking the question of how to specify the database in the first place.
Can you add a debug warning message to suggest adding the database name to the url? This will guide developers to the correct design over time.
Both, so can get benefit of simpler more obvious syntax without breaking existing users. Or, if you think you can get away with it without defections, #1.
the first one!!!
Both
I would choose the first one, with the addition of a "default" database and the management of naming conflict for this default database (default db would not be allowed if it has documents which name correspond to the name of an other DB). That way, no breaking change.
Well the second option discloses more information about your system and provides a potentially greater attack surface.
First option for me is preferable and likely to be more secure.
Break it, it will be time-boxed evil, and long-term goodness. It's not as if you were in v4.0.
Both with the first option as default.
I don't know the specifics but rewriting a URL doesn't seem like it would be that much extra work.
I'd say "breaking change" as well. knowing your style for more than couple of years, it is something i believe you'd do. It is more intuitive from the end user point of view, even though it is a breaking change.
Break it, break it, break it! The first one. The second is uglier, and staying with ungly, imo wrong API would cause future problems.
Comment preview