aboutsummaryrefslogtreecommitdiffstats
path: root/activemodel
Commit message (Collapse)AuthorAgeFilesLines
...
* | Apply scale before precision when coercing floats to decimalSean Griffin2016-03-242-2/+17
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Since precision is always larger than scale, it can actually change rounding behavior. Given a precision of 5 and a scale of 3, when you apply the precision of 5 to `1.25047`, the result is `1.2505`, which when the scale is applied would be `1.251` instead of the expected `1.250`. This issue appears to only occur with floats, as scale doesn't apply to other numeric types, and the bigdecimal constructor actually ignores precision entirely when working with strings. There's no way we could handle this for the "unknown object which responds to `to_d`" case, as we can't assume an interface for applying the scale. Fixes #24235
* | Use Range#cover? for Date inclusion validatorojab2016-03-241-3/+4
| |
* | Add edge cases to Time/Date/DateTime inclusion validation testsojab2016-03-241-3/+17
|/
* revises the homepage URL in the gemspecs [ci skip]Xavier Noria2016-03-101-1/+1
| | | | References https://github.com/rails/homepage/issues/46.
* use same name to type objectyuuji.yaginuma2016-03-091-1/+1
| | | | Follow up to #24079
* Remove load_paths fileArthur Neves2016-02-271-2/+0
|
* Preparing for 5.0.0.beta3 releaseeileencodes2016-02-241-0/+5
| | | | Adds changelog headers for beta3 release
* Prep release for Rails 5 beta3eileencodes2016-02-241-1/+1
|
* Revert changes to validations from PR #18612eileencodes2016-02-231-11/+0
| | | | | | | | | | | | | | | | | | | | In order to fix issue #17621 we added a check to validations that determined if a record should be validated. Based on the existing tests and behavior we wanted we determined the best way to do that was by checking if `!record.peristed? || record.changed? || record.marked_for_destruction?` This change didn't make it into a release until now. When #23790 was opened we realized that `valid?` and `invalid?` were broken and did not work on persisted records because of the `!record.persisted?`. While there is still a bug that #17621 brought up, this change was too drastic and should not be a RC blocker. I will work on fixing this so that we don't break `valid?` but also aren't validating parent records through child records if that parent record is validate false. This change removes the code changes to validate and the corresponding tests. It adds tests for two of the bugs found since Rails 5 beta2 release. Fixes #17621
* remove args from assert_nothing_raised in testsTara Scherner de la Fuente2016-02-222-4/+4
|
* Merge pull request #23743 from maclover7/rm-unused-parameterSantiago Pastorino2016-02-211-2/+2
|\ | | | | Remove unused parameter from method
| * Remove unused parameter from methodJon Moss2016-02-171-2/+2
| | | | | | | | | | | | The `attribute` parameter is not used inside the `normalize_detail` method. This does not need to go through a deprecation cycle, since the method is private.
* | Always validate record if validating a virtual attributeeileencodes2016-02-201-0/+7
|/ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Fixes #23645 When you're using an `attr_accessor` for a record instead of an attribute in the database there's no way for the record to know if it has `changed?` unless you tell it `attribute_will_change!("attribute")`. The change made in 27aa4dd updated validations to check if a record was `changed?` or `marked_for_destruction?` or not `persisted?`. It did not take into account virtual attributes that do not affect the model's dirty status. The only way to fix this is to always validate the record if the attribute does not belong to the set of attributes the record expects (in `record.attributes`) because virtual attributes will not be in that hash. I think we should consider deprecating this particular behavior in the future and requiring that the user mark the record dirty by noting that the virtual attribute will change. Unfortunately this isn't easy because we have no way of knowing that you did the "right thing" in your application by marking it dirty and will get the deprecation warning even if you are doing the correct thing. For now this restores expected behavior when using a virtual attribute by always validating the record, as well as adds tests for this case. I was going to add the `!record.attributes.include?(attribute)` to the `should_validate?` method but `uniqueness` cannot validate a virtual attribute with nothing to hold on to the attribute. Because of this `should_validate?` was about to become a very messy method so I decided to split them up so we can handle it specifically for each case.
* Add documentation about method to describe how it works [ci skip]Mehmet Emin İNAÇ2016-02-041-0/+9
|
* Preparing for Rails 5.0.0.beta2Sean Griffin2016-02-012-1/+6
|
* Wrangle the asset build into something that sounds more generalMatthew Draper2016-02-011-0/+3
|
* Merge branch '5-0-beta-sec'Aaron Patterson2016-01-253-3/+4
|\ | | | | | | | | | | | | | | | | | | | | * 5-0-beta-sec: bumping version fix version update task to deal with .beta1.1 Eliminate instance level writers for class accessors allow :file to be outside rails root, but anything else must be inside the rails view directory Don't short-circuit reject_if proc stop caching mime types globally use secure string comparisons for basic auth username / password
| * bumping versionAaron Patterson2016-01-251-1/+1
| |
| * Eliminate instance level writers for class accessorsAaron Patterson2016-01-222-2/+3
| | | | | | | | | | | | | | | | | | Instance level writers can have an impact on how the Active Model / Record objects are saved. Specifically, they can be used to bypass validations. This is a problem if mass assignment protection is disabled and specific attributes are passed to the constructor. CVE-2016-0753
* | Refactor tz aware types, add support for PG rangesSean Griffin2016-01-081-0/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This is an alternate implementation to #22875, that generalizes a lot of the logic that type decorators are going to need, in order to have them work with arrays, ranges, etc. The types have the ability to map over a value, with the default implementation being to just yield that given value. Array and Range give more appropriate definitions. This does not automatically make ranges time zone aware, as they need to be added to the `time_zone_aware` types config, but we could certainly make that change if we feel it is appropriate. I do think this would be a breaking change however, and should at least have a deprecation cycle. Closes #22875. /cc @matthewd
* | remove activemodel dependency on builderLachlan Sylvester2016-01-061-2/+0
| |
* | Move CHANGELOG entry to Active RecordRafael Mendonça França2016-01-051-5/+0
| | | | | | | | | | | | | | | | While the type definition is in Active Model the change of behavior will be only user facing in Active Record so better to put the entry in its changelog. [ci skip]
* | Take UTC offset into account when assigning string value to time attribute.Andrey Novikov2016-01-053-1/+9
| |
* | Update copyright notices to 2016 [ci skip]Rashmi Yadav2015-12-312-2/+2
| |
* | Convert non-`Numeric` values to FloatsRobert Eshleman2015-12-221-1/+1
| |
* | Fix Regression in Numericality ValidationsRobert Eshleman2015-12-221-2/+9
| | | | | | | | | | | | | | | | | | | | | | | | A regression (#22744) introduced in 7500dae caused certain numericality validations to raise an error when run against an attribute with a string value. Previously, these validations would successfully run against string values because the value was cast to a numeric class. This commit resolves the regression by converting string values to floats before performing numericality comparison validations. [fixes #22744]
* | Failing Tests for Validating String NumbericalityRobert Eshleman2015-12-221-0/+42
| | | | | | | | | | | | | | | | | | | | | | Covers Regressions: * <= * < * == * > * >= * other than
* | No more no changes entries in the CHANGELOGsGenadi Samokovarov2015-12-211-3/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | During the `5.0.0.beta1` release, the CHANGELOGs got an entry like the following: ``` * No changes. ``` It is kinda confusing as there are indeed changes after it. Not a biggie, just a small pass over the CHANGELOGs. [ci skip]
* | Add missing @claudiob credit to change log [skip ci]Jon Atack2015-12-201-0/+1
|/
* Add CHANGELOG headers for Rails 5.0.0.beta1eileencodes2015-12-181-0/+5
|
* Change `alpha` to `beta1` to prep for release of Rails 5eileencodes2015-12-181-1/+1
| | | | :tada: :beers:
* Merge pull request #22598 from yui-knk/deprecate_string_callbackRafael França2015-12-162-1/+2
|\ | | | | Deprecate passing string to define callback.
| * Deprecate passing string to define callback.yui-knk2015-12-162-1/+2
| |
* | `ActiveRecord::Base#becomes` should copy the errorsVokhmin Alexey V2015-12-142-0/+22
| |
* | Use a bind param for `LIMIT` and `OFFSET`Sean Griffin2015-12-141-0/+5
|/ | | | | | | | | | | | | | | We currently generate an unbounded number of prepared statements when `limit` or `offset` are called with a dynamic argument. This changes `LIMIT` and `OFFSET` to use bind params, eliminating the problem. `Type::Value#hash` needed to be implemented, as it turns out we busted the query cache if the type object used wasn't exactly the same object. This drops support for passing an `Arel::Nodes::SqlLiteral` to `limit`. Doing this relied on AR internals, and was never officially supported usage. Fixes #22250.
* Merge pull request #22381 from yahonda/use_adapter_subsecond_precision_supportedAaron Patterson2015-12-131-1/+5
|\ | | | | Use adapter supports_datetime_with_precision
| * Avoid dummy_time_value to add "2000-01-01" twiceYasuo Honda2015-11-301-1/+5
| |
* | Merge pull request #22517 from Elektron1c97/masterRafael França2015-12-071-2/+1
|\ \ | | | | | | [ci skip] Add a dollar sign to each command in the READMEs
| * | [ci skip] Add a dollar sign to each command in the READMEsElektron1c972015-12-061-2/+1
| |/ | | | | | | | | | | According to pr #22443 in the guides there's always a dollar sign before every command, so why is in the main README a `$` and in every submodule a `%`? Just eye candy..
* / add test for nested model translationkeepcosmos2015-12-031-0/+5
|/
* Fix test failures caused by #21000Sean Griffin2015-11-231-0/+1
|
* Merge pull request #21000 from twalpole/find_or_parameter_issuesSean Griffin2015-11-233-6/+31
|\ | | | | Update and fix forbidden attributes test issues caused by AC::Parameters change
| * Update and fix forbidden attributes testsThomas Walpole2015-11-033-6/+31
| | | | | | | | Add AC::Parameters tests for WhereChain#not
* | Merge pull request #22333 from harrykiselev/patch-3Yves Senn2015-11-211-1/+5
|\ \ | | | | | | | | | [ci skip] Update dirty.rb: documentation fix.
| * | Update dirty.rb: documentation fix.Harry V. Kiselev2015-11-191-1/+5
|/ / | | | | ActiveModel::Dirty module documentation fix.
* / Require only necessary concurrent-ruby classes.Jerry D'Antonio2015-11-041-1/+1
|/
* Really fix test failures caused by #19851Sean Griffin2015-10-201-5/+6
| | | | | | | Ok, this explains why the branch showed as green. We don't run files in isolation for PRs, only for master. Active Support monkeypatches `BigDecimal#to_s`, so the generated error message was different depending on if the file was run in isolation
* Fix test failures caused by #19851Sean Griffin2015-10-201-5/+5
| | | | | | | | | The error message when asserting `greater_than: BigDecimal.new` will give an error message based on how BigDecimal displays itself. Big decimal appears to always use scientific notation. This might not be the best error message for the general case, but the general case wouldn't use big decimal for the validation. And if they do, they likely need this level of precision.
* Merge pull request #19851 from repinel/numericality-validation2Sean Griffin2015-10-202-13/+47
|\ | | | | Use the post-type-cast version of the attribute to validate numericality
| * Conditionally convert the raw_value received by the numeric validator.Roque Pinel2015-07-112-13/+47
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This fixes the issue where you may be comparing (using a numeric validator such as `greater_than`) numbers of a specific Numeric type such as `BigDecimal`. Previous behavior took the numeric value to be validated and unconditionally converted to Float. For example, due to floating point precision, this can cause issues when comparing a Float to a BigDecimal. Consider the following: ``` validates :sub_total, numericality: { greater_than: BigDecimal('97.18') } ``` If the `:sub_total` value BigDecimal.new('97.18') was validated against the above, the following would be valid since `:sub_total` is converted to a Float regardless of its original type. The result therefore becomes Kernel.Float(97.18) > BigDecimal.new('97.18') The above illustrated behavior is corrected with this patch by conditionally converting the value to validate to float. Use the post-type-cast version of the attribute to validate numericality [Roque Pinel & Trevor Wistaff]
generated by cgit v1.2.3 (git 2.25.1) at 2024-11-16 06:08:29 +0000