The bug is that an error would be raised while attempting to convert a
template from one encoding to another.
Please see http://redmine.ruby-lang.org/issues/5564 for more details.
The workaround is to load all conversions into memory ahead of time,
and will only happen if the ruby version is *exactly* 1.9.3p0. The
hope is obviously that the underlying problem will be resolved in
the next patchlevel release of 1.9.3.
This is a first implementation, EXPLAIN is highly
dependent on the database and I have made some
compromises.
On one hand, the method allows you to run the most
common EXPLAIN and that's it. If you want EXPLAIN
ANALYZE in PostgreSQL you need to do it by hand.
On the other hand, I've tried to construct a string
as close as possible to the ones built by the
respective shells. The rationale is that IMO the
user should feel at home with the output and
recognize it at first sight. Per database.
I don't know whether this implementation is going
to work well. Let's see whether people like it.
This test is affected by a bug in Ruby 1.9.3p0 and trunk:
http://redmine.ruby-lang.org/issues/5564
Given we cannot fix it for ourselves, it is better to skip for now so
that we will easily see if further failures are introduced.
Jon Leighton is monitoring the bug report and will revert this when a
suitable solution is found (either a new Ruby release or a generic
workaround).
If you are using 1.9.3 in your app and have templates that are not in
UTF-8, you should add a workaround early on in the boot process. For
example, if your templates are Shift_JIS encoded, then add the
following in an initializer:
Encoding::Converter.new('Shift_JIS', 'UTF-8')
Defining after_initialize and after_find as ordinary methods like documented
in the guide doesn't work with Rails 3.1.1; now macro-style is used here, too.
Reasons:
* Markdown reads well as plain text, but can also be formatted.
* It will make it easier for people to read on the web as Github
formats the Markdown nicely.
* It will encourage a level of consistency when people are writing
CHANGELOG entries.
The script used to perform the conversion is at
https://gist.github.com/1339263
Building the conditions of a nested through association could
potentially modify the conditions of the through and/or source
association.
This is a Bad Thing.
If a record is removed from a has_many :through, all of the join records
relating to that record should also be removed from the through
association's target.
(Previously the records were removed in the database, but only one was
removed from the in-memory target array.)
