Skip to content


Subversion checkout URL

You can clone with
Download ZIP
Commits on Jun 30, 2015
  1. @sgrif

    Correct through associations using scopes

    sgrif authored
    The changes introduced to through associations in c80487e were quite
    interesting. Changing `relation.merge!(scope)` to `relation =
    relation.merge(scope)` should in theory never cause any changes in
    behavior. The subtle breakage led to a surprising conclusion.
    The old code wasn't doing anything! Since `merge!` calls
    `instance_exec` when given a proc, and most scopes will look something
    like `has_many :foos, -> { where(foo: :bar) }`, if we're not capturing
    the return value, it's a no-op. However, removing the `merge` causes
    `unscope` to break.
    While we're merging in the rest of the chain elsewhere, we were never
    merging in `unscope` values, causing a breakage on associations where a
    default scope was being unscoped in an association scope (yuk!). This is
    subtly related to #20722, since it appears we were previously relying on
    this mutability.
    Fixes #20721.
    Fixes #20727.
  2. @senny
  3. @senny

    `dump_schema_after_migration` applies migration tasks other than db:m…

    senny authored
    Closes #20743.
    The task `db:_dump` now only dumps the schema if
    `ActiveRecord::Base.dump_schema_after_migration` is true. This has
    - `db:migrate:up`
    - `db:migrate:down`
    - `db:forward`
    - `db:rollback`
Commits on Jun 29, 2015
  1. @senny

    docs, nodoc `NullPreloader` and `AlreadyLoaded`.

    senny authored
    These classes are part of Active Record Preloader, which is not part of
    the public API.
Commits on Jun 28, 2015
  1. @sgrif

    Revert the behavior of association names and `where` to be closer to 4.2

    sgrif authored
    With this change, we will always assume the association name is the same
    as the table it's referencing. This is subtly different than treating
    the hash key passed to `where` as the table name, as it still allows the
    class referenced by the association to provide additional type
    After exploring several possible solutions to the ambiguity problem, I
    do not think there is a short term answer that will maintain backwards
    This change will make it so the following code does not work:
        class User
          has_many :approved_posts, -> { where(approved: true) }, class_name: "Post"
        User.where(approved_posts: { id: 1 })
    But prevents potential ambiguity and collision as demonstrated in [this
    Unfortunately, truely solving this requires significantly
    re-architecting this code, so that what is currently represented as an
    `Arel::Attribute` is instead another data structure that also references
    the association it is representing, so we can identify the proper table
    name for aliasing when we construct the final tree.
    While I'd still like to accomplish that in the long run, I don't think
    I'll be able to get there in time for Rails 5 (since I'm not full time
    OSS any more, and this is several weeks worth of work). I'm hoping to
    achieve this for Rails 5.1.
    Fixes #20308
Commits on Jun 27, 2015
  1. @rafaelfranca

    Merge pull request #20607 from cmtonkinson/update-console-colors

    rafaelfranca authored
    More granular console SQL coloration
  2. @rafaelfranca

    Merge pull request #20699 from vngrs/foreign_key_with_table_name_suff…

    rafaelfranca authored
    Add table name prefix and suffix support for foreign keys
  3. @rafaelfranca

    Merge pull request #20018 from sikachu/change-column-default-recorder

    rafaelfranca authored
    Add reversible syntax for change_column_default
Commits on Jun 26, 2015
  1. @sikachu

    Update .pluck documentation on uniq

    sikachu authored
    This is to show users that they can chain `.uniq` and `.pluck` to get
    the `DISTINCT column` result. They don't have to do `DISTINCT column`
  2. @sikachu

    Add reversible syntax for change_column_default

    sikachu authored
    Passing `:from` and `:to` to `change_column_default` makes this command
    reversible as user has defined its previous state.
    So, instead of having the migration command as:
        change_column_default(:posts, :state, "draft")
    They can write it as:
        change_column_default(:posts, :state, from: nil, to: "draft")
Commits on Jun 25, 2015
  1. @meinac

    Add table name prefix and suffix support to add_foreign_key and remov…

    meinac authored
    …e_foreign_key methods
    fix tests
