Add a spec for Database#drop_column with :cascade. Also, move some classes to spec_helper. Inline classes in multithousand line spec files are not a good thing.
Of the databases I looked at, only PostgreSQL supports this, but it is in SQL92, so I don't have a problem adding it.
…ng CASCADE This makes drop_table and drop_view accept an options hash as the final argument. Currently they only support the :cascade=>true option for turning on CASCADE. No longer use CASCADE unilaterally when dropping tables on PostgreSQL. This breaks backwards compatibility, but is in my mind the sanest choice. CASCADE is a dangerous option, and using it implicitly is a bad idea. The usage of CASCADE by default dates back to the original import of Sequel code into the subversion repository on February 28, 2007. This adds the private drop_view_sql method, and makes drop_table_sql take two arguments. This also moves some schema related specs to the schema_spec file.
… name to them in Errors#full_messages Feature requested by Andic on the Google Group, abuse of the LiteralString class was my own idea.
…s, or ::DatasetMethods is defined Thanks to Mikhail Shirkov on the Google Group for pointing this bug out and suggesting the fix.
…can force use of having or where clause This also adds the private Dataset#_filter_or_exclude method to reduce duplication.
…columns from each given table
…me columns Refactor group_and_count to use select_group.
…olumns This changes how columns are added by using Array#concat to extend the existing array instead of Array#+ to create a new array. However, as all methods that call it use *columns to get the columns, there is no risk of modifying a passed in argument.
…XISTS syntax (Fixes #362), bump version to 3.24.1
…ents by default for regular association loading This is similar to the prepared_statements_with_pk plugin, as it also uses Dataset#unbind, but it should be more safe as it skips using a prepared statement completely if it detects that there are association options that it does not handle.
…lean valid? should always return a boolean even if a validation hook fails. However, when save validates, a HookFailure exception should be raised instead. The _valid? method takes a parameter for whether to raise or return false for hook failures. It's no longer safe to override valid?, which I was doing in a few specs. You should only be overriding validate to add errors.
… returning false Because around hooks can now raise exceptions similar to before hooks, rename the exception to HookFailed, but still assign it to the BeforeHookFailed constant as well for backwards compatibility. With this change and the previous one, around hooks are now very similar to ActiveSupport ones in terms of behavior, though they use instance methods instead of blocks.
Use checked_save_failure and raise_hook_failure so that validation failures are handled just like other save failures. Also, try to return intelligent things for super calls inside around hooks. For validation this returns true/false depending on the whether the object has errors. For all other around hooks, just return true since there isn't any other useful information.
…e with models more safe This new plugin doesn't use prepared statements at all, but it's designed to be used with (and requires) the prepared_statements plugin. The basic security issue with using prepared statements implicitly with Sequel is that Sequel by default only uses uses the currently present columns when insert (some subset of the table's columns), and by default when updating only saves the changed columns. For prepared statements to be used, each set of columns in the insert and update statements needs to have its own prepared statement. If you have a table with 1 primary key column and 4 other columns, you can have up to 2^4 = 16 prepared statements created, one for each subset of the 4 columns. If you have 1 primary key column and 20 other columns, there are over a million subsets, and you would assuredly hit your database limit for prepared statements (a denial of service attack). The fix for this is to use every column possible when inserting and updating. For updating, this is simple, as you just save all columns. For inserting, this isn't always possible, as you can't necessarily insert a correct default value, as it could depend on a database function. So for NULL defaults and defaults that Sequel can parse, Sequel will add those columns to the insert statement.
…th_pk plugin This functionality now uses Dataset#unbind to create a more generic dataset, which lowers the risk of an unbounded number of prepared statements being create, but it does not eliminate the risk. This plugin should only be used by those who are sure that their usage of Dataset#with_pk cannot result in a denial of service attack.
…false as bound values A separate prepared_arg? method has been added to see if argument used is actually in the bound variables. The argument mappers used for native bound variable support always return true for this method.