Skip to content


Subversion checkout URL

You can clone with
Download ZIP
Commits on Oct 3, 2011
  1. Bump version to 3.28.0

Commits on Oct 1, 2011
  1. fix SecurityError on connect with $SAFE=1

    Dmitry Borodaenko authored
    If core.rb was required without raising a SecurityError, the directory
    it was loaded from is trusted enough to untaint.
Commits on Sep 27, 2011
Commits on Sep 26, 2011
  1. Make Dataset#with_pk use a qualified primary key, so it works correct…

    …ly on joined datasets
    This also removes some error checking when you use a composite
    primary key when you should be using a simple primary key and
  2. Support the :limit association option when using eager_graph

    Currently, this only does an array slice in ruby, it doesn't add
    support for various eager limit strategies.  Supporting such
    strategies in eager graph is possible, but I'm not sure it's wise
    as it would have to apply to the entire table.
    While here, fix the one_to_one issue with multiple objects the
    same way it was fixed for eager, by picking the first matching
    record instead of the last.
  3. Make after_load association hooks apply when using eager_graph

    Historically, eager_graph ignored any after_load hooks, but now
    that it isn't difficult to support, we should probably do so.
    The :alias_association_type_map and :alias_association_name_map
    settings are being removed from the :eager_graph dataset option
    since they can both be determined by looking at the association
  4. Make Dataset#with_sql treat a symbol as a first argument as a method …

    …name to call to get the SQL
    The expected use case for this is with Dataset#returning and
       with_sql(:update_sql, :b => :b + 1).
    Basically, it makes it more easily to statically set the
    insert/update/delete SQL, and then be able to use the full
    dataset API for returning results.
  5. Make Dataset #delete, #insert, #update return array of plain hashes i…

    …f block not given and Dataset#returning is used
Commits on Sep 21, 2011
  1. Allow Dataset #map, #to_hash, #select_map, #select_order_map, and #se…

    …lect_hash to take arrays of columns instead of single columns
    If arrays are columns are given as arguments, the output will use
    an array of values for those arguments.
    This also expands the handling of various SQL::Expression
    subclasses, so most things just work.
    Additionally, this adds integration tests for the methods.

    …DELETE on Postgresql 9.1
    This is a fairly large commit that changes some of the core parts
    of Sequel.  It adds a Dataset#returning method that sets the columns
    to return, and changes Dataset #insert, #update, and #delete to
    yield the returned rows to a block if #returning is used.  The rows
    are yielded as plain hashes, as it uses #fetch_rows instead of #each.
    I may add the ability to use #each in the future, but I'll wait to
    see if anyone needs that.  To work correctly with the master/slave
    support, when #returning is used with #insert, #update, or #delete,
    the :default server is used if no server has been set.
    The only database that I know of that supports these features is
    PostgreSQL 9.1, but the changes were too invasive to make to just
    the shared postgres adapter.  Hopefully, future versions of other
    database libraries will support the syntax as well.
    The changes to the shared postgres adapter are significant.
    Dataset#insert was modified signficantly to use the new returning
    feature.  That require changes to the bound variable/prepared
    statement support in the shared postgres adapter.
    There are a few backwards incompatible changes to the PostgreSQL
    and Firebird adapters.  The previously public dataset method
    something different. The private #insert_returning_pk_sql and
    unlikely user code would be calling these methods anyway.  I haven't
    tested the Firebird support, but I will try to soon.
    Another backwards incompatible change is th Dataset::WITH_SUPPORTED
    constant has been removed.
    Dataset#supports_cte? now takes an optional type argument, which
    defaults to :select for backwards compatibility.  It can be now be
    used for checking for WITH support in INSERT/UPDATE/DELETE.
    Dataset#supports_returning? has been added.  It's type argument is
    required, and it can be used for checking whether RETURNING is
    supported in INSERT/UPDATE/DELETE.
