| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
|
|
|
| |
When inserting new records, only the fields which have been changed
from the defaults will actually be included in the INSERT statement.
The other fields will be populated by the database.
This is more efficient, and also means that it will be safe to
remove database columns without getting subsequent errors in running
app processes (so long as the code in those processes doesn't
contain any references to the removed column).
|
| |
|
|
|
|
| |
65843e1acc0c8d285ff79f8c9c49d4d1215440be
|
| |
|
|
|
|
|
| |
Related to 761bc751d31c22e2c2fdae2b4cdd435b68b6d783 and
eb876c4d07130f15be2cac7be968cc393f959c62
|
|
|
|
|
|
|
| |
This reverts commit 761bc751d31c22e2c2fdae2b4cdd435b68b6d783.
This commit wasn't fixing any issue just using the same table for
different models with different primary keys.
|
| |
|
|
|
|
| |
set utf8_unicode_ci collation on latin1 table.
|
|\
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Conflicts:
actionmailer/lib/action_mailer/base.rb
activesupport/lib/active_support/configurable.rb
activesupport/lib/active_support/core_ext/module/deprecation.rb
guides/source/action_controller_overview.md
guides/source/active_support_core_extensions.md
guides/source/ajax_on_rails.textile
guides/source/association_basics.textile
guides/source/upgrading_ruby_on_rails.md
While resolving conflicts, I have chosen to ignore changes done in
docrails at some places - these will be most likely 1.9 hash syntax
changes.
|
| |
| |
| |
| | |
Callbacks may interfere with each other.
|
| | |
|
| | |
|
| |
| |
| |
| | |
Fixes #3458.
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
If your database supports setting the isolation level for a transaction,
you can set it like so:
Post.transaction(isolation: :serializable) do
# ...
end
Valid isolation levels are:
* `:read_uncommitted`
* `:read_committed`
* `:repeatable_read`
* `:serializable`
You should consult the documentation for your database to understand the
semantics of these different levels:
* http://www.postgresql.org/docs/9.1/static/transaction-iso.html
* https://dev.mysql.com/doc/refman/5.0/en/set-transaction.html
An `ActiveRecord::TransactionIsolationError` will be raised if:
* The adapter does not support setting the isolation level
* You are joining an existing open transaction
* You are creating a nested (savepoint) transaction
The mysql, mysql2 and postgresql adapters support setting the
transaction isolation level. However, support is disabled for mysql
versions below 5, because they are affected by a bug
(http://bugs.mysql.com/bug.php?id=39170) which means the isolation level
gets persisted outside the transaction.
|
|\ \
| | |
| | |
| | |
| | | |
jcoleman/should-unset-association-when-an-existing-record-is-destroyed
Unset association when existing record is destroyed.
|
| | |
| | |
| | |
| | | |
To avoid foreign key errors (and invalid data) in the database, when a belongs_to association is destroyed, it should also be nil'd out on the parent object.
|
| | | |
|
| | | |
|
| | | |
|
|\ \ \
| | | |
| | | | |
Freeze columns before using them as hash keys
|
| | | |
| | | |
| | | | |
This reduces the number of allocated strings from columns * (rows + 1) to just columns.
|
| | | | |
|
|\ \ \ \
| | | | |
| | | | | |
AR::Base#attributes= is just an alias for AR::Base#assign_attributes
|
| | | | | |
|
| | | | | |
|
| | | | | |
|
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
db:structure:load
"
Breaks db:setup because it tries to load the environment before creating the database.
This reverts commit 5ca11fefce6d83f5db399aa4412f1f1a0d42b2e6.
|
| | | | |
| | | | |
| | | | |
| | | | | |
Closes #6960
|
|/ / / /
| | | |
| | | |
| | | | |
reference to mass_assignment options
|
| | | |
| | | |
| | | |
| | | | |
references to mass assignment options
|
| | | | |
|
|\ \ \ \
| | | | |
| | | | | |
Integrate strong_parameters in Rails 4
|
| | | | | |
|
| | | | | |
|
| | | | |
| | | | |
| | | | |
| | | | | |
or new protection model
|
| | | | | |
|
| | | | | |
|
|\ \ \ \ \
| |/ / / /
|/| | | | |
Fix collection= on hm:t join models when unsaved
|
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
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.
|
|\ \ \ \ \
| | | | | |
| | | | | | |
Adds migration and type casting support for PostgreSQL Array datatype
|
| | |/ / /
| |/| | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
Having column related schema dumper code in the AbstractAdapter. The
code remains the same, but by placing it in the AbstractAdapter, we can
then overwrite it with Adapter specific methods that will help with
Adapter specific data types.
The goal of moving this code here is to create a new migration key for
PostgreSQL's array type. Since any datatype can be an array, the goal is
to have ':array => true' as a migration option, turning the datatype
into an array. I've implemented this in postgres_ext, the syntax is
shown here: https://github.com/dockyard/postgres_ext#arrays
Adds array migration support
Adds array_test.rb outlining the test cases for array data type
Adds pg_array_parser to Gemfile for testing
Adds pg_array_parser to postgresql_adapter (unused in this commit)
Adds schema dump support for arrays
Adds postgres array type casting support
Updates changelog, adds note for inet and cidr support, which I forgot to add before
Removing debugger, Adds pg_array_parser to JRuby platform
Removes pg_array_parser requirement, creates ArrayParser module used by
PostgreSQLAdapter
|
| | | | | |
|
|\ \ \ \ \
| |_|/ / /
|/| | | |
| | | | |
| | | | |
| | | | | |
Don't preserve SELECT columns on COUNT
Closes #7651
|
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
The COUNT clause of a finder_sql relationship is being rewritten from
COUNT(*) to COUNT(table_name.*). This does not appear to be valid syntax
in MySQL:
```
mysql> SELECT COUNT( table_name.* ) FROM `table_name`;
ERROR 1064 (42000): You have an error in your SQL syntax; check the
manual that corresponds to your MySQL server version for the right
syntax to use near '* ) FROM `table_name`' at line 1
```
This fixes the bug, as well as adding tests so we don't re-introduce
it in the future.
Fixes #3956.
|
| | | | | |
|
| | | | | |
|
| | | | | |
|
| | | | | |
|
|/ / / / |
|
| | | |
| | | |
| | | |
| | | | |
Accidentally checked in commented test code. Fail. >_<
|