Permalink
Commits on Jul 1, 2010
  1. Bump the version to 3.13.0

    committed Jul 1, 2010
Commits on Jun 29, 2010
  1. Use a real instance variable for the :nulls option to OrderedExpression

    Previously, it kept all options in a hash, but that's not the best
    way to handle it.  Keep the options hash for the initialize, but
    take the :nulls option out and store it in a separate instance
    variable with it's own accessor for ease of use.
    committed Jun 29, 2010
Commits on Jun 28, 2010
Commits on Jun 26, 2010
  1. fixed a couple of typos.

    burningTyger committed Jun 26, 2010
Commits on Jun 25, 2010
  1. Minor RDoc updates

    committed Jun 25, 2010
  2. More RDoc updates to sql.rb

    committed Jun 25, 2010
  3. Make PlaceholderLiteralString a GenericExpression subclass

    This allows you to use all of the GenericExpression methods on
    placeholder literal strings, just like you can on regular
    most other expression objects.
    committed Jun 25, 2010
  4. Minor RDoc updates in sql.rb

    committed Jun 25, 2010
  5. Allow nil/NULL to be used as a CASE expression value

    Previously, you could not use nil/NULL as a case expression:
    
      {1=>2}.case(0, nil)
      # CASE WHEN 1 THEN 2 ELSE 0 END
    
    With this commit, if you provide a 2nd argument to case, the
    expression is always used, even if it is nil, so you get:
    
      # CASE NULL WHEN 1 THEN 2 ELSE 0 END
    
    This behavior makes more sense when you consider the following
    scenario:
    
      {1=>2}.case(0, team_id)
    
    If team_id is nil, you want to use NULL, because without the
    NULL expression, the result would be 2 instead of 0 (or an
    exception would be raised if the database doesn't allow integers
    to be used for booleans).
    
    Implementing this is fairly easy using a similar hack to the one
    used for Symbol#*, which allows you to recognized whether or not
    an optional was given, even if it has the same value as the
    default.
    
    This breaks backwards compatibility if you were previously
    passing nil as the 2nd argument to case and did not want to
    use an expression value.
    committed Jun 25, 2010
  6. RDoc updates in sql.rb

    committed Jun 25, 2010
  7. Support bitwise operators on more databases

    This commit expands the bitwise operator support to more databases.
    In some cases where bitwise operators are not supported directly,
    they are emulated using database functions. Specifically, the
    following adapters now support the following bitwise operators:
    
    * H2: &, |, ^, <<, >>
    * MSSQL: <<, >>
    * MySQL: ~
    
    Previously, ~ on MySQL did work, but it returned an unsigned
    integer.  It is now casted to return a signed integer, for better
    compatibility with other databases.
    
    Of the tested adapters, the only ones without full bitwise operator
    support are H2 (which doesn't support ~) and SQLite (which doesn't
    support ^).
    committed Jun 25, 2010
  8. Make PostgreSQL do bitwise xor instead of exponentiation for ^ operator

    One of Sequel's jobs is to provide an interface that maps ruby
    syntax to get the same semantics regardless of database (as much
    as possible).  Ruby's ^ operator does bitwise xor, but PostgreSQL's
    ^ operator does exponentiation.  This commit makes Sequel use the
    PostgreSQL bitwise xor operator (#) on PostgreSQL, so that you will
    get similar results as on other databases.
    
    This breaks backwards compatibility for people currently using the
    ^ operator on PostgreSQL.  In the meantime, you can probably switch
    to using the power function.
    committed Jun 25, 2010
  9. Minor RDoc updates

    committed Jun 25, 2010
Commits on Jun 24, 2010
  1. Fix handling of tinyint(1) columns when connecting to MySQL via JDBC

    I didn't think JDBC handled MySQL tinyint(1) columns as booleans,
    but apparently it does.  Thanks to viking for the heads up.
    committed Jun 24, 2010
  2. Handle arrays of two element arrays as filter hash values automatically

    Previously, Sequel's behavior of arrays of two element arrays
    as hash values was suboptimal (some would say broken).
    Because the values were an array, an IN operator was used,
    but because arrays of two element arrays are considered
    condition specifiers, the argument was converted to a
    boolean condition:
    
      DB[:a].filter([:a, :b]=>[[1, 2], [3, 4]])
      # SELECT * FROM a WHERE ((a, b) IN ((1 = 2) AND (3 = 4)))
    
    This changes the behavior so that you now get the SQL you
    expect:
    
      SELECT * FROM a WHERE ((a, b) IN ((1, 2), (3, 4)))
    
    Previously, you had to call sql_array (which was added in
    Sequel 2.7.0) on the array to get the correct SQL, but that
    is no longer necessary when the array is a filter hash
    value.  However, it is still necessary to use a method that
    wraps the array to two element arrays if you are going to
    use it as a placeholder value:
    
      DB[:a].filter('(a, b) IN ?', [[1, 2], [3, 4]])
    
    This is because Sequel doesn't have the context to know that
    the array of two element arrays is being used as a an IN
    predicate (as Sequel does not parse SQL).
    
    This actually started when I decided that SQLArray was a
    bad name for the class, since arrays in standard SQL (starting
    with SQL99) are very different that what SQLArray actually
    represented, which was an IN predicate value list.  To that
    end, SQLArray has been renamed to ValueList, though SQLArray
    still exists as an alias.  Likewise Array#sql_value_list has
    been added, though Array#sql_array still exists as an alias
    to it.  However, in most cases, the methods are no longer
    necessary, and Sequel internally no longer uses ValueList,
    as the only time it wants to deal with arrays of two element
    arrays as value lists, it uses them as hash values, which
    Sequel can now handle automatically.
    
    Another main difference is that ValueList now inherits from
    ::Array, not from Expression.  This simplified some code, and
    since you can't really perform any operations on an SQL value
    list by itself (until it is used as part of an IN expression),
    there's no reason it needs to be an Expression subclass.
    
    While here, fix a minor bug in Expression#inspect.
    committed Jun 24, 2010
  3. Minor RDoc updates

    committed Jun 24, 2010
  4. Minor doc updates

    committed Jun 24, 2010
Commits on Jun 23, 2010
  1. Minor updates to the README

    committed Jun 23, 2010
  2. Allow :frame option for windows to take a string that is used literally

    Previously, the :frame option could just be nil, :all, or :rows.
    Those three options covered all cases possible in PostgreSQL 8.4+,
    but the SQL standard (and PostgreSQL 9.0) supports many more
    possibilities.  In the future, it's possible that better DSL support
    will be added, but in the meantime using a string allows you full
    control over the window's frame.
    committed Jun 23, 2010
Commits on Jun 22, 2010
  1. Support transaction isolation levels on PostgreSQL, MySQL, and MSSQL

    Transaction isolation levels are a way to specify how visible
    outside changes are to a running transaction.  Sequel previously
    did not have the ability to specify which transaction isolation
    level to use, which means the database's default was always used.
    
    This commit adds support for an :isolation option to
    Database#transaction, which will modify the isolation level to
    use for the transaction.  It also adds a
    transaction_isolation_level Database attr_accessor, which specifies
    the default transaction isolation level if one is not given via
    the :isolation option.  On MSSQL, it's recommended that if you
    ever use the :isolation option, you also set the
    transaction_isolation_level attribute, as MSSQL transaction
    isolation levels are per connection, not transaction.
    
    The four transaction isolation levels supported by PostgreSQL,
    MySQL, and MSSQL are :uncommitted, :committed, :repeatable,
    and :serializable, for READ UNCOMMITTED, READ COMMITTED,
    REPEATABLE READ, and SERIALIZABLE.
    
    I looked into support for Oracle, Firebird, SQLite, and H2,
    but while all of them have similar options, I don't test on
    Oracle or Firebird, and SQLite and H2 transaction isolation
    level support is substantially different from the SQL
    standard to support using a separate API (which may be added if
    requested).
    committed Jun 22, 2010
  2. Support prepared transactions/two-phase commit on PostgreSQL, MySQL, …

    …and H2
    
    This commit enables you to use prepared transactions using the
    :prepare option to Database#transaction.  The :prepare option
    value should be some transaction id string, which is used
    in the SQL query when preparing a transaction.  On PostgreSQL
    and MySQL, it is literalized as an SQL string, while on H2,
    it is used literally.
    
    Setting up a prepared transaction is fairly easy:
    
      DB.transaction(:prepare=>'some_transaction_id_string') do
        ...
      end
    
    One a prepared transaction has been set up, it can be commited
    using commit_prepared_transaction:
    
      DB.commit_prepared_transaction('some_transaction_id_string')
    
    or rolled back with rollback_prepared_transaction:
    
      DB.rollback_prepared_transaction('some_transaction_id_string')
    
    Note that if the transaction block itself rolls back the
    transaction (by raising an exception), neither
    commit_prepared_transaction or rollback_prepared_transaction
    will work.
    
    In order to support prepared transactions, the Database private
    instance methods _transaction, begin_transaction,
    commit_transaction, and rollback_transaction all take an optional
    options hash.  External adapters, even if they don't support
    prepared transactions, must add an optional options hash to their
    implementation of these methods or they will probably break.
    This commit modifies all built-in adapters have already to support
    this new API.
    
    This commit also modifies the H2 JDBC subadapter to support
    savepoints.
    committed Jun 22, 2010
Commits on Jun 21, 2010
  1. Allow NULLS FIRST/LAST when ordering using the :nulls=>:first/:last o…

    …ption to asc and desc
    
    NULLS FIRST/LAST is an SQL:2003 extension supported by PostgreSQL
    8.3+, Firebird 1.5+, Oracle, and probably some other databases
    as well.  As you might expect, NULLS FIRST makes NULL values show
    up before other values, and NULLS LAST makes NULL values show up
    after other values.
    
    In Sequel, this feature is exposed via the new :nulls option to
    asc and desc:
    
      ds.filter(:release_date.desc(:nulls=>:first),
                :name.asc(:nulls=>:last))
    
    Sequel can correctly invert orders even when the :nulls option is
    used, switching ASC NULLS FIRST to DESC NULLS LAST, for example.
    committed Jun 21, 2010
  2. On PostgreSQL, if no :schema option is provided for #tables, #table_e…

    …xists?, or #schema, assume all schemas except the default non-public ones (Fixes #305)
    
    This changes Sequel's behavior on PostgreSQL for the Database
    methods #tables, #table_exists?, or #schema to assume any/all
    schemas except the default non-public ones (pg_catalog, pg_toast,
    pg_temp_1, pg_toast_temp_1, and information_schema).  Before,
    didn't assume any particular schema, which led to bad results if
    you used a table name that was the same as a table name in the
    information schema.
    committed Jun 21, 2010