If assigning to a has_many :through collection against an unsaved
object using the collection=[<array_of_items>] syntax, the join models
were not properly created, previously.

Don't explain except normal CRUD sql.

Fix find_in_batches with customized primary_key

Query for loading index info should be marked as SCHEMA.

Clarify the documentation on the Rails::Application#call method

This fix the build http://travis-ci.org/#!/rails/rails/builds/2459981

fix the build

Deprecate ActiveSupport::Benchmarkable#silence.

Improve Process::Status#to_json

Because Process::Status has no instance_variables, the
ActiveSupport version of #to_json produces {}, which isn't good.

Therefore, we implement our own #as_json, which makes it useful
again.

Fixes #4857

Support for multiple etags in an If-None-Match header

This is a rebased version of #2520.

Conflicts:

	actionpack/test/dispatch/request_test.rb

Few more warnings removed.

I found them when I was running
warning mode on with railties

See https://github.com/rails/rails/pull/3782

Due to its lack of thread safety, we're deprecating this, and it
will be removed in Rails 4.1.

Fixes #4060.

Accidentally checked in commented test code. Fail. >_<

This method was first seen in 045713ee,
and subsequently reimplemented in
fb2325e3.

According to @jeremy, this is okay to remove. He thinks it was added
because at the time we didn't have much transaction state to keep track
of, and he viewed it as a hack for us to track it internally, thinking
it was better to ask the connection for the transaction state.

Over the years we have added more and more state to track, a lot of
which is impossible to ask the connection for. So it seems that this is
just a relic of the passed and we will just track the state internally
only.

The caller needs to have knowledge of the rollback either way, so do it
all in the caller (#transaction)

This avoids us having to manually increment and decrement it.

This reverts commit c24c8852.

Here's the explanation I just sent to @tenderlove:

Hey,

I've been thinking about about the transaction memory leak thing that we
were discussing.

Example code:

post = nil
Post.transaction do
  N.times { post = Post.create }
end

Post.transaction is going to create a real transaction and there will
also be a (savepoint) transaction inside each Post.create.

In an idea world, we'd like all but the last Post instance to be GC'd,
and for the last Post instance to receive its after_commit callback when
Post.transaction returns.

I can't see how this can work using your solution where the Post itself
holds a reference to the transaction it is in; when Post.transaction
returns, control does not switch to any of Post's instance methods, so
it can't trigger the callbacks itself.

What we really want is for the transaction itself to hold weak
references to the objects within the transaction. So those objects can
be GC'd, but if they are not GC'd then the transaction can iterate them
and execute their callbacks.

I've looked into WeakRef implementations that are available. On 1.9.3,
the stdlib weakref library is broken and we shouldn't use it.

There is a better implementation here:

https://github.com/bdurand/ref/blob/master/lib/ref/weak_reference/pure_ruby.rb

We could use that, either by pulling in the gem or just copying the code
in, but it still suffers from the limitation that it uses ObjectSpace
finalizers.

In my testing, this finalizers make GC quite expensive:
https://gist.github.com/3722432

Ruby 2.0 will have a native WeakRef implementation (via
ObjectSpace::WeakMap), hence won't be reliant on finalizers:
http://bugs.ruby-lang.org/issues/4168

So the ultimate solution will be for everyone to use Ruby 2.0, and for
us to just use ObjectSpace::WeakMap.

In the meantime, we have basically 3 options:

The first is to leave it as it is.

The second is to use a finalizer-based weakref implementation and take
the GC perf hit.

The final option is to store object ids rather than the actual objects.
Then use ObjectSpace._id2ref to deference the objects at the end of the
transaction, if they exist. This won't stop memory use growing within
the transaction, but it'll grow more slowly.

I benchmarked the performance of _id2ref this if the object does or does
not exist: https://gist.github.com/3722550

If it does exist it seems decent, but it's hugely more expensive if it
doesn't, probably because we have to do the rescue nil.

Probably most of the time the objects will exist. However the point of
doing this optimisation is to allow people to create a large number of
objects inside a transaction and have them be GC'd. So for that use
case, we'd be replacing one problem with another. I'm not sure which of
the two problems is worse.

My feeling is that we should just leave this for now and come back to it
when Ruby 2.0 is out.

I'm going to revert your commit because I can't see how it solves this.
Hope you don't mind... if I've misunderstood then let me know!

Jon

update CHANGELOG

Add entry about 24594110 and
95be790e.

warning removed: shadowing outer local variable - message

Build fix for ActionMailer