Repository navigation
Add documentation for database transaction handling with Sequel #242
Description
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.
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
Activity
rfestag commentedon May 15, 2017
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 commentedon May 15, 2017
@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.