Commits on Jun 7, 2011
  1. Move some more specs from database_spec to schema_spec

    jeremyevans committed Jun 7, 2011
    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.
  2. Support :cascade option to #drop_column and #drop_constraint

    jeremyevans committed Jun 7, 2011
    Of the databases I looked at, only PostgreSQL supports this, but
    it is in SQL92, so I don't have a problem adding it.
  3. Support :cascade option to Database#drop_table and #drop_view for usi…

    jeremyevans committed Jun 7, 2011
    …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.
  4. Fix typo in RDoc

    jeremyevans committed Jun 7, 2011
  5. If validation error messages are LiteralStrings, don't add the column…

    jeremyevans committed Jun 7, 2011
    … name to them in Errors#full_messages
    Feature requested by Andic on the Google Group, abuse of the
    LiteralString class was my own idea.
  6. Fix bug loading plugins on 1.9 where ::ClassMethods, ::InstanceMethod…

    jeremyevans committed Jun 7, 2011
    …s, or ::DatasetMethods is defined
    Thanks to Mikhail Shirkov on the Google Group for pointing this bug
    out and suggesting the fix.
Commits on Jun 3, 2011
  1. Add Dataset#exclude_where and Dataset#exclude_having methods, so you …

    jeremyevans committed Jun 3, 2011
    …can force use of having or where clause
    This also adds the private Dataset#_filter_or_exclude method to
    reduce duplication.
  2. Allow Dataset#select_all to take table name arguments and select all …

    jeremyevans committed Jun 3, 2011
    …columns from each given table
  3. Add Dataset#select_group method, for selecting and grouping on the sa…

    jeremyevans committed Jun 3, 2011
    …me columns
    Refactor group_and_count to use select_group.
  4. Add a private Dataset#virtual_row_columns method for adding virtual c…

    jeremyevans committed Jun 3, 2011
    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.
  5. Ignore index creation errors if using create_table? with the IF NOT E…

    jeremyevans committed Jun 3, 2011
    …XISTS syntax (Fixes #362), bump version to 3.24.1
Commits on Jun 2, 2011
Commits on Jun 1, 2011
  1. Bump version to 3.24.0

    jeremyevans committed Jun 1, 2011
Commits on May 31, 2011
Commits on May 26, 2011
  1. Add prepared_statements_association plugin, for using prepared statem…

    jeremyevans committed May 26, 2011
    …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.
  2. Make unbind handle conditions in JOIN ON clauses

    jeremyevans committed May 26, 2011
    JOIN ON can be used to filter just like the WHERE clause, so it too
    should be handled and variables unbound if possible.
  3. Add _valid? private model method so that valid? can always return boo…

    jeremyevans committed May 26, 2011
    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.
  4. Treat not calling super/yielding in an around hook like a before hook…

    jeremyevans committed May 26, 2011
    … 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
    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.
  5. Don't return false inside around_validation, for easier hook writing

    jeremyevans committed May 26, 2011
    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.
Commits on May 25, 2011
  1. Add prepared_statements_safe plugin, for making prepared statement us…

    jeremyevans committed May 25, 2011
    …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
    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.
  2. Move Dataset#with_pk prepared statement use to prepared_statements_wi…

    jeremyevans committed May 25, 2011
    …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
  3. Fix bug in emulated prepared statement support not supporting nil or …

    jeremyevans committed May 25, 2011
    …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.