Commits on Sep 20, 2011
  1. Add Database#copy_table for PostgreSQL COPY support when using the po…

    …stgres adapter with pg
    If you want to get CSV formatted data, this can be much faster than
    getting the results normally and formatting them in ruby.
    PostgreSQL actually has three separate COPY syntaxes, one before
    7.3, one from 7.3 to 8.4, and one starting in 9.0.  While 9.0+
    supports earlier syntaxes, I choose to support only the 9.0+
    syntax.  You can provide the COPY command as a string if you
    want to run on versions before 9.0.
    If the COPY results are not fully retrieved, the connection is
    left in an unstable state, so I choose to just raise a
    DatabaseDisconnectError in that case.  Another option would be
    to attempt to fully retrieve results, but that has more corner
  2. Add support for Sequel::Model.default_eager_limit_strategy to set the…

    … default :eager_limit_strategy for *_many associations
    No similar setting exists for one_to_one associations.  I could add one
    in the future, but since you generally only want an eager_limit_strategy
    for specific associations that aren't truly one-to-one, having a
    default that applies to all one_to_one associations may not be a good
    idea in general.
Commits on Sep 19, 2011
  1. Add support for an :eager_limit_strategy => :correlated_subquery valu…

    …e for limiting using correlated subqueries
    This will never be used by default as it can generate very slow
    queries if not used wisely.  But for databases that don't support
    window functions, this may be the best way to eagerly load limited
    Unforatunately, due to MySQL bugs, the :correlated_subquery
    strategy doesn't work on MySQL.  MySQL doesn't allow a LIMIT
    directly in an IN subselect, and when you work around that using a
    nested subquery, it appears MySQL doesn't handle the correlation
    This also doesn't work correctly on DB2, probably because DB2's
    scoping only looks in the directly enclosing scope and not all
    enclosing scopes.
    This also contains another spec for the window_function case
    in many_through_many, some spec description fixes in
    many_through_many, as well as a fix if the core extensions
    are not enabled.
  2. Work around issues with using LIMIT/OFFSET in IN subqueries on MySQL,…

    … MSSQL, and DB2
    MySQL just has a flat out bug where you can't use a LIMIT in the IN
    subquery, but you can run the query as a nested subquery without
    any problems.
    MSSQL and DB2 emulate offset support using ROW_NUMBER, which modifies
    the SELECTed columns to add the ROW_NUMBER.  This breaks use with IN
    as the subquery should only be returning a single column.  So this
    runs a nested subquery that only selects the first column.
    To DRY up some code, move emulated offset support into a separate
    module that both the shared mssql and db2 adapters include.
Commits on Sep 18, 2011
  1. Work around serious ActiveSupport bug in Time.=== that breaks literal…

    …ization of Time values
    Since it's been over two weeks without any response to my Rails pull
    request to fix this obvious bug, just modify Sequel to not use
    SQLTime.===.  This way the Sequel users who are using Rails won't
    have their apps break.
    I really hate working around bugs in other libraries, but in this
    case I think the benefit outweighs the cost.
  2. Significant changes to how the Sequel DSL handles corner cases

    The main feature added by this commit is changing the + operator
    to do string concatenation instead of addition if given a string,
    and the & and | operators to do & and | instead of AND and OR
    if given a number.
      (:x + 'a')
      # Before: (x + 'a')
      #  After: (x || 'a')
      (:x & 1)
      # Before: (x AND 1)
      #  After: (x & 1)
    Those changes are only made when Sequel doesn't have an indication
    of the SQL type.  For example:
      (:x + 1 + 'a')
      # (x + 1 + 'a')
      (:x & :y & 1)
      # (x AND y AND 1)
    This is because x + 1 should result in a numeric type, and x AND y
    should result in a boolean type.
    This removes a lot of the defense code in the DSL designed to ensure
    that you can't create types that don't make logical sense, such as
    performing AND or OR operations on numbers or strings or greater or
    less than opreations on booleans.  However, many databases allow such
    operations, and Sequel should be a tool to allow you to interact with
    the database, not an arbiter of what is allowed or not allowed.
    This could break backwards compatibility if you are doing :x + 'a'
    or :x & 1.  Anyone doing that needs to switch to :x.sql_number + 'a'
    or :x.sql_boolean & 1.
    This changes the bitwise operators to combine multiple
    expressions with the same operation, eliminating unnecessary
    This switches the metaprogramming used in the DSL to define many
    similar methods from using define_method to using module_eval,
    which should speed up such method calls by about 50% on both 1.8
    and 1.9.
    This adds sql_{boolean,number,string} methods to complex expressions,
    allowing to return a new expression with the same operator and
    arguments but with different behavior, allowing you to do things
    such as:
      (x + 1).sql_string + 'a'
      # ((x + 1) || 'a')
  3. Fix :time typecasting from Time to SQLTime for fractional seconds on …

    …ruby 1.9
    Thanks to John Anderson for pointing out this problem.
