This is an issue brought up by @daniel-rikowski in rails/web-console#91.
Citing his PR proposal here:
> Prior to this, backtrace lines were simply split by a single colon.
>
> Unfortunately that is also the drive letter delimiter in Windows paths
> which resulted in a lot of empty source fragments of "C:0". ("C" from
> the drive letter and 0 from "/path/to/rails/file.rb:16".to_i)
>
> Now the trace line is split by the first colon followed by some digits,
> which works for both Windows and Unix path styles.
Now, the PR was sent against web-console, because of the templates copy
issue we used to had. Instead of bothering the contributor to reopen the
issue against upstream Rails itself, I will make sure he gets the credit
by putting his name in [rails-contributors/hard_coded_authors.rb][].
[rails-contributors/hard_coded_authors.rb]: (https://github.com/fxn/rails-contributors/blob/master/app/models/names_manager/hard_coded_authors.rb).
It's finally finished!!!!!!! The reason the Attributes API was kept
private in 4.2 was due to some publicly visible implementation details.
It was previously implemented by overloading `columns` and
`columns_hash`, to make them return column objects which were modified
with the attribute information.
This meant that those methods LIED! We didn't change the database
schema. We changed the attribute information on the class. That is
wrong! It should be the other way around, where schema loading just
calls the attributes API for you. And now it does!
Yes, this means that there is nothing that happens in automatic schema
loading that you couldn't manually do yourself. (There's still some
funky cases where we hit the connection adapter that I need to handle,
before we can turn off automatic schema detection entirely.)
There were a few weird test failures caused by this that had to be
fixed. The main source came from the fact that the attribute methods are
now defined in terms of `attribute_names`, which has a clause like
`return [] unless table_exists?`. I don't *think* this is an issue,
since the only place this caused failures were in a fake adapter which
didn't override `table_exists?`.
Additionally, there were a few cases where tests were failing because a
migration was run, but the model was not reloaded. I'm not sure why
these started failing from this change, I might need to clear an
additional cache in `reload_schema_from_cache`. Again, since this is not
normal usage, and it's expected that `reset_column_information` will be
called after the table is modified, I don't think it's a problem.
Still, test failures that were unrelated to the change are worrying, and
I need to dig into them further.
Finally, I spent a lot of time debugging issues with the mutex used in
`define_attribute_methods`. I think we can just remove that method
entirely, and define the attribute methods *manually* in the call to
`define_attribute`, which would simplify the code *tremendously*.
Ok. now to make this damn thing public, and work on moving it up to
Active Model.
This method doesn't need to be lazy, as it is never called from reads.
The only time it is called are in write cases, where we're about to loop
through the results of it, and build the attribute objects anyway. So we
don't gain anything by dodging the instantiation here. This is the only
method that coupled `AttributeSet` to `LazyAttributeHash`, so removing
it puts us back in a place where we can use a normal hash instead.
Remove '<3.0.0' requirement for queue_classic gem. This fixes the issue
that the gem was attempting to parse the queue name as a URI, causing
all of the tests to fail.
Unfortunately, the HashWithIndifferent access approach is insufficient
for our needs. It's perfectly reasonable to want to use keyword
arguments with Active Job, which we will see as a symbol keyed hash. For
Ruby to convert this back to keyword arguments, it must deserialize to a
symbol keyed hash.
There are two primary changes to the serialization behavior. We first
treat a HWIA separately, and mark it as such so we can convert it back
into a HWIA during deserialization.
For normal hashes, we keep a list of all symbol keys, and convert them
back to symbol keys after deserialization.
Fixes#18741.
Remaining are `limit`, `precision`, `scale`, and `type` (the symbol
version). These will remain on the column, since they mirror the options
to the `column` method in the schema definition DSL
The goal is to remove the type object from the column, and remove
columns from the type casting process entirely. The primary motivation
for this is clarity. The connection adapter does not have sufficient
type information, since the type we want to work with might have been
overriden at the class level. By taking this object from the column,
it is easy to mistakenly think that the column object which exists on
the connection adapter is sufficient. It isn't.
A concrete example of this is `serialize`. In 4.2 and earlier, `where`
worked in a very inconsistent and confusing manner. If you passed a
single value to `where`, it would serialize it before querying, and do
the right thing. However, passing it as part of an array, hash, or range
would cause it to not work. This is because it would stop using prepared
statements, so the type casting would come from arel. Arel would have no
choice but to get the column from the connection adapter, which would
treat it as any other string column, and query for the wrong value.
There are a handful of cases where using the column object to find the
cast type is appropriate. These are cases where there is not actually a
class involved, such as the migration DSL, or fixtures. For all other
cases, the API should be designed as such that the type is provided
before we get to the connection adapter. (For an example of this, see
the work done to decorate the arel table object with a type caster, or
the introduction of `QueryAttribute` to `Relation`).
There are times that it is appropriate to use information from the
column to change behavior in the connection adapter. These cases are
when the primitive used to represent that type before it goes to the
database does not sufficiently express what needs to happen. An example
of this that affects every adapter is binary vs varchar, where the
primitive used for both is a string. In this case it is appropriate to
look at the column object to determine which quoting method to use, as
this is something schema dependent.
An example of something which would not be appropriate is to look at the
type and see that it is a datetime, and performing string parsing when
given a string instead of a date. This is the type of logic that should
live entirely on the type. The value which comes out of the type should
be a sufficiently generic primitive that the adapter can be expected to
know how to work with it.
The one place that is still using the column for type information which
should not be necessary is the connection adapter type caster which is
sometimes given to the arel table when we can't find the associated
table. This will hopefully go away in the near future.
The test added in 85465ed3e6c582d25f0c8fafe21f7a2c182c2f67 was passing
when the file was run on its own, but failing when the entire suite was
run since this test modifies the class and doesn't clean up.
It was not possible to create a new gem with a hyphenated name via the `rails plugin new` generator.
The naming guide of rubygems clearly says dashes should be used for gems that extend other gems. http://guides.rubygems.org/name-your-gem/
a column type `xml` is missing in regexp pattarn. However,
`assert_equal 1, lengths.uniq.length` is success when `lengths` are all
`nil` because a column type is missing. a test will be failed by using
`compact` when a column type is missing.
