This accessor allows setting a default transaction mode for new transactions, making it easier to write and maintain database-independent code. DB#transaction(:mode => ...) overrides the default transaction mode of the database handle. Additionally, there is now additional validation to prevent invalid transaction modes from being used.
SQLite supports IMMEDIATE and EXCLUSIVE transactions which prevents SQLITE_BUSY errors at the expense of concurrent performance. DEFERRED transactions remain the default, but may be explicitly specified in case this default behavior changes. ref: http://search.cpan.org/dist/DBD-SQLite/lib/DBD/SQLite.pm#Transaction_and_Database_Locking ref: https://www.sqlite.org/lang_transaction.html
Historically, Sequel's connection pool has been completely decoupled from the database. The database originally just provided a connection proc to the pool, which the pool called to get a connection. The default connection proc just called connect on the database object. When I added disconnection handling to the connection pool, I had to hack it in in an ugly manner, passing the disconnection proc option via the opts hash. I'm planning on further improvements that will require more interaction between the database and connection pool, and adding another hash entry for a proc is not a good idea. Since AFAIK no one uses custom connection and disconnection procs for the connection pool, change things so that the connection pool gets a reference to the database object that creates it, and just call the connect and disconnect_connection methods directly on the database. As the disconnect_connection method was not defined by default, define it as a public method, and modify the adapters to make it a public method.
An earlier commit added this module just to PGArray, this expands it to other pg_* extension objects.
Before, the touch plugin would try to update a joined dataset for many_*_many associations. Now, if it detects a joined dataset, it just iterates over the associated object and updates them individually. This changes touched_associations class method to return a hash keyed by association name symbols instead of dataset method symbols.
This fixes non-determinism issues in two places. This fixes foreign_key_list to handle composite foreign keys in the correct column order, which could result in incorrect behavior. foreign_key_list should always give the :columns entry in the order of declared foreign key columns, and that didn't always happen. This also fixes determinism in the spec. Since a hash is used internally, on ruby 1.8, results can come in any order, so the spec should sort before comparison.
…ow aliasing PGArrays without having to use Sequel.as()
… mysql, and mysql2 adapters (Fixes #560)
Sequel has never had consistent treatment of clob fields. Unlike blob fields, there is no special Sequel type for clobs, and historically, they were treated like blobs in most places, though a few adapters treated them like strings. This changes it so that clobs are treated as strings. We return clob values as strings, not SQL::Blob instances, and have the model typecasting code cast clob column values to string instead of blob. This breaks backwards compatibility on some jdbc subadapters, since clob values will now be returned as strings instead of blobs. However, as Sequel::SQL::Blob subclasses String, it is unlikely that this will cause any issues. The only case I can think off where this will cause an issue is if the database requires clob columns to be literalized as blobs instead of strings.
Due to issues with CUBRID itself and the cubrid ruby gem, I haven't bothered to add spec guards for all of the integration spec failures. If the situation improves I will probably do so.
The jdbc/cubrid adapter currently uses the JDBC implementation, but this should work on all adapters that access CUBRID.
CUBRID uses the STRING type.
CUBRID uses case insensitive identifiers, so it doesn't make sense to have an input/output method. While here, do some reorganization and add some RDoc.
…JRuby Note that this doesn't currently have integration spec guards when running the integration tests on CUBRID. This is due to the excessive number of bugs in CUBRID itself. Once CUBRID fixes these bugs, I'll consider adding the spec guards.
Only the jdbc/mysql adapter used this feature, so just move the generated keys handling into the jdbc/mysql adapter. Break out some code into smaller methods for easier overriding. Make sure to pass the prepared statement object to last_insert_id when inserting. In mysql/jdbc, use return generated keys for prepared statement inserts as well as regular inserts.
Just in case the database default is a non-String value, we should return the value as-is instead of breaking later when using a regexp for parsing.
This makes them treated similarly to blobs, which are returned as instances of Sequel::SQL::Blob (a String subclass).
Previously, attempting to use String :text=>true in a migration failed on these databases, since it uses the text type by default, and these databases don't support that type.
The underlying hash used by the delegate class must use a default proc for the symbol=>string conversion, so add _dump/_load methods that store the underlying data as an array instead of a hash.