Commits on Jun 23, 2015
  1. @jmondo
  2. @cmtonkinson

    More granular console SQL coloration

    cmtonkinson authored
    This new coloration approach makes it easier to scan the rails console
    for specific types of activity with more fine-grained visual cues.
    Virtual terminal ANSI color escape codes are used when displaying SQL
    statements in the rails console. The former implementation alternates
    line prefix information (including the statement name and execution
    latency) between CYAN and MAGENTA. This visually differentiates any SQL
    statements in the log and is useful for quickly scanning for database
    While a great idea and a solid foundation, alternating between just two
    colors on an even/odd basis (much like striping an HTML table) can be
    improved upon.
    This patch replaces the even/odd striping with a more comprehensive
    scheme that applies coloration based on the type of statement being
    run. Every statement logged has its prefix (name and latency) colored
    white (as the statement body was previously). The statement body is now
    colored according to the nature of the statement:
      - INSERT statements are GREEN (symbolic of creation or genesis)
      - SELECT statements are BLUE (typically used for informational
        displays, as SELECT statements do not normally have side-effects)
      - DELETE statements are RED (commonly used to indicate the danger of
        a destructive action)
      - UPDATE statements are YELLOW (it's like a less extreme RED :P)
      - TRANSACTION statements are CYAN (arbitrary)
      - and any other statements are MAGENTA (again, arbitrary)
  3. @robin850
  4. @senny

    Merge pull request #20673 from aditya-kapoor/correct-preload-doc

    senny authored
    [ci skip] correct for ActiveRecord::Associations::Preloader
  5. @senny
  6. @aditya-kapoor
  7. @senny

    Merge pull request #20552 from jamesdabbs/belongs-to-polymorphic-forc…

    senny authored
    Fix `undefined method uncached` for polymorphic belongs_to #20426
Commits on Jun 22, 2015
  1. @dcrec1

    thrown ActiveRecord::AssociationTypeMismatch when assigning a wrong v…

    dcrec1 authored
    …alue for a namespaced association
    fixes #20541
  2. @senny

    refactor, don't duplicate presence validator logic.

    senny authored
    This is a small refactoring that simplifies the Active Record specific
    lenght validator.
  3. @senny
  4. @senny

    AR absence validator respects `marked_for_destruction?`. Closes #20449.

    senny authored
    Associated objects that were marked for destruction are considered absent.
Commits on Jun 19, 2015
  1. @sgrif

    Include `Enumerable` in `ActiveRecord::Relation`

    sgrif authored
    After discussing, we've decided it makes more sense to include it. We're
    already forwarding every conflicting method to `to_a`, and there's no
    conflation of concerns. `Enumerable` has no mutating methods, and it
    just allows us to simplify the code. No existing methods will have a
    change in behavior. Un-overridden Enumerable methods will simply
    delegate to `each`.
    [Sean Griffin & bogdan]
  2. @sgrif

    Use `Enumerable#sum` on `ActiveRecord::Relation` when a block is given

    sgrif authored
    This matches our behavior in other cases where useful enumerable methods
    might have a different definition in `Relation`. Wanting to actually
    enumerate over the records in this case is completely reasonable, and
    wanting `.sum` is reasonable for the same reason it is on `Enumerable`
    in the first place.
  3. @senny

    Merge pull request #20259 from rastasheep/rastasheep-patch-1

    senny authored
    Update documentation for ActiveRecord::Migration#remove_index
  4. @senny

    Merge pull request #19843 from marshall-lee/explain_cte_queries

    senny authored
    Let WITH (CTE) queries be explainable
Commits on Jun 18, 2015
  1. @rafaelfranca
Commits on Jun 16, 2015
  1. @meinac

    Fix descriptions of databases.rake [ci skip]

    meinac authored
    revert create and drop task descriptions
  2. @dcrec1

    raise ActiveModel::MissingAttributeError when trying to access a rela…

    dcrec1 authored
    …tionship without the foreign key attribute
    fixes regression reported on #20253
    ActiveRecord::Base#[] was not used cause of 8b95420
Commits on Jun 15, 2015
  1. @arthurnn

    Small refactor on db:reset

    arthurnn authored
    db:reset should not prematurely load the environment, so, for instance,
    if there is any initializer that touches th DB, it will not touch that
    before droping it.
    Also this makes the code simpler.
    This changed was made back in 15fb430
    , not sure why. But I am pretty much sure we should do it like this, as
    drop and setup should load its dependencies tasks if necessary.
  2. @arthurnn

    Merge pull request #20016 from steved/sdavidovitz/abort_if_pending

    arthurnn authored
    make sure to load_config for db:abort_if_pending_migrations
  3. @robin850
  4. @senny

    make `remove_index :table, :column` reversible.

    senny authored
    This used to raise a `IrreversibleMigration` error (since #10437).
    However since `remove_index :table, :column` is probably the most basic
    use-case we should make it reversible again.
  5. @senny

    Merge pull request #20550 from maurogeorge/add_reference-rdoc

    senny authored
    Add RDoc about add_reference to ActiveRecord::Migration
    [ci skip]
Commits on Jun 14, 2015
  1. @kuldeepaggarwal
Something went wrong with that request. Please try again.