Add documentation for database transaction handling with Sequel

[bethesque]

I'm currently using Rack/Webmachine/Sequel together. Sequel will only allow you to create transactions with a block - there is no API to start and end a transaction manually. This doesn't play nicely with the way a Webmachine resource is "executed" via multiple separate methods, so the best way I've found to handle database transactions is to create some rack middleware that wraps around the entire call to Webmachine. I'd like to add an example of this to the documentation, but I thought I'd just check to see if anyone had a better/another way before I do this.

@seancribbs @lgierth @Asmod4n

module Rack
  module Middleware
    class DatabaseTransaction

      REQUEST_METHOD = "REQUEST_METHOD".freeze
      GET = "GET".freeze
      HEAD = "HEAD".freeze

      def initialize app, database_connection
        @app = app
        @database_connection = database_connection
      end

      def call env
        if env[REQUEST_METHOD] != GET && env[REQUEST_METHOD] != HEAD
          call_with_transaction env
        else
          call_without_transaction env
        end
      end

      def call_without_transaction env
        @app.call(env)
      end

      def call_with_transaction env
        response = nil
        @database_connection.transaction do
          response = @app.call(env)
          raise Sequel::Rollback if response.first == 500
        end
        response
      end
    end
  end
end

[rfestag]

I guess I don't really see why resource execution across multiple callbacks is an issue with transactions. Even of you are trying to execute the transaction across multiple callbacks, you could simply set memoized variables to access later on, and perform the entire transaction in a single callback. That seems to be more like how Webmachine resources are usually written, and is portable across all adapters.

I don't normally use transactions, so I may well be missing something. Just my $0.02.

[bethesque]

@rfestag I understand that you could do the entire thing in one method early in the FSM, but to me, this reduces the benefit of having small, single purpose methods. It takes you back from exposing "facts" about your resource to executing one big block of procedural code again.

It also means you don't get that "pre validation" you get from having all the early content type/method/validation methods done and dusted before you actually get to parsing the content and interacting with the database.