- 05 3月, 2016 1 次提交
-
-
由 yuuji.yaginuma 提交于
-
- 14 10月, 2015 1 次提交
-
-
由 Yves Senn 提交于
The focus of this change is to make the API more accessible. References to method and classes should be linked to make it easy to navigate around. This patch makes exzessiv use of `rdoc-ref:` to provide more readable docs. This makes it possible to document `ActiveRecord::Base#save` even though the method is within a separate module `ActiveRecord::Persistence`. The goal here is to bring the API closer to the actual code that you would write. This commit only deals with Active Record. The other gems will be updated accordingly but in different commits. The pass through Active Record is not completely finished yet. A follow up commit will change the spots I haven't yet had the time to update. /cc @fxn
-
- 06 10月, 2015 1 次提交
-
-
由 Kir Shatrov 提交于
-
- 16 9月, 2015 1 次提交
-
-
由 Philipp Fehre 提交于
I came across this while trying it out, with the provided code the `MoneyType` does not save as it complains that `Fixnum` does not define `include?`. I think the sensible thing is to check if it already is a `Numeric`.
-
- 31 5月, 2015 1 次提交
-
-
由 Sean Griffin 提交于
-
- 29 5月, 2015 2 次提交
-
-
由 Sean Griffin 提交于
This is a usability change to fix a quirk from our definition of partial writes. By default, we only persist changed attributes. When creating a new record, this is assumed that the default values came from the database. However, if the user provided a default, it will not be persisted, since we didn't see it as "changed". Since this is a very specific case, I wanted to isolate it with the other quirks that come from user provided default values. The number of edge cases which are presenting themselves are starting to make me wonder if we should just remove the ability to assign a default, in favor of overriding `initialize`. For the time being, this is required for the attributes API to not have confusing behavior. We had to delete one test, since this actually changes the meaning of `.changed?` on Active Record models. It now specifically means `changed_from_database?`. While I think this will make the attributes API more ergonomic to use, it is a subtle change in definition (though not a backwards incompatible one). We should probably figure out the right place to document this. (Feel free to open a PR doing that if you're reading this). /cc @rafaelfranca @kirs @senny This is an alternate implementation of #19921. Close #19921. [Sean Griffin & Kir Shatrov]
-
由 Sean Griffin 提交于
This is a variant implementation of the changes proposed in #19914. Unlike that PR, the change in behavior is isolated in its own class. This is to prevent wonky behavior if a Proc is assigned outside of the default, and it is a natural place to place the behavior required by #19921 as well. Close #19914. [Sean Griffin & Kir Shatrov]
-
- 05 3月, 2015 1 次提交
-
-
由 Robin Dupret 提交于
* Fix a few typos * Wrap some lines around 80 chars * Rephrase some statements
-
- 18 2月, 2015 4 次提交
-
-
由 Sean Griffin 提交于
-
由 Sean Griffin 提交于
-
由 Sean Griffin 提交于
-
由 Sean Griffin 提交于
-
- 16 2月, 2015 1 次提交
-
-
由 Sean Griffin 提交于
We do this in the adapter classes specifically, so the types aren't registered if we don't use that adapter. Constants under the PostgreSQL namespace for example are never loaded if we're using mysql.
-
- 08 2月, 2015 1 次提交
-
-
由 Ryuta Kamizono 提交于
-
- 07 2月, 2015 5 次提交
-
-
由 Sean Griffin 提交于
-
由 Sean Griffin 提交于
-
由 Sean Griffin 提交于
-
由 Sean Griffin 提交于
-
由 Sean Griffin 提交于
The same is not true of `define_attribute`, which is meant to be the low level no-magic API that sits underneath. The differences between the two APIs are: - `attribute` - Lazy (the attribute will be defined after the schema has loaded) - Allows either a type object or a symbol - `define_attribute` - Runs immediately (might get trampled by schema loading) - Requires a type object This was the last blocker in terms of public interface requirements originally discussed for this feature back in May. All the implementation blockers have been cleared, so this feature is probably ready for release (pending one more look-over by me).
-
- 03 2月, 2015 1 次提交
-
-
由 Sean Griffin 提交于
`attributes_to_define_after_schema_loads` better describes the difference between `attribute` and `define_attribute`, and doesn't conflate terms since we no longer differentiate between "user provided" and "schema provided" types.
-
- 01 2月, 2015 1 次提交
-
-
由 Sean Griffin 提交于
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.
-
- 21 1月, 2015 1 次提交
-
-
由 Santosh Wadghule 提交于
-
- 11 1月, 2015 1 次提交
-
-
由 Sean Griffin 提交于
This sets a precident for how we handle `attribute` calls, which aren't backed by a database column. We should not take this as a conscious decision on how to handle them, and this can change when we make `attribute` public if we have better ideas in the future. As the composed attributes API gets fleshed out, I expect the `persistable_attributes` method to change to `@attributes.select(&:persistable).keys`, or some more performant variant there-of. This can probably go away completely once we fully move dirty checking into the attribute objects once it gets moved up to Active Model. Fixes #18407
-
- 30 12月, 2014 1 次提交
-
-
由 Sean Griffin 提交于
-
- 23 12月, 2014 1 次提交
-
-
由 Yves Senn 提交于
-
- 01 11月, 2014 1 次提交
-
-
由 Sean Griffin 提交于
Nothing is directly using the columns for the default values anymore. This step helps us get closer not not mutating the columns hash.
-
- 30 6月, 2014 1 次提交
-
-
由 Sean Griffin 提交于
`AttributeSet#dup` has all the behavior we need.
-
- 24 6月, 2014 2 次提交
-
-
由 Yves Senn 提交于
Adding `# :nodoc:` to the parent `class` / `module` is not going to ignore nested classes or modules. There is a modifier `# :nodoc: all` but sadly the containing class or module will continue to be in the docs. /cc @sgrif
-
由 Anton Cherepanov 提交于
-
- 20 6月, 2014 1 次提交
-
-
由 Sean Griffin 提交于
Mostly delegation to start, but we can start moving a lot of behavior in bulk to this object.
-
- 07 6月, 2014 1 次提交
-
-
由 Sean Griffin 提交于
For consistency with https://github.com/rails/rails/pull/15557
-
- 04 6月, 2014 1 次提交
-
-
由 Sean Griffin 提交于
The contract of `_field_changed?` assumes that the old value is always type cast. That is not the case for the value in `Column#default` as things are today. It appears there are other public methods that assume that `Column#default` is type cast, as well. The reason for this change originally was because the value gets put into `@raw_attributes` in initialize. This reverts to the old behavior on `Column`, and updates `initialize` to make sure that the values are in the right format.
-
- 03 6月, 2014 1 次提交
-
-
由 Sean Griffin 提交于
-
- 31 5月, 2014 1 次提交
-
-
由 Sean Griffin 提交于
-
- 30 5月, 2014 2 次提交
-
-
由 Sean Griffin 提交于
-
由 Sean Griffin 提交于
Many of the methods defined in `AttributeMethods::Serialization` can be refactored onto this type as well, but this is a reasonable small step. Removes the `Type` class, and the need for `decorate_columns` to handle serialized types.
-
- 29 5月, 2014 3 次提交
-
-
由 Sean Griffin 提交于
- Create a consistent API across adapters for building new columns - Use it for custom properties so we don't get `UndefinedMethodError`s in stuff I'm implementing elsewhere.
-
由 Sean Griffin 提交于
Working towards re-implementing serialized attributes to use the properties API exposed the need for this, as serializing a column shouldn't change the order of the columns.
-
由 Sean Griffin 提交于
-
- 28 5月, 2014 1 次提交
-
-
由 Sean Griffin 提交于
`ActiveRecord::ConnectionAdapters::Type::Value` => `ActiveRecord::Type::Value`
-