The output in Travis is a bit different. The SQLite
documentation (http://www.sqlite.org/eqp.html) warns
output may change dramatically between releases. I
do not want to mock the result set because I want a
real EXPLAIN to happen. I prefer a test that may fail
in future releases than a test that may give false
positives in future releases.
The last argument to DateTime.new/civil is the Julian day number for
when the calendar reform occured. DateTime ignores it if it's 0, and
sets it to the default of DateTime::ITALY instead, so we could just
leave it out. This also removes the warnings while running the
ActiveSupport tests (there still are some for the setup though).
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
