# ANN: Sequel 2.6.0 Released **URL:** \ **Category:** Ruby\ **Created:** [October 12, 2008, 3:30am UTC](https://www.ruby-forum.com/t/ann-sequel-2-6-0-released/150726 "2008-10-12T03:30:05Z")\ **Posts on this page:** 4\ **Page:** 1
**Author:** ![nerdmaster](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/n/c68b51/32.png) [@nerdmaster](https://www.ruby-forum.com/u/nerdmaster)\ **Post date:** [October 12, 2008, 3:30am UTC](https://www.ruby-forum.com/t/ann-sequel-2-6-0-released/150726/1 "2008-10-12T03:30:05Z")
- Sequel provides thread safety, connection pooling and a concise DSL for constructing database queries and table schemas. - Sequel also includes a lightweight but comprehensive ORM layer for mapping records to Ruby objects and handling associated records. - Sequel supports advanced database features such as prepared statements, bound variables, master/slave configurations, and database sharding. - Sequel makes it easy to deal with multiple records without having to break your teeth on SQL. - Sequel currently has adapters for ADO, DB2, DBI, Informix, JDBC, MySQL, ODBC, OpenBase, Oracle, PostgreSQL and SQLite3. Sequel 2.6.0 has been released and should be available on the gem mirrors. The 2.6.0 release adds numerous minor features and improvements: ## New Features - Schema parsing was refactored, resulting in a huge speedup when using MySQL. MySQL now uses the DESCRIBE statement instead of the INFORMATION\_SCHEMA. PostgreSQL now uses the pg\_\* system catalogs instead of the INFORMATION schema. - The schema information now includes the :primary\_key field. Models now use this field to automatically determine the primary key for a table, so it no longer needs to be specified explicitly. Models even handle the composite primary key case. - The raise\_on\_typecast\_failure switch was added, with it being true by default (so no change in behavior). This allows the user to silently ignore errors when typecasting fails, at the global, class, and instance levels. - Associations’ orders are now respected when eager loading via eager\_graph. Sequel will qualify the columns in the order with the alias being used, so you can have overlapping columns when eager loading multiple associations. - The support for CASE expressions has been enhanced by allowing the use of an optional expression: - You can now change the NULL/NOT NULL value of an existing column using the set\_column\_allow\_null method. - You can now get the schema information for a table in a non-public schema in PostgreSQL using the implicit :schema\_\_table syntax. Before, the :schema option had to be given explicitly to Database#schema. This allows models to get schema information for tables outside the public schema. - Transactions are now supported on MSSQL. - Dataset#tables now returns all tables in the database for MySQL databases accessed via JDBC. - Database#drop\_view can now drop multiple views at once. ## Other Improvements - The SQLite adapter now respects the Sequel.datetime\_class option for timestamp and datetime columns. - Adding a unique constraint no longer explicity creates a unique index. If you want a unique index, use index :unique=\>true. - If no language is specified when creating a full text index on PostgreSQL, the simple language is assumed. - Errors when typecasting fails are now Sequel::Error::InvalidValue instead of the more generic Sequel::Error. - Specifying constraints now works correctly for all types of arguments. Previously, it did not work unless a block or interpolated string were used. - Loading an association with the same name as a table in the FROM clause no longer causes an error. - When eagerly loading many\_to\_one associations where no objects have an associated object, the negative lookup is now cached. - String keys can now be used with Dataset#multi\_insert, just like they can be used for Dataset#insert. - Dataset#join\_table now generates the correct SQL when doing the first join to a dataset where the first source is a dataset, when an unqualified column is used in the conditions. - Cascading associations after \*\_to\_many associations can now be eagerly loaded via eager\_graph. - Eagerly loading \*\_to\_many associations that are cascaded behind a many\_to\_one association now have their duplicates removed if a cartesian product join is done. - The SQLite adapter now uses string literals in all of the AS clauses. While the SQL standard specifies that identifiers should be used, SQLite documentation explicitly states that string literals are expected (though it generally works with identifiers by converting them implicitly). - Database methods that modify the schema now remove the cached schema entry. - The hash keys that Database#schema returns when no table is requested are now always supposed to be symbols. - The generation of SQL for composite foreign keys on MySQL has been fixed. - A schema.rdoc file was added to the documentation explaining the various parts of Sequel related to schema generation and modification and how they interact ([http://sequel.rubyforge.org/rdoc/files/doc/schema\_rdoc.html](http://sequel.rubyforge.org/rdoc/files/doc/schema_rdoc.html)). - The RDoc template for the website was changed from the default template to the hanna template. ## Backwards Compatibility - The :numeric\_precision and :max\_chars schema entries have been removed. Use the :db\_type entry to determine this information, if available. - The SQLite adapter used to always return Time instances for timestamp types, even if Sequel.datetime\_class was DateTime. For datetime types it always returned a DateTime instance. It now returns an instance of Sequel.datetime\_class in both cases. - It’s possible that the including of associations’ orders when eager loading via eager\_graph could cause problems. You can use the :order\_eager\_graph=\>false option to not use the :order option when eager loading via :eager\_graph. - There were small changes in SQL creation where the AS keyword is now used explicitly. These should have no effect, but could break tests for explicit SQL. If you have any questions, please post on the Google Group. Thanks, Jeremy - {Website}[[http://sequel.rubyforge.org](http://sequel.rubyforge.org)] - {Source code}[[GitHub - jeremyevans/sequel: Sequel: The Database Toolkit for Ruby](http://github.com/jeremyevans/sequel)] - {Bug tracking}[[Google Code Archive - Long-term storage for Google Code Project Hosting.](http://code.google.com/p/ruby-sequel/issues/list)] - {Google group}[[http://groups.google.com/group/sequel-talk](http://groups.google.com/group/sequel-talk)] - {RDoc}[[http://sequel.rubyforge.org/rdoc](http://sequel.rubyforge.org/rdoc)] ---
**Author:** ![nerdmaster](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/n/c68b51/32.png) [@nerdmaster](https://www.ruby-forum.com/u/nerdmaster)\ **Post date:** [October 12, 2008, 3:46am UTC](https://www.ruby-forum.com/t/ann-sequel-2-6-0-released/150726/2 "2008-10-12T03:46:42Z")
On Sun, Oct 12, 2008 at 10:27:35AM +0900, Jeremy E. wrote: > - Schema parsing was refactored, resulting in a huge speedup when > using MySQL. MySQL now uses the DESCRIBE statement instead of the > INFORMATION\_SCHEMA. PostgreSQL now uses the pg\_\* system catalogs > instead of the INFORMATION schema. I’m curious: given the huge speed improvement using their native metadata tables, does this mean that INFORMATION\_SCHEMA support (which is the standard way to access this type of information across database engines) is poorly implemented in MySQL/PostgreSQL? Or is INFORMATION\_SCHEMA itself poorly designed? ---
**Author:** ![nerdmaster](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/n/c68b51/32.png) [@nerdmaster](https://www.ruby-forum.com/u/nerdmaster)\ **Post date:** [October 14, 2008, 5:42pm UTC](https://www.ruby-forum.com/t/ann-sequel-2-6-0-released/150726/3 "2008-10-14T17:42:52Z")
Jos B. wrote: > On Sun, Oct 12, 2008 at 10:27:35AM +0900, Jeremy E. wrote: > > > - Schema parsing was refactored, resulting in a huge speedup when > > using MySQL. MySQL now uses the DESCRIBE statement instead of the > > INFORMATION\_SCHEMA. PostgreSQL now uses the pg\_\* system catalogs > > instead of the INFORMATION schema. > > I’m curious: given the huge speed improvement using their native > metadata > tables, does this mean that INFORMATION\_SCHEMA support (which is the > standard > way to access this type of information across database engines) is > poorly > implemented in MySQL/PostgreSQL? Or is INFORMATION\_SCHEMA itself poorly > designed? In MySQL’s case, it probably isn’t implemented well (surprise, surprise). I think the INFORMATION\_SCHEMA is implemented fine on PostgreSQL, since there isn’t a noticeable speed difference. The reason we switched to the pg\_\* system catalogs on PostgreSQL was to get the primary key information, not for speed related reasons. It’s possible that the primary key information is available somewhere in the INFORMATION\_SCHEMA, it was just easier to switch to the pg\_\* system catalogs than do the necessary research. Jeremy ---
**Author:** ![nerdmaster](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/n/c68b51/32.png) [@nerdmaster](https://www.ruby-forum.com/u/nerdmaster)\ **Post date:** [October 16, 2008, 1:58am UTC](https://www.ruby-forum.com/t/ann-sequel-2-6-0-released/150726/4 "2008-10-16T01:58:49Z")
On Wed, Oct 15, 2008 at 12:42:49AM +0900, Jeremy E. wrote: > In MySQL’s case, it probably isn’t implemented well (surprise, > surprise). I think the INFORMATION\_SCHEMA is implemented fine on > PostgreSQL, since there isn’t a noticeable speed difference. This confirms my suspicions. Thanks for sharing, Jeremy.