It looks like these methods all get included into the AbstractAdapter,
and then in github/github we have our own Adapter as an internal gem.
So this should be easy enough to override in our vendor'ed adapter.
This will allow us to still grab errors that happen in `after_commit`
which would normally be swallowed in Rails 3.0 (and beyond).
Conflicts:
activerecord/lib/active_record/connection_adapters/abstract/database_statements.rb
should fix issues with commit callbacks getting called when the record
is not persisted (yet) in a inner transaction or due to some other edge
case.
see also caabed6c76
Conflicts:
activerecord/lib/active_record/transactions.rb
When calling quote_value the underlying connection sometimes requires
more information about the column to properly return the correct quoted
value.
I ran into this issue when using optimistic locking in JRuby and the
activerecord-jdbcmssql-adapter. In SQLSever 2000, we aren't allowed to
insert a integer into a NVARCHAR column type so we need to format it as
N'3' if we want to insert into the NVARCHAR type. Unfortuantely, without
the column type being passed the connection adapter cannot properly return
the correct quote value because it doesn't know to return N'3' or '3'.
This patch is fairly straight forward where it just passes in the column
type into the quote_value, as it already has the ability to take in the column,
so it can properly handle at the connection level.
I've added the tests required to make sure that the quote_value method
is being passed the column type so that the underlying connection can
determine how to quote the value.
Conflicts:
activerecord/CHANGELOG.md
activerecord/lib/active_record/locking/optimistic.rb
This change fixes a bug by which 3.2-STABLE users can't globally override the default STI inheritance column with `ActiveRecord::Base.inheritance_column = 'some_column'`. 3.2-STABLE users are forced to use a deprecated method or monkey patch it otherwise.
Test case written by tkhr <takehiro0740@gmail.com>.
This reverts commit 6675d71318, reversing
changes made to 919d1a19d5.
I missed to check the target branch and wrongly merged it into 3-2-stable directly.
Fix the `:primary_key` option for `has_many` associations.
Conflicts:
activerecord/CHANGELOG.md
activerecord/lib/active_record/associations/has_many_association.rb
This is a backport of #10417
fixes bug introduced by #3329
These are the conditions necessary to reproduce the bug:
- For an association, autosave => true.
- An association record is being destroyed
- A new association record is being created.
- There is a unique index one of the association's fields.
- The record being created has the same value as the record being
destroyed on the indexed field.
Before, the deletion of records was postponed until after all
insertions/saves. Therefore the new record with the identical value in
the indexed field caused a non-unique value error to be thrown at the
database
level.
With this fix, the deletions happen first, before the insertions/saves.
Therefore the record with the duplicate value is gone from the database
before the new record is created, thereby avoiding the non-uniuqe value
error.
that #exists? and others can produce invalid SQL: "SELECT DISTINCT DISTINCT"
The combination of a :uniq => true association and the #distinct call
in #construct_limited_ids_condition combine to create invalid SQL, because
we're explicitly selecting DISTINCT, and also sending #distinct on to AREL,
via the relation#distinct_value.
Where #6792 was the forever fix, this is the minimal fix. Instead of
properly indicating the distinctness of the query through #uniq_value alone,
we use a literal select statement and set #uniq_value to always be falsey
