tdiary 5.0.6 → 5.0.7

data/vendor/bundle/gems/sequel-5.3.0/doc/security.rdoc

@@ -0,0 +1,433 @@
+= Security Considerations with Sequel
+
+When using Sequel, there are some security areas you should be aware of:
+
+* Code Execution
+* SQL Injection
+* Denial of Service
+* Mass Assignment
+* General Parameter Handling
+
+== Code Execution
+
+The most serious security vulnerability you can have in any library is
+a code execution vulnerability.  Sequel should not be vulnerable to this,
+as it never calls eval on a string that is derived from user input.
+However, some Sequel methods used for creating methods via metaprogramming
+could conceivably be abused to do so:
+
+* Sequel::Dataset.def_sql_method
+* Sequel::JDBC.load_driver
+* Sequel::Plugins.def_dataset_methods
+* Sequel::Dataset.prepared_statements_module (private)
+* Sequel::SQL::Expression.to_s_method (private)
+
+As long as you don't call those with user input, you should not be
+vulnerable to code execution.
+
+== SQL Injection
+
+The primary security concern in SQL database libraries is SQL injection.
+Because Sequel promotes using ruby objects for SQL concepts instead
+of raw SQL, it is less likely to be vulnerable to SQL injection.
+However, because Sequel still makes it easy to use raw SQL, misuse of the
+library can result in SQL injection in your application.
+
+There are basically two kinds of possible SQL injections in Sequel:
+
+* SQL code injections
+* SQL identifier injections
+
+=== SQL Code Injections
+
+==== Full SQL Strings
+
+Some Sequel methods are designed to execute raw SQL strings, including:
+
+* Sequel::Database#execute
+* Sequel::Database#execute_ddl
+* Sequel::Database#execute_dui
+* Sequel::Database#execute_insert
+* Sequel::Database#run
+* Sequel::Database#<<
+* Sequel::Dataset#fetch_rows
+* Sequel::Dataset#with_sql_all
+* Sequel::Dataset#with_sql_delete
+* Sequel::Dataset#with_sql_each
+* Sequel::Dataset#with_sql_first
+* Sequel::Dataset#with_sql_insert
+* Sequel::Dataset#with_sql_single_value
+* Sequel::Dataset#with_sql_update
+
+Here are some examples of use:
+
+  DB.execute 'SQL'
+  DB.execute_ddl 'SQL'
+  DB.execute_dui 'SQL'
+  DB.execute_insert 'SQL'
+  DB.run 'SQL'
+  DB << 'SQL'
+  DB.fetch_rows('SQL'){|row| }
+  DB.dataset.with_sql_all('SQL')
+  DB.dataset.with_sql_delete('SQL')
+  DB.dataset.with_sql_each('SQL'){|row| }
+  DB.dataset.with_sql_first('SQL')
+  DB.dataset.with_sql_insert('SQL')
+  DB.dataset.with_sql_single_value('SQL')
+  DB.dataset.with_sql_update('SQL')
+
+If you pass a string to these methods that is derived from user input, you open
+yourself up to SQL injection.  These methods are not designed to work at all
+with user input.  If you must call them with user input, you should escape the
+user input manually via Sequel::Database#literal. Example:
+
+  DB.run "SOME SQL #{DB.literal(params[:user].to_s)}"
+
+==== Full SQL Strings, With Possible Placeholders
+
+Other Sequel methods are designed to support execution of raw SQL strings that may contain placeholders:
+
+* Sequel::Database#[]
+* Sequel::Database#fetch
+* Sequel::Dataset#with_sql
+
+Here are some examples of use:
+
+  DB['SQL'].all
+  DB.fetch('SQL').all
+  DB.dataset.with_sql('SQL').all
+
+With these methods you should use placeholders, in which case Sequel automatically escapes the input:
+
+  DB['SELECT * FROM foo WHERE bar = ?', params[:user].to_s]
+
+==== Manually Created Literal Strings
+
+Sequel generally treats ruby strings as SQL strings (escaping them correctly), and
+not as raw SQL.  However, you can convert a ruby string to a literal string, and
+Sequel will then treat it as raw SQL.  This is typically done through
+Sequel.lit[rdoc-ref:Sequel::SQL::Builders#lit].
+
+  Sequel.lit('a')
+
+Using Sequel.lit[rdoc-ref:Sequel::SQL::Builders#lit] to turn a ruby string into a literal string results
+in SQL injection if the string is derived from user input.  With both of these
+methods, the strings can contain placeholders, which you can use to safely include
+user input inside a literal string:
+
+  Sequel.lit('a = ?', params[:user_id].to_s)
+
+Even though they have similar names, note that Sequel::Database#literal operates very differently from
+String#lit or Sequel.lit[rdoc-ref:Sequel::SQL::Builders#lit].
+Sequel::Database#literal is for taking any supported object,
+and getting an SQL representation of that object, while
+String#lit or Sequel.lit[rdoc-ref:Sequel::SQL::Builders#lit] are for treating
+a ruby string as raw SQL.  For example:
+
+  DB.literal(Date.today) # "'2013-03-22'"
+  DB.literal('a') # "'a'"
+  DB.literal(Sequel.lit('a')) # "a"
+  DB.literal(:a => 'a') # "(\"a\" = 'a')"
+  DB.literal(:a => Sequel.lit('a')) # "(\"a\" = a)"
+
+==== SQL Filter Fragments
+
+Starting in Sequel 5, Sequel does not automatically convert plain strings to
+literal strings in typical code.  Instead, you can use Sequel.lit to
+create literal strings:
+
+  Sequel.lit("name > 'A'")
+
+To safely include user input as part of an SQL filter fragment, use Sequel.lit
+with placeholders:
+
+  DB[:table].where(Sequel.lit("name > ?", params[:id].to_s)) # Safe
+
+Be careful to never call Sequel.lit where the first argument is derived from
+user input.
+
+There are a few uncommon cases where Sequel will still convert
+plain strings to literal strings.
+
+==== SQL Fragment passed to Dataset#lock_style and Model#lock!
+
+The Sequel::Dataset#lock_style and Sequel::Model#lock! methods also treat
+an input string as SQL code. These methods should not be called with user input.
+
+  DB[:table].lock_style(params[:id]) # SQL injection!
+  Album.first.lock!(params[:id]) # SQL injection!
+
+==== SQL Type Names
+
+In general, most places where Sequel needs to use an SQL type that should
+be specified by the user, it allows you to use a ruby string, and that
+string is used verbatim as the SQL type.  You should not use user input
+for type strings.
+
+  DB[:table].select(Sequel.cast(:a, params[:id])) # SQL injection!
+
+==== SQL Function Names
+
+In most cases, Sequel does not quote SQL function names.  You should not use
+user input for function names.
+
+  DB[:table].select(Sequel.function(params[:id])) # SQL injection!
+
+==== auto_literal_strings extension
+
+If the auto_literal_strings extension is used for backwards compatibility,
+then Sequel will treat plain strings as literal strings if they are used
+as the first argument to a filtering method.  This can lead to SQL
+injection:
+
+  DB[:table].where("name > #{params[:id].to_s}")
+  # SQL injection when using auto_literal_strings extension
+
+If you are using the auto_literal_strings extension, you need to be very careful,
+as the following methods will treat a plain string given as the first argument
+as a literal string:
+
+* Sequel::Dataset#where
+* Sequel::Dataset#having
+* Sequel::Dataset#filter
+* Sequel::Dataset#exclude
+* Sequel::Dataset#exclude_having
+* Sequel::Dataset#or
+* Sequel::Dataset#first
+* Sequel::Dataset#last
+* Sequel::Dataset#[]
+
+Even stuff that looks like it may be safe isn't:
+
+  DB[:table].first(params[:num_rows])
+  # SQL injection when using auto_literal_strings extension
+
+The Model.find[rdoc-ref:Sequel::Model::ClassMethods#find] and
+Model.find_or_create[rdoc-ref:Sequel::Model::ClassMethods#find_or_create]
+class methods will also treat string arguments as literal strings if the
+auto_literal_strings extension is used:
+
+  Album.find(params[:id])
+  # SQL injection when using auto_literal_strings extension
+
+Similar to the filter methods, the auto_literal_strings extension
+also makes Sequel::Dataset#update treats a string argument as raw SQL:
+
+  DB[:table].update("column = 1")
+
+So you should not do:
+
+  DB[:table].update(params[:changes])
+  # SQL injection when using auto_literal_strings extension
+
+or:
+
+  DB[:table].update("column = #{params[:value].to_s}")
+  # SQL injection when using auto_literal_strings extension
+
+Instead, you should do:
+
+  DB[:table].update(:column => params[:value].to_s) # Safe
+
+Because using the auto_literal_strings extension makes SQL injection
+so much eaiser, it is recommended to not use it, and instead
+use Sequel.lit with placeholders.
+ 
+=== SQL Identifier Injections
+
+Usually, Sequel treats ruby symbols as SQL identifiers, and ruby
+strings as SQL strings.  However, there are some parts of Sequel
+that treat ruby strings as SQL identifiers if an SQL string would
+not make sense in the same context.
+
+For example, Sequel::Database#from and Sequel::Dataset#from will treat a string as
+a table name:
+
+  DB.from('t') # SELECT * FROM "t"
+
+Another place where Sequel treats ruby strings as identifiers are
+the Sequel::Dataset#insert and Sequel::Dataset#update methods:
+
+  DB[:t].update('b'=>1) # UPDATE "t" SET "b" = 1
+  DB[:t].insert('b'=>1) # INSERT INTO "t" ("b") VALUES (1)
+
+Note how the identifier is still quoted in these cases.  Sequel quotes identifiers by default
+on most databases.  However, it does not quote identifiers by default on DB2.
+On those databases using an identifier derived from user input can lead to SQL injection.
+Similarly, if you turn off identifier quoting manually on other databases, you open yourself
+up to SQL injection if you use identifiers derived from user input.
+
+When Sequel quotes identifiers, using an identifier derived from user input does not lead to
+SQL injection, since the identifiers are also escaped when quoting.
+Exceptions to this are Oracle (can't escape <tt>"</tt>) and Microsoft Access
+(can't escape <tt>]</tt>).
+
+In general, even if doesn't lead to SQL Injection, you should avoid using identifiers
+derived from user input unless absolutely necessary.
+
+Sequel also allows you to create identifiers using
+Sequel.identifier[rdoc-ref:Sequel::SQL::Builders#identifier] for plain identifiers,
+Sequel.qualify[rdoc-ref:Sequel::SQL::Builders#qualify] and
+Sequel::SQL::Indentifier#[][rdoc-ref:Sequel::SQL::QualifyingMethods#[]] for qualified identifiers, and
+Sequel.as[rdoc-ref:Sequel::SQL::Builders#as] for aliased expressions.  So if you
+pass any of those values derived from user input, you are dealing with the same scenario.
+
+Note that the issues with SQL identifiers do not just apply to places where
+strings are used as identifiers, they also apply to all places where Sequel
+uses symbols as identifiers.  However, if you are creating symbols from user input,
+you at least have a denial of service vulnerability in ruby <2.2, and possibly a
+more serious vulnerability.
+
+Note that many Database schema modification methods (e.g. create_table, add_column)
+also allow for SQL identifier injections, and possibly also SQL code injections.
+These methods should never be called with user input.
+
+== Denial of Service
+
+Sequel converts some strings to symbols.  Because symbols in ruby <2.2 are not
+garbage collected, if the strings that are converted to symbols are
+derived from user input, you have a denial of service vulnerability due to
+memory exhaustion.
+
+The strings that Sequel converts to symbols are generally not derived
+from user input, so Sequel in general is not vulnerable to this.  However,
+users should be aware of the cases in which Sequel creates symbols, so
+they do not introduce a vulnerability into their application.
+
+=== Column Names/Aliases
+
+Sequel returns SQL result sets as an array of hashes with symbol keys.  The
+keys are derived from the name that the database server gives the column. These
+names are generally static.  For example:
+
+  SELECT column FROM table
+
+The database will generally use "column" as the name in the result set.
+
+If you use an alias:
+
+  SELECT column AS alias FROM table
+
+The database will generally use "alias" as the name in the result set. So
+if you allow the user to control the alias name:
+
+  DB[:table].select(:column.as(params[:alias]))
+
+Then you can have a denial of service vulnerability.  In general, such a vulnerability
+is unlikely, because you are probably indexing into the returned hash(es) by name,
+and if an alias was used and you didn't expect it, your application wouldn't work.
+
+=== Database Connection Options
+
+All database connection options are converted to symbols.  For a
+connection URL, the keys are generally fixed, but the scheme is turned
+into a symbol and the query option keys are used as connection option
+keys, so they are converted to symbols as well.  For example:
+
+  postgres://host/database?option1=foo&option2=bar
+
+Will result in :postgres, :option1, and :option2 symbols being created.
+
+Certain option values are also converted to symbols.  In the general case,
+the sql_log_level option value is, but some adapters treat additional
+options similarly.
+
+This is not generally a risk unless you are allowing the user to control
+the connection URLs or are connecting to arbitrary databases at runtime.
+
+== Mass Assignment
+
+Mass assignment is the practice of passing a hash of columns and values
+to a single method, and having multiple column values for a given object set
+based on the content of the hash.
+The security issue here is that mass assignment may allow the user to
+set columns that you didn't intend to allow.
+
+The Model#set[rdoc-ref:Sequel::Model::InstanceMethods#set] and Model#update[rdoc-ref:Sequel::Model::InstanceMethods#update] methods do mass
+assignment.  The default configuration of Sequel::Model allows all model
+columns except for the primary key column(s) to be set via mass assignment.
+
+Example:
+
+  album = Album.new
+  album.set(params[:album]) # Mass Assignment
+
+Both Model.new[rdoc-ref:Sequel::Model::InstanceMethods::new] and Model.create[rdoc-ref:Sequel::Model::ClassMethods#create]
+call Model#set[rdoc-ref:Sequel::Model::InstanceMethods#set] internally, so
+they also allow mass assignment:
+
+  Album.new(params[:album]) # Mass Assignment
+  Album.create(params[:album]) # Mass Assignment
+
+When the argument is derived from user input, instead of these methods, it is encouraged to either use 
+Model#set_fields[rdoc-ref:Sequel::Model::InstanceMethods#set_fields] or
+Model#update_fields[rdoc-ref:Sequel::Model::InstanceMethods#update_fields],
+which allow you to specify which fields to allow on a per-call basis.  This
+pretty much eliminates the chance that the user will be able to set a column
+you did not intend to allow:
+
+  album.set_fields(params[:album], [:name, :copies_sold])
+  album.update_fields(params[:album], [:name, :copies_sold])
+
+These two methods iterate over the second argument (+:name+ and +:copies_sold+ in
+this example) instead of iterating over the entries in the first argument
+(<tt>params[:album]</tt> in this example).
+
+If you want to override the columns that Model#set[rdoc-ref:Sequel::Model::InstanceMethods#set]
+allows by default during mass assignment, you can use the whitelist_security plugin, then call
+the set_allowed_columns class method.
+
+  Album.plugin :whitelist_security
+  Album.set_allowed_columns(:name, :copies_sold)
+  Album.create(params[:album]) # Only name and copies_sold set
+
+Being explicit on a per-call basis using the set_fields and update_fields methods is recommended
+instead of using the whitelist_security plugin and setting a global whitelist.
+
+For more details on the mass assignment methods, see the {Mass Assignment Guide}[rdoc-ref:doc/mass_assignment.rdoc].
+
+== General Parameter Handling
+
+This issue isn't necessarily specific to Sequel, but it is a good general practice.
+If you are using values derived from user input, it is best to be explicit about
+their type.  For example:
+
+  Album.where(:id=>params[:id])
+
+is probably a bad idea.  Assuming you are using a web framework, <tt>params[:id]</tt> could
+be a string, an array, a hash, nil, or potentially something else.
+
+Assuming that +id+ is an integer field, you probably want to do:
+
+  Album.where(:id=>params[:id].to_i)
+
+If you are looking something up by name, you should try to enforce the value to be
+a string:
+
+  Album.where(:name=>params[:name].to_s)
+
+If you are trying to use an IN clause with a list of id values based on input provided
+on a web form:
+
+  Album.where(:id=>params[:ids].to_a.map(&:to_i))
+
+Basically, be as explicit as possible. While there aren't any known security issues
+in Sequel when you do:
+
+  Album.where(:id=>params[:id])
+
+It allows the attacker to choose to do any of the following queries:
+
+  id IS NULL # nil
+  id = '1' # '1'
+  id IN ('1', '2', '3') # ['1', '2', '3']
+  id = ('a' = 'b') # {'a'=>'b'}
+  id = ('a' IN ('a', 'b') AND 'c' = '') # {'a'=>['a', 'b'], 'c'=>''}
+
+While none of those allow for SQL injection, it's possible that they
+might have an issue in your application.  For example, a long array
+or deeply nested hash might cause the database to have to do a lot of
+work that could be avoided.
+
+In general, it's best to let the attacker control as little as possible,
+and explicitly specifying types helps a great deal there.

data/vendor/bundle/gems/sequel-5.3.0/doc/testing.rdoc

@@ -0,0 +1,167 @@
+= Testing with Sequel
+
+Whether or not you use Sequel in your application, you are usually going to want to have tests that ensure that your code works.  When you are using Sequel, it's helpful to integrate it into your testing framework, and it's generally best to run each test in its own transaction if possible.  That keeps all tests isolated from each other, and it's simple as it handles all of the cleanup for you.  Sequel doesn't ship with helpers for common libraries, as the exact code you need is often application-specific, but this page offers some examples that you can either use directly or build on.
+
+== Transactional tests
+
+These run each test in its own transaction, the recommended way to test.
+
+=== minitest/spec
+
+==== with minitest-hooks
+
+  require 'minitest/hooks/default'
+  class Minitest::HooksSpec
+    def around
+      Sequel::Model.db.transaction(:rollback=>:always, :auto_savepoint=>true){super}
+    end
+  end
+
+==== without minitest-hooks
+
+  class Minitest::Spec
+    def run(*args, &block)
+      Sequel::Model.db.transaction(:rollback=>:always, :auto_savepoint=>true){super}
+    end
+  end
+
+=== minitest/test
+
+  # Use this class as the base class for your tests
+  class SequelTestCase < Minitest::Test
+    def run(*args, &block)
+      Sequel::Model.db.transaction(:rollback=>:always, :auto_savepoint=>true){super}
+    end
+  end
+
+=== rspec >= 2.8
+
+  RSpec.configure do |c|
+    c.around(:each) do |example|
+      DB.transaction(:rollback=>:always, :auto_savepoint=>true){example.run}
+    end
+  end
+
+== Transactional testing with multiple databases
+
+You can use the Sequel.transaction method to run a transaction on multiple databases, rolling all of them back.  Instead of:
+
+  Sequel::Model.db.transaction(:rollback=>:always)
+
+Use Sequel.transaction with an array of databases:
+
+  Sequel.transaction([DB1, DB2, DB3], :rollback=>:always)
+
+== Transactional testing with savepoints
+
+Using minitest/spec and minitest-hooks, and assuming your database supports it, you can use
+transactions around entire test suites, using savepoints around each test.  This can sigificantly
+speed up any test suite where there is a lot of shared setup in a before all hook.  By using
+savepoints per test, each test is isolated from each other, rolling back changes after it
+completes, and by using transactions per test suite, you only pay the cost to load the data once
+for the test suite, and it is automatically rolled back after the test suite completes.
+
+Example:
+
+  require 'minitest/hooks/default'
+  class Minitest::HooksSpec
+    def around
+      Sequel::Model.db.transaction(:rollback=>:always, :savepoint=>true, :auto_savepoint=>true){super}
+    end
+
+    def around_all
+      Sequel::Model.db.transaction(:rollback=>:always){super}
+    end
+  end
+
+  describe "some large test suite" do
+    before(:all) do
+      DB[:table].import # Large number of rows
+    end
+  end
+
+== Nontransactional tests
+
+In some cases, it is not possible to use transactions.  For example, if you are testing a web application that is running in a separate process, you don't have access to that process's database connections, so you can't run your examples in transactions.  In that case, the best way to handle things is to cleanup after each test by deleting or truncating the database tables used in the test.
+
+The order in which you delete/truncate the tables is important if you are using referential integrity in your database (which you should be doing).  If you are using referential integrity, you need to make sure to delete in tables referencing other tables before the tables that are being referenced.  For example, if you have an +albums+ table with an +artist_id+ field referencing the +artists+ table, you want to delete/truncate the +albums+ table before the +artists+ table.  Note that if you have cyclic references in your database, you will probably need to write your own custom cleaning code.
+
+=== minitest/spec or rspec
+
+  describe "some test suite" do
+    after do
+      [:table1, :table2].each{|x| Sequel::Model.db.from(x).truncate}
+      # or
+      [:table1, :table2].each{|x| Sequel::Model.db.from(x).delete}
+    end
+  end
+
+=== minitest/test
+
+  class SomeTestClass < Minitest::Test
+    def teardown
+      [:table1, :table2].each{|x| Sequel::Model.db.from(x).truncate}
+      # or
+      [:table1, :table2].each{|x| Sequel::Model.db.from(x).delete}
+    end
+  end
+
+= Testing Sequel Itself
+
+Sequel has multiple separate test suites.  All test suites use minitest/spec, with the minitest-hooks and minitest-shared_description extensions.
+
+== rake
+
+The default rake task runs Sequel's core, model, plugin, and extension specs, the same as <tt>rake spec</tt> or <tt>rake spec_core spec_model spec_plugin</tt>.
+
+== rake spec_core
+
+The +spec_core+ rake task runs Sequel's core specs.  These specs use a mocked database connection, and test for specific SQL used and for generally correct behavior.
+
+== rake spec_model
+
+The +spec_model+ rake task runs Sequel's model specs.  These specs also use a mocked database connection, and operate similar to the core tests.
+
+== rake spec_plugin
+
+The +spec_plugin+ rake task runs the specs for the plugins and extensions that ship with Sequel.  These also use a mocked database connection, and operate very similarly to the general Sequel core and model specs.
+
+== rake spec_core_ext
+
+The +spec_core_ext+ rake task runs the specs for the core_extensions extension.  These are run separately from the other extension tests to make sure none of the other extensions require the core_extensions.
+
+== rake spec_bin
+
+The +spec_bin+ rake task runs the specs for bin/sequel.  These use an SQLite3 database, and require either the sqlite3 (non-JRuby) or jdbc-sqlite3 (JRuby) gem.
+
+== rake spec_<i>adapter</i> (e.g. rake spec_postgres)
+
+The <tt>spec_<i>adapter</i></tt> specs run against a real database connection with nothing mocked, and test for correct results.  They are slower than the standard specs, but they will catch errors that are mocked out by the default specs, as well as show issues that only occur on a certain database, adapter, or a combination of the two.
+
+These specs are broken down into two parts.  For each database, there are specific specs that only apply to that database, and these are called the adapter specs.  There are also shared specs that apply to all (or almost all) databases, these are called the integration specs. For database types that don't have specific adapter tests, you can use <tt>rake spec_integration</tt> to just run the shared integration tests.
+
+== Environment variables
+
+Sequel uses environment variables when testing to specify either the database to be tested or specify how testing should be done.  You can also specify the databases to test by copying <tt>spec/spec_config.rb.example</tt> to <tt>spec/spec_config.rb</tt> and modifying it.  See that file for details.  It may be necessary to use +spec_config.rb+ as opposed to an environment variable if your database connection cannot be specified by a connection string.
+
+Sequel does not create test databases automatically, except for file-based databases such as SQLite/H2/HSQLDB/Derby.  It's up to the user to create the test databases manually and give Sequel a valid connection string in an environment variable (or setup the connection object in +spec_config.rb+).
+
+=== Connection Strings
+
+The SEQUEL_INTEGRATION_URL environment variable specifies the Database connection URL to use for the adapter and integration specs.  Additionally, when running the adapter specs, you can also use the SEQUEL_<i>ADAPTER</i>_URL environment variable (e.g. SEQUEL_POSTGRES_URL for spec_postgres).
+
+=== Other
+
+SEQUEL_COLUMNS_INTROSPECTION :: Use the columns_introspection extension when running the specs
+SEQUEL_CONNECTION_VALIDATOR :: Use the connection validator extension when running the specs
+SEQUEL_DUPLICATE_COLUMNS_HANDLER :: Use the duplicate columns handler extension with value given when running the specs
+SEQUEL_ERROR_SQL :: Use the error_sql extension when running the specs
+SEQUEL_FREEZE_DATABASE :: Freeze the database before running the integration specs
+SEQUEL_IDENTIFIER_MANGLING :: Use the identifier_mangling extension when running the specs
+SEQUEL_MODEL_PREPARED_STATEMENTS :: Use the prepared_statements plugin when running the specs
+SEQUEL_NO_CACHE_ASSOCIATIONS :: Don't cache association metadata when running the specs
+SEQUEL_NO_CHECK_SQLS :: Don't check for specific SQL syntax when running the specs
+SEQUEL_CHECK_PENDING :: Try running all specs (note, can cause lockups for some adapters), and raise errors for skipped specs that don't fail
+SEQUEL_NO_PENDING :: Don't skip any specs, try running all specs (note, can cause lockups for some adapters)
+SEQUEL_SPLIT_SYMBOLS :: Turn on symbol splitting when running the adapter and integration specs
+SEQUEL_SYNCHRONIZE_SQL :: Use the synchronize_sql extension when running the specs