Support collections

[sebastienros]

Be able to shard content items in different Document tables, a.k.a collections.

Create a DocumentTableStrategy class that can provide the table name for a class. It could a single table, one per class, one per hierarchy, or a specific classes in the same tables.
When loading documents, the type needs to be defined to be able to select which table to query.

[jersiovic]

What do you think on a more generic approach preparing YesSQL field for a future evolution where YesSQL coordinates a distributed system of dbs where sharding logic goes beyond the type of the document to store documents in one location or other based on data within the document like other NoSQL systems do.

Asking the user for the type to find out the collection when he wants to execute a query IMO limits the future support of other sharding strategies not based on the type.
So, instead of hiding the fact we need to know the collection where we are going to look for the document, I would ask for the collection instead of the type. Or at least I would offer both options:

• No collection or type is defined, session.QueryAsync(): with a param it can be decided if it will make the query to look for results in default collection or in every collection.
• Collections are defined session.QueryAsync("PersonCollectionSpain","PersonCollectionFrance"): query limited to the provided collections.
• Define the type but not the collection session.QueryAsync<Person>(): The collection query will look for content with those types in all the collections or in the default collection depending on a parameter.
• Define the collection and the type: session.QueryAsync("PersonCollectionSpain","PersonCollectionFrance")()

[jersiovic]

Initially this will neither have any performance penalty on Orchard 2 nor any change on its code. Cause YesSql by default will use default collection. For the case of OpenIdTokens we will specify explicitly the "OpenIdToken" collection.

[jersiovic]

Creation of an index also will need we provide the collection where it has to be created, isn't it? Maybe index tables need a prefix with the collection to avoid duplicated names of an index used in two different collections.

[sebastienros]

So far I intend to support collections by prefixing all tables with its name. So a query will have to provide a collection name. Querying won't be supported cross-collections unless you create your own SQL queries to do unions. We would be able to add support for cross-collections queries at a later time.

I will also provide an option to move a document from one collection to the other. And some extensibility to configure how to find the collection for a document, for instance to define that Token documents always go to tokens collection.

[sebastienros]

Because collections will contain indexes, documents and content tables, we should be able to use different connection strings for each collection. Also it should be pretty straightforward to have a class and its indexes in a separate collection by default.