…e oracle adapter
Unfortunately, ruby-OCI8 doesn't know what to do with nil values if you don't specify a type, so add in type specifying support similar to the postgres adapter, using a __* suffix for the placeholder. This also catches RuntimeErrors raised when running queries. ruby-oci8 raises strings, so these should be reraised as DatabaseErrors.
:always will always rollback, :reraise will reraise any Sequel::Rollback exceptions raised by the block.
…dapter Sequel will load the jdbc-derby gem automatically for this adapter, but the gem version is currently for Derby 10.6, which lacks support for booleans and truncate. The latest release of Derby is 10.8, which supports both, so I'd recommend using the .jar file until the gem is updated. I'll only be testing with the 10.8 .jar file.
This was thankfully fairly easy, as HSQLDB sticks very close to the SQL standard. There are a few things that HSQLDB supports that Sequel does not enable, such as savepoints (HSQLDB seems not to respect transaction statements in SQL, only the java methods on the connection object, and Sequel doesn't support savepoints using java methods in the jdbc transaction support), but almost everything works (only 2 pending specs). Note that this will not work with the jdbc-hsqldb gem, as that uses 18.104.22.168, and the HSQLDB documentation for 22.214.171.124 plain lies and I don't feel like supporting it (I'll accept patches that don't break 2.2.5). You'll need to require the 2.2.5 hsqldb.jar file manually to use this jdbc subadapter, like you do with the jdbc subadapters that don't have gems, at least until the jdbc-hsqldb gem is updated. There are a couple of minor spec changes (other than guards) that fix specs on HSQLDB. These changes were made as they don't affect the purposes of the specs, and the previous code was causing failures on HSQLDB.
…e for limiting using correlated subqueries This will never be used by default as it can generate very slow queries if not used wisely. But for databases that don't support window functions, this may be the best way to eagerly load limited associations. Unforatunately, due to MySQL bugs, the :correlated_subquery strategy doesn't work on MySQL. MySQL doesn't allow a LIMIT directly in an IN subselect, and when you work around that using a nested subquery, it appears MySQL doesn't handle the correlation properly. This also doesn't work correctly on DB2, probably because DB2's scoping only looks in the directly enclosing scope and not all enclosing scopes. This also contains another spec for the window_function case in many_through_many, some spec description fixes in many_through_many, as well as a fix if the core extensions are not enabled.
…r limiting using window functions This works for all association types that do eager limiting. It's the default type used by datasets that support window functions, assuming you are using :eager_limit_strategy=>true to enable the support (except for one_to_one on PostgreSQL, which uses :distinct_on). Basically, the row_number window function is added to the query in a subselect, and the main query does a filter on the row number to remove rows outside the range of row numbers you are looking for. The row_number window function uses a partition so there is a separate series for each of the main objects, which is how you can get eager loading to work correctly. This can be much faster than the default :ruby method for limiting eagerly loaded associations, if your limit is small compared to the number of rows actually associated.
…e_to_one associations for using DISTINCT ON If you are using PostgreSQL with a one_to_one association that does not represent a true one_to_one relationship, but a one_to_many where many objects are associated but you are using :order on the association to pick the first associated one, this could be a major performance improvement.
…apter methods do
The dataset part is mostly borrowed from the sqlite support. The database part is based on code in the ActiveRecord SQL Server adapter (thanks metaskills).
…he mysql2 adapter The mysql and mysql2 adapters are very similar, so this extracts the existing support from the mysql adapter into a shared adapter that both the mysql and mysql2 adapter can use. mysql2 doesn't appear to support stored procedures that return results, but it does support other types of prepared statements. I think this could be fixed by setting flags when connecting, but I'm not sure that Mysql2 supports the same flags that Mysql does (it has CLIENT_PS_MULTI_RESULTS but not CLIENT_MULTI_RESULTS).
This removes the copying of the :host option to the :dataserver option when using the tinytds adapter. That worked fine for previous versions of tiny_tds, but no longer works with 0.4.5. This breaks backwards compatibility with previous connection urls where the freetds.conf name was specified as the :host. To use an entry in the freetds.conf file, you must now provide the :dataserver option. Unfortunately, tinytds 0.4.5 does not work with FreeTDS 0.91rc1, you have to use FreeTDS 0.91rc2 or an older version of FreeTDS such as 0.82 (and older versions require the use of the freetds.conf file). Since 0.4.5 is now required, switch to using active? instead of closed? and dead? to detect disconnects.