Skip to content
This repository has been archived by the owner on Jan 28, 2021. It is now read-only.

Allow many different DocumentTypes to be saved in the same collection #607

Open
krist00fer opened this issue Nov 24, 2017 · 5 comments
Open
Assignees

Comments

@krist00fer
Copy link
Contributor

Allow many different DocumentTypes to be saved in the same collection in order to save money for low usage. For example, all documents could have a mandatory property called DocumentType that is always include in the queries.

@krist00fer krist00fer self-assigned this Nov 24, 2017
@PoisonousJohn
Copy link

Could you please elaborate more on the issue?

@krist00fer
Copy link
Contributor Author

Sure thing,

Since Azure DocumentDB charges you per collection, smaller game studios (hobbyists or others that are conscious about spending money) might think that it's a waste of money to put every type of document in a new "collection". Another way to keep the different document types apart would be to add a property to each type of document and then use that document type whenever we save or retrieve documents from a collection.

So adding the Property DocumentType to each saved document would allow us to use a single (or configurable) amount of collections. By default we could use one single collection called "Nether" and put everything in there unless otherwise configured. This would make sure we have the most cheap solution for smaller studios, while still allowing bigger studios to do otherwise.

In order to do this we need to make adjustments to all documents as well as all queries we do.

@PoisonousJohn
Copy link

Got it, thank you. Would be great to have it for sure.

@dgkanatsios
Copy link
Collaborator

An article showing how it's done on CosmosDB with Mongo API https://anthonychu.ca/post/cosmos-db-mongoose-discriminators/

@krist00fer
Copy link
Contributor Author

Thanks @dgkanatsios :-) this is exactly what we are doing, but we are not using Mongoose at the moment, so we are adding the "discriminatorKey" manually. One idea would be to refer to that property as just a "discriminatorKey", just in order to keep the similarities if anyone looks at the code that are more used to Mongoose. I'm currently working on this and will tweak my implementation to be even more inline with this.

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

No branches or pull requests

3 participants