Skip to content
Commits on Jun 7, 2011
  1. @jeremyevans

    Move some more specs from database_spec to schema_spec

    jeremyevans committed
    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. @jeremyevans

    Support :cascade option to #drop_column and #drop_constraint

    jeremyevans committed
    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. @jeremyevans

    Support :cascade option to Database#drop_table and #drop_view for usi…

    jeremyevans committed
    …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. @jeremyevans
  5. @jeremyevans
  6. @jeremyevans
  7. @jeremyevans

    Fix typo in RDoc

    jeremyevans committed
  8. @jeremyevans

    If validation error messages are LiteralStrings, don't add the column…

    jeremyevans committed
    … name to them in Errors#full_messages
    Feature requested by Andic on the Google Group, abuse of the
    LiteralString class was my own idea.
  9. @jeremyevans

    Fix bug loading plugins on 1.9 where ::ClassMethods, ::InstanceMethod…

    jeremyevans committed
    …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. @jeremyevans
  2. @jeremyevans

    Add Dataset#exclude_where and Dataset#exclude_having methods, so you …

    jeremyevans committed
    …can force use of having or where clause
    This also adds the private Dataset#_filter_or_exclude method to
    reduce duplication.
  3. @jeremyevans
  4. @jeremyevans
  5. @jeremyevans

    Allow Dataset#select_all to take table name arguments and select all …

    jeremyevans committed
    …columns from each given table
  6. @jeremyevans

    Add Dataset#select_group method, for selecting and grouping on the sa…

    jeremyevans committed
    …me columns
    Refactor group_and_count to use select_group.
  7. @jeremyevans

    Add a private Dataset#virtual_row_columns method for adding virtual c…

    jeremyevans committed
    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.
  8. @jeremyevans
  9. @jeremyevans
  10. @jeremyevans

    Ignore index creation errors if using create_table? with the IF NOT E…

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

    Bump version to 3.24.0

    jeremyevans committed
Commits on May 31, 2011
  1. @jeremyevans
Commits on May 26, 2011
  1. @jeremyevans

    Add prepared_statements_association plugin, for using prepared statem…

    jeremyevans committed
    …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. @jeremyevans

    Make unbind handle conditions in JOIN ON clauses

    jeremyevans committed
    JOIN ON can be used to filter just like the WHERE clause, so it too
    should be handled and variables unbound if possible.
  3. @jeremyevans
  4. @jeremyevans
  5. @jeremyevans
  6. @jeremyevans
  7. @jeremyevans

    Add _valid? private model method so that valid? can always return boo…

    jeremyevans committed
    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.
  8. @jeremyevans

    Treat not calling super/yielding in an around hook like a before hook…

    jeremyevans committed
    … 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.
  9. @jeremyevans

    Don't return false inside around_validation, for easier hook writing

    jeremyevans committed
    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. @jeremyevans

    Add prepared_statements_safe plugin, for making prepared statement us…

    jeremyevans committed
    …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. @jeremyevans

    Move Dataset#with_pk prepared statement use to prepared_statements_wi…

    jeremyevans committed
    …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. @jeremyevans
  4. @jeremyevans

    Fix bug in emulated prepared statement support not supporting nil or …

    jeremyevans committed
    …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.
Something went wrong with that request. Please try again.