| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
|
|
|
|
| |
This includes fixing typos in changelog, removing a deprecated
mocha/setup test require, and preferring the `column_for_attribute`
accessor over direct access to the columns_hash in the new code.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
When calling quote_value the underlying connection sometimes requires
more information about the column to properly return the correct quoted
value.
I ran into this issue when using optimistic locking in JRuby and the
activerecord-jdbcmssql-adapter. In SQLSever 2000, we aren't allowed to
insert a integer into a NVARCHAR column type so we need to format it as
N'3' if we want to insert into the NVARCHAR type. Unfortuantely, without
the column type being passed the connection adapter cannot properly return
the correct quote value because it doesn't know to return N'3' or '3'.
This patch is fairly straight forward where it just passes in the column
type into the quote_value, as it already has the ability to take in the column,
so it can properly handle at the connection level.
I've added the tests required to make sure that the quote_value method
is being passed the column type so that the underlying connection can
determine how to quote the value.
|
| |
|
| |
|
|
|
|
|
| |
This allows end-users to have a `connection` method on their models
without clashing with ActiveRecord internals.
|
|\
| |
| |
| |
| | |
Conflicts:
guides/source/getting_started.md
|
| |
| |
| |
| | |
particularly, `all(options)` would warn
|
|/ |
|
| |
|
|
|
|
|
|
|
|
|
|
| |
In the end I think the pain of implementing this seamlessly was not
worth the gain provided.
The intention was that it would allow plain ruby objects that might not
live in your main application to be subclassed and have persistence
mixed in. But I've decided that the benefit of doing that is not worth
the amount of complexity that the implementation introduced.
|
|
|
|
| |
This reverts commit 83846838252397b3781eed165ca301e05db39293.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
I think it's going to be too much pain to try to transition the
:active_record load hook from executing against Base to executing
against Model.
For example, after Model is included in Base, and modules included in
Model will no longer get added to the ancestors of Base.
So plugins which wish to be compatible with both Model and Base should
use the :active_record_model load hook which executes *before* Base gets
loaded.
In general, ActiveRecord::Model is an advanced feature at the moment and
probably most people will continue to inherit from ActiveRecord::Base
for the time being.
|
|
|
|
| |
Rather than doing it every time an instance is instantiated.
|
|
|
|
| |
exists in class method.
|
|
|
|
|
| |
Get rid of ActiveModel::Configuration, make better use of
ActiveSupport::Concern + class_attribute, etc.
|
| |
|
| |
|
|\
| |
| | |
Fix deleting from a HABTM join table upon destroying an object of a model with optimistic locking enabled.
|
| |
| |
| |
| | |
with optimistic locking enabled. Issue #5332.
|
|/ |
|
| |
|
|
|
|
|
|
|
|
|
| |
* Relation#order can receive order attributes as different arguments,
add example;
* Readonly does not handle deletion of records, only modification;
* locking_version column does not need to default to 0, Rails handles
nil values;
* Change references from "set_locking_column" to "self.locking_column".
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Add a `with_lock` method to ActiveRecord objects, which starts
a transaction, locks the object (pessimistically) and yields to the block.
The method takes one (optional) parameter and passes it to `lock!`.
Before:
class Order < ActiveRecord::Base
def cancel!
transaction do
lock!
# ... cancelling logic
end
end
end
After:
class Order < ActiveRecord::Base
def cancel!
with_lock do
# ... cancelling logic
end
end
end
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The problem: We need to be able to specify configuration in a way that
can be inherited to models that include ActiveRecord::Model. So it is
no longer sufficient to put 'top level' config on ActiveRecord::Base,
but we do want configuration specified on ActiveRecord::Base and
descendants to continue to work.
So we need something like class_attribute that can be defined on a
module but that is inherited when ActiveRecord::Model is included.
The solution: added ActiveModel::Configuration module which provides a
config_attribute macro. It's a bit specific hence I am not putting this
in Active Support or making it a 'public API' at present.
|
| |
|
| |
|
| |
|
| |
|
| |
|
|
|
|
| |
across web workers.
|
| |
|
| |
|
|
|
|
| |
for generating SQL. This improves the code architecture generally, and solves some problems with marshalling. Adapter authors please take note: you now need to define an Adapter.visitor_for method, but it degrades gracefully with a deprecation warning for now.
|
| |
|
|
|
|
| |
Fixed what looks like minor cut/paste error in documentation for ActiveRecord::Locking:Pessimistic
|
| |
|
|
|
|
| |
delete method.
|
| |
|
|
|
|
| |
Signed-off-by: Santiago Pastorino <santiago@wyeworks.com>
|
|
|
|
|
|
| |
optimistic locking [#5505 state:resolved]
Signed-off-by: Santiago Pastorino and José Ignacio Costa <santiago+jose@wyeworks.com>
|
| |
|
|
|
|
| |
Signed-off-by: Santiago Pastorino <santiago@wyeworks.com>
|
|
|
|
| |
Signed-off-by: Santiago Pastorino <santiago@wyeworks.com>
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
- persisted? is the API defined in ActiveModel
- makes it easier for extension libraries to conform to ActiveModel APIs
without concern for whether the extended object is specifically
ActiveRecord
[#5927 state:committed]
Signed-off-by: Santiago Pastorino <santiago@wyeworks.com>
|
| |
|
|
|
|
| |
Signed-off-by: José Valim <jose.valim@gmail.com>
|
| |
|
| |
|