RethinkDB Connection
Database connections are generally defined at either the application or request instance levels. The C# RethinkDB driver is designed for the former, and configuring it as a singleton is the recommended implementation. We will do that for our application. In the process of ensuring that we can properly configure this instance, we will also have to address the concepts of configuration and dependency injection (or, in the case of our Freya implementation, its replacement). You can review the all the code at the checkpoint for step 3.
A Bit about RethinkDB
RethinkDB is a document database, and the C# implementation allows us to represent our documents as Plain Old CLR
Objects (AKA POCOs). It uses JSON.Net to serialize POCOs into JSON documents, which are then stored by the server.
It exposes collections of documents as "databases" and "tables" within each database, mirroring its relational database
cousins. However, there are no schemas for tables, and a table can have documents of varying formats. Each table can
have one or more indexes that can be used to retrieve documents without scanning the entire table. It provides its own
query language (ReQL) that utilizes a fluent interface, where queries begin with an R. or r. and end in a Run*
statement.
It has other features, such as server clustering and change feeds, but these will not be part of our project (although change feeds could be an interesting Step n-2 project for post comments). We will use a single instance of RethinkDB, and a single database within it, for all our data.
All Implementations
Each of our implementations will allow for the following user-configurable options:
Hostname- The hostname for the server; defaults to "localhost"Port- The port to use to connect to the server; defaults to 28015Database- The default database to use for queries that do not specify a database; defaults to "test"AuthKey- The authorization key to provide for the connection; defaults to "" (empty)Timeout- How long to wait when connecting; defaults to 20
Additionally, we will write start-up code that ensures our requisite tables exist, and that each of these tables has the appropriate indexes. To hold our documents, we will create the following tables:
- Category
- Comment
- Page
- Post
- User
- WebLog
We will be able to retrieve individual documents by Id without any further definition. Additionally, we will create indexes to support the following scenarios:
- Category retrieval by web log Id (used to generate lists of available categories)
- Category retrieval by web log Id and slug (used to retrieve details for category archive pages)
- Comment retrieval by post Id (used to retrieve comments for a post)
- Page retrieval by web log Id (used to retrieve a list of pages)
- Page retrieval by permalink (used to fulfill single page requests)
- Post retrieval by web log Id (used many places)
- Post retrieval by category Id (used to get posts for category archive pages)
- Post retrieval by tag (used to get posts for tag archive pages)
- User retrieval by e-mail address and password (used for log in)
Individual Implementations
Each of these not only evolves from step 2 to step 3, they also evolve as Uno moves to Quatro. It may help understanding to read each of them, even if your interest is just in one of them.
Uno - In Depth
Dos - In Depth
Tres - In Depth
Quatro - In Depth
