1. 14 Nov, 2014 6 commits
  2. 13 Nov, 2014 3 commits
  3. 12 Nov, 2014 14 commits
  4. 11 Nov, 2014 9 commits
  5. 09 Nov, 2014 1 commit
  6. 05 Nov, 2014 1 commit
  7. 04 Nov, 2014 1 commit
  8. 18 Oct, 2014 4 commits
    • Merge pull request #356 from mapbox/upgrade-internal-sqlite3 · 4d6e3627
      upgrade internal sqlite3 to 3.8.7
      Mithgol authored
    • Merge pull request #355 from glasser/run-undefined · 146ff9f8
      Better behavior from statement.run(undefined)
      Dane Springmeyer authored
    • Better behavior from statement.run(undefined) · 9d287d82
      Let's say you prepare a statement with no parameters, and .run() it to
      completion. Now the 'status' field on the Statement is SQLITE_DONE.
      
      Now let's say that you run it, accidentally calling
        statement.run(undefined, callback)
      instead of leaving out the first argument or passing an empty array.
      
      The Baton returned by Bind<RunBaton> will have a parameters array with a
      single NULL.
      
      Then Work_Run will invoke stmt->Bind with this one-element array, while
      stmt->status is still SQLITE_DONE.
      
      Before this patch, the for loop in stmt->Bind would execute once, not
      calling any bind functions, but still execute the
      "stmt->status != SQLITE_OK" check. Since status is SQLITE_DONE, this
      will cause the stmt->Bind to return false and for Work_Run to skip the
      actual call to sqlite3_step.
      
      However, since stmt->status is *still* SQLITE_DONE, Work_AfterRun will
      report success.
      
      It is arguably a bug to pass undefined in this case anyway, but the
      current behavior where run() reports success without actually executing
      the method is confusing.  (Especially when things work as expected on
      the FIRST call to run(), because the initial status value is SQLITE_OK.)
      David Glasser authored
  9. 29 Sep, 2014 1 commit