Connection

A connection is one of the key parts when working with databases. It represents the runway through which statements travel from our application to the database.

In Crystal we have two ways of building this connection. And so, coming up next, we are going to present examples with some advice on when to use each one.

DB module

Give me a place to stand, and I shall move the earth.
Archimedes

The DB module, is our place to stand when working with databases in Crystal. As written in the documentation: is a unified interface for database access.

One of the methods implemented in this module is DB#connect. Using this method is the first way for creating a connection. Let's see how to use it.

DB#connect

When using DB#connect we are indeed opening a connection to the database. The uri passed as the argument is used by the module to determine which driver to use (for example: mysql://, postgres://, sqlite://, etc.) i.e. we do not need to specify which database we are using.

The uri for this example is mysql://root:root@localhost/test, and so the module will use the mysql driver to connect to the MySQL database.

Here is the example:

require "mysql"

cnn = DB.connect("mysql://root:root@localhost/test")
puts typeof(cnn) # => DB::Connection
cnn.close

It's worth mentioning that the method returns a DB::Connection object. Although more specifically, it returns a MySql::Connection object, it doesn't matter because all types of connections should be polymorphic. So hereinafter we will work with a DB::Connection instance, helping us to abstract from specific issues of each database engine.

When creating a connection manually (as we are doing here) we are responsible for managing this resource, and so we must close the connection when we are done using it. Regarding the latter, this little details can be the cause of huge bugs! Crystal, being a language for humans, give us a more safe way of manually creating a connection using blocks, like this:

require "mysql"

DB.connect "mysql://root:root@localhost/test" do |cnn|
  puts typeof(cnn) # => DB::Connection
end # the connection will be closed here

Ok, now we have a connection, let's use it!

require "mysql"

DB.connect "mysql://root:root@localhost/test" do |cnn|
  puts typeof(cnn)                         # => DB::Connection
  puts "Connection closed: #{cnn.closed?}" # => false

  result = cnn.exec("drop table if exists contacts")
  puts result

  result = cnn.exec("create table contacts (name varchar(30), age int)")
  puts result

  cnn.transaction do |tx|
    cnn2 = tx.connection
    puts "Yep, it is the same connection! #{cnn == cnn2}"

    cnn2.exec("insert into contacts values ('Joe', 42)")
    cnn2.exec("insert into contacts values (?, ?)", "Sarah", 43)
  end

  cnn.query_each "select * from contacts" do |rs|
    puts "name: #{rs.read}, age: #{rs.read}"
  end
end

First, in this example, we are using a transaction (check the transactions section for more information on this topic) Second, it's important to notice that the connection given by the transaction is the same connection that we were working with, before the transaction begin. That is, there is only one connection at all times in our program. And last, we are using the method #exec and #query. You may read more about executing queries in the database section.

Now that we have a good idea about creating a connection, let's present the second way for creating one: DB#open

DB#open

require "mysql"

db = DB.open("mysql://root:root@localhost/test")
puts typeof(db) # DB::Database
db.close

As with a connection, we should close the database once we don't need it anymore. Or instead, we could use a block and let Crystal close the database for us!

But, where is the connection? Well, we should be asking for the connections. When a database is created, a pool of connections is created with connections to the database prepared and ready to use! (Do you want to read more about pool of connections? In the connection pool section you may read all about this interesting topic!)

How do we use a connection from the database object? For this, we could ask the database for a connection using the method Database#checkout. But, doing this will require to explicitly return the connection to the pool using Connection#release. Here is an example:

require "mysql"

DB.open "mysql://root:root@localhost/test" do |db|
  cnn = db.checkout
  puts typeof(cnn)

  puts "Connection closed: #{cnn.closed?}" # => false
  cnn.release
  puts "Connection closed: #{cnn.closed?}" # => false
end

And we want a safe way (i.e. no need for us to release the connection) to request and use a connection from the database, we could use Database#using_connection:

require "mysql"

DB.open "mysql://root:root@localhost/test" do |db|
  db.using_connection do |cnn|
    puts typeof(cnn)
    # use cnn
  end
end

In the next example we will let the database object to manage the connections by itself, like this:

require "mysql"

DB.open "mysql://root:root@localhost/test" do |db|
  db.exec("drop table if exists contacts")
  db.exec("create table contacts (name varchar(30), age int)")

  db.transaction do |tx|
    cnn = tx.connection
    cnn.exec("insert into contacts values ('Joe', 42)")
    cnn.exec("insert into contacts values (?, ?)", "Sarah", 43)
  end

  db.query_each "select * from contacts" do |rs|
    puts "name: #{rs.read}, age: #{rs.read}"
  end
end

As we may notice, the database is polymorphic with a connection object with regard to the #exec / #query / #transaction methods. The database is responsible for the use of the connections. Great!

When to use one or the other?

Given the examples, it may come to our attention that the number of connections is relevant. If we are programming a short living application with only one user starting requests to the database then a single connection managed by us (i.e. a DB::Connection object) should be enough (think of a command line application that receives parameters, then starts a request to the database and finally displays the result to the user) On the other hand, if we are building a system with many concurrent users and with heavy database access, then we should use a DB::Database object; which by using a connection pool will have a number of connections already prepared and ready to use (no bootstrap/initialization-time penalizations). Or imagine that you are building a long-living application (like a background job) then a connection pool will free you from the responsibility of monitoring the state of the connection: is it alive or does it need to reconnect?