Quino Data Driver architecture, Part I: Applications & Sessions

One part of Quino that has undergone quite a few changes in the last few versions is the data driver. The data driver is responsible for CRUD: create, read, update and delete operations. One part of this is the ORM—the object-relational mapper—that marshals data to and from relational databases like PostgreSql, SQL Server and SQLite.

We’re going to cover a few topics in this series:

1. Applications & Sessions
2. The Data Pipeline
3. Builders & Commands
4. Contexts and Connections
5. Sessions, resources & objects

But first let’s take a look at an example to anchor our investigation.

Introduction

An application makes a request to the data driver using commands like Save() to save data and GetObject() or GetList() to get data. How are these high-level commands executed? Quino does an excellent job of shielding applications from the details but it’s still very interesting to know how this is achieved.

The following code snippet creates retrieves some data, deletes part of it and saves a new version.

using (var session = application.CreateSession())
{
  var people = session.GetList<Person>();
  people.Query.WhereEquals(Person.Fields.FirstName, "john");
  session.Delete(people);
  session.Save(new Person { FirstName = "bob", LastName = "doe" });
}

In this series, we’re going to answer the following questions…and probably many more.

• Where does the data come from?
• What kind of sources are supported? How?
• Is at least some of the data cached?
• Can I influence the cache?
• What is a session? Why do I need one?
• Wait…what is the application?

Let’s tackle the last two questions first.

Application

The application defines common configuration information. The most important bits for the ORM are as follows:

• Model: The model is the central part of any Quino application. The model defines entities, their properties, relationships between entities and so on. Looking at the example above, the model will include a definition for a Person, which has at least the two properties LastName and FirstName. There is probably an entity named Company as well, with a one-to-many relationship to Person. As you can imagine, Quino uses this information to formulate requests to data stores that contain data in this format.[1] For drivers that support it, Quino also uses this information in order to create that underlying data schema.[2]
• DataProvider: The data provider encapsulates all of the logic and components needed to map the model to data sources. This is the part of the process on which this series will concentrate.
• ConfigurationData: The configuration data describes which parts of the model are connected to which parts of the data provider. The default is, of course, that the entire model is mapped to a single data source. However, even in that case, the configuration indicates which data source: Sql Server? PostgreSql? A remote application server (2nd tier)? With a high-level API as described above, all of these decisions can be made in the configuration rather than assumed throughout the application. Yes, this means that you can change your Quino application from a two-tier to a three-tier application with a single configuration change.

Sessions

So that’s the application. There is a single shared application for a process.

But in any non-trivial application—and any non-desktop application—we will have multiple data requests running, possibly in different threads of execution.

• Each request in a web application is a separate data context. Changes made in one request should not affect any other request. Each request may be authenticated as a different user.
• A remote application-server is very similar to a web application. It handles requests from multiple users. Since it’s generally the second layer, it will most likely have direct connections to one or more databases. In this case, it will probably be in charge of executing business logic, most likely in a database transaction. In that case, we definitely don’t want one request using the transaction context from another request.
• Even a non-web client-side application may want to execute some logic in the background or in a separate thread. In those cases, we probably want to keep the data used there separate from the data or objects used to render the other parts of the application.

That’s where sessions come in. The session encapsulates a data context, which contains the following information:

• Application: The application will, as described above, tell the session which model and data provider to use.
• Current user: For those familiar with ASP.NET, this is very similar to the HttpContext.Current.User but generalized to be available in any Quino application. All data requests over a session are made in the context of this user.
• Access control: The access control provides information about the security context of an application. An application generally uses the access control to perform authorization checks.
• Cache: Each session also has its own cache. There are global caches, but those are for immutable data. The session’s cache is always available, even when using transactions.
• ConnectionManager: Many external data sources have transactable/shared state in the form of a connection. As with data, connections can sometimes be shared between sessions and sometimes they can’t. The connection manager takes care of knowing all of that for you.

If we go back to the original code sample, we now know that creating a new session with CreateSession() creates a new data context, with its own user and its own data cache. Since we didn’t pass in any credentials, the session uses the default credentials for the application.[3] All data access made on that session is nicely shielded and protected from any data access made in other sessions (where necessary, of course).

So now we’re no closer to knowing how Quino works with data on our behalf, but we’ve taken the first step: we know all about one of the main inputs to the data driver, the session.

In the next part, we’ll cover the topic “The Data Pipeline”.

var requestCredentials = requestSession.AccessControl.CurrentUser.CreateCredentials();
using (var session = application.CreateSession(requestCredentials))
{
  // Work with session
}