Commits on Sep 16, 2011
  1. Add documentation that makes it clear you shouldn't give an associati…

    …on the same name as a column
  2. Make Dataset#select_append check for DB2 syntax issue with SELECT *, …

    …column not being supported
    This adds Dataset#supports_select_all_and_column? for checking
    for support, which is currently only false on DB2.  If the value
    is false and no columns are selected, it automatically selects
    all columns from all FROM and JOIN tables to emulate *.  This
    cleans up the DB2 offset emulation and makes the new
    :window_function eager limit strategy work on DB2.
Commits on Sep 15, 2011
  1. More fixes to the db2 adapter

    * Make insert return autogenerated primary key
    * Fix convert_type using DBI types
    * Speed up fetch_rows
    * Remove private Dataset#hash_row
  2. Various fixes for the firebird adapter

    Even with these changes, Sequel's support on Firebird is minimal at
    best.  It seems fairly easy to get the connection into a state
    where subsequent queries fail, even with the changes I added to
    attempt to prevent this.
    I tried getting the firebird adapter to work with the standard fb
    gem instead of wishdev's fork, but I got request synchronization
    errors for most queries.
    Here's a list of changes made:
    * Add disconnect support for certain error conditions.
    * Remove the downcase_names setting, which shouldn't be needed.
    * Fetch rows as arrays instead of hashes, as the resulting hashes
      still need to be processed, and using arrays is faster.
    * Remove Database#primary_key_for_table, which shouldn't have been
    * Make Database#primary_key only accept a single argument, and fix
      it so it works correctly.  This allows insert to correctly use
      the primary key value.
    * Clear cached primary keys when dropping tables.
    * Support Database#views
    * Remove unused Dataset#hash_row method.
  3. Add support for an :eager_limit_strategy => :window_function value fo…

    …r limiting using window functions
    This works for all association types that do eager limiting.  It's
    the default type used by datasets that support window functions,
    assuming you are using :eager_limit_strategy=>true to enable the
    support (except for one_to_one on PostgreSQL, which uses
    Basically, the row_number window function is added to the query in
    a subselect, and the main query does a filter on the row number
    to remove rows outside the range of row numbers you are looking
    for.  The row_number window function uses a partition so there is
    a separate series for each of the main objects, which is how you
    can get eager loading to work correctly.
    This can be much faster than the default :ruby method for limiting
    eagerly loaded associations, if your limit is small compared to
    the number of rows actually associated.
  4. Add Dataset#row_number_column to DRY up some adapter code and for fut…

    …ure eager limit strategy use
  5. Add support for an :eager_limit_strategy => :distinct_on value for on…

    …e_to_one associations for using DISTINCT ON
    If you are using PostgreSQL with a one_to_one association that
    does not represent a true one_to_one relationship, but a
    one_to_many where many objects are associated but you are using
    :order on the association to pick the first associated one,
    this could be a major performance improvement.
  6. Add Dataset#supports_ordered_distinct_on? for checking if the dataset…

    … can use distinct on while respecting order
    Currently only PostgreSQL supports a DISTINCT ON while respecting
    ORDER.  The emulation on MySQL using GROUP BY does not respect
    the order.  In some queries, this matters, so a separate method
    is needed.
  7. Refactor eager loading of limited associations support

    This moves support into the association reflection.  Future
    strategies are going to require access to the associated
    dataset, so we can't precompute the values, we must delay calling
    to get the strategy until in the eager loader.
Something went wrong with that request. Please try again.