aboutsummaryrefslogtreecommitdiffstats
path: root/activerecord/lib/active_record/attribute_methods
Commit message (Collapse)AuthorAgeFilesLines
* applies new doc guidelines to Active Record.Yves Senn2015-10-143-5/+5
| | | | | | | | | | | | | | | | | | | 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
* Add Singleton in NullMutationTracker classacapilleri2015-10-031-1/+1
| | | | to reduce allocation of same object
* Build the `AttributeMutationTracker` lazilySean Griffin2015-10-021-13/+15
| | | | | For reads, we never need to construct this object. The double `defined?` check is to avoid errors in tests
* Fix test failures on MySQLSean Griffin2015-10-021-1/+3
| | | | | There were a few places where I missed a `create` vs `new` before_type_cast check, and the semantics of `reload` became wrong.
* Further encapsulate dirty checking on `Attribute`Sean Griffin2015-10-021-4/+7
| | | | | | | | | | | | | | | | | | | We can skip the allocation of a full `AttributeSet` by changing the semantics of how we structure things. Instead of comparing two separate `AttributeSet` objects, and `Attribute` is now a singly linked list of every change that has happened to it. Since the attribute objects are immutable, to apply the changes we simply need to copy the head of the list. It's worth noting that this causes one subtle change in the behavior of AR. When a record is saved successfully, the `before_type_cast` version of everything will be what was sent to the database. I honestly think these semantics make more sense, as we could have just as easily had the DB do `RETURNING *` and updated the record with those if we had things like timestamps implemented at the DB layer. This brings our performance closer to 4.2, but we're still not quite there.
* Separate `dup` from `deep_dup` in the attributes hashSean Griffin2015-09-281-1/+1
| | | | | | | | | | | I'm looking to move towards a tree-like structure for dirty checking that involves an attribute holding onto the attribute that it was created from. This means that `changed?` can be fully encapsulated on that object. Since the objects are immutable, in `changes_applied`, we can simply perform a shallow dup, instead of a deep one. I'm not sure if that will actually end up in a performance boost, but I'd like to semantically separate these concepts regardless
* Apply subsecond precision on assignment when using TZ aware attributesSean Griffin2015-09-241-1/+1
| | | | | | | | | | | When a time object was assigned to a datetime column, the decorator for TZ aware attributes wouldn't call super, so when using a database without support for subsecond precision, the nanosecond would not be truncated, leading to the value being marked as changed. Interestingly, this also shows our new implementation of dirty checking to be more robust than the old one (with less code and better performance! :tada:!!!)
* We still need to reset `@changed_attributes` in `changes_applied`Sean Griffin2015-09-241-0/+2
| | | | | | When I removed the call to `super` to avoid the setting of `@previous_changes`, I forgot to duplicate the other part of that behavior, which led to failing tests
* Improve the performance of `save` and friendsSean Griffin2015-09-241-2/+10
| | | | | | | | | | | | | | | | | | | | | | The biggest source of the performance regression in these methods occurred because dirty tracking required eagerly materializing and type casting the assigned values. In the previous commits, I've changed dirty tracking to perform the comparisons lazily. However, all of this is moot when calling `save`, since `changes_applied` will be called, which just ends up eagerly materializing everything, anyway. With the new mutation tracker, it's easy to just compare the previous two hashes in the same lazy fashion. We will not have aliasing issues with this setup, which is proven by the fact that we're able to detect nested mutation. Before: User.create! 2.007k (± 7.1%) i/s - 10.098k After: User.create! 2.557k (± 3.5%) i/s - 12.789k Fixes #19859
* Encapsulate a lot of the logic from `Dirty` in an objectSean Griffin2015-09-241-24/+9
| | | | | | | | | In order to improve the performance of dirty checking, we're going to need to duplicate all of the `previous_` methods in Active Model. However, these methods are basically the same as their non-previous counterparts, but comparing `@original_attributes` to `@previous_original_attributes` instead of `@attributes` and `@original_attributes`. This will help reduce that duplication.
* Clean up the implementation of AR::DirtySean Griffin2015-09-241-78/+39
| | | | | | | | | | | | | This moves a bit more of the logic required for dirty checking into the attribute objects. I had hoped to remove the `with_value_from_database` stuff, but unfortunately just calling `dup` on the attribute objects isn't enough, since the values might contain deeply nested data structures. I think this can be cleaned up further. This makes most dirty checking become lazy, and reduces the number of object allocations and amount of CPU time when assigning a value. This opens the door (but doesn't quite finish) to improving the performance of writes to a place comparable to 4.1
* Move ActiveRecord::Type to ActiveModelKir Shatrov2015-09-211-1/+1
| | | | The first step of bringing typecasting to ActiveModel
* Merge pull request #21650 from mcfiredrill/nodoc-raw-write-attributeArthur Nogueira Neves2015-09-191-1/+1
|\ | | | | nodoc raw_write_attribute
| * nodoc raw_write_attributeTony Miller2015-09-191-1/+1
| | | | | | | | | | Is this supposed to be public API? If so, I can document it instead. :memo:
* | Inline uneccessary frozen string constantSean Griffin2015-08-311-3/+1
| | | | | | | | | | | | | | We are only supporting Ruby 2.2 and later in Rails 5, so we do not need an actual constant here. Additionally, referencing a constant actually does a hash lookup (because constants are not constant in Ruby >_>). This will be marginally (likely immeasurable) faster. It is less ugly.
* | [ci skip] Fix rdoc markupakihiro172015-08-121-1/+1
|/
* Freeze string literals when not mutated.schneems2015-07-192-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | I wrote a utility that helps find areas where you could optimize your program using a frozen string instead of a string literal, it's called [let_it_go](https://github.com/schneems/let_it_go). After going through the output and adding `.freeze` I was able to eliminate the creation of 1,114 string objects on EVERY request to [codetriage](codetriage.com). How does this impact execution? To look at memory: ```ruby require 'get_process_mem' mem = GetProcessMem.new GC.start GC.disable 1_114.times { " " } before = mem.mb after = mem.mb GC.enable puts "Diff: #{after - before} mb" ``` Creating 1,114 string objects results in `Diff: 0.03125 mb` of RAM allocated on every request. Or 1mb every 32 requests. To look at raw speed: ```ruby require 'benchmark/ips' number_of_objects_reduced = 1_114 Benchmark.ips do |x| x.report("freeze") { number_of_objects_reduced.times { " ".freeze } } x.report("no-freeze") { number_of_objects_reduced.times { " " } } end ``` We get the results ``` Calculating ------------------------------------- freeze 1.428k i/100ms no-freeze 609.000 i/100ms ------------------------------------------------- freeze 14.363k (± 8.5%) i/s - 71.400k no-freeze 6.084k (± 8.1%) i/s - 30.450k ``` Now we can do some maths: ```ruby ips = 6_226k # iterations / 1 second call_time_before = 1.0 / ips # seconds per iteration ips = 15_254 # iterations / 1 second call_time_after = 1.0 / ips # seconds per iteration diff = call_time_before - call_time_after number_of_objects_reduced * diff * 100 # => 0.4530373333993266 miliseconds saved per request ``` So we're shaving off 1 second of execution time for every 220 requests. Is this going to be an insane speed boost to any Rails app: nope. Should we merge it: yep. p.s. If you know of a method call that doesn't modify a string input such as [String#gsub](https://github.com/schneems/let_it_go/blob/b0e2da69f0cca87ab581022baa43291cdf48638c/lib/let_it_go/core_ext/string.rb#L37) please [give me a pull request to the appropriate file](https://github.com/schneems/let_it_go/blob/b0e2da69f0cca87ab581022baa43291cdf48638c/lib/let_it_go/core_ext/string.rb#L37), or open an issue in LetItGo so we can track and freeze more strings. Keep those strings Frozen ![](https://www.dropbox.com/s/z4dj9fdsv213r4v/let-it-go.gif?dl=1)
* Copy-edits in 04c349659bfd97f9eaf5266ef7a64b4eb367c6a8Rafael Mendonça França2015-06-121-1/+2
|
* add doc about how empty serialization objects are persisted Diego Carrion2015-06-121-0/+2
| | | the test case for this commit is in cd3f5db
* Don't crash when mutating attributes in a getterSean Griffin2015-06-121-1/+6
| | | | | | | | | | | If a getter has side effects on the DB, `changes_applied` will be called twice. The second time will try and remove the changed attributes cache, and will crash because it's already been unset. This also demonstrates that we shouldn't assume that calling getters won't change the value of `changed_attributes`, and we need to clear the cache if an attribute is modified. Fixes #20531.
* Merge pull request #20364 from ernie/update-serialize-docsSean Griffin2015-05-291-0/+9
|\ | | | | | | | | | | Update docs for ActiveRecord `serialize` [ci skip]
| * Update docs for ActiveRecord `serialize`Ernie Miller2015-05-291-0/+9
|/ | | | | | | | | | | | For certain column types, using `serialize` is unnecessary, or the user may get unexpected contents back from the DB adapter (which is handling some basic deserialization for them). Call this out in the documentation. For background, see: https://gist.github.com/ernie/33f75f2294885b9806f9 https://twitter.com/erniemiller/status/604262907442905090
* `type_cast_from_user` -> `cast`Sean Griffin2015-02-171-2/+2
|
* `Type#type_cast_from_database` -> `Type#deserialize`Sean Griffin2015-02-171-1/+1
|
* rm `Type#number?`Sean Griffin2015-02-071-2/+1
| | | | | This predicate is only used in `query_attribute`, and is relatively easy to remove without adding a bunch of is a checks.
* rm `ActiveRecord::Type::Decorator`Sean Griffin2015-02-071-2/+0
| | | | | | | It only existed to make sure the subclasses of `Delegator` were YAML serializable. As of Ruby 2.2, these are YAML dumpable by default, as it includes https://github.com/tenderlove/psych/commit/2a4d9568f7d5d19c00231cf48eb855cc45ec3394
* Push multi-parameter assignement into the typesSean Griffin2015-02-071-0/+8
| | | | | | | | | | | | This allows us to remove `Type::Value#klass`, as it was only used for multi-parameter assignment to reach into the types internals. The relevant type objects now accept a hash in addition to their previous accepted arguments to `type_cast_from_user`. This required minor modifications to the tests, since previously they were relying on the fact that mulit-parameter assignement was reaching into the internals of time zone aware attributes. In reaility, changing those properties at runtime wouldn't change the accessor methods for all other forms of assignment.
* Significantly improve the performance of `_read_attribute` on JRubySean Griffin2015-02-061-2/+11
| | | | | | | | | | | | | The `&block` form is more than twice as fast as the manual form of delegation (and is the code I'd rather write anyway). Unfortunately, it's still twice as slow on MRI. However, this is enough of a hotspot to justify giving JRuby special treatment. I can't currently provide benchmarks in the context of Active Record, since the JDBC adapters still aren't updated for 4.2, but the actual work performed (assuming it's been read at least once already) will have nearly the same performance characteristics as https://gist.github.com/sgrif/b86832786551aaee74de.
* Attribute assignment and type casting has nothing to do with columnsSean Griffin2015-01-311-3/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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.
* Remove most type related predicates from `Column`Sean Griffin2015-01-301-1/+2
| | | | | | Remaining are `limit`, `precision`, `scale`, and `type` (the symbol version). These will remain on the column, since they mirror the options to the `column` method in the schema definition DSL
* Merge pull request #18588 from thegcat/patch-1Rafael Mendonça França2015-01-271-1/+1
|\ | | | | [ci skip] fix typo still -> will
| * fix typo still cause -> still causesFelix Schäfer2015-01-271-1/+1
| |
* | Errors raised in `type_cast_for_database` no longer raise on assignmentSean Griffin2015-01-231-1/+1
|/ | | | Fixes #18580.
* Don't calculate in-place changes on attribute assignmentSean Griffin2015-01-181-1/+1
| | | | | | | | | | | When an attribute is assigned, we determine if it was already marked as changed so we can determine if we need to clear the changes, or mark it as changed. Since this only affects the `attributes_changed_by_setter` hash, in-place changes are irrelevant to this process. Since calculating in-place changes can be expensive, we can just skip it here. I also added a test for the only edge case I could think of that would be affected by this change.
* [ci skip] fix typo sill -> stillAditya Kapoor2015-01-151-1/+1
|
* Time columns should support time zone aware attributesSean Griffin2015-01-151-4/+29
| | | | | | The types that are affected by `time_zone_aware_attributes` (which is on by default) have been made configurable, in case this is a breaking change for existing applications.
* Only use the `_before_type_cast` in the form when from user inputSean Griffin2015-01-141-0/+5
| | | | | | While we don't want to change the form input when validations fail, blindly using `_before_type_cast` will cause the input to display the wrong data for any type which does additional work on database values.
* Don't attempt to save dirty attributes which are not persistableSean Griffin2015-01-101-1/+1
| | | | | | | | | | | | | | | | 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
* fix `attribute` method scoping(i.e. private)Kuldeep Aggarwal2015-01-061-3/+1
| | | | ref #52f641264b1325a4c2bdce7971b14524bd4905f1
* replacing 'attribute' method with an aliasGeorge Millo2015-01-061-3/+2
|
* remove files which is dependent on ruby1.9 as we do not support Ruby1.9Kuldeep Aggarwal2015-01-042-44/+24
| | | | | Conflicts: activerecord/lib/active_record/attribute_methods/read.rb
* Remove unneeded requiresRafael Mendonça França2015-01-041-2/+0
| | | | These requires were added only to change deprecation message
* Remove deprecated `serialized_attributes`Rafael Mendonça França2015-01-041-13/+0
|
* Remove `cache_attributes` and friendsRafael Mendonça França2015-01-041-11/+0
|
* Don't raise on out-of-range datetimes passed by a userGrey Baker2014-12-231-1/+5
|
* Don't calculate all in-place changes to determine if attribute_changed?Sean Griffin2014-12-221-0/+4
| | | | | | | | | Calling `changed_attributes` will ultimately check if every mutable attribute has changed in place. Since this gets called whenever an attribute is assigned, it's extremely slow. Instead, we can avoid this calculation until we actually need it. Fixes #18029
* `update_column` take ruby-land input, not database-land inputSean Griffin2014-12-161-1/+1
| | | | | | | | | | | | | | | In the case of serialized columns, we would expect the unserialized value as input, not the serialized value. The original issue which made this distinction, #14163, introduced a bug. If you passed serialized input to the method, it would double serialize when it was sent to the database. You would see the wrong input upon reloading, or get an error if you had a specific type on the serialized column. To put it another way, `update_column` is a special case of `update_all`, which would take `['a']` and not `['a'].to_yaml`, but you would not pass data from `params` to it. Fixes #18037
* Allow custom handling of non-standard types in `time_zone_conversion`Sean Griffin2014-12-081-1/+1
| | | | | | | | | | | | PostgreSQL for example, allows infinity as a valid value for date time columns. The PG type has explicit handling for that case. However, time zone conversion will end up trampling that handling. Unfortunately, we can't call super and then convert time zones. However, if we get back nil from `.in_time_zone`, it's something we didn't expect so we can let the superclass handle it. Fixes #17971
* Ensure numericality validations work with mutationSean Griffin2014-12-011-6/+6
| | | | | | | | | | | | | | | | | | | | | The detection of in-place changes caused a weird unexpected issue with numericality validations. That validator (out of necessity) works on the `_before_type_cast` version of the attribute, since on an `:integer` type column, a non-numeric string would type cast to 0. However, strings are mutable, and we changed strings to ensure that the post type cast version of the attribute was a different instance than the before type cast version (so the mutation detection can work properly). Even though strings are the only mutable type for which a numericality validation makes sense, special casing strings would feel like a strange change to make here. Instead, we can make the assumption that for all mutable types, we should work on the post-type-cast version of the attribute, since all cases which would return 0 for non-numeric strings are immutable. Fixes #17852
* Improve the performance of reading attributesSean Griffin2014-11-183-6/+12
| | | | | | | We added a comparison to "id", and call to `self.class.primary_key` a *lot*. We also have performance hits from `&block` all over the place. We skip the check in a new method, in order to avoid breaking the behavior of `read_attribute`
generated by cgit v1.2.3 (git 2.25.1) at 2024-07-04 06:03:27 +0000