Update CHANGELOG
Use Database#extend_datasets instead of creating classes manually

Now extend_datasets already creates a class manually, so this
isn't really a performance optimization unless the user manually
uses extend_datasets.  However, it does allow the deletion of
quite a bit of boilerplate code.
Change primary key optimization to still use the dataset row_proc

Previously it assumed the dataset row_proc was the model, which is
true in most cases but not always true.  It's not true in the
single_table_inheritance plugin, for example.
Update CHANGELOG for 3.34.1
Bump version to 3.34.1
Merge commit 'b140e794222097baef458262b78c32ff0f81e5b2'
Minor cleanup for Mike's recent MSSQL commit

* Use frozen constants for optimization.
* Don't tie regular expression to end of string.
* Use gsub instead of sub to get all occurences.
* Work correctly on tinytds, since that has it's own escape code.
* Move specs to integration specs so all adapters get checked.

While here, fix surrounding specs so they actually check something.
No longer escape backslashes by default

Move the backslash escaping to MySQL, since that is apparently the
only database that needs it.
Fix more specs with missing should

One disadvantage of using RSpec is this kind of error isn't
too hard to make if you are writing specs after code.

While here, do some minor test refactoring.
Don't use auto parameterization when using cursors (Fixes #463)
Make the migrators only use transactions by default if the database supports transactional DDL

Using transactions by default doesn't harm things in most cases,
but it can in some cases.  For example, on SQLite, when emulating
alter_table on a table referenced by foreign keys, you need to
disabled foreign key use outside of a transaction.  If the
migrator runs the migration inside a transaction, it messes up
the foreign key reference to point to the backup table.

Seems like PostgreSQL, MSSQL, and Derby support transactional
schema, so this doesn't change things for those databases.

This adds the transaction method to the migration DSL, so you
can force transactions on a per migration basis for databases
that don't support transactional schema.
Add a spec guard on Oracle
Add Database#log_exception, which logs when a query raises an exception, for easier overriding (Fixes #465)
Add note about sequel_pg to the database connection documentation
Use date and timestamp formats that are multilanguage and not DATEFORMAT dependent on Microsoft SQL Server

Thanks to Tom Wardrop for bringing this to my attention, and Mike Luu
for pointing me to the the relevant documentation.
Don't assign instance variables to Java objects, for future JRuby 2.0 support (Fixes #466)

Soon to be gone are the days where you could assume everything is an
ruby object in JRuby.  In JRuby 2.0, some objects will be more equal
than others.

Sequel used to modify the connection objects to give them a
per-connection hash of native prepared statements, because that's
how Sequel works on other adapters.  However, because JRuby 2.0
will make object proxy caching opt-in, you either have to manually
set __persistent__ = true for each connection object class, or
you have to not modify that class.  Since java object proxy caching
apparently hurts performance (which is the reason they want to
make it opt-in), switch to using a single hash in the Database object,
keyed by connection (protected by a mutex for thread-safety).
Remove old line in prepared_statements rdoc
Add guard for h2 for correlated_subquery integration tests

Older versions of h2 worked correctly, but newer versions do
no longer handle the correlated subquery properly.
Fix possible thread safety issues in creating Database objects and anonymous model classes

Creating a Database object adds the instance to the Sequel::DATABASES
array, and creating an anonymous model class using Sequel::Model()
adds an entry to the Sequel::Model::ANONYMOUS_MODEL_CLASSES hash.
Older versions of JRuby (and all versions of MRI) don't have any
issues with the previous code.  MRI has a GVL, and older versions
of JRuby had enough locking so that I was never able to construct
a failing test, even in heavily threaded situations.

However, with JRuby 1.6.7, I was finally able to get a program that
would at least fail occassionally with a ConcurrencyError when
creating Sequel::Database objects with a block in a tight loop.

It's fairly easy to protect against this using a simple global mutex,
which is what this commit does.  Any code that accesses those two
mutable global data structures should use Sequel.synchronize to
protect access.

It is possible there are other similar thread-safety corner cases
in Sequel, in very difficult to hit situations.  I'll try to be
proactive in dealing with these as I discover them.
Fix typo in documentation.