| Commit message (Collapse) | Author | Age | Files | Lines |
|\
| |
| | |
Do not store production information in .yml files
|
| | |
|
| | |
|
| | |
|
| |
| |
| |
| |
| |
| |
| |
| |
| | |
This commit also cleans up the rake tasks that were checking
for DATABASE_URL in different places.
In fact, it would be nice to deprecate DATABASE_URL usage in the long
term, considering the direction we are moving of allowing those in .yml
files.
|
| |
| |
| |
| | |
Instead, read information from environment variables.
|
| |
| |
| |
| |
| | |
Missed AMo when adding to the other components in
ae196e85ee7169700afac2eecdc276bc06b10b8d.
|
| |
| |
| |
| |
| | |
Always pass in the column for quote_bound_value and quote using it in
case it exists there.
|
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Fixes #12261. Closes #12395.
Conflicts:
activerecord/CHANGELOG.md
activerecord/test/cases/adapters/postgresql/array_test.rb
activerecord/test/cases/adapters/postgresql/json_test.rb
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
The code uses these checks in several places to know what to do with a
particular column, for instance AR attribute query methods has a branch
like this:
if column.number?
!value.zero?
end
This should never be true for array columns, since it would be the same
as running [].zero?, which results in a NoMethodError exception.
Fixing this by ensuring that array columns in PostgreSQL never return
true for number?/text? checks.
Since most of the array support was based on the postgres_ext lib, it's
worth noting it does the same thing for numeric array columns too:
https://github.com/dockyard/postgres_ext/blob/v1.0.0/lib/postgres_ext/active_record/connection_adapters/postgres_adapter.rb#L72
This extended the same logic for text columns to ensure consistency.
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
TLDR: always return an object that responds to the query methods from
request.format, and do not touch Mime::Type[] lookup to avoid bugs.
---
Long version:
The initial issue was about being able to do checks like
request.format.html? for request with an unknown format, where
request.format would be nil.
This is where the issue came from at first in #7837 and #8085
(merged in cba05887dc3b56a46a9fe2779b6b228880b49622), but the
implementation went down the path of adding this to the mime type
lookup logic.
This unfortunately introduced subtle bugs, for instance in the merged
commit a test related to send_file had to be changed to accomodate the
introduction of the NullType.
Later another bug was found in #13064, related to the content-type being
shown as #<Mime::NullType:...> for templates with localized extensions
but no format included. This one was fixed in #13133, merged in
43962d6ec50f918c9970bd3cd4b6ee5c7f7426ed.
Besides that, custom handlers were not receiving the proper template
formats anymore when passing through the rendering process, because of
the NullType addition. That was found while migrating an application
from 3.2 to 4.0 that uses the Markerb gem (a custom handler that
generates both text and html emails from a markdown template).
---
This changes the implementation moving away from returning this null
object from the mime lookup, and still fixes the initial issue where
request.format.zomg? would raise an exception for unknown formats due to
request.format being nil.
|
|\ \
| |/
|/| |
[ci skip] a destroy action in controller, not delete [getting_stated.md].
|
|/ |
|
|\
| |
| | |
Tell how to Create a Database in Error Message
|
|/
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Currently if you attempt to use a database that does not exist you get an error:
```
PG::ConnectionBad FATAL: database "db_error" does not exist
```
The solution is easy, create and migrate your database however new developers may not know these commands by memory. Instead of requiring the developer to search for a solution, tell them how to fix the problem in the error message:
```
ActiveRecord::NoDatabase: FATAL: database "db_error" does not exist
Run `$ bin/rake db:create db:migrate` to create your database
```
Active Record should not know about `rake db:migrate` so this additional information needs to come from the railtie. Potential alternative implementation suggestions are welcome.
|
| |
|
|\
| |
| | |
On destroying do not touch destroyed belongs to association.
|
|/
|
|
| |
Fixes: #13445
|
|\
| |
| | |
Resolver test cases
|
| | |
|
|\ \
| | |
| | | |
Add missing av/railtie require
|
|/ / |
|
| | |
|
|\ \
| | |
| | | |
Fix typecasting array of integers
|
|/ /
| |
| |
| | |
Closes #13444
|
| | |
|
|/ |
|
|\
| |
| | |
Fix DB Console tests
|
| | |
|
|/
|
|
|
|
|
|
|
|
|
| |
The build is broken: https://travis-ci.org/rails/rails/builds/15824530
This commit fixes it.
The problem: Sqlite expects the `database` part to be an absolute path. That prompted this change to be committed to master: https://github.com/rails/rails/commit/fbb79b517f3127ba620fedd01849f9628b78d6ce
This change provides correct behavior. Unfortunately tests were introduced in https://github.com/rails/rails/commit/971d5107cd4cd08c22a85d34546f4ba03ed5c925 that were relying on the incorrect behavior. We can avoid the fix by changing to another database url such as `mysql` or `postgresql`
In addition to fixing the failure, the assertions are changed so that the "expected" value comes before "actual" value.
|
|\
| |
| | |
Enable memcached service on travis for running cache tests.
|
| | |
|
|\ \
| | |
| | | |
Add missing changelog entries and fix few typos
|
| | | |
|
| | | |
|
| | | |
|
| | | |
|
|/ / |
|
| |
| |
| |
| |
| |
| |
| |
| | |
AC::Parameters#fetch was refactored in 7171111 to prevent self mutation, but
in doing so it hardcodes logic #convert_hashes_to_parameters is supposed to
encapsulate.
Better leave the delegation, and add a way to avoid mutating self in there.
|
| | |
|
|\ \
| | |
| | | |
Generates html and text templates for mailers by default.
|
| | | |
|
| | |
| | |
| | |
| | | |
#13382]
|
|/ / |
|
|\ \
| | |
| | | |
Bump Jbuilder version to 2.0.0
|
|/ / |
|
|\ \
| | |
| | | |
Do not expect database user with app name to exist
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
By default when creating a project with `--database=postgresql` the `config/database.yml` file that is generated has a user specified that is the same as the app name
```
development:
adapter: postgresql
encoding: unicode
database: <%= app_name %>_development
pool: 5
username: <%= app_name %>
password:
```
This is counterintuitive and would rarely be valid. By default postgres creates a user with the current user name (http://www.postgresql.org/docs/9.3/static/database-roles.html) "it will have the same name as the operating system user that initialized the database cluster":
```
$ whoami
schneems
```
If the `username` is left out postgresql will assume that you wish to log in as the default user
```
$ psql -c '\du'
List of roles
Role name | Attributes | Member of
-----------+------------------------------------------------+-----------
schneems | Superuser, Create role, Create DB, Replication | {}
```
A good sensible default then for auto generated `database.yml` files is to remove the `username`, and have postgres attempt to connect to the database as the currently logged in user.
Instead of submitting with a blank password, don't submit a password.
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
before:
ActiveSupport::NumberHelper.number_to_rounded '3.14159', precision: 50
=> "3.14158999999999988261834005243144929409027099609375"
after:
ActiveSupport::NumberHelper.number_to_rounded '3.14159', precision: 50
=> "3.14159000000000000000000000000000000000000000000000"
|
|\ \ \
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
Add configuration option to optionally disable deep_munge
Conflicts:
actionpack/CHANGELOG.md
|