- 07 2月, 2015 1 次提交
-
-
由 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 2 次提交
-
-
由 Sean Griffin 提交于
`ActiveRecord::ConnectionAdapters::Type::Value` => `ActiveRecord::Type::Value`
-
由 Sean Griffin 提交于
Making this part of the public API was premature, let's make it private again while I continue to work on the surrounding code.
-
- 27 5月, 2014 2 次提交
-
-
由 Sean Griffin 提交于
With ActiveRecord::Properties, we now have a reasonable path for users to continue to keep this behavior if they want it. This is an edge case that has added a lot of complexity to the code base.
-
由 Sean Griffin 提交于
As a result of all of the refactoring that's been done, it's now possible for us to define a public API to allow users to specify behavior. This is an initial implementation so that I can work off of it in smaller pieces for additional features/refactorings. The current behavior will continue to stay the same, though I'd like to refactor towards the automatic schema detection being built off of this API, and add the ability to opt out of automatic schema detection. Use cases: - We can deprecate a lot of the edge cases around types, now that there is an alternate path for users who wish to maintain the same behavior. - I intend to refactor serialized columns to be built on top of this API. - Gem and library maintainers are able to interact with `ActiveRecord` at a slightly lower level in a more stable way. - Interesting ability to reverse the work flow of adding to the schema. Model can become the single source of truth for the structure. We can compare that to what the database says the schema is, diff them, and generate a migration.
-