894 KiB
894 KiB
"id","pr_id","comment_id","author_id","author_name","comment_body","comment_type","created_at"
"245600","91","117255866","964251","scari","Wow! Great job! ??","1","2015-06-30T16:58:13Z"
"245601","92","104802155","1642081","mortada","This would raise if `verify_integrity=True` though, seems like what that was meant for.
```
In [6]: x.append(y, verify_integrity=True)
ValueError: Indexes have overlapping values: [0, 1, 2]
```
Perhaps a good idea to do this?
```
The indexes must not overlap if verify_integrity is True
```","1","2015-05-22T23:36:54Z"
"245602","92","104823908","781659","jakevdp","The documentation of ``verify_integrity`` already says this pretty clearly. I'm not sure the information needs to be repeated in the general description. For what it's worth, [``DataFrame.append``](https://github.com/pydata/pandas/blob/master/pandas/core/frame.py#L3886) and [``pd.concat``](https://github.com/pydata/pandas/blob/master/pandas/tools/merge.py#L700) both have the same behavior, and don't mention anything about duplicate indices in the general description.","1","2015-05-23T03:22:56Z"
"245603","92","104855454","1020496","jorisvandenbossche","I think this looks good!","1","2015-05-23T07:09:34Z"
"245604","92","104873779","1642081","mortada","@jakevdp ah I see, yeah that makes sense","1","2015-05-23T09:31:18Z"
"245605","92","105214261","1020496","jorisvandenbossche","@jakevdp Thanks!","1","2015-05-25T11:29:44Z"
"245606","93","105241650","1020496","jorisvandenbossche","Thanks a lot!","1","2015-05-25T14:17:25Z"
"245607","94","105078870","1217238","shoyer","This need some tests.","1","2015-05-24T23:24:29Z"
"245608","94","105079524","2264215","mayankasthana","I'll add some tests too.
Meanwhile I am trying to fix the build fail due to a stray \xe2 character.","1","2015-05-24T23:32:11Z"
"245609","94","105162974","2264215","mayankasthana","The interpolation argument was added to np.percentile() only in numpy version 1.9.0. The tests don't pass where numpy version < 1.9.0. How to handle this?","1","2015-05-25T08:20:45Z"
"245610","94","105206866","1020496","jorisvandenbossche","For the tests to handle the numpy version, you can do something like this:
```
if _np_version_under1p9:
raise nose.SkipTest('numpy >= 1.9 required')
```","1","2015-05-25T11:02:01Z"
"245611","94","105227199","2264215","mayankasthana","What should happen when numpy version is < 1.9.0?
1. Should quantile() still work and ignore the `interpolation` argument? OR
2. should it fail saying that pd > 1.9 is required?
if 1. , then I can put the `if _np_version_under1p9:` check inside `quantile()` and handle the different numpy versions transparently. We can throw a warning if the interpolation keyword is specified, but not being used (np < 1.9).","1","2015-05-25T12:46:55Z"
"245612","94","105314123","1217238","shoyer","The default interpolation argument should work on all supported versions of NumPy.
For numpy < 1.9.0, it's OK not to support other interpolation options. In these cases, we should raise a `ValueError` with an informative error message. We should certainly not ignore the interpolation argument or merely raise a warning -- that could lead to unanticipated bugs.","1","2015-05-25T21:05:39Z"
"245613","94","105325366","2264215","mayankasthana","Now the default interpolation argument works on all supported versions of NumPy.
And raised `ValueError` if an interpolation method other than `linear` is specified when numpy versions <1.9.
Will add tests soon.","1","2015-05-25T22:08:46Z"
"245614","94","105536049","2264215","mayankasthana","I added tests for Dataframe.quantile . This is my first time writing tests, so please verify if it is done right.
If someone verifies these tests, I'll write the tests for Series.quantile too.","1","2015-05-26T14:05:48Z"
"245615","94","105541162","1020496","jorisvandenbossche","Tests look good! Most important things to be tested is that the keyword is passed to percentile correctly, that it generate an error for older numpy versions, and that the default is not changed. And those are included, so OK!","1","2015-05-26T14:21:48Z"
"245616","94","105550173","2264215","mayankasthana","I added the explicit test that the result with interpolation='linear' and without specifying it is the same.
Also added the github issue number.","1","2015-05-26T14:47:25Z"
"245617","94","105551320","953992","jreback","this is getting to be lots of duplicated code. I would prefer that this all be moved to ``core/generic.py``, see #10207 ","1","2015-05-26T14:50:58Z"
"245618","94","128151252","953992","jreback","can you rebase?","1","2015-08-05T21:14:43Z"
"245619","94","129240362","2264215","mayankasthana","@jreback rebase done!","1","2015-08-09T21:04:48Z"
"245620","94","129410483","953992","jreback","not really sure what you did. you should have 1 commit.
pls see contributing docs: http://pandas.pydata.org/pandas-docs/stable/contributing.html","1","2015-08-10T11:15:26Z"
"245621","94","129428904","2264215","mayankasthana","I screwed up a lot. I fetched upstream and then rebased on that or something.
It's better I close this and create a new pull request following the contributing guide.
@jreback Is there any better way?","1","2015-08-10T12:42:08Z"
"245622","94","129449103","1020496","jorisvandenbossche","@mayankasthana No, there is no need to close this and create a new PR.
Normally, doing this:
```
git fetch upstream
git rebase upstream/master
git push -f origin interpolationQuantile
```
should be all that is needed to clean this up","1","2015-08-10T13:25:30Z"
"245623","94","129626423","2264215","mayankasthana","@jreback Thanks for the help with git. Here is the expected 1 commit. ","1","2015-08-10T21:57:46Z"
"245624","94","129630475","953992","jreback","looks pretty good. pls add a release note.","1","2015-08-10T22:09:59Z"
"245625","94","130314943","2264215","mayankasthana","@jreback @jorisvandenbossche Where should I add the feature description in `v0.17.0.txt`?
Under `Other API Changes` or `Other enhancements`? And does it require a usage example?","1","2015-08-12T14:00:10Z"
"245626","94","130327170","1020496","jorisvandenbossche","You can put it under 'Other enhancements'. A one line sentence explaining it is enough I think.","1","2015-08-12T14:45:35Z"
"245627","94","130539871","2264215","mayankasthana","@jorisvandenbossche @jreback Added release note, rebased to get a single commit. Please review.","1","2015-08-13T05:26:24Z"
"245628","94","132792319","953992","jreback","@mayankasthana can you update","1","2015-08-19T21:28:56Z"
"245629","94","132902721","2264215","mayankasthana","@jreback How can the signature be same for Dataframe.quantile and Series.quantile?
For `Dataframe` it is `def quantile(self, q=0.5, axis=0, numeric_only=True, interpolation='linear')`
and for `Series` it is `def quantile(self, q=0.5, interpolation='linear'):`
So, should the `Series.quantile` be `def quantile(self, q=0.5, axis=0, numeric_only=True, interpolation='linear')` and in the code to `assert` `axis=0` and `numeric_only=True`?
How would the usage for `Series.quantile` be? For using interpolation, only named parameter will have to be used.
As for the update, I'll finish this up by tonight.","1","2015-08-20T06:05:16Z"
"245630","94","132926207","1020496","jorisvandenbossche","It is true that the signatures are quite different (Series.quantile does not accept axis at the moment), so I think it is OK to leave that for another PR (combining them into generic.py).","1","2015-08-20T08:05:06Z"
"245631","94","133044000","953992","jreback","@mayankasthana I don't think its a big deal to make these have the same signature. just add to ``Series`` ``axis/numeric_only``.","1","2015-08-20T15:09:28Z"
"245632","94","133056412","2264215","mayankasthana","@jreback I didn't mean the method signatures. I meant that the doc strings are too different to be made generic with replacements.
For example, the return value for `DataFrame.quantile` is `Series or DataFrame`, and for `Series.quantile` it is `float or Series`.
The examples I saw of replacements are like this `@Appender(_shared_docs['boxplot'] % _shared_doc_kwargs)` with the `_shared_doc_kwargs` having the `DataFrame` or `Series` specific args, which are very simple replacements (Eg. `dict(axes='index, columns', klass='DataFrame',
axes_single_arg=""{0, 1, 'index', 'columns'}"")`.
But these simple replacements from a generic `_shared_doc` won't work here because the return values, the parameters, examples are very different.
Am I understanding what you want correctly?","1","2015-08-20T15:44:57Z"
"245633","94","133832705","953992","jreback","note that you will need to rebase as https://github.com/pydata/pandas/pull/10881 was merged","1","2015-08-23T13:29:03Z"
"245634","94","136687904","953992","jreback","pls rebase and address comments","1","2015-09-01T11:58:34Z"
"245635","94","137662403","2264215","mayankasthana","@jreback Rebased. Test is green.","1","2015-09-04T07:08:51Z"
"245636","94","141540049","2264215","mayankasthana","@jreback Rebased. Test is green.","1","2015-09-18T19:13:00Z"
"245637","95","105483107","953992","jreback","thanks!","1","2015-05-26T10:32:59Z"
"245638","97","105612078","1217238","shoyer","thanks!","1","2015-05-26T17:28:26Z"
"245639","98","105667862","1020496","jorisvandenbossche","I agree that the `left_index=True, right_index=True` is rather verbose, and some improvement of the API is welcome here. Thanks for initiating this!
But I also agree this (using `on=pd.Index`) is bit hacky, or at least, not really consistent with how such things are done in the rest of pandas.
So maybe it is also worth looking at what could be alternatives, before deciding on the API?
- a new keyword, e.g. `on_index=True`
- promote `df1.join(df2)`, which joins on the index by default
- add a `pd.join(df1, df2)` that does the same as `DataFrame.join` (similar to pd.merge vs DataFrame.merge). So a `pd.merge` alternative that has different defaults
- ...
Other ideas?","1","2015-05-26T21:18:10Z"
"245640","98","105674607","781659","jakevdp","Thanks! I didn't realize that ``df.join()`` will join on index by default. Perhaps just emphasizing/promoting that more would be sufficient?","1","2015-05-26T21:43:21Z"
"245641","98","108085263","953992","jreback","@jakevdp would love to have an addition to the docs to emphasize this. ","1","2015-06-02T20:18:04Z"
"245642","98","108146276","1217238","shoyer","FWIW, I have always been confused about the distinction between `pd.merge` and `pd.join`.","1","2015-06-03T01:03:38Z"
"245643","98","125766677","953992","jreback","closing as this is just diff between ``merge`` and defaults in ``join``. suppose docs could be added.","1","2015-07-28T22:04:14Z"
"245644","99","105704635","1312546","TomAugspurger","Ok, good to merge when Travis is green. Thanks!","1","2015-05-27T00:39:20Z"
"245645","5061","87968666","1153097","Narretz","I'll check in 30 minutes ?
----- Ursprüngliche Nachricht -----
Von: ""Pete Bacon Darwin"" <notifications@github.com>
Gesendet: 31.03.2015 08:43
An: ""angular/angular.js"" <angular.js@noreply.github.com>
Cc: ""Martin Staffa"" <mjstaffa@googlemail.com>
Betreff: Re: [angular.js] fix(ngAnimate): ensure that minified repaint codeisn't removed (#11469)
LGTM. @Narretz does this work for you?
—
Reply to this email directly or view it on GitHub.","1","2015-03-31T07:02:44Z"
"245646","5061","87969054","15655","petebacondarwin","Fine by me
On 31 Mar 2015 08:04, ""Matias Niemelä"" <notifications@github.com> wrote:
> @petebacondarwin <https://github.com/petebacondarwin> @Narretz
> <https://github.com/Narretz>'s code was having issues with #11336
> <https://github.com/angular/angular.js/pull/11336>. So this PR won't be
> compatible with the issues he's facing. However this issue still does exist
> for other versions of Angular and this patch corrects that.
>
> —
> Reply to this email directly or view it on GitHub
> <https://github.com/angular/angular.js/pull/11469#issuecomment-87968655>.
>
","1","2015-03-31T07:05:24Z"
"245647","5061","87983105","1153097","Narretz","Ah, I didn't see this was a new issue. Interesting, I never had this problem in Firefox before. At least not as visible.","1","2015-03-31T07:48:52Z"
"245648","5061","88247869","93018","matsko","MERGED
Landed as:
https://github.com/angular/angular.js/commit/c55a494433e619aad0c7ef9fddadc0b3fdf53915
https://github.com/angular/angular.js/commit/d5c99ea42b834343fd0362cfc572f47e7536ccfb
https://github.com/angular/angular.js/commit/b041b664752e34a42bbc65e02bf0009f0836c50c","1","2015-03-31T21:07:11Z"
"245649","5062","8124265","747138","thomseddon","Tested working, (thanks)","1","2012-08-29T12:59:01Z"
"245650","5062","8278551","111951","mhevery","Thanks for your contribution! In order for us to be able to accept it, we ask you to sign our CLA (contributor's license agreement).
CLA is important for us to be able to avoid legal troubles down the road.
For individuals (a simple click-through form):
http://code.google.com/legal/individual-cla-v1.0.html
For corporations (print, sign and scan+email, fax or mail):
http://code.google.com/legal/corporate-cla-v1.0.html","1","2012-09-04T20:55:49Z"
"245651","5062","8296140","1157864","andresmoschini","I have accepted the contributor agreement.
Regarding adding tests, I could, but maybe in about a week or two because I am a little busy right now.","1","2012-09-05T12:22:41Z"
"245652","5062","9028550","144792","Enome","Would like to see this feature in angular.","1","2012-10-01T11:38:35Z"
"245653","5062","10203773","973550","pkozlowski-opensource","It would be very useful addition to angular's routing system. It is a pity that this PR doesn't have an associated test nor documentation changes :-(
Also, this PR introduces a new syntax for route params, so we would have:
* `:param` for a single param
* `*param` for catch-all params
On top of this I'm not clear if those catch-all routes should be supported only at the end of a URL or in a middle as well. Test and documentation changes should explain this.
@andresmoschini are you planning to add tests / documentation to this PR?","1","2012-11-08T20:35:27Z"
"245654","5062","10206612","1157864","andresmoschini","I am sorry, but we are not using Angular right now and I am a little busy to add test and documentation.
Right now both `edit/color/:color/largecode/*largecode` and `edit/largecode/*largecode/color/:color/` works.","1","2012-11-08T21:53:11Z"
"245655","5062","10268302","547387","lrlopez","I also find it a rather useful improvement. @andresmoschini and @pkozlowski-opensource , would you mind if I implement the required tests and the documentation?","1","2012-11-11T15:28:08Z"
"245656","5458","119961999","6240529","Mohamed5amy","I signed it! ?
On Thu, Jul 9, 2015 at 3:11 PM, googlebot <notifications@github.com> wrote:
> Thanks for your pull request. It looks like this may be your first
> contribution to a Google open source project, in which case you'll need to
> sign a Contributor License Agreement (CLA).
>
> [image: :memo:] *Please visit https://cla.developers.google.com/
> <https://cla.developers.google.com/> to sign.*
>
> Once you've signed, please reply here (e.g. I signed it!) and we'll
> verify. Thanks.
> ------------------------------
>
> - If you've already signed a CLA, it's possible we don't have your
> GitHub username or you're using a different email address. Check your
> existing CLA data <https://cla.developers.google.com/clas> and verify
> that your email is set on your git commits
> <https://help.github.com/articles/setting-your-email-in-git/>.
> - If you signed the CLA as a corporation, please let us know the
> company's name.
>
> —
> Reply to this email directly or view it on GitHub
> <https://github.com/angular/angular.js/pull/12314#issuecomment-119955870>.
>
","1","2015-07-09T13:20:55Z"
"245657","5458","119962006","5384588","googlebot","CLAs look good, thanks!
<!-- ok -->","1","2015-07-09T13:20:57Z"
"245658","5459","121734817","127199","christianvuerings","@petebacondarwin - could you have a look at this PR? Let me know if you would like me to make any changes.","1","2015-07-15T20:20:34Z"
"245659","5459","121761923","15655","petebacondarwin","I'll take a look in the next week","1","2015-07-15T21:58:45Z"
"245660","5459","121767435","127199","christianvuerings","@petebacondarwin thanks!","1","2015-07-15T22:29:07Z"
"245661","5459","123042526","15655","petebacondarwin","This is a big breaking change so will have to go into 1.5.
We also need to have a clear message for what people need to do if they rely on this `ngClick` implementation. We need to update the docs for `ngTouch` and the migration guide doc. In these docs we should talk about how to use fastclick.js and why we are proposing that rather than what we had before.
Also I think the breaking change message should be a bit more involved - is it really simply a case of loading fastclick.js or do we need to do some configuration?
Finally do we have any examples or e2e tests that rely on this behaviour?","1","2015-07-20T21:17:15Z"
"245662","5460","120229717","5384588","googlebot","Thanks for your pull request. It looks like this may be your first contribution to a Google open source project, in which case you'll need to sign a Contributor License Agreement (CLA).
:memo: **Please visit <https://cla.developers.google.com/> to sign.**
Once you've signed, please reply here (e.g. `I signed it!`) and we'll verify. Thanks.
---
- If you've already signed a CLA, it's possible we don't have your GitHub username or you're using a different email address. Check [your existing CLA data](https://cla.developers.google.com/clas) and verify that your [email is set on your git commits](https://help.github.com/articles/setting-your-email-in-git/).
- If you signed the CLA as a corporation, please let us know the company's name.
<!-- need_sender_cla -->","1","2015-07-10T05:14:29Z"
"245663","5460","120232880","11195840","joelviseu","I signed it!","1","2015-07-10T05:27:16Z"
"245664","5460","120232889","5384588","googlebot","CLAs look good, thanks!
<!-- ok -->","1","2015-07-10T05:27:18Z"
"245665","5460","120285405","973550","pkozlowski-opensource","@joelviseu this sounds like a potential 3rd party module that you should maintain and submit to http://ngmodules.org/ (or similar repo), but it doesn't belong to the core. Thnx for the proposal, though.","1","2015-07-10T08:14:10Z"
"245666","5461","8177692","111951","mhevery","Thanks for your contribution! In order for us to be able to accept it, we ask you to sign our CLA (contributor's license agreement).
CLA is important for us to be able to avoid legal troubles down the road.
For individuals (a simple click-through form):
http://code.google.com/legal/individual-cla-v1.0.html
For corporations (print, sign and scan+email, fax or mail):
http://code.google.com/legal/corporate-cla-v1.0.html
","1","2012-08-30T23:07:05Z"
"245667","5462","120386514","5384588","googlebot","Thanks for your pull request. It looks like this may be your first contribution to a Google open source project, in which case you'll need to sign a Contributor License Agreement (CLA).
:memo: **Please visit <https://cla.developers.google.com/> to sign.**
Once you've signed, please reply here (e.g. `I signed it!`) and we'll verify. Thanks.
---
- If you've already signed a CLA, it's possible we don't have your GitHub username or you're using a different email address. Check [your existing CLA data](https://cla.developers.google.com/clas) and verify that your [email is set on your git commits](https://help.github.com/articles/setting-your-email-in-git/).
- If you signed the CLA as a corporation, please let us know the company's name.
<!-- need_sender_cla -->","1","2015-07-10T11:08:50Z"
"245668","5462","120558981","8806001","APassanisi","I signed it!","1","2015-07-11T01:11:35Z"
"245669","5462","120558983","5384588","googlebot","CLAs look good, thanks!
<!-- ok -->","1","2015-07-11T01:11:37Z"
"245670","5463","120453477","5384588","googlebot","Thanks for your pull request. It looks like this may be your first contribution to a Google open source project, in which case you'll need to sign a Contributor License Agreement (CLA).
:memo: **Please visit <https://cla.developers.google.com/> to sign.**
Once you've signed, please reply here (e.g. `I signed it!`) and we'll verify. Thanks.
---
- If you've already signed a CLA, it's possible we don't have your GitHub username or you're using a different email address. Check [your existing CLA data](https://cla.developers.google.com/clas) and verify that your [email is set on your git commits](https://help.github.com/articles/setting-your-email-in-git/).
- If you signed the CLA as a corporation, please let us know the company's name.
<!-- need_sender_cla -->","1","2015-07-10T16:34:10Z"
"245671","5463","120456195","5555468","AlexanderZon","I signed it!","1","2015-07-10T16:46:43Z"
"245672","5463","120456200","5384588","googlebot","CLAs look good, thanks!
<!-- ok -->","1","2015-07-10T16:46:45Z"
"245673","5463","120475644","1153097","Narretz","We are using https://github.com/google/closure-library/tree/master/closure/goog/i18n for our locale files. So any bugs must either be fixed in the library, or we must import the library to update the code. Would you be able to check if this is still bugged in closure?","1","2015-07-10T17:44:54Z"
"245674","5463","120761871","391394","lgalfaso","This should get fixed once #12307 lands","1","2015-07-12T21:01:19Z"
"245675","5464","120564683","5384588","googlebot","Thanks for your pull request. It looks like this may be your first contribution to a Google open source project, in which case you'll need to sign a Contributor License Agreement (CLA).
:memo: **Please visit <https://cla.developers.google.com/> to sign.**
Once you've signed, please reply here (e.g. `I signed it!`) and we'll verify. Thanks.
---
- If you've already signed a CLA, it's possible we don't have your GitHub username or you're using a different email address. Check [your existing CLA data](https://cla.developers.google.com/clas) and verify that your [email is set on your git commits](https://help.github.com/articles/setting-your-email-in-git/).
- If you signed the CLA as a corporation, please let us know the company's name.
<!-- need_sender_cla -->","1","2015-07-11T02:31:15Z"
"245676","5464","120564803","1940369","ddavtian","I signed it!
> On Jul 10, 2015, at 7:33 PM, googlebot <notifications@github.com> wrote:
>
> Thanks for your pull request. It looks like this may be your first contribution to a Google open source project, in which case you'll need to sign a Contributor License Agreement (CLA).
>
> Please visit https://cla.developers.google.com/ <https://cla.developers.google.com/> to sign.
>
> Once you've signed, please reply here (e.g. I signed it!) and we'll verify. Thanks.
>
> If you've already signed a CLA, it's possible we don't have your GitHub username or you're using a different email address. Check your existing CLA data <https://cla.developers.google.com/clas> and verify that your email is set on your git commits <https://help.github.com/articles/setting-your-email-in-git/>.
> If you signed the CLA as a corporation, please let us know the company's name.
> —
> Reply to this email directly or view it on GitHub <https://github.com/angular/angular.js/pull/12325#issuecomment-120564683>.
>
","1","2015-07-11T02:34:50Z"
"245677","5464","120564804","5384588","googlebot","CLAs look good, thanks!
<!-- ok -->","1","2015-07-11T02:34:51Z"
"245678","5465","120574037","5384588","googlebot","Thanks for your pull request. It looks like this may be your first contribution to a Google open source project, in which case you'll need to sign a Contributor License Agreement (CLA).
:memo: **Please visit <https://cla.developers.google.com/> to sign.**
Once you've signed, please reply here (e.g. `I signed it!`) and we'll verify. Thanks.
---
- If you've already signed a CLA, it's possible we don't have your GitHub username or you're using a different email address. Check [your existing CLA data](https://cla.developers.google.com/clas) and verify that your [email is set on your git commits](https://help.github.com/articles/setting-your-email-in-git/).
- If you signed the CLA as a corporation, please let us know the company's name.
<!-- need_sender_cla -->","1","2015-07-11T05:22:13Z"
"245679","5465","120580456","459272","maurya777","I signed it!","1","2015-07-11T06:07:43Z"
"245680","5465","120580458","5384588","googlebot","CLAs look good, thanks!
<!-- ok -->","1","2015-07-11T06:07:44Z"
"245681","5466","120615167","5384588","googlebot","Thanks for your pull request. It looks like this may be your first contribution to a Google open source project, in which case you'll need to sign a Contributor License Agreement (CLA).
:memo: **Please visit <https://cla.developers.google.com/> to sign.**
Once you've signed, please reply here (e.g. `I signed it!`) and we'll verify. Thanks.
---
- If you've already signed a CLA, it's possible we don't have your GitHub username or you're using a different email address. Check [your existing CLA data](https://cla.developers.google.com/clas) and verify that your [email is set on your git commits](https://help.github.com/articles/setting-your-email-in-git/).
- If you signed the CLA as a corporation, please let us know the company's name.
<!-- need_sender_cla -->","1","2015-07-11T13:02:44Z"
"245682","5466","120615230","5570504","TommyZG","I signed it!","1","2015-07-11T13:04:35Z"
"245683","5466","120615232","5384588","googlebot","CLAs look good, thanks!
<!-- ok -->","1","2015-07-11T13:04:36Z"
"245684","5466","120998158","1153097","Narretz","Thanks for the PR. However, ngLocale basically imports the i18n part of https://github.com/google/closure-library, so all fixes must be made there before they can land in angular.","1","2015-07-13T17:21:46Z"
"245685","5467","121429182","1327886","tealtail","Thanks for pointing me in the right direction. I've updated the PR.","1","2015-07-14T23:38:22Z"
"245686","5467","121532720","1153097","Narretz","@tealtail Thanks! The final thing we need now is a test that ensures, we only decrement the counter if an element has actually been removed from the cache.","1","2015-07-15T08:45:00Z"
"245687","5467","121770650","391394","lgalfaso","Just to complement what @Narretz just said. A test that without this chance would fail.","1","2015-07-15T22:48:40Z"
"245688","5467","121775644","1327886","tealtail","Alright, I've added a new test case to `cacheFactorySpec.js`. Let me know if I need to make any changes.","1","2015-07-15T23:31:16Z"
"245689","5467","121776921","391394","lgalfaso","besides the comment, and that a test on the LRU case would be great. LGTM","1","2015-07-15T23:41:55Z"
"245690","5467","121789186","1327886","tealtail","Now using `createMap` when creating `lruHash`, and I've added the additional test using `hasOwnProperty` as a key. You mentioned an LRU test as well, but I'm not sure what the desired test case is for that.","1","2015-07-16T00:31:00Z"
"245691","5467","121870426","8604205","gkalpak","Regarding the `lruHash` test, it is not easy to test it directly without its being exposed, but an indirect test is described in this [CodePen][1].
Basically, it relies on the fact that when calling `cache.get(key)` and the cache instance has a capacity (less than `Number.MAX_VALUE`), it will look `key` up in the `lruHash` and call `refresh(entry)`, which in turn will call `link(entry, ...)`, which in turn will add `entry.n` and `entry.p` properties.
It's quite indirect though :confused:
---
Not directly related to this PR, but the `destroy` method needs some massaging I think.
(At the very least, unsetting `freshEnd` and `staleEnd`, to allow them to be GC'ed. You can make a different PR if you fancy :smiley:)
[1]: http://codepen.io/ExpertSystem/pen/VLdoGZ?editors=001","1","2015-07-16T07:58:05Z"
"245692","5469","120706628","973550","pkozlowski-opensource","It sounds like a good addition, but it definitively need tests before it can be merged. @gabrielmaldi could you please add tests for this change? You can use the existing ones as inspiration.","1","2015-07-12T10:29:58Z"
"245693","5469","120761588","3728897","gabrielmaldi","I added one test for `toJSON`, think it's enough because there already are others which test object serialization.","1","2015-07-12T20:56:00Z"
"245694","5469","120761765","391394","lgalfaso","Given the breaking chance nature, I am leaning on moving this to 1.5. @petebacondarwin WDYT?","1","2015-07-12T20:59:07Z"
"245695","5469","122201546","3728897","gabrielmaldi","I made an adjustment:
The call to `serializeValue(toSerialize)` returned a quoted string because `JSON.stringify(""baz"") === """"baz""""` (and then `encodeUriQuery` would turn that into `%22baz%22`).
So now we call `toSerialize.toJSON()` directly and get `""baz""`.","1","2015-07-17T07:23:57Z"
"245696","5469","144217394","3728897","gabrielmaldi","Hey guys, I rebased my changes. Now that `1.5.0-beta.1` is out maybe we can continue working on this PR?","1","2015-09-29T23:11:43Z"
"245697","5469","159664425","3728897","gabrielmaldi","I found a problem when a `Resource` is serialized.
`Resource` defines `toJSON` [here](https://github.com/angular/angular.js/blob/98528be311b48269ba0e15ba4e3e2ad9b89693a9/src/ngResource/resource.js#L570-L575), but it doesn't return a string, it returns the same object (cloned) minus a couple of properties.
Since `toJSON` is defined, it falls into this case:
```js
} else if (isFunction(toSerialize.toJSON)) {
parts.push(encodeUriQuery(prefix) + '=' + encodeUriQuery(toSerialize.toJSON()));
```
And everything ends up with `""[object Object]""`.
I didn't find a place where `Resource.prototype.toJSON` is called explicitly. I did find [this test](https://github.com/angular/angular.js/blob/98528be311b48269ba0e15ba4e3e2ad9b89693a9/test/ngResource/resourceSpec.js#L679-L693).
If `toJSON` is not used, perhaps we could remove it? If it is in fact used, it is weird that it doesn't conform to what `toJSON` is expected to do (i.e. return a string), but if we change that we may break things. We could rename `Resource.prototype.toJSON` to something else. Or make a special case for `Resource` in this PR:
```js
} else if (isFunction(toSerialize.toJSON) && toSerialize.constructor.name !== ""Resource"") {
parts.push(encodeUriQuery(prefix) + '=' + encodeUriQuery(toSerialize.toJSON()));
```
But this is very fragile because of the use of `.constructor.name` and also depending on `""Resource""` which could be another object.
What do you guys think?
Thanks!","1","2015-11-25T16:34:11Z"
"245698","5469","159874961","8604205","gkalpak","> If toJSON is not used, perhaps we could remove it?
It is used implicitly by `JSON.stringify()` when the object is converted to JSON. This is not something Angular-specific, it's plain old JavaScript.
See [`toJSON()` on MDN][1].
--
> If it is in fact used, it is weird that it doesn't conform to what toJSON is expected to do (i.e. return a string)
It **does** conform to what `toJSON()` is expected to do (see link above). The name isn't very intuitive indeed, but `toJSON()` is supposed to return _the value to be serialized_ (and **not** _the serialized value_).
---
WRT to this PR in general, I am not sure if it is a good idea to take `toJSON()` into account, since it's purpose is very specific (to be used when converting to JSON) and we are doing something completely different (serializing an object as URL query params according to jQuery's conventions).
If jQuery does that (which I don't think it should - but that is irrelevant), we should do it too in order to be consistent. But if jQuery doesn't do it, then neither should we.
[1]: https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/JSON/stringify#toJSON()_behavior","1","2015-11-26T10:42:07Z"
"245699","5469","159972332","3728897","gabrielmaldi","I had read that MDN article but I guess that since in their example they return a string, it wasn't immediatly obvious to me that
> the value returned by the toJSON() method when called will be serialized
meant that you should return
> the value to be serialized (and not the serialized value).
Sorry about that and thanks for clarifying!
> If jQuery does that (which I don't think it should - but that is irrelevant), we should do it too in order to be consistent. But if jQuery doesn't do it, then neither should we.
I ran some tests on jQuery and Angular with and without this PR:
-----
##### jQuery
```js
jQuery.param({
myObject: {
prop1: 'value1',
toJSON: function () {
return 'anotherValue';
}
}
});
```
`""myObject%5Bprop1%5D=value1&myObject%5BtoJSON%5D=anotherValue""`
```js
jQuery.param({
myObject: {
prop1: 'value1',
func1: function () {
return { 'prop2': 'value2' };
}
}
});
```
`""myObject%5Bprop1%5D=value1&myObject%5Bfunc1%5D=%5Bobject+Object%5D""`
-----
##### Angular without this PR
```js
jqrSer({
myObject: {
prop1: 'value1',
toJSON: function () {
return 'anotherValue';
}
}
});
```
`""myObject%5Bprop1%5D=value1&myObject%5BtoJSON%5D=function+()+%7B%0A++++++++++++return+'anotherValue';%0A++++++++%7D""`
```js
jqrSer({
myObject: {
prop1: 'value1',
func1: function () {
return { 'prop2': 'value2' };
}
}
});
```
`""myObject%5Bfunc1%5D=function+()+%7B%0A++++++++++++return+%7B+'prop2':+'value2'+%7D;%0A++++++++%7D&myObject%5Bprop1%5D=value1""`
-----
##### Angular with this PR
```js
jqrSer({
myObject: {
prop1: 'value1',
toJSON: function () {
return 'anotherValue';
}
}
});
```
`""myObject=anotherValue""`
```js
jqrSer({
myObject: {
prop1: 'value1',
func1: function () {
return { 'prop2': 'value2' };
}
}
});
```
`""myObject%5Bfunc1%5D=function+()+%7B%0A++++++++++++return+%7B+'prop2':+'value2'+%7D;%0A++++++++%7D&myObject%5Bprop1%5D=value1""`
-----
The first thing that emerges (from the very first test) is that jQuery doesn't use `toJSON` to get the value of the object.
However, it seems that jQuery also includes the values returned by any functions (it doesn't treat `toJSON` specially in this regard, it treats it like any other function), and if the function returns another object, it doesn't serialize it recursively.
Angular is currently not consistent with this behaviour. I don't like jQuery's behaviour either, I'd ditch serializing functions altogether. But if jQuery does it this way, should we too? I don't know if consistency with jQuery should be the only deciding factor here, because what it is doing with funcions is IMHO nonsense (what we are doing is too). Also, jQuery doesn't sort parameters while Angular does (should we switch from `forEachSorted` to `forEach`?), so we're not currently replicating jQuery's logic strictly.
If it were up to me, I wouldn't serialize functions and I'd take `toJSON` into account; after all, if `toJSON` is defined in an object, it means that you want another representation of that object to be used when serializing, either if you are serializing to JSON or to query string params. I think this is a reasonable assumption that devs would make.
I updated the PR with these changes and added a couple of tests. This also solves the problem with `Resource` (since we now support `toJSON` returning an object as well as a string), and continues to work fine with dates and `Moment.js` moments (which was the motivation behind this PR).
Thanks for your time!","1","2015-11-26T18:19:17Z"
"245700","5470","120877477","5384588","googlebot","Thanks for your pull request. It looks like this may be your first contribution to a Google open source project, in which case you'll need to sign a Contributor License Agreement (CLA).
:memo: **Please visit <https://cla.developers.google.com/> to sign.**
Once you've signed, please reply here (e.g. `I signed it!`) and we'll verify. Thanks.
---
- If you've already signed a CLA, it's possible we don't have your GitHub username or you're using a different email address. Check [your existing CLA data](https://cla.developers.google.com/clas) and verify that your [email is set on your git commits](https://help.github.com/articles/setting-your-email-in-git/).
- If you signed the CLA as a corporation, please let us know the company's name.
<!-- need_sender_cla -->","1","2015-07-13T09:54:57Z"
"245701","5472","8282070","111951","mhevery","Thanks for the pull request. I am not sure we want to make this API public. Could you justify your use case?
For now I am going to close this. Feel free to reopen it if you can provide a use case which makes sense.
Also:
Thanks for your contribution! In order for us to be able to accept it, we ask you to sign our CLA (contributor's license agreement).
CLA is important for us to be able to avoid legal troubles down the road.
For individuals (a simple click-through form):
http://code.google.com/legal/individual-cla-v1.0.html
For corporations (print, sign and scan+email, fax or mail):
http://code.google.com/legal/corporate-cla-v1.0.html","1","2012-09-04T22:59:36Z"
"245702","5474","121353633","15655","petebacondarwin","@jdalton, @realityking, @lgalfaso and @btford - can you take a look?","1","2015-07-14T19:43:25Z"
"245703","5474","121377254","628508","realityking","@petebacondarwin I like it (a lot)!","1","2015-07-14T20:37:42Z"
"245704","5474","121760880","15655","petebacondarwin","I have added a commit with changes thanks to the feedback.","1","2015-07-15T21:52:53Z"
"245705","5474","121761624","8604205","gkalpak","LGTM :+1:","1","2015-07-15T21:56:52Z"
"245706","5474","122034608","474988","btford",":+1: ","1","2015-07-16T17:53:28Z"
"245707","5475","121746359","8604205","gkalpak","LGTM
<sub>The implementation seems unnecessarily complex imo. I don't have proof though and since I can't spot any functional issue/bug (e.g. as was the case with the previous implementation), I'll leave it to the LGTM :smile:</sub>","1","2015-07-15T21:02:17Z"
"245708","5475","132402688","93018","matsko","Closed in favour of: https://github.com/angular/angular.js/pull/12619","1","2015-08-19T00:29:21Z"
"245709","5476","121528212","2579336","jniebuhr","Well I guess the build failing wasn't rly my fault.","1","2015-07-15T08:31:26Z"
"245710","5476","121619843","15655","petebacondarwin","I am a bit torn about this.
On the surface don't really like this idea since we are undermining the standard.
But then again I see that accepting `=` chars after the first char is not going to break valid fully encoded URL query strings.
While I can see that it would make life much easier in the cases where `=` characters were inadvertently un-encoded, it is a special case. What happens if there is an unencoded `&` in the value?","1","2015-07-15T13:37:37Z"
"245711","5476","121712603","2579336","jniebuhr","If there is an unencoded & in the string, something is rly wrong and that can't be solved. The case I needed this for are base64 encoded strings.","1","2015-07-15T18:59:05Z"
"245712","5476","121774216","391394","lgalfaso","Even when I agree with @petebacondarwin that this does not follow the spec, the behavior in the PR is how most servers handle unencoded `=`","1","2015-07-15T23:18:32Z"
"245713","5476","122040814","15655","petebacondarwin","OK, if @lgalfaso is happy then I am happy. I think we can improve the algorithm and then land this.","1","2015-07-16T18:23:18Z"
"245714","5476","122042740","2579336","jniebuhr","Sounds great, will this be available in any 1.2.* version? That's the version my project currently runs on.","1","2015-07-16T18:31:47Z"
"245715","5476","123041228","15655","petebacondarwin","We are only putting security fixes into 1.2 but I guess since you asked so nicely we could consider backporting this in.","1","2015-07-20T21:12:50Z"
"245716","5476","124848398","391394","lgalfaso","The version I posted or the version from @petebacondarwin works fine with me. @jniebuhr can you please update the PR?","1","2015-07-25T13:47:41Z"
"245717","5477","121647071","2294695","caitp","looks okay to me, I think","1","2015-07-15T15:12:24Z"
"245718","5477","122581337","489010","matthewjh","Cool. Please can you merge this in, @caitp?","1","2015-07-18T19:11:54Z"
"245719","5478","122032467","15655","petebacondarwin","LGTM!!","1","2015-07-16T17:44:04Z"
"245720","5479","121898934","5384588","googlebot","Thanks for your pull request. It looks like this may be your first contribution to a Google open source project, in which case you'll need to sign a Contributor License Agreement (CLA).
:memo: **Please visit <https://cla.developers.google.com/> to sign.**
Once you've signed, please reply here (e.g. `I signed it!`) and we'll verify. Thanks.
---
- If you've already signed a CLA, it's possible we don't have your GitHub username or you're using a different email address. Check [your existing CLA data](https://cla.developers.google.com/clas) and verify that your [email is set on your git commits](https://help.github.com/articles/setting-your-email-in-git/).
- If you signed the CLA as a corporation, please let us know the company's name.
<!-- need_sender_cla -->","1","2015-07-16T09:28:39Z"
"245721","5479","121971130","1110441","dod38fr","Mon company (HP) has a corporate agreement. My work address is dominique.dumont at hp.com","1","2015-07-16T14:24:01Z"
"245722","5479","122069933","1608223","jnizet","As far as I understand the code, the url passed to $http() or $http.get() is not the actual key of the cache. The key is the url of the config followed by the query string built from the parameters:
var url = buildUrl(config.url, config.paramSerializer(config.params));
So I think the suggested addition would make things more confusing: readers might fear that parameters are not taken into account, or might expect a cached response to be evicted if they don't take parameters into account.","1","2015-07-16T19:53:36Z"
"245723","5479","122201099","1110441","dod38fr","So, if I understand correctly, there's no simple way to clean up the cache passed to `$http.get` except by calling `removeAll()` (which clean *all* cache entries instead of just one).
Is this assessment correct ?","1","2015-07-17T07:20:42Z"
"245724","5479","122251525","8604205","gkalpak","@dod38fr, there is indeed no simple way to know the key if you are using query parameters.
It's not super complex or impossible to build the key yourself (you have all necessary pieces (`url`, `params`, `paramSerializer`) and the implementation of `buildUrl()` is really simple), but I definitely wouldn't recommend it.
Depending on your usecase, you might be able to create a very simple wrapper around a cache that does what you want.","1","2015-07-17T11:31:10Z"
"245725","5479","122251939","8604205","gkalpak","BTW, I agree with @jnizet - the suggested docs addition is inaccurate and could prove misleading.","1","2015-07-17T11:34:17Z"
"245726","5479","122257659","1110441","dod38fr","@gkalpak , the use case is: I have a remote storage that I mostly read from and sometimes write to. When I write to this remote storage, the next read should contain the data that was just written. Hence the need to invalidate the cache for a specific URL.
This is currently not possible using the simple cache facility provided by `$http`.
BTW, I agree with both of you. The doc modif I suggest is not good currently. I'll amend it or close this PR.
I just wish there was a simple way to know the cache key used by `$http`. Would it be possible to modify `$http` to provide this cache key in the `then` callback ? With this information, managing the cache content would then be possible.","1","2015-07-17T12:09:54Z"
"245727","5479","122403861","8604205","gkalpak","There are several ways to achieve the same I guess, but off the top of my head, I would try something [that][1].
(I.e. augment the cache used by `$http` to store the key somewhere.)
[1]: http://codepen.io/ExpertSystem/pen/NqBwWE?editors=101","1","2015-07-17T20:29:19Z"
"245728","5479","122974277","1110441","dod38fr","There's also a more simple (even if more resource consuming) way: use one cache object per API endpoint and use `removeAll` on this object when the cache needs to be flushed.
This avoid adding more complexity in my project for a problem that should be handled by AngularJS framework.
I agree that the augment trick may not be much by itself, but it adds up with other workarounds and make on-boarding of new developers much more difficult.","1","2015-07-20T18:22:05Z"
"245729","5479","127368605","1153097","Narretz","Ok, it looks like the docs changes are not really correct. I am gonna close this then. Still, @dod38fr, thanks for contribution - you can open a new issue that addresses the problem with getting the cache key and / or another PR that correctly explains what the cache key is for $http is.","1","2015-08-03T18:50:34Z"
"245730","5480","122236029","1153097","Narretz","Is this resolved by https://github.com/angular/angular.js/commit/9e492c358c19549696577c86c2c61b93f50ab356 and https://github.com/angular/angular.js/commit/92c7ce5becb9b90216c49f50e0f57f5dbeda8eba?","1","2015-07-17T10:12:19Z"
"245731","5480","122265779","15655","petebacondarwin","Yes. ","1","2015-07-17T12:53:47Z"
"245732","5481","122019268","391394","lgalfaso","Please add Closes #12307. Otherwise, LGTM","1","2015-07-16T16:51:35Z"
"245733","5483","122430945","808755","snayagar","Looks like this is by design...I don't know why.","1","2015-07-17T22:10:11Z"
"245734","5484","122526805","5384588","googlebot","Thanks for your pull request. It looks like this may be your first contribution to a Google open source project, in which case you'll need to sign a Contributor License Agreement (CLA).
:memo: **Please visit <https://cla.developers.google.com/> to sign.**
Once you've signed, please reply here (e.g. `I signed it!`) and we'll verify. Thanks.
---
- If you've already signed a CLA, it's possible we don't have your GitHub username or you're using a different email address. Check [your existing CLA data](https://cla.developers.google.com/clas) and verify that your [email is set on your git commits](https://help.github.com/articles/setting-your-email-in-git/).
- If you signed the CLA as a corporation, please let us know the company's name.
<!-- need_sender_cla -->","1","2015-07-18T10:16:01Z"
"245735","5484","122526917","9882445","RolfDeVries","I signed it!","1","2015-07-18T10:17:29Z"
"245736","5484","122526919","5384588","googlebot","CLAs look good, thanks!
<!-- ok -->","1","2015-07-18T10:17:31Z"
"245737","5484","122532976","391394","lgalfaso","Would it be possible to see a plunker and a test that triggers this issue?
","1","2015-07-18T11:35:30Z"
"245738","5484","122814050","9882445","RolfDeVries","I'm sorry the issue was filed a while ago in our app, and we don't have a test not a plunker.
As I agree the issue is somewhat strange, because $window is initialized and should not become null.
It is found only on a WP8.1 which makes it even harder to debug.
But as you can see the check is quite simple and harmless, so should cause no issues.
Can you please pull in the request so we don't have to change the code after each new release, thanks!
Here is some more detailed information for our logs:
""device"": ""{\""ua\"":\""Mozilla/5.0 (Mobile; Windows Phone 8.1; Android 4.0; ARM; Trident/7.0; Touch; WebView/2.0; rv:11.0; IEMobile/11.0; NOKIA; Lumia 820) like iPhone OS 7_0_3 Mac OS X AppleWebKit/537 (KHTML, like Gecko) Mobile Safari/537\"",\""browser\"":{\""name\"":\""IEMobile\"",\""version\"":\""11.0\"",\""major\"":\""11\""},\""engine\"":{\""name\"":\""Trident\"",\""version\"":\""7.0\""},\""os\"":{\""name\"":\""Windows Phone\"",\""version\"":\""8.1\""},\""device\"":{\""model\"":\""Lumia 820\"",\""vendor\"":\""Nokia\"",\""type\"":\""mobile\""},\""cpu\"":{}}"",
""timestamp"": ""2015-06-23T08:11:39.171Z"",
""category"": ""ERROR"",
""message"": ""Unexpected error occoured: Unable to get property 'scrollTo' of undefined or null reference\r\nTypeError: Unable to get property 'scrollTo' of undefined or null reference\n at Anonymous function ","1","2015-07-20T08:40:42Z"
"245739","5484","122842728","391394","lgalfaso","@RolfDeVries I understand that this change is somehow innocuous, but without a test nor a plunker that shows the error, then I lean towards not merging this.","1","2015-07-20T10:30:54Z"
"245740","5484","122845506","9882445","RolfDeVries","I understand your point, but unfortunally I cannot deliver, thanks anyway.","1","2015-07-20T10:40:59Z"
"245741","5485","122659550","391394","lgalfaso","I do not expect a lot of people to actually use this API, but `module.filter`, anyhow, thanks for the PR.","1","2015-07-19T12:50:35Z"
"245742","5485","122659768","489010","matthewjh","Agreed Lucus. I used it for the first time with typescript and the definition was off (it spoke nothing of a second parameter), presumably because of this doc.
On Sun, Jul 19, 2015 at 5:52 AM -0700, ""Lucas Mirelmann"" <notifications@github.com> wrote:
I do not expect a lot of people to actually use this API, but `module.filter`, anyhow, thanks for the PR.
---
Reply to this email directly or view it on GitHub:
https://github.com/angular/angular.js/pull/12378#issuecomment-122659550
","1","2015-07-19T12:54:31Z"
"245743","12919","152339131","975","ktheory","Yay! ? Thanks, Sean.
On Thu, Oct 29, 2015 at 5:31 PM Sean Griffin <notifications@github.com>
wrote:
> Merged #13008 <https://github.com/rails/rails/pull/13008>.
>
> —
> Reply to this email directly or view it on GitHub
> <https://github.com/rails/rails/pull/13008#event-449773927>.
>
","1","2015-10-29T21:53:55Z"
"245744","12921","29129441","354185","robin850","@arunagw : Can I ask you what's the point of the `DEFAULT_APP_CONSTANT` please ? I just see it in the `default_files` method but the latter is not used anywhere in the tests.
The removal of the `test_creation_of_*` tests seems legit but it would be nice to have a test which iterates over the constant to check whether the file is generated. What do you think ? Sorry if I'm misunderstanding something.","1","2013-11-23T09:59:19Z"
"245745","12921","29129739","3948","arunagw","Hey @robin850 no problem.
You are asking about `DEFAULT_APP_FILES` right?
If you look into in shared_generator_test here
https://github.com/rails/rails/blob/master/railties/test/generators/shared_generator_tests.rb#L26
This `default_files` has been used. And app_generator_test is using shared_generator_test
https://github.com/rails/rails/blob/master/railties/test/generators/app_generator_test.rb#L49","1","2013-11-23T10:21:30Z"
"245746","12921","29129795","354185","robin850","Ah right, thank you for the explanations, awesome! :smiley:","1","2013-11-23T10:24:30Z"
"245747","12921","29130232","5402","senny","@arunagw thanks :yellow_heart: ","1","2013-11-23T10:56:17Z"
"245748","12923","29132170","5402","senny","@harrigan thank you.","1","2013-11-23T13:14:48Z"
"245749","12924","29134880","5402","senny","This behavior spans across all generators. We can't just change it in the migrations generator, people will expect it to behave the same for all generators.
I'm not sure we should handle the case differently. If you are using a VCS you will see what happened and it's good practice to check what happened after such commands (eg. `git status`).
```
rails_4_0_1 » bin/rails destroy controller test ~/Projects/playground/ruby/rails/rails_4_0_1
remove app/controllers/test_controller.rb
invoke erb
remove app/views/test
invoke test_unit
remove test/controllers/test_controller_test.rb
invoke helper
remove app/helpers/test_helper.rb
invoke test_unit
remove test/helpers/test_helper_test.rb
invoke assets
invoke coffee
remove app/assets/javascripts/test.js.coffee
invoke scss
remove app/assets/stylesheets/test.css.scss
```
```
rails_4_0_1 » bin/rails destroy model test ~/Projects/playground/ruby/rails/rails_4_0_1
invoke active_record
remove /Users/senny/Projects/playground/ruby/migration/templates/create_table_migration.rb
remove app/models/test.rb
invoke test_unit
remove test/models/test_test.rb
remove test/fixtures/tests.yml
```
@rafaelfranca @carlosantoniodasilva thoughts?","1","2013-11-23T15:56:19Z"
"245750","12924","29137516","621238","prathamesh-sonpatki","@senny I agree. It should have consistent behavior for all generators. I get the point of using `git status` but if the file is not there, it should not show that we are deleting it","1","2013-11-23T17:55:42Z"
"245751","12924","33721850","47848","rafaelfranca","Fixed by #13691 ","1","2014-01-30T19:12:17Z"
"245752","12925","29135059","5402","senny","awesome! :yellow_heart: ","1","2013-11-23T16:05:34Z"
"245753","12927","29151779","354185","robin850","Actually the `compact` method is useful when it is a ""final"" release (e.g. [4.0.1](https://github.com/rails/rails/blob/v4.0.1/version.rb)) ; the `PRE` constant is `nil` so compact removes it. Thank you but I'm closing it.
~~~irb
>> [5, 0, 0, nil].join('.')
=> ""5.0.0.""
~~~","1","2013-11-24T09:23:26Z"
"245754","12928","29282392","5402","senny","This looks good. I just added a minor comment. Can you also push a rebased version?","1","2013-11-26T10:40:55Z"
"245755","12928","29299448","3731516","heruku","@senny Sorry, I'm very fond of hashrockets. Just pushed up the changes.","1","2013-11-26T15:09:11Z"
"245756","12928","29300072","5402","senny","@heruku thank you for your contribution :yellow_heart: ","1","2013-11-26T15:16:14Z"
"245757","12929","29155434","3948","arunagw","Can you please squash commits into one?","1","2013-11-24T13:35:05Z"
"245758","12929","29155472","237493","razielgn","Sure.","1","2013-11-24T13:37:01Z"
"245759","12929","29157407","237493","razielgn","Ah snap, forgot to update also the `allow_failures` section.","1","2013-11-24T15:12:45Z"
"245760","12929","29157487","237493","razielgn","See #13021.","1","2013-11-24T15:16:45Z"
"245761","12930","29167799","237493","razielgn","Thanks! There are still a couple of PR related to MRI-independency: #11993 #11848. It'd be awesome to have them merged.","1","2013-11-24T22:12:35Z"
"245762","12931","29157728","237493","razielgn","Thanks!","1","2013-11-24T15:27:40Z"
"245763","12932","29280617","5402","senny","Could this break applications that rely on the fact that currently methods are leaked?","1","2013-11-26T10:11:58Z"
"245764","12932","29325242","11460","pwnall","It depends on how you define ""break"".
This only impacts fixture code, so it won't break the folks who don't have tests at all.
Assuming you have tests, and you run them when you upgrade Rails, this will turn flaky tests into definite failures.
I think the fixtures load order is currently decided by [this call to `Dir.[]`](https://github.com/rails/rails/blob/master/activerecord/lib/active_record/fixtures.rb#L830). That method has no guarantee for the order in which it returns directory entries. One would hope it will return sorted entries, but in my tests this was not the case. [StackOverflow agrees with me](http://stackoverflow.com/questions/6220753/does-dir-glob-guarantee-the-order).
For some restricted definition of ""break"", this is a breaking change. I am willing to write the documentation needed for devs who run into this to understand what's happening. At the same time, I consider that the change turns ticking bombs into problems that are immediately visible.
For context, imagine this exploding all of a sudden in a continuous integration / continuous deployment environment. :bomb: :cry: ","1","2013-11-26T19:41:44Z"
"245765","12932","29366701","5402","senny","of course by breaking I meant the tests and not production code. I don't see a reasonable way to issue depreciation warnings only in these cases so we need to compensate with docs.
/cc @rafaelfranca ","1","2013-11-27T08:14:27Z"
"245766","12932","29415607","11460","pwnall","@senny I figured you already knew the answer, and were asking for documentation purposes, or to have the answer spelled out in the PR log. Sorry, I misunderstood and my answer was weird :/
I didn't see a `4_1_release_notes.md` in `rails/guides/source`. What is a good place to document the change?","1","2013-11-27T19:59:08Z"
"245767","12932","29453917","5402","senny","@pwnall sorry for being vague. It's good to reflect these thoughts in the PR so we can later link to it.
I'll prepare the release notes and the upgrading guide today. I'll let you know when things are ready.
In the meantime you could polish the rdocs. To make sure people find `render_context` we should add a section to the main [fixture documentation](https://github.com/rails/rails/blob/master/activerecord/lib/active_record/fixtures.rb).
","1","2013-11-28T10:25:21Z"
"245768","12932","29562316","11460","pwnall","@senny I added a Changelog entry and a paragraph in the fixtures documentation. Can I do anything else to help document this?","1","2013-11-30T22:18:31Z"
"245769","12932","29564026","5402","senny","You can add a section to the [upgrading ruby on rails guide](https://github.com/rails/rails/blob/master/guides/source/upgrading_ruby_on_rails.md#upgrading-from-rails-40-to-rails-41)
I pushed a first draft of the [4.1 release notes](https://github.com/rails/rails/blob/master/guides/source/4_1_release_notes.md#active-record). You can add an entry in the notable changes section and even link to the upgrading guide.","1","2013-11-30T23:56:44Z"
"245770","12932","29604081","11460","pwnall","@senny Thank you! I added notes in the upgrade guide and 4.1 release notes. I look forward to your feedback!","1","2013-12-02T09:29:04Z"
"245771","12932","29611027","5402","senny","I added some minor comments. This is looking good.","1","2013-12-02T11:32:18Z"
"245772","12932","29654761","5402","senny","I discussed this change with @rafaelfranca. We came to the conclusion that we should:
1. use an anonymous class as the context. This will get rid of the lookup hack and the `render_context.rb` file.
```ruby
class Fixture
def self.context
@context ||= Class.new do
def get_binding
binding()
end
end
end
end
```
2. We should expose a simple API for third party code to provide helpers for that context. `ActiveRecord::FixtureSet.context` will return the anonymous context class. Third party code can add helpers like so: `ActiveRecord::FixtureSet.context.send :include, Paperclip::FixtureHelpers`
3. The docs should only talk about `ActiveRecord::FixtureSet.context`
4. We still create a subclass of the context to isolate each file.
","1","2013-12-02T20:34:00Z"
"245773","12932","29654965","47848","rafaelfranca",":+1:","1","2013-12-02T20:36:37Z"
"245774","12932","29657250","11460","pwnall","This doesn't quite work :(
I tried adding this to `fixtures.rb`
```ruby
class ActiveRecord::FixtureSet
def self.context
@context ||= Class.new do
def get_binding
binding()
end
end
end
end
```
One problem is that `FixtureSet` is now in the lookup scope of the binding, so using `File.read` in a helper will actually break, because `File` will get resolved as `ActiveRecord::FixtureSet::File`.
The other problem is that unless I define `get_binding` on the class is that is used as a context, `test_independent_render_contexts` fails, implying that methods are actually getting defined on the shared superclass.
Thoughts?","1","2013-12-02T21:03:59Z"
"245775","12932","29659237","5402","senny","We can define `get_binding` in the created subclass.","1","2013-12-02T21:27:10Z"
"245776","12932","29659728","47848","rafaelfranca","About the `File` problem it is more about class clash than lookup scope. I have the feeling that `ActiveRecord::FixtureSet::File` should not be called `File`","1","2013-12-02T21:32:19Z"
"245777","12932","29664500","11460","pwnall","@rafaelfranca In the end, we'll have a namespace where we have to pay a lot of attention when we add new names. I think that `ActiveRecord::FixtureSet` is less suitable than a namespace that is specifically designed for this purpose, like `ActiveRecord::FixtureSet::RenderContext`.
@senny I think that is correct. I also think it has to be defined in a ""clean"" namespace, because that namespace will be in lookup scope.","1","2013-12-02T22:25:59Z"
"245778","12932","29665164","47848","rafaelfranca","I'm fine with a clean namespace but I don't want to see that module hack. It is ugly and hard to understand.
So if there is a way to make a clean namespace without it :+1:","1","2013-12-02T22:34:28Z"
"245779","12932","29665433","11460","pwnall","@rafaelfranca What do you think about this version?
`ActiveRecord::FixtureSet::RenderContext` does not show up in the hierarchy of the ERB evaluation context, and it's just a private namespace that is an implementation detail.","1","2013-12-02T22:37:37Z"
"245780","12932","29665625","47848","rafaelfranca","Very good :heart:","1","2013-12-02T22:39:45Z"
"245781","12932","29665694","11460","pwnall","@rafaelfranca The other alternative I have is along the lines of
```ruby
ActiveRecord::FixtureSet::File.define_singleton_method(:render_context) do
Class.new ActiveRecord::FixtureSet.context do
def get_binding
binding()
end
end
end
```","1","2013-12-02T22:40:29Z"
"245782","12932","29665815","11460","pwnall","@rafaelfranca Thank you! I'll go through the docs and update everything.","1","2013-12-02T22:41:47Z"
"245783","12932","29666515","11460","pwnall","@rafaelfranca I updated the docs and commit message.","1","2013-12-02T22:50:21Z"
"245784","12932","29689695","11460","pwnall","@senny Sorry, and thank you for catching that! I used `git grep` to make sure I didn't miss any other occurrence.","1","2013-12-03T07:53:33Z"
"245785","12932","29690461","5402","senny","@pwnall :+1: I think we are ready to go. Thank you very much for all the experimentation and updates, the speedy replies and the contribution. :heart: ","1","2013-12-03T08:11:02Z"
"245786","12932","29690561","11460","pwnall","@senny Thank you and @rafaelfranca for the patience and guidance!","1","2013-12-03T08:13:26Z"
"245787","12932","29866754","47848","rafaelfranca","Great we could make this in time to 4.1, thank you so much for the work","1","2013-12-05T02:30:58Z"
"245788","12933","29183450","5402","senny","Does this fully solve #5738 ?","1","2013-11-25T08:08:03Z"
"245789","12933","29184065","11460","pwnall","I think so.
The root cause seems to be that mysql2 produces String instances whose encodings are set to UTF-8, but whose contents is ASCII. That being said, programming errors happen, and it's nice if Rails could do something reasonable here.","1","2013-11-25T08:23:53Z"
"245790","12933","29184182","11460","pwnall","I was wrong about the source of the error. I still think we should have the `rescue` even if we're able to fix the underlying error, since we're in an exception handler.","1","2013-11-25T08:26:44Z"
"245791","12933","29185084","5402","senny","I agree that the exception handler should be as error-safe as possible.
@pwnall could you verify if this PR fixes #5738? Also please add a changelog entry.
@rafaelfranca can you take a look?","1","2013-11-25T08:44:36Z"
"245792","12933","29219987","11460","pwnall","@senny This does not fix #5738 for me.
This is my repro based on the comments in the bug:
https://github.com/pwnall/rails5738/commit/b06914fa86262cdd5176bb005844134129121e05
And this is the commit for switching to my branch:
https://github.com/pwnall/rails5738/commit/eee371ddcc440c6bc855a65d07a7924ba3782797
The top of the exception trace:
```
Encoding::CompatibilityError: incompatible character encodings: UTF-8 and ISO-8859-1
/home/pwnall/.gem/ruby/bundler/gems/rails-483ba4d87a61/activerecord/lib/active_record/connection_adapters/abstract_adapter.rb:361:in `rescue in log'
/home/pwnall/.gem/ruby/bundler/gems/rails-483ba4d87a61/activerecord/lib/active_record/connection_adapters/abstract_adapter.rb:359:in `log'
/home/pwnall/.gem/ruby/bundler/gems/rails-483ba4d87a61/activerecord/lib/active_record/connection_adapters/abstract_mysql_adapter.rb:299:in `execute'
```
The line where the exception occurs seems consistent with the comments in #5738
https://github.com/rails/rails/blob/c576e24e0e589703eac48dc06fe48a24d9cf8e18/activerecord/lib/active_record/connection_adapters/abstract_adapter.rb#L361
","1","2013-11-25T17:07:07Z"
"245793","12933","29220720","5402","senny","@pwnall thank you for your confirmation. Will see if we can still apply this patch.","1","2013-11-25T17:14:58Z"
"245794","12933","29221049","11460","pwnall","@senny Here's how I'd fix #5738. Want me to put together a patch?
```ruby
begin
message = ""#{e.class.name}: #{e.message}: #{sql}""
rescue Encoding::CompatibilityError
encoded_message = e.message.encode(Encoding.default_internal, invalid: :replace, undef: :replace)
encoded_sql = sql.encode(Encoding.default_internal, invalid: :replace, undef: :replace)
message = ""#{e.class.name}: #{encoded_message}: #{encoded_sql}""
end
```","1","2013-11-25T17:18:33Z"
"245795","12933","29222395","5402","senny","@pwnall yes please create a PR.
About the PR at hand, can you rescue the specific exception instead of `StandardError`? This will both serve as documentation and won't swallow problems with the code itself.","1","2013-11-25T17:33:09Z"
"245796","12933","29223779","11460","pwnall","Re: this PR -- I will switch to an explicit catch if you'd like me to, but I'd like to explain my reasoning for the way I wrote this.
I think this is one of the rare cases when the naked `rescue` is the right thing to do. The handler is trying to figure out if the exception matches a certain pattern, in order to replace it with a better exception.
I think the original exception should be re-raised if does not match the expected pattern, for any reason. Whatever exception gets raised here will be less helpful to developers than the original one.
I think we can defend against errors in code by having a test that proves the exception replacement happens.","1","2013-11-25T17:47:37Z"
"245797","12933","29225368","11460","pwnall","@senny I made the change here and kept the old code in https://github.com/pwnall/rails/tree/mysql_binary_error2
Please let me know if you'd like me to switch it back, or if this looks better to you.","1","2013-11-25T18:01:33Z"
"245798","12933","29354132","199","jeremy","This is due to mysql error message charset mismatches. It's a mysql2 bug. If you upgrade to mysql 5.5+ the problem will go away.
https://github.com/rails/rails/pull/13041#r7946284","1","2013-11-27T01:50:13Z"
"245799","12933","29354346","11460","pwnall","@jeremy I ran into this on Fedora 20, which uses mariadb. That's mysql 5.5 with more patches.
Like I said in the comments, it is true that the root cause here is a bug in the mysql2 gem. At the same time, the exception handler in Rails could be careful and avoid swallowing exceptions that would help me debug what's going on.","1","2013-11-27T01:55:48Z"
"245800","12933","29374884","199","jeremy","@pwnall I couldn't find any info about changes to MariaDB error message language or encoding. If it's the same as MySQL, I'm surprised that you're having this issue. Perhaps these MySQL 5.5 changes didn't hit MariaDB, or ?
I hear you re. being careful and avoiding masking exceptions. Generally speaking, we rely on strong API boundaries that set a clear contract about string encodings. Otherwise all code would need to defensively check and rescue from possibly poisoned strings from the library, driver, IO, etc that it's using. That'd be no good. So, the best option is to push these duties down beneath the API layer responsible for it.","1","2013-11-27T10:42:50Z"
"245801","12933","29412031","11460","pwnall","@jeremy I totally agree with relying on API boundaries and not being paranoid in general.
At the same time, if a bug happens once, it's likely that it'll happen again. Encodings are hard in Ruby, so the mysql2 gem might have other encoding bugs that did not show up, and new encoding bugs might get introduced. A simple `rescue ''` at the end of the line (my original patch) might save a day of debugging for someone else.
Also, [RHEL will ship with MariaDB](http://www.theregister.co.uk/2013/06/15/red_hat_to_ditch_mysql_for_mariadb_in_rhel_7/) at some point, so I think it is unwise to discount it.","1","2013-11-27T19:13:23Z"
"245802","12933","30733458","199","jeremy","@pwnall we reached a resolution @ https://github.com/brianmario/mysql2/pull/459 - give it a shot!","1","2013-12-17T08:26:07Z"
"245803","12933","30812414","11460","pwnall","Sorry for being so slow on verifying this! I couldn't repro the bug using my original setup, and I'm trying to get that figured out. /embarrassed","1","2013-12-18T02:57:18Z"
"245804","12933","30822347","5402","senny","@pwnall on `master` we simply removed the custom error handling code. See https://github.com/rails/rails/commit/c28d0f2031d31aeb5289b73acbb5c1adb7bd71d4 I think we should be good.","1","2013-12-18T07:37:52Z"
"245805","12933","30839845","11460","pwnall","@senny Ah, that's why I couldn't repro :) Thank you! Removing the handler will definitely fix this :+1: ","1","2013-12-18T13:05:06Z"
"245806","12933","31056548","39406","sodabrew","Is the fix in brianmario/mysql2#459 sufficient, or do I need to dig into it further? I recently found that we're not alone in this quest:
http://bibwild.wordpress.com/2013/03/12/removing-illegal-bytes-for-encoding-in-ruby-1-9-strings/
https://github.com/jrochkind/ensure_valid_encoding
https://github.com/jrochkind/ensure_valid_encoding/blob/master/lib/ensure_valid_encoding.rb","1","2013-12-21T04:28:14Z"
"245807","12933","31062674","11460","pwnall","@sodabrew This bug was fixed by removing the exception handler that masked the original exception.
There is another encoding-related bug, #5738, which I proposed a fix for in #13041. That handler is still there, and it still gave me an error when I tried it with the mysql commit that you pointed me at. My last comment in #13041 points at a repository that I used to reproduce the bug.","1","2013-12-21T12:49:22Z"
"245808","12933","31066027","39406","sodabrew","Thanks for the explanation, I will follow up at #13041 / at your repro repo.","1","2013-12-21T16:01:16Z"
"245809","12933","31066262","11460","pwnall","Thank _you_ for looking into this!","1","2013-12-21T16:14:08Z"
"245810","12934","29177927","59744","schneems",":heart: this commit. Better errors ftw. Can you add a changelog to actionpack and squash?","1","2013-11-25T05:00:55Z"
"245811","12934","29183540","11460","pwnall","@schneems, @senny Thank you very much for your feedback! I hope I have addressed it.","1","2013-11-25T08:10:39Z"
"245812","12934","29183547","5402","senny","looks good :yellow_heart: ","1","2013-11-25T08:10:41Z"
"245813","12934","29183711","11460","pwnall","Thank you for the quick feedback! :heart: ","1","2013-11-25T08:15:13Z"
"245814","12935","29183008","5402","senny","looks good :+1: ","1","2013-11-25T07:56:29Z"
"245815","12936","29189578","1928523","akshay-vishnoi","@senny - `html_attributes[:selected] ` used. PR updated, please check it again.
Here are the benchmarks: https://gist.github.com/akshay-vishnoi/7638030","1","2013-11-25T10:08:01Z"
"245816","12936","29190374","5402","senny","looks good.","1","2013-11-25T10:21:14Z"
"245817","12936","29190542","1928523","akshay-vishnoi","Thanks :yellow_heart:","1","2013-11-25T10:23:58Z"
"245818","12936","29194988","26328","carlosantoniodasilva","Thanks @akshay-vishnoi but I had to revert, check the commit message for the reason.","1","2013-11-25T11:36:08Z"
"245819","12936","29202321","5402","senny","My mistake. Thank you for the revert Carlos :+1: ","1","2013-11-25T13:47:42Z"
"245820","12937","29185176","5402","senny","This fix still contains mentions of ""delgated"". See https://github.com/vipulnsward/rails/blob/b88c615cdc02c5f04f165f206cc45471b16b5266/activerecord/test/cases/relation/delegation_test.rb#L71 for example. As #13029 already fixes everything I'm going to merge that one.","1","2013-11-25T08:46:36Z"
"245821","12937","29185284","567626","vipulnsward",":+1: ","1","2013-11-25T08:48:42Z"
"245822","12938","29185268","5402","senny","@akshay-vishnoi for further doc patches, please add `[ci skip]` to the commit message.","1","2013-11-25T08:48:30Z"
"245823","12938","29185561","1928523","akshay-vishnoi",":+1: ","1","2013-11-25T08:53:16Z"
"245824","12939","29200701","277819","zzak","It would be nice to explain _when_ touch is called maybe","1","2013-11-25T13:20:27Z"
"245825","12939","29205462","1930730","kuldeepaggarwal","@zzak : Please have a look on the usage of `touch` http://railscasts.com/episodes/172-touch-and-cache?view=asciicast","1","2013-11-25T14:32:13Z"
"245826","12939","29209712","125715","pftg","@kuldeepaggarwal I think @zzak asked to add more details about `touch` to this PR, not just explain to him :smile: ","1","2013-11-25T15:21:55Z"
"245827","12939","29210661","1930730","kuldeepaggarwal","@zzak Sorry.. :innocent:","1","2013-11-25T15:32:10Z"
"245828","12939","29213612","1930730","kuldeepaggarwal","@pftg But `touch` has its own documentation to clear where it can be used. I don't think, I should explain all those use cases with this PR. What you say?","1","2013-11-25T16:02:56Z"
"245829","12939","29213904","9347","dmathieu","If we're documenting `touch` in the guides, I agree we need to mention in which cases it's going to be triggered.","1","2013-11-25T16:06:08Z"
"245830","12939","29214200","1930730","kuldeepaggarwal","@dmathieu Got it, I will update the PR.","1","2013-11-25T16:09:07Z"
"245831","12939","29221032","1930730","kuldeepaggarwal","@pftg Added more cases of `after_create` callback.","1","2013-11-25T17:18:25Z"
"245832","12939","29263413","277819","zzak","`touch` is specifically `nodoc`'d:
*edit*: sorry i thought you meant the callback :(","1","2013-11-26T02:45:16Z"
"245833","12939","29368268","1930730","kuldeepaggarwal","cc: @senny ","1","2013-11-27T08:48:04Z"
"245834","12939","30407246","1930730","kuldeepaggarwal","@senny done. :+1: ","1","2013-12-12T11:09:34Z"
"245835","12939","30407385","5402","senny","@kuldeepaggarwal please squash your commits.","1","2013-12-12T11:11:57Z"
"245836","12939","30407663","1930730","kuldeepaggarwal","@senny I have updated the PR.","1","2013-12-12T11:15:50Z"
"245837","12939","30407907","5402","senny","@kuldeepaggarwal thank you.","1","2013-12-12T11:18:15Z"
"245838","12939","30407993","1930730","kuldeepaggarwal","@senny Thanks for merging. :green_heart: ","1","2013-12-12T11:19:02Z"
"245839","12940","29229008","47848","rafaelfranca","Could you fix the commit message, this will not skip the ci","1","2013-11-25T18:40:30Z"
"245840","12940","29229051","47848","rafaelfranca","And also it will make the contributors application give the commit to ci-skip :smile:","1","2013-11-25T18:41:01Z"
"245841","13374","72293125","42868","tvdeyen","??","1","2015-01-31T00:16:14Z"
"245842","13376","31626172","47848","rafaelfranca","See https://github.com/rails/rails/pull/6964#issuecomment-6764558 and the next comments from @josevalim and @fxn.
That said you should require `active_support.rb` before requiring any other file inside that framework. Doing this you will not need this require.","1","2014-01-06T04:01:39Z"
"245843","13376","31626291","395621","alindeman","OK, understood, I wasn't aware of the change until now.","1","2014-01-06T04:05:45Z"
"245844","13377","31627014","1930","kbrock","This is a fun (and more radical) solution to #8328","1","2014-01-06T04:35:38Z"
"245845","13377","46056152","47848","rafaelfranca","Fixed by https://github.com/rails/rails/pull/15674","1","2014-06-13T20:26:35Z"
"245846","13377","46180915","1930","kbrock","@rafaelfranca thank you for getting this in","1","2014-06-16T13:56:25Z"
"245847","13379","1251425","9582","josevalim","It seems something is wrong with your pull request. :P","1","2011-05-27T20:05:09Z"
"245848","13379","1251447","56807","sirlantis","Whoops. Github exploded. Fixed the Pull-Request (now 1362). Sorry for the mess.","1","2011-05-27T20:09:51Z"
"245849","13380","31639792","5402","senny","@robinboening this is looking good. Are they currently passing or failing?","1","2014-01-06T10:42:08Z"
"245850","13380","31640081","342977","robinboening","The tests are passing. Travis should inform us in a second. :)","1","2014-01-06T10:47:54Z"
"245851","13380","31640165","5402","senny","@robinboening more in an hour I guess... I'm giving this a merge.","1","2014-01-06T10:49:21Z"
"245852","13381","31845772","5402","senny","I think this is a good approach. However I'm not very familiar with Thor. We should wait for some feedback from @rafaelfranca","1","2014-01-08T15:45:55Z"
"245853","13381","31905703","1296472","asiniy","Yes, it seems good idea","1","2014-01-09T06:20:51Z"
"245854","13381","33430501","290596","eval","Added tests, Changelog entry and rebased. Input welcome! /cc @rafaelfranca ","1","2014-01-27T22:25:28Z"
"245855","13382","31651842","9347","dmathieu","Thank you. :heart:","1","2014-01-06T14:29:32Z"
"245856","13383","31656150","47848","rafaelfranca","cc @fxn ","1","2014-01-06T15:24:16Z"
"245857","13383","31657555","3387","fxn",":-1:
On a broad sense I don't think Rails methods should be robust to malformed strings, it is the caller who must ensure proper form, adequate Unicode normalization, etc.
And the caller wants to do that at the I/O boundaries.
In this particular case in addition, the definition of present (the opposite of blank) requires that there is at least one non-space character. Returning always false that way does not make sense to me.
All in all, I believe we shouldn't go in that direction.","1","2014-01-06T15:40:05Z"
"245858","13383","31820678","9582","josevalim","The problem here though is that Rails is tagging all input data, including files, as utf-8. Rails should probably keep attachments in a multipart request as binary. So I agree the data in the boundary should be properly set. However, that's mostly Rails responsibility and we are doing it wrong.","1","2014-01-08T10:35:15Z"
"245859","13383","31821330","9582","josevalim","Maybe we should open a separate issue for this? Since this is definitely not the proper fix. The regex will do the proper job as long as the input is properly tagged.","1","2014-01-08T10:44:44Z"
"245860","13383","31821754","3387","fxn",":+1: ","1","2014-01-08T10:51:37Z"
"245861","13386","31697257","4312","mkdynamic",":+1:","1","2014-01-06T23:05:46Z"
"245862","13386","31697507","47848","rafaelfranca","Cc @fxn ","1","2014-01-06T23:08:51Z"
"245863","13386","31746844","6321","pixeltrix","Tests fail on 1.9.3 because en dash is a UTF8 char and the source file isn't marked as UTF8. Even with that fixed it'll still fail because the expected values in the tests haven't been changed.","1","2014-01-07T15:30:18Z"
"245864","13386","31748443","3387","fxn","Mixed feelings.
On one hand I feel an en dash is more appropriate, but on the other hand this feature seems quite arbitrary as well. I mean, the helper appends the number in an arbitrary but fixed manner. Can we do better?","1","2014-01-07T15:45:53Z"
"245865","13386","31748992","6321","pixeltrix","How about accepting a string format for the `:add_month_numbers` option:
``` ruby
elsif @options[:add_month_numbers]
if @options[:add_month_numbers].is_a?(String)
@options[:add_month_numbers] % [number, month_names[number]]
else
""#{number} – #{month_names[number]}""
end
else
```","1","2014-01-07T15:51:30Z"
"245866","13386","31749084","3387","fxn","@pixeltrix I was thinking exactly that (except for `== true` in my head :).","1","2014-01-07T15:52:28Z"
"245867","13386","31749574","3387","fxn","Yeah, checking for string seems the way to go, since we do no require a singleton. That means it is not really backwards compatible, but may be a corner case anyway.
A little tweak for extra flexibility by the same price would be to use keys in the format string, so that the helper passes a hash with documented keys.","1","2014-01-07T15:57:24Z"
"245868","13386","31751218","6321","pixeltrix","Actually wouldn't it make more sense to add a `:custom_month_name` option that supports a range of replacement values. It also wouldn't break backwards compatibly.","1","2014-01-07T16:14:24Z"
"245869","13386","31751817","3387","fxn","@pixeltrix much better!","1","2014-01-07T16:20:17Z"
"245870","13386","31781319","223324","mikegowen","I fixed the encoding and the broken tests.
IMHO we should to address the incorrect usage and not let the scope of the issue creep :) Whether the character is arbitrary or not could be a separate discussion.","1","2014-01-07T21:28:54Z"
"245871","13386","31844625","354185","robin850","Thanks for your patch @mikegowen but I can guess that this would break exisiting 4.0.x application, I think that you will have to reopen this pull request targeting the `master` branch. Could you squash your commits together anyway please (with `git rebase -i HEAD~2` and replacing the second pick with `squash`) ?","1","2014-01-08T15:34:39Z"
"245872","13386","31846869","354185","robin850","(Actually I've commented a bit too fast ; let's first have a look at the decision we will take with this issue, then we would reopen if any API/breaking change is planned)","1","2014-01-08T15:56:31Z"
"245873","13386","35155393","3387","fxn","@mikegowen we finally opted for a generic format string option. Thanks for raising this issue that led to it, and also thanks for the patch even if it was not applied in the end.","1","2014-02-15T12:47:11Z"
"245874","13387","1251457","9582","josevalim","Could you please add a test to ensure we won't have regressions?","1","2011-05-27T20:11:21Z"
"245875","13923","38187068","567626","vipulnsward","? Nicely done .","1","2014-03-20T16:14:16Z"
"245876","13924","38125142","26328","carlosantoniodasilva","Thank you for your contribution, however we consider such changes mainly cosmetic, making the history harder to follow, and usually don't accept them unless being part of a bigger change in the related code. Thanks again.","1","2014-03-20T00:52:11Z"
"245877","13925","38134222","55829","chancancode","Thanks!","1","2014-03-20T04:23:45Z"
"245878","13927","38210440","47848","rafaelfranca","Please see the related issue above.","1","2014-03-20T19:26:58Z"
"245879","13927","38210718","492603","westonplatter","@rafaelfranca thanks for the info.","1","2014-03-20T19:29:33Z"
"245880","13927","38572817","137","josh","For the record, no one actually peer reviewed the CVE. This was a little premature.","1","2014-03-25T14:47:28Z"
"245881","13928","38213659","47848","rafaelfranca","`order` doesn't must behave like `where` they are different methods, so I don't think this will improve `order` over `order('topic.id ASC')`","1","2014-03-20T19:57:13Z"
"245882","13928","38214015","47848","rafaelfranca","Thank you for the pull request.
I think parsing the string to search `.` will likely break. We should not try to parse SQL.
So, unless we are planning to implement a SQL parser, I think this should not be supported.","1","2014-03-20T20:00:29Z"
"245883","13977","105575707","384288","joepasq","@valscion are you using `attachments['image'].url` for every image?
Previewing in Firefox, Chrome and Safari, using `.url`, the resource requested is `cid:#{hash}@#{localhost}`, but fails to load with an unknown URL scheme / unsupported URL. Inspecting the HTML in the preview, I have not been able to identify a base64 encoded image.
Requesting the resource using `attachment['image'].filename` does load it correctly from the relative URL `/assets/image`. I am not sure if `.filename` will work for every email situation (or enough of the time ?), as it would be a remote resource. I also noticed that @pixeltrix's [tests use `.url`](https://github.com/rails/rails/commit/350d272d6cd6fbbb127133773c79c3c17e4216f0#diff-6cd2f2bc2d75ddac6c0d1e85983e983dR590). ","1","2015-05-26T15:55:22Z"
"245884","13977","105773033","482561","valscion","@joepasq Ah, seems to be that the preview of inline images do fail, but at least it doesn't error out anymore and that was all I wanted.","1","2015-05-27T06:26:38Z"
"245885","14360","45333449","15688","thedarkone","Damn, here I go again :disappointed:.
Even though the PR now passes the `abstract` behavior test, that I've added previously, it is still differs from the current implementation (the test passes simply because `_layout_proc` is a `class_attribute` and they are inheritable, not because the layout lookup code after refactor behaves the same, test attached below).
Then there are `_layout_conditions`: in your PR they are reinterpreted (via `_conditional_layout?`) when dispatching to `controller_class.superclass`, this is different from the current implementation that always uses the current controller's `_layout_conditions`.
It comes to this:
```ruby
class FooController < ActionController::Base
layout 'foo'
def index
@_action_name = 'index'
_layout.inspect
end
def show
@_action_name = 'show'
_layout.inspect
end
end
class BarController < FooController
layout 'bar', :only => :index
end
class BazController < BarController
layout 'baz', :only => :show
end
puts ""FooController.new.index: #{FooController.new.index}""
puts ""FooController.new.show: #{FooController.new.show}""
puts ""BarController.new.index: #{BarController.new.index}""
puts ""BarController.new.show: #{BarController.new.show}""
puts ""BazController.new.index: #{BazController.new.index}""
puts ""BazController.new.show: #{BazController.new.show}""
```
Current behavior:
```
FooController.new.index: ""foo""
FooController.new.show: ""foo""
BarController.new.index: ""bar""
BarController.new.show: nil
BazController.new.index: nil
BazController.new.show: ""baz""
```
After PR:
```
FooController.new.index: ""foo""
FooController.new.show: ""foo""
BarController.new.index: ""bar""
BarController.new.show: ""foo""
BazController.new.index: ""bar""
BazController.new.show: ""baz""
```
Current behavior is to interpret layout conditions ""exclusively"":
* declaring `layout 'bar', :only => :index` is interpreted as: this controller controller has layout `'bar'` on `index` action and no layout otherwise,
* whereas your refactor interprets: `layout 'bar', :only => :index` as: this controller has layout `'bar'` on `index` action and inherits layout behavior from `superclass` on all other actions.
Tests covering the above (previously untested) behavior: https://github.com/thedarkone/rails/commit/d6a06277276d04b2370c7f469e54d449dc628d42.","1","2014-06-06T12:57:46Z"
"245886","14360","46165926","10406","apotonick","@thedarkone Thanks for all your tests, man!
I'm not sure if I understand correctly. I was playing around with your additions from https://github.com/thedarkone/rails/commit/d6a06277276d04b2370c7f469e54d449dc628d42 and am skeptical if your interpretation is correct.
As you say, my code is definitely wrong as it doesn't stop the lookup when a filter option tells it to do so. I added that.
However, now a bunch of other tests fail. I don't really understand when to stop the lookup.
Here's how I changed `_layout_for` to stop lookup when a filter is present.
```ruby
def _layout_for(action_name, lookup_context, exec_context)
return if abstract?
default_layout = DefaultLayout.new(action_name, lookup_context, exec_context)
if _layout_conditions
return unless _conditional_layout?(action_name) # return here breaks your new tests.
default_layout.for_instance(self, _layout_proc)
else
default_layout.for_class(self)
end
end
```
If a filter (except or only) is present and evaluates to false, we don't look further for layouts. Apparently, this is (sometimes?) wrong.
As a sidenote, we should get that refactoring passing the requirements and then deprecate as much as possible for Rails 5: the current ""design"" is sick, in a negative way. I have serious doubts that users understand all the implications.
We should offer a few simple options to pick a layout instead of allowing 25 different possible combinations - nobody uses that! In Cells, this is all simplified and no one ever complained.
","1","2014-06-16T11:09:09Z"
"245887","14360","46218889","15688","thedarkone","@apotonick I'll push some code in a moment.","1","2014-06-16T18:52:56Z"
"245888","14360","46233184","15688","thedarkone","@apotonick the solution is to move even more state (and methods) into `DefaultLayout`: https://github.com/thedarkone/rails/commit/f4789893d0dfa4c7e5cde2042873bb5e0a8c86d5.
Since you forced my hand (into debugging the madness that is Rails layout lookup behavior :anguished:) I also changed some other things and renamed/moved quite a few methods (`DefaultLayout` class also got a new name). In particular I got rid of massively confusing usage of `_conditional_layout?` and renamed somewhat misleading `for_instance`/`for_class` (and I know that `for_instance`/`for_class` method names were my idea :grin:).
Your turn to review.","1","2014-06-16T20:37:24Z"
"245889","14360","46239246","10406","apotonick","This is problably allright, I think you have a better understanding of what this crazy let's-allow-user-20-different-combinations-of-layout-finding _thing_ is supposed to do.
Personally, I am absolutely not interested in the implementation (not to talk about using this) as we completely replace layouts in Cells.
I _knew_ that someone's gonna come up with the name `LayoutFinder`, but this is _wrong_: It's either `Layout.find` or `LayoutFinder.call`. As I said, I am thankful for your changes :heart: as I just want this horrible code to be out of ActionController and in a disposable class. I think we did a good job on that :smirk: ","1","2014-06-16T21:18:11Z"
"245890","14360","46240681","15688","thedarkone","> `LayoutFinder`, but this is wrong: It's either `Layout.find` or `LayoutFinder.call`.
We feel free to rename, I just thought `DefaultLayout`, after all the changes, no longer fits.","1","2014-06-16T21:31:04Z"
"245891","14360","46243870","10406","apotonick","Yeah agreed, ""Default"" is not appropriate anymore. Why don't we call it `Expose20DifferentWaysToDefineInferOrFindYourBloodyLayout`???? :grin: ","1","2014-06-16T22:01:53Z"
"245892","14360","46245463","10406","apotonick","@thedarkone Are you keen on writing a quick benchmark test for a layout lookup?
One thing: Rails should definitely consider using something like [`Uber::Options::Value`](https://github.com/apotonick/uber#single-values) for dynamic options evaluation (string, symbol or lambda) as this logic is constantly repeated across the entire framework. I don't even think about suggesting that on rails-core, though.
What do you think about general acceptance of simplifying layout semantics in 5.0, @thedarkone ? @rafaelfranca ?","1","2014-06-16T22:20:05Z"
"245893","14360","46359058","15688","thedarkone","> Are you keen on writing a quick benchmark test for a layout lookup?
Nice try :stuck_out_tongue_closed_eyes: (I __maybe__ will write one in a couple of days, not sure if I have time for this).
> What do you think about general acceptance of simplifying layout semantics in 5.0?
To achieve what?","1","2014-06-17T20:14:36Z"
"245894","14360","46372271","10406","apotonick","Haha, ok, I'll try to do performance tests, too. Thanks again @thedarkone for all your help, I would have been lost in this madness without your backup.
>> What do you think about general acceptance of simplifying layout semantics in 5.0?
> To achieve what?
To get the view layer into a maintainable, improvable form again. Just because someone introduced loads of code 7 years ago to handle some very very specific and outdated edge-cases doesn't mean it has to survive for another 10 years.
I have been working on Rails view layer stuff for almost 10 years now and nothing is moving on because old code and requirements block innovation. I've moved on long time ago and build my own ""parallel view universe"" called Cells but I wanna give back to the core what I learned from that. Is that... wrong?","1","2014-06-17T22:09:01Z"
"245895","14360","75931536","5091","dmitry","Hopefully it will be completed. :+1: ","1","2015-02-25T09:40:38Z"
"245896","14360","108144548","47848","rafaelfranca","For what I could see this can be slower than the current implementation. The current implementation generates the method using metaprogramming at class load time. This implementation call `LayoutFinder#find` every time we are rendering a layout.
Am I missing something or this can be potentially slower?","1","2015-06-03T00:46:12Z"
"245897","14360","108145517","15688","thedarkone","> Am I missing something or this can be potentially slower?
@rafaelfranca yes, that is my worry/suspicion as well. I'm also not sure that this doesn't introduce unintended behavior changes. Meanwhile I'll check if the commit 83ab0a044d3b90ddb8faa9b85826f9818517a7e7 with additional tests passes on master, and then open a PR for it.","1","2015-06-03T00:55:39Z"
"245898","14360","108151402","10406","apotonick","We can cache the LayoutFinder at class load time. The focus here is maintainability, speeding up afterwards is simple.
@thedarkone Are you adding the test cases you found were missing to master?","1","2015-06-03T01:26:46Z"
"245899","14360","108152271","47848","rafaelfranca","@apotonick :+1: I just prefer to at least keep the same speed before merging. I was thinking on checking the finder at class level, but even doing this simpler cases like `layout 'my_layout`` will be slower. But I'm just wondering how much slower? Depending on the result it just doesn't matter.","1","2015-06-03T01:32:03Z"
"245900","14360","108155140","10406","apotonick","@rafaelfranca We can merge/fix this in the process of the AV ""review"", I didn't mean we have to merge it right now. Of course, we need to benchmark before merging, I totally understand this.
However, we should drop some ""features"" that are not even documented. While we were at this, @thedarkone and I found out that there's about 20 different ways to compute a layout and I have the objection that this blocks us from a clean refactoring. At the same time, I doubt people use all those functions anyway?
But we had that discussion already, see above..","1","2015-06-03T01:40:19Z"
"245901","14360","108157732","47848","rafaelfranca","> At the same time, I doubt people use all those functions anyway?
You will be surprised how much people use of Rails :smile:. I was review some of these behaviors while reviewing this patch. Some of them are very confusing and even me got it wrong as you can see at 8193a09a1f0f15c4b7624d6c24e8a779baa64d39.
I'm up to deprecate, change some of them and I think we should do what the commit revert at 8193a09a1f0f15c4b7624d6c24e8a779baa64d39 does.
I'm writing some benchmark to compare before and after the patch, let me see.","1","2015-06-03T01:47:29Z"
"245902","14360","108159255","47848","rafaelfranca","I used this script to benchmark before and after the patch
```ruby
require 'benchmark/ips'
require 'actionpack/abstract/layouts_test'
Benchmark.ips(5) do |bm|
bm.report 'Layout with string' do
Minitest.run_one_method(AbstractControllerTests::Layouts::TestBase, 'test_when_layout_is_specified_as_a_string,_render_with_that_layout')
end
bm.report 'Layout with proc' do
Minitest.run_one_method(AbstractControllerTests::Layouts::TestBase, 'test_when_layout_is_specified_as_a_proc,_call_it_and_use_the_layout_returned')
end
bm.report 'Layout with symbol' do
Minitest.run_one_method(AbstractControllerTests::Layouts::TestBase, 'test_when_layout_is_specified_as_a_symbol,_call_the_requested_method_and_use_the_layout_returned')
end
end
```
### Before
```
Calculating -------------------------------------
Layout with string 480.000 i/100ms
Layout with proc 534.000 i/100ms
Layout with symbol 522.000 i/100ms
-------------------------------------------------
Layout with string 5.048k (± 8.4%) i/s - 25.440k
Layout with proc 5.234k (± 5.7%) i/s - 26.166k
Layout with symbol 5.045k (± 8.1%) i/s - 25.056k
```
### After
```
Calculating -------------------------------------
Layout with string 495.000 i/100ms
Layout with proc 498.000 i/100ms
Layout with symbol 516.000 i/100ms
-------------------------------------------------
Layout with string 5.063k (± 9.1%) i/s - 25.245k
Layout with proc 5.246k (± 6.4%) i/s - 26.394k
Layout with symbol 4.050k (±21.0%) i/s - 19.608k
```
@matthewd @thedarkone WDYT about the benchmark script?","1","2015-06-03T01:57:31Z"
"245903","14360","108178054","15688","thedarkone","> @thedarkone Are you adding the test cases you found were missing to master?
@apotonick yes (since they are already written).
> WDYT about the benchmark script?
@rafaelfranca it tests the whole stack, if only the layout is benched:
```ruby
require 'benchmark/ips'
require 'action_controller'
require 'action_view'
module Bench
class Base < AbstractController::Base
include AbstractController::Rendering
include ActionView::Rendering
include ActionView::Layouts
abstract!
end
class WithString < Base
layout 'hello'
end
class WithProc < Base
layout proc { 'overwrite' }
end
class WithSymbol < Base
layout :hello
private
def hello
'overwrite'
end
end
class InheritingIntermidiary < WithString; end
class Inheriting < InheritingIntermidiary; end
end
with_string = Bench::WithString.new
with_proc = Bench::WithProc.new
with_symbol = Bench::WithSymbol.new
inheriting = Bench::Inheriting.new
Benchmark.ips(5) do |bm|
bm.report 'Layout with string' do
with_string.send(:_layout)
end
bm.report 'Layout with proc' do
with_proc.send(:_layout)
end
bm.report 'Layout with symbol' do
with_symbol.send(:_layout)
end
bm.report 'Layout with inheritance' do
inheriting.send(:_layout)
end
end
```
## Before
```
Calculating -------------------------------------
Layout with string 99.194k i/100ms
Layout with proc 81.674k i/100ms
Layout with symbol 79.457k i/100ms
Layout with inheritance
101.416k i/100ms
-------------------------------------------------
Layout with string 3.561M (± 3.0%) i/s - 17.855M
Layout with proc 2.372M (± 1.7%) i/s - 11.924M
Layout with symbol 2.047M (± 2.4%) i/s - 10.250M
Layout with inheritance
3.595M (± 3.3%) i/s - 17.951M
```
## After
```
Calculating -------------------------------------
Layout with string 39.967k i/100ms
Layout with proc 34.408k i/100ms
Layout with symbol 34.717k i/100ms
Layout with inheritance
40.218k i/100ms
-------------------------------------------------
Layout with string 620.074k (± 3.7%) i/s - 3.117M
Layout with proc 494.184k (± 3.2%) i/s - 2.477M
Layout with symbol 513.993k (± 1.7%) i/s - 2.569M
Layout with inheritance
617.246k (± 3.9%) i/s - 3.097M
```
There is some slow-down, don't know why it is not visible in your full-stack bench.","1","2015-06-03T03:31:02Z"
"245904","14360","108179263","47848","rafaelfranca","Hmm, the slow-down is significant.","1","2015-06-03T03:42:26Z"
"245905","14488","43898759","3124","tenderlove","????❤️?❤️??????
--
Aaron Patterson
http://tenderlovemaking.com/
I'm on an iPhone so I apologize for top posting.
> On May 22, 2014, at 7:25 AM, Arthur Nogueira Neves <notifications@github.com> wrote:
>
> @tenderlove , I am also concerned about people accessing those reflections.
> So lets this, as this is the work around we need for 4.1. And I will work in a better structure for 4.2(master)
>
> —
> Reply to this email directly or view it on GitHub.","1","2014-05-22T14:52:44Z"
"245906","14488","43967729","833383","arthurnn","https://www.youtube.com/watch?v=BTTygyxuGj8#t=2166","1","2014-05-23T03:21:31Z"
"245907","14488","44057956","47848","rafaelfranca","@arthurnn could you add CHANGELOG entry?","1","2014-05-23T20:41:51Z"
"245908","14488","44059053","833383","arthurnn","for sure.. 1 sec
On Friday, May 23, 2014, Rafael Mendonça França <notifications@github.com>
wrote:
> @arthurnn <https://github.com/arthurnn> could you add CHANGELOG entry?
>
> —
> Reply to this email directly or view it on GitHub<https://github.com/rails/rails/pull/15210#issuecomment-44057956>
> .
>
--
Arthur Nogueira Neves
Follow me @arthurnn <http://www.twitter.com/arthurnn89>","1","2014-05-23T20:52:11Z"
"245909","14488","44063686","833383","arthurnn","Changelog added. good to go..","1","2014-05-23T21:40:35Z"
"245910","14490","43706040","47848","rafaelfranca","I think string support would be great. Mind to update this PR?","1","2014-05-21T02:28:14Z"
"245911","14490","43712076","120350","todd","On it.","1","2014-05-21T04:51:58Z"
"245912","14490","43715876","120350","todd","@rafaelfranca Code added, would love your feedback.","1","2014-05-21T06:16:54Z"
"245913","14490","43804099","120350","todd","@rafaelfranca Just pushed changes based on @arthurnn's and your feedback.","1","2014-05-21T19:39:22Z"
"245914","14490","44357498","120350","todd","@rafaelfranca I'm sure you're busy, but I just wanted to make sure that you saw that I made the changes based on your feedback. Let me know if I need to change anything else.","1","2014-05-28T02:05:09Z"
"245915","14490","44445996","47848","rafaelfranca",":+1: I saw your changes. I still have a open tab in my chrome to this. I'll merge as soon I finish the release.","1","2014-05-28T18:26:22Z"
"245916","14490","44447921","120350","todd",":heart: ","1","2014-05-28T18:41:34Z"
"245917","14491","43714370","55829","chancancode",":+1:. However, we can't edit the release notes post-release, can you revert those changes? Also, it's probably worth adding a CHANGELOG entry for this (the one in the /guides folder). Finally, it would be nice to add ""This is a continuation of 2d46e77 / #13774"" or something similar in the commit message to help future contributors out.
If you can do those changes and squash them back into a single commit, that would be great :heart:","1","2014-05-21T05:44:24Z"
"245918","14491","43807865","160941","guilleiguaran","We need a rebase also :heart: ","1","2014-05-21T20:13:35Z"
"245919","14491","43844150","2823694","JohnKellyFerguson","@chancancode @guilleiguaran, I addressed all of your comments:
* Reverted the changes to release notes
* Updated the changelog
* Changed the commit message
* Rebased
This should be good to merge. :heart: :smile: ","1","2014-05-22T03:05:03Z"
"245920","14491","43844338","55829","chancancode","Actually, can you put your changelog entry at the top of the file? :smile: if you don't have time I can fix that for you later and merge it.
Thanks for you effort! :+1:","1","2014-05-22T03:09:01Z"
"245921","14541","44077579","3124","tenderlove","?????
--
Aaron Patterson
http://tenderlovemaking.com/
I'm on an iPhone so I apologize for top posting.
> On May 23, 2014, at 11:12 AM, Sean Griffin <notifications@github.com> wrote:
>
> @tenderlove and I were talking about this a bit, as well.
>
> —
> Reply to this email directly or view it on GitHub.","1","2014-05-24T04:35:29Z"
"245922","14542","44046870","47848","rafaelfranca","Is it necessary? It is already documented as `* Any other key creates standard HTML attributes for the tag.`. Also I don't think we should add an example for every possible HTML attribute.","1","2014-05-23T18:46:23Z"
"245923","14542","44047831","4130121","omarismail","I was trying to use jQuery in order to target a select tag based off its id, and wanted to set its id to something other than the name. I had to look in the source code to see how to do it, and the docs didnt show how to alter the id. So i figured other people would find it useful as well. ","1","2014-05-23T18:55:36Z"
"245924","14542","44048285","47848","rafaelfranca","Is not `* Any other key creates standard HTML attributes for the tag.` clear about this? `id` is one HTML attributes for a tag.
Maybe we should change the example that set the class to include also the id instead of adding a new example. What do you think?","1","2014-05-23T19:00:37Z"
"245925","14542","44049251","4130121","omarismail","Yeah it is clear about this. I didn't actually see that line, I went directly to the examples to see if it was done. My bad.
Sure, I think that changing the example which sets the class to also include the id is a cleaner approach. ","1","2014-05-23T19:09:37Z"
"245926","14542","44049367","47848","rafaelfranca","Great! So please update your patch to change the existing example.
Thank you for working on it.","1","2014-05-23T19:10:46Z"
"245927","14542","44050625","4130121","omarismail","Updated!
Thanks for the feedback! This is my first PR to Rails","1","2014-05-23T19:23:57Z"
"245928","14542","44051508","125715","pftg","@oismail91 please squash your commits","1","2014-05-23T19:33:34Z"
"245929","14542","44057756","47848","rafaelfranca","Very good! Thank you so much.","1","2014-05-23T20:39:46Z"
"245930","14543","44048081","1529387","sgrif","/cc @tenderlove @senny @rafaelfranca ","1","2014-05-23T18:58:10Z"
"245931","14543","44048593","47848","rafaelfranca","Cool! I'm thinking, could we go a step forward and make this feature part of Active Model? I think it is very useful to have typecasting behaviour in PORO objects.","1","2014-05-23T19:03:33Z"
"245932","14543","44048732","1529387","sgrif","Yes! However, I'd like to work towards that in smaller steps.
On May 23, 2014 12:04 PM, ""Rafael Mendonça França"" <notifications@github.com>
wrote:
> Cool! I'm thinking, could we go a step forward and make this feature part
> of Active Model? I think it is very useful to have typecasting behaviour in
> PORO objects.
>
> —
> Reply to this email directly or view it on GitHub<https://github.com/rails/rails/pull/15284#issuecomment-44048593>
> .
>","1","2014-05-23T19:04:52Z"
"245933","14543","44048814","47848","rafaelfranca",":+1:, yes. I agree, I was just wondering since this is something I always wanted to have in Active Model.","1","2014-05-23T19:05:34Z"
"245934","14543","44059156","1529387","sgrif","@rafaelfranca Updated, squashed, rebased.","1","2014-05-23T20:53:13Z"
"245935","14543","44061983","3124","tenderlove","Weren't we going to implement serialized columns in terms of this?","1","2014-05-23T21:20:26Z"
"245936","14543","44062039","1529387","sgrif","Yes, planning on doing that as a separate PR.","1","2014-05-23T21:20:51Z"
"245937","14543","44062584","3124","tenderlove","@jeremy wdyt?","1","2014-05-23T21:26:14Z"
"245938","14543","44085608","1529387","sgrif","CI failure seems to be something unrelated crapping out.","1","2014-05-24T12:22:21Z"
"245939","14543","44087726","5402","senny","In my opinion we need to make sure that the `Type` can control both ways of casting:
1. `SQL Type` => `Ruby Type`
2. `Ruby Type` => `SQL Type`
Before that we should not expose this API. Currently these `Type` objects allow you to control 1.) but 2.) is still hardcoded in case statements within `quoting.rb`.","1","2014-05-24T13:48:08Z"
"245940","14543","44224542","47848","rafaelfranca","@senny's concerns were already implemented so I'm merging this to not block @sgrif future work.","1","2014-05-26T23:53:27Z"
"245941","14543","44279130","2741","dhh","We use the term ""attributes"" everywhere else in the code. Like update!(attributes). Is properties the same concept? Does it make sense to have it be called something else?","1","2014-05-27T13:55:42Z"
"245942","14543","44279740","1529387","sgrif","I went with the name `property`, to distance it from `attr_accessor`s, and things from active support like `class_attribute`. We also have a module in AR/AM called `AttributeMethods`, which would have a confusingly similar name. That said, I don't feel terribly strongly about it, and I'm not opposed to changing the method to `attribute`. WDYT?","1","2014-05-27T14:00:28Z"
"245943","14543","44280414","2741","dhh","I don’t like having a domain language that uses both “attributes” and “properties” to talk about the same thing. One thing could be to clarify things further with something like `attribute_type :price_in_cents, MoneyType.new`. Then we could call this whole thing AttributeTypes.
Looking at the API for the ActiveRecord::Type, I don’t quite understand the MoneyType.new. Are the initializers always parameterless? What’s the API contract for these types?
On May 27, 2014, at 4:01 PM, Sean Griffin <notifications@github.com> wrote:
> I went with the name property, to distance it from attr_accessors, and things from active support like class_attribute. We also have a module in AR/AM called AttributeMethods, which would have a confusingly similar name. That said, I don't feel terribly strongly about it, and I'm not opposed to changing the method to attribute. WDYT?
>
> —
> Reply to this email directly or view it on GitHub.
> ","1","2014-05-27T14:05:37Z"
"245944","14543","44281650","1529387","sgrif","`attribute_type` feels misleading, since this creates an attribute, not necessarily just changing an existing one. What do you think about just `attribute`?
The initializer for the built in types (with the exception of a handful of PG specific types) takes an options hash for things like `precision` and `scale`. At the moment there's no reason for a user to specify those, as this does not affect schema dumping, though they are used when these types are built internally, and I plan for there to be a few use cases in which the user may want to specify them.
The contract for the types are the public methods on `Type::Value`. Most users will subclass that, or one of the existing types. My expectation is that most users will only override `type_cast`, and possibly `type_cast_for_database`.","1","2014-05-27T14:15:41Z"
"245945","14543","44281663","47848","rafaelfranca","Good question. I believe they are the same concept.
When defining a Active Record Model we loop in all the columns of the database and call the `define_attribute_method` method to define the writer and reader to that column. The new API introduced in this PR changes the way these attributes are converted and change these methods indirectly changing the column hash, that said they are the same concept.
Thinking about moving this behavior to Active Model I think it make more sense this new API be called `attribute`.","1","2014-05-27T14:15:45Z"
"245946","14543","44281930","2741","dhh","The problem with attribute is that appears exhaustive, which is confusing when using with AR. Most AR attribute types are derived automatically from the schema. If you start declaring “attribute :x” in an AR, it’s going to feel incomplete unless you declare all of them. And we don’t want to do that.
On May 27, 2014, at 4:16 PM, Sean Griffin <notifications@github.com> wrote:
> attribute_type feels misleading, since this creates an attribute, not necessarily just changing an existing one. What do you think about just attribute?
>
> The initializer for the built in types (with the exception of a handful of PG specific types) takes an options hash for things like precision and scale. At the moment there's no reason for a user to specify those, as this does not affect schema dumping, though they are used when these types are built internally, and I plan for there to be a few use cases in which the user may want to specify them.
>
> The contract for the types are the public methods on Type::Value. Most users will subclass that, or one of the existing types. My expectation is that most users will only override type_cast, and possibly type_cast_for_database.
>
> —
> Reply to this email directly or view it on GitHub.
> ","1","2014-05-27T14:17:52Z"
"245947","14543","44282086","1529387","sgrif","@rafaelfranca I do think this should end up on Active Model, but I have more refactoring to do before it's ready to be moved up.
@dhh The plan is to have automatically derived attributes from the schema call this method internally, and have the ability to opt out of automatic schema detection.","1","2014-05-27T14:19:01Z"
"245948","14543","44282681","2741","dhh","Here's what I wouldn't like to see:
```ruby
class Person < ActiveRecord::Base
attribute :name, Type::Name.new
end
```
That implies that the only attribute the Person class has is name. That's very unclear. Explicit declarations mixed with implicit derived types does not mix well unless the API is exceedingly clear. This, imo, is not.
Secondarily, how does this mesh with other attribute declarations, like validations?","1","2014-05-27T14:23:32Z"
"245949","14543","44282753","833383","arthurnn","my 2 cents on this: I would go with `attribute_type` , Indeed, if we allow some generic method name like `attribute`, users might get confused about which attributes should they define in the class, if all, and why not all. But if we are more specific like `attribute_type value: Decimal` it will be more clear the functionality of that method.","1","2014-05-27T14:24:04Z"
"245950","14543","44283104","47848","rafaelfranca","The problem with `attribute_type` is when using it on Active Model
```ruby
class ContactForm
include ActiveModel::Model
attribute_type :name, Type::String.new
end
```
To me this would not define the `ContactForm.new.name` method and I would have to call `define_attribute_method :name` too.","1","2014-05-27T14:26:35Z"
"245951","14543","44283331","2741","dhh","In fact, I might even suggest going more explicit: `attribute_type_cast :price_in_cents, Type::Integer.new`. This, imo, should not be that regular of an occurrence. I'd rather we make it very clear what's going on than try to optimize the char count on the call.","1","2014-05-27T14:28:12Z"
"245952","14543","44283351","1529387","sgrif","> Secondarily, how does this mesh with other attribute declarations, like validations?
It shouldn't affect them at all.
My only concern with `attribute_type` is that it implies the only thing it does is change the type casting behavior of existing attributes. The actual behavior here is to add a new attribute, overriding what was there before if there was anything. Especially once this goes up to Active Model, the name should imply that it can be exhaustive.","1","2014-05-27T14:28:21Z"
"245953","14543","44283900","1529387","sgrif","Couldn't one make the same argument for `attr_accessor` on models, as well? Users have no trouble mixing explicit vs implicit there, I think the same logic applies here.","1","2014-05-27T14:32:22Z"
"245954","14543","44284172","2741","dhh","I don't think it applies here because of how we're using the word attributes. ActiveModel is great, but the 95% use case is ActiveRecord. So the needs of secondary uses of ActiveModel should be subservient to the needs of ActiveRecord. And the need of ActiveRecord in this case is to make sure it's not confusing that you can declare your own type casts alongside the implicit schema-derived typecasts.","1","2014-05-27T14:34:29Z"
"245955","14543","44284973","47848","rafaelfranca","I agree Active Record is the majority of cases but I don't think Active Model should be irrelevant for defining this API. I also agree we need to make sure it is not confusing, so I think we should go with `attribute_type_cast` and make it an alias to `attribute_with_type_cast` documenting the first as the preferred way to define type cast behaviour on Active Record. On Active Model we can use the second, making the behaviour explicit in both cases.","1","2014-05-27T14:40:34Z"
"245956","14543","44285224","1529387","sgrif","I'm fine with `attribute_with_type_cast` -- The other case to think about with both AR and AM is additional options that are a property of the attribute, not the type, such as `default` (which there is a PR open to add).","1","2014-05-27T14:42:14Z"
"245957","14543","44285488","1529387","sgrif","Thoughts on aliasing it to `attribute`, as well? The succinctness is really nice if you've got a lot of these on your model.","1","2014-05-27T14:44:03Z"
"245958","14543","44286061","2741","dhh","I don’t want two APIs for this on Active Record. That’s just going to lead to different people and teams do different things.
To me, it doesn’t make sense unless every single attribute is listed to call it attribute. It implies full comprehensiveness.
On May 27, 2014, at 4:44 PM, Sean Griffin <notifications@github.com> wrote:
> Thoughts on aliasing it to attribute, as well? The succinctness is really nice if you've got a lot of these on your model.
>
> —
> Reply to this email directly or view it on GitHub.
> ","1","2014-05-27T14:47:57Z"
"245959","14543","44286522","47848","rafaelfranca","Ok. I think we are in the same page about calling it only `attribute`. I'd go with `attribute_type_cast`. It is still misleading since this method also define new attributes but we can add a note about this in the documentation.","1","2014-05-27T14:51:16Z"
"245960","14543","44286715","1529387","sgrif","> To me, it doesn’t make sense unless every single attribute is listed to call it attribute. It implies full comprehensiveness.
That will technically be true in the near future, as I'm refactoring towards this method being called by the automatic schema detection. Is there a way we can make that clear to users?
I'm also working on an alternate work flow where you are able to disable automatic schema detection, you do call this method for every attribute on the model, and then we're able to diff that against the schema and generate a migration, allowing the model to become the single source of truth for the attributes on it (I've always hated having to go to `schema.rb` to see the attributes available).
> It is still misleading since this method also define new attributes but we can add a note about this in the documentation.
I really worry we can turn this into a mine field that way. I shouldn't need to check the docs to see if the method does what the name implies or something else.","1","2014-05-27T14:52:32Z"
"245961","14543","44287712","1034","matthewd","`typed_attribute`?","1","2014-05-27T14:59:42Z"
"245962","14543","44314314","2741","dhh","I think we're trying to solve two problems with one API and it's not going well.
ActiveModel needs, perhaps, a way to define all attributes on that model in a typed way.
ActiveRecord needs a way to apply custom type casting.
Solving both problems with the same API is just not working. I could see ActiveModel having a separate Attributes declaration form that can be optionally mixed in that uses the ""attribute :name, :type, default: x"" form, but that's not available in AR. AR only gets ""attribute_type_cast :name, Type.new"".","1","2014-05-27T18:15:35Z"
"245963","14543","44314475","47848","rafaelfranca",":+1: Seems a good plan to me.","1","2014-05-27T18:16:54Z"
"245964","14543","44314502","2741","dhh","BTW, could someone share the use case they have for typed attribute declarations in AM? We shouldn't just be freewheeling here. Let's extract, not invent.","1","2014-05-27T18:17:07Z"
"245965","14543","44314632","47848","rafaelfranca","Sure. I have some examples.","1","2014-05-27T18:18:07Z"
"245966","14543","44315415","47848","rafaelfranca","```ruby
class Article
include ApiModel
attribute :title, String
attribute :subtitle, String
attribute :body, String
attribute :published_at, DateTime
attribute :pageviews, Integer
attribute :source
attribute :journalists, Array[Journalist]
attribute :channel, Channel
attribute :medias, MediaCollection
attribute :topics, Array[Topic]
attribute :content_type, String
end
```
This is extracted from one of our applications. These classes are used as clients to services APIs where the response body is JSON. With this custom type cast code we were able to reduce a lot of code to type cast native types like integers and date objects but we were also to cast some custom objects like `Channel` and array of `Topic` objects","1","2014-05-27T18:24:18Z"
"245967","14543","44315689","2741","dhh","So you use this Article to hold stuff you get from the API in JSON form? That seems like a good case. This example would certainly look much nicer with symbol references for the common types than full classes.
On May 27, 2014, at 8:24 PM, Rafael Mendonça França <notifications@github.com> wrote:
> class Article
> include ApiModel
>
> attribute :title, String
> attribute :subtitle, String
> attribute :body, String
> attribute :published_at
> attribute :pageviews, Integer
> attribute :source
> attribute :journalists, Array[Journalist]
> attribute :channel, Channel
> attribute :medias, MediaCollection
> attribute :topics, Array[Topic]
> attribute :content_type, String
> end
> This is extracted from one of our applications. These classes are used as clients to services APIs where the response body is JSON. With this custom type cast code we were able to reduce a lot of code to type cast native types like integers and date objects but we were also to cast some custom objects like Channel and array of Topic objects
>
> —
> Reply to this email directly or view it on GitHub.
> ","1","2014-05-27T18:26:30Z"
"245968","14543","44316052","1529387","sgrif","I think we should focus on getting a clean, consistent implementation, and then add things like symbols for types if we're still not happy about it once we've got everything else hammered out.","1","2014-05-27T18:29:07Z"
"245969","14543","44316589","2741","dhh","I think we should focus on solving actual cases that make real code better. Implementation is about efficiency, this is about effectiveness.
On May 27, 2014, at 8:29 PM, Sean Griffin <notifications@github.com> wrote:
> I think we should focus on getting a clean, consistent implementation, and then add things like symbols for types if we're still not happy about it once we've got everything else hammered out.
>
> —
> Reply to this email directly or view it on GitHub.
> ","1","2014-05-27T18:33:23Z"
"245970","14543","44316928","47848","rafaelfranca","Yes. All models on this application access data from APIs and all endpoints returns JSON, there is no database directly involved. So we hold the data on these models to use in our controllers and views, but without proper type cast code we would have to explicitly define accessors for each attribute that needs a type different from string.
So, before implementing this type cast code we had something like:
```ruby
class Article
def initialize(attributes)
@attributes = attributes
end
def published_at
DateTime.parse(@attributes[""published_at""])
end
end
```
In the last three years, the most part of applications I worked on were using JSON APIs for backend, and I do think adding this inside Rails would help to improve how these APIs clients are written.","1","2014-05-27T18:35:59Z"
"245971","14543","44317442","2741","dhh","Great example. This will be perfect for that.
On May 27, 2014, at 8:36 PM, Rafael Mendonça França <notifications@github.com> wrote:
> Yes. All models on this application access data from APIs and all endpoints returns JSON, there is no database directly involved. So we hold the data on these models to use in our controllers and views, but without proper type cast code we would have to explicitly define accessors for each attribute that needs a type different from string.
>
> So, before implementing this type cast code we had something like:
>
> class Article
> def initialize(attributes)
> @attributes = attributes
> end
>
> def published_at
> DateTime.parse(@attributes[""published_at""])
> end
> end
> In the last three years, the most part of applications I worked on were using JSON APIs for backend, and I do think adding this inside Rails would help to improve how these APIs clients are written.
>
> —
> Reply to this email directly or view it on GitHub.
> ","1","2014-05-27T18:39:55Z"
"245972","14543","44330025","1529387","sgrif","What I'd like to see happen with this feature is this:
- Both `attribute` and `attribute_type_cast` as method names. Similar to `before_filter` and `before_action`, one may read better than the other in some situations, but the default should imply all of its behavior and not rely on a comment in the docs.
- Simple, low level, public API. This has been about exposing a lower level to work at, and making it public so users or gem makers who choose to work at that level can rely on its continued existence. The goal has been to add ways to remove magic, not add more of it. Things like symbols with special meaning rather than objects undermines that goal. Higher level abstractions can be built on top of this if needed.","1","2014-05-27T20:21:28Z"
"245973","14543","44330175","1529387","sgrif","Also we should focus on Active Record, and wait until we're in a place that AM is ready to be worked on before worrying about the needs there.","1","2014-05-27T20:22:26Z"
"245974","14543","44330545","47848","rafaelfranca","If this is a low level API it should not be present in documentation. But I really didn't get the downsides of implementing the symbol support. There is no magic involved. It is a deterministic behaviour and if properly documented it will be not a problem.","1","2014-05-27T20:25:36Z"
"245975","14543","44330671","2741","dhh","I'm not interested in having `attribute` exposed by default in AR for the reasons explained above. It makes sense when you're providing a full declaration of all attributes, as in Rafael's example, but I find it terribly confusing when it's only a partial declaration. So :-1: on that.
I guess we have different goals. Rafael has provided the only ActiveModel specific use case in this thread, and that case would clearly read much better with symbol references for the default types. If you have other use cases that counter that, I'd love to see that.","1","2014-05-27T20:26:42Z"
"245976","14543","44330802","2741","dhh","(Also, for the record, I'd like to remove `before_filter` from Rails 5)","1","2014-05-27T20:27:57Z"
"245977","14543","44331211","242532","egilburg",">(Also, for the record, I'd like to remove before_filter from Rails 5)
From controllers? What do you envision replacing it with? Just inline method code for each action?","1","2014-05-27T20:31:32Z"
"245978","14543","44331364","1529387","sgrif","Low level doesn't necessarily mean not useful to hook into, hence the desire to make it public, and therefore stable. Symbol support just feels unnecessary, given how light weight instantiating the objects is. Most of the refactoring that was required to make this happen was removing conditionals based on symbols with special meaning in favor of objects. I'd like to avoid ending up back in that situation. ","1","2014-05-27T20:32:54Z"
"245979","14543","44331410","47848","rafaelfranca","@egilburg `before_action` is the replacement.","1","2014-05-27T20:33:16Z"
"245980","14543","44331897","47848","rafaelfranca","@sgrif I think you misunderstood what would be the symbol support. The type object would be still there, but with a better API. A simple and dirty implementation:
```ruby
def property(name, cast_type_symbol)
name = name.to_s
cast_type = Type.const_get(cast_type_symbol)
user_provided_columns[name] = ConnectionAdapters::Column.new(name, nil, cast_type.new)
end
```
","1","2014-05-27T20:37:17Z"
"245981","14543","44331938","1529387","sgrif","And as I've said previously, I'm also concerned that things like symbols for types will make it more difficult to work on this as we see how the API evolves as the implementation finishes.","1","2014-05-27T20:37:32Z"
"245982","14543","44331975","2741","dhh","Here’s a general value for Rails development: We will jump through hoops on the implementation to make the user-facing API nicer. Rafael’s example is made worse for dropping the symbol conversion, and if the only justification is “less implementational work”, then that violates the stated value above.
On May 27, 2014, at 10:33 PM, Sean Griffin <notifications@github.com> wrote:
> Low level doesn't necessarily mean not useful to hook into, hence the desire to make it public, and therefore stable. Symbol support just feels unnecessary, given how light weight instantiating the objects is. Most of the refactoring that was required to make this happen was removing conditionals based on symbols with special meaning in favor of objects. I'd like to avoid ending up back in that situation.
>
> —
> Reply to this email directly or view it on GitHub.
> ","1","2014-05-27T20:37:50Z"
"245983","14543","44332634","1529387","sgrif","I'm not saying we shouldn't jump through hoops to simplify the implementation, I'm saying its premature. We're not sure of the needs at the lower level yet. We should get that implemented well in a maintainable fashion, and then evaluate what's missing from the public API.","1","2014-05-27T20:43:19Z"
"245984","14543","44333135","2741","dhh","We shouldn’t even work on the implementation if we don’t know how this is going to be used.
But Rafael’s use case looks clear to me. What is left to understand?
On May 27, 2014, at 10:43 PM, Sean Griffin <notifications@github.com> wrote:
> I'm not saying we shouldn't jump through hoops to simplify the implementation, I'm saying its premature. We're not sure of the needs at the lower level yet. We should get that implemented well in a maintainable fashion, and then evaluate what's missing from the public API.
>
> —
> Reply to this email directly or view it on GitHub.
> ","1","2014-05-27T20:47:32Z"
"245985","14543","44343951","116327","gylaz","What about `attribute_with_type`? This name seems to imply that an attribute is created (with getters/setters), but it can also be derived that its usage is to specify a type that is different from the one inferred by automatic schema generation. Thus, it alleviates the problem that only `attribute_with_type` entries are attributes of a record.","1","2014-05-27T22:30:32Z"
"245986","14543","44387483","2741","dhh","All attributes has some kind of type, and `attribute_with_type` still implies an exhaustive list of all attributes is presented.","1","2014-05-28T10:16:33Z"
"245987","14543","44394057","2394703","seuros","What about :
```ruby
class Article
include ApiModel
cast_attributes_as String, :title, :subtitle, :body
cast_attributes_as DateTime, :published_at
cast_attributes_as Integer, :pageviews
# ......
end
```","1","2014-05-28T11:24:10Z"
"245988","14543","44421934","2741","dhh","When you're supplying an exhaustive list of all attributes, I prefer the `attribute :title` per-line approach. I don't think we need to try to save a newline per attribute.","1","2014-05-28T15:28:02Z"
"245989","14543","44432652","7371","mcmire","What about `add_attribute`? This implies that you're adding to what currently exists. If you have an ActiveModel class, your model doesn't have any attributes to begin with, so you're adding starting from nothing. If you have an ActiveRecord class, it could imply either that you're overriding an attribute that already exists, or you're adding a new attribute.","1","2014-05-28T16:39:49Z"
"245990","14543","44432967","2741","dhh","Not liking that either. In AR, this is used to perform custom type casts on attributes that have already been dynamically reflected from the schema. In the API example, you’re exhaustively declaring all the attributes up front.
On May 28, 2014, at 6:40 PM, Elliot Winkler <notifications@github.com> wrote:
> What about add_attribute? This implies that you're adding to what currently exists. If you have an ActiveModel class, your model doesn't have any attributes to begin with, so you're adding starting from nothing. If you have an ActiveRecord class, it could imply either that you're overriding an attribute that already exists, or you're adding a new attribute.
>
> —
> Reply to this email directly or view it on GitHub.
> ","1","2014-05-28T16:42:07Z"
"245991","14543","44778847","354185","robin850","I'm not comfortable with AR internals but I'm :+1: with @matthewd's suggestion (i.e. [this one](https://github.com/rails/rails/pull/15284#issuecomment-44287712)). I agree with @dhh that we should have two different APIs. I think `property` is doing too much. We should provide something like:
~~~ruby
type_cast :price, to: Type::Custom.new
~~~
And for the case of the ""automatic schema detection"", we can provide what Rafael suggested for Active Model (i.e. `attribute :attr, Object`) and just extend this method in Active Record to define the schema.
Sorry if what I'm saying doesn't make any sense.","1","2014-06-01T14:18:48Z"
"245992","14543","44855674","2741","dhh","How is all this different than the existing `composed_of` method, btw?","1","2014-06-02T15:57:24Z"
"245993","14543","44857562","1529387","sgrif","```ruby
class UsesComposedOf < ActiveRecord::Base
composed_of :balance, constructor: (value)-> { create_money(value) }, converter: (value)-> { dump_money(value) }
end
class UsesProperty < ActiveRecord::Base
property :balance, MyType.new
end
uses_composed_of = UsesComposedOf.new
uses_composed_of.balance = some_money
# calls: dump_money -> Type::Integer#type_cast_for_write -> @raw_attributes['balance']
uses_composed_of.balance
# calls: @raw_attributes['balance'] -> Type::Integer#type_cast -> create_money
uses_property = UsesProperty.new
uses_property.balance = some_money
# calls: MyType#type_cast_for_write -> @raw_attributes['balance']
uses_property.balance
# calls: @raw_attributes['balance'] -> MyType#type_cast
```
This allows you to override behavior, `composed_of` lets you add another layer in a less meaningful way. `composed_of` actually could be simplified if it called this API under the hood, while this feature could not be implemented in terms of `composed_of`. As I've said earlier, this could eventually even create a different flow for schema/migrations, since this lets us hook into that level. `serialized_attributes` is down to ~10 lines of code, and a fairly simple type object after refactoring it to be defined in terms of this API. Custom PG types could be supported with this, while they could not with `composed_of`.
For the time being this has been removed from the public API while I flesh out some other issues, so I'd like to table the discussion for now, and continue when we start looking at exposing the public API again. ","1","2014-06-02T16:12:39Z"
"245994","14543","47997721","808","cmrichards","Interesting discussion.
How is using a symbol clearer than using a class? I must be missing something here. I use Virtus every so often and it uses classes and works perfectly well. I can't see what would be gained by Virtus switching from classes to symbols. I'm happy to have my eyes opened on this one if there's something I'm missing. Is it just a subjective style issue or would there be a real advantage? ","1","2014-07-04T00:15:01Z"
"245995","14543","47997850","2741","dhh","Your problem is right here: ""Is it just a subjective style issue or would there be a real advantage?"". Pitting those two terms against each other is not what we do here. Much of Rails is ""subjective style issues"" that together add up to ""a real advantage"".","1","2014-07-04T00:17:25Z"
"245996","14543","47998406","808","cmrichards","I suppose that using symbols instead of classes would at least make it more consistent with other areas in Rails, such as migrations, which has to count for something. From this point of view the question turns into : ""why should we use classes?"".
Wouldn't using classes make it easier to use your own class as a type?","1","2014-07-04T00:30:05Z"
"245997","14543","47998449","1529387","sgrif","Both will be supported
On Jul 3, 2014 6:30 PM, ""Chris"" <notifications@github.com> wrote:
> I suppose that using symbols instead of classes would at least make it
> more consistent with other areas in Rails, such as migrations, which has to
> count for something. From this point of view the question turns into : ""why
> should we use classes?"".
>
> Wouldn't using classes make it easier to use your own class as a type?
>
> —
> Reply to this email directly or view it on GitHub
> <https://github.com/rails/rails/pull/15284#issuecomment-47998406>.
>","1","2014-07-04T00:31:11Z"
"245998","14543","47998479","2741","dhh","The two are not in opposition either. You can use symbols to refer to base classes, and you can also accept classes for your own types.
On Jul 3, 2014, at 7:30 PM, Chris <notifications@github.com> wrote:
> I suppose that using symbols instead of classes would at least make it more consistent with other areas in Rails, such as migrations, which has to count for something. From this point of view the question turns into : ""why should we use classes?"".
>
> Wouldn't using classes make it easier to use your own class as a type?
>
> —
> Reply to this email directly or view it on GitHub.
> ","1","2014-07-04T00:32:00Z"
"245999","14543","51003453","2741","dhh","Was this merged as `property`? I thought we agreed on changing the API to `attribute`,","1","2014-08-03T21:20:36Z"
"246000","14543","51004157","2394703","seuros","It was merged before the discussion apparently.","1","2014-08-03T21:43:36Z"
"246001","14543","51004767","1529387","sgrif","It was merged and made private. Its been renamed to `attribute` since, but its still private for the time being as I'm still doing work around it. ","1","2014-08-03T22:04:59Z"
"246002","14544","44058821","2371639","sergey-alekseev","cc @jonleighton 8c2c60511beaad05a218e73c4918ab89fb1804f0
and @amatsuda de75af7acc5c05c708443de40e78965925165217","1","2014-05-23T20:49:58Z"
"246003","14544","44059131","47848","rafaelfranca","Yes, you are right. We only need to remove the tests since `where!` is not public API.","1","2014-05-23T20:52:59Z"
"246004","14544","44059467","2371639","sergey-alekseev","@rafaelfranca Did it.","1","2014-05-23T20:56:36Z"
"246005","14545","44058993","277819","zzak","@rafaelfranca here is the backport commit: afb44f4","1","2014-05-23T20:51:39Z"
"246006","14545","44059582","277819","zzak","commit miss, see afb44f46c7b6a807ed17f504546256382c019fcc","1","2014-05-23T20:58:07Z"
"246007","14552","44133215","59744","schneems","Fixed, build is green","1","2014-05-25T13:29:20Z"
"246008","14552","44140456","752058","gregmolnar",":+1: ","1","2014-05-25T17:26:44Z"
"246009","14553","44090604","47848","rafaelfranca","There are some deprecation warning in our test suite we should silent they.","1","2014-05-24T15:30:36Z"
"246010","14553","44270079","1529387","sgrif","@rafaelfranca This has been updated.","1","2014-05-27T12:43:14Z"
"246011","14556","665194","199","jeremy","Thanks!","1","2011-01-09T23:48:43Z"
"246012","14560","44101492","833383","arthurnn","looks good.. thanks","1","2014-05-24T22:28:42Z"
"246013","14561","44104251","833383","arthurnn","Not sure if we need to update all those spots, and if so, we need to automate that. I remember @rafaelfranca talked about a little short ago.. thoughts Rafael?","1","2014-05-24T22:56:53Z"
"246014","14561","44104317","277819","zzak","Technically this should be 4.2.0, as that is what we're using on master.
That said, @JohnKellyFerguson, could you rebase this against the 4-1-stable branch?","1","2014-05-24T22:57:08Z"
"246015","14561","44104402","3387","fxn","@arthurnn but until we have no automation PRs have to be merged, having obsolete versions is not an option.","1","2014-05-24T22:58:13Z"
"246016","14561","44104655","277819","zzak","backport what i could to 4-1-stable in 45c5f43","1","2014-05-24T23:13:41Z"
"246017","14561","44115039","1000669","JuanitoFatas","Previous discussion of Automation PR is here: https://github.com/rails/rails/pull/14996","1","2014-05-25T06:04:50Z"
"246018","14562","44110165","4335742","tgxworld","cc @rafaelfranca ","1","2014-05-25T03:00:27Z"
"246019","14563","44113316","55829","chancancode","cc @senny if you want to follow along.
In 4.1 and before, the items in the release notes are from oldest (top) to newest (bottom). Here we decided to reverse it to match the ordering of CHANGELOGs. Since we intend to continuously add new stuff to the release notes after this is merged into master, making CHANGELOGs and release notes follow the same convention would make things less error prone and easier to review. Any objections there?","1","2014-05-25T05:34:34Z"
"246020","14563","44113340","55829","chancancode","We also use a different tense in CHANGELOGS/commit messages (""Add xyz"", ""Change xyz"", ""Remove xyz"") and release notes (""Added xyz"", ""Changed xyz"", ""Removed xyz"")... :neutral_face: <---- @fxn do you know why?","1","2014-05-25T05:36:36Z"
"246021","14563","44119104","1034","matthewd","Release notes are written to be read; the obvious situation that comes to mind is where one release note item builds upon another (without sufficient overlap to warrant merging them).
But from a quick scroll through the last few, it sounds more like they're ordered by significance/impact -- which seems a more reader-friendly choice than any arbitrary chronology.","1","2014-05-25T07:04:35Z"
"246022","14563","44121181","3387","fxn","@chancancode it is not something chosen that I know of, probably just people following the existing pattern in each place.","1","2014-05-25T07:34:01Z"
"246023","14563","45134046","55829","chancancode","@senny @fxn @rafaelfranca @zzak @robin850 @rafaelfranca I think this is good for a final review and then merged into master :grinning: I removed it from the index as this is clearly incomplete, but people can start working on it from now.
@matthewd I kept the same order as the CHANGELOG for now, to make it easier to review and sync. We can do a final pass before release to clean it up.","1","2014-06-04T18:47:31Z"
"246024","14564","44111008","1529387","sgrif","@senny Simpler and less of a refactor than we wanted, but the code in question is a complete rats nest, and requires larger changes. Going to refactor the surrounding code *a lot* this week, but this should be the minimum acceptable to get #15284 out the door so I can continue working on that as well.","1","2014-05-25T04:09:20Z"
"246025","14564","44142278","55829","chancancode","@sgrif @senny there are actually four ways of ""typecasting"" that a column type might want to control:
User input (strings from forms) <=> Ruby <=> Database
When some of these APIs [were first introduced](https://github.com/rails/rails/commit/7b5ed66122873eebb773a6418f3a94d946cc4f8c), the distinction between these tasks were not clearly distinguished (sometimes implicit, even). We managed to get by because historically the types are pretty simple and these roles overlapped.
(For example, what does the ""typecast"" in `_before_typecast` refer to?)
As we move towards more complex types, we should probably clean that up and eliminate the confusions if we can.
Examples:
""$12.5"" <=> Money.new(12, 5) <=> 1250
""unread"" <=> :unread <=> 1
""1"" <=> true<=> ""1""
...
(This comment is not directed towards the implementation in this PR but more towards the direction I think we should take.)","1","2014-05-25T18:45:42Z"
"246026","14564","44142317","1529387","sgrif","I agree, that's partially what I'm working towards
On May 25, 2014 11:46 AM, ""Godfrey Chan"" <notifications@github.com> wrote:
> @sgrif <https://github.com/sgrif> @senny <https://github.com/senny> there
> are actually four ways of ""typecasting"" that a column type might want to
> control:
>
> User input (strings from forms) <=> Ruby <=> Database
>
> When some of these APIs were first introduced<https://github.com/rails/rails/commit/7b5ed66122873eebb773a6418f3a94d946cc4f8c>,
> the distinction between these tasks were not clearly distinguished
> (sometimes implicit, even). We managed to get by because historically the
> types are pretty simple and these roles overlapped.
>
> (For example, what does the ""typecast"" in _before_typecast refer to?)
>
> As we move towards more complex types, we should probably clean that up
> and eliminate the confusions if we can.
>
> Examples:
>
> ""$12.5"" <=> Money.new(12, 5) <=> 1250
> ""unread"" <=> :unread <=> 1
> ""1"" <=> true<=> ""1""
>
> ...
>
> (This comment is not directed towards the implementation in this PR but
> more towards the direction I think we should take.)
>
> —
> Reply to this email directly or view it on GitHub<https://github.com/rails/rails/pull/15307#issuecomment-44142278>
> .
>","1","2014-05-25T18:47:24Z"
"246027","14564","44149240","1529387","sgrif","In the long term, I think there's a few steps we should take, and type casting should be broken into several pieces.
- form data => type cast ruby value
- I do not think this logic should live in Active Record
- ruby => form data
- Should maintain the behavior of `_before_type_cast`, but with a better name.
- database => type cast ruby value
- Should maintain the behavior of `type_cast`, but with a more descriptive name.
- ruby => database
- I think `type_cast_for_database` fits here.
A side effect of the first piece of that is that we should reduce the amount of type casting that occurs when setting an attribute under normal circumstances. If any type casting at all happens, it should follow ruby semantics. Boolean should do `!!value`. String should do `value.to_s`. Integer should do `value.to_i`.
I do not think we can get there in 4.2, as most of those thoughts would require breaking changes to public APIs. I also think all of these points require further discussion, but long term that is the general direction that I'd like to move this behavior.","1","2014-05-25T23:54:01Z"
"246028","14564","44149340","55829","chancancode","Do you have any proposals for `form data <-> ruby`? If it would require knowing the `Type` to work properly, it seems reasonable that it happens inside the `Type`?
> ...reduce the amount of type casting that occurs when setting an attribute under normal circumstances
I think we need to define ""normal"" here. In a web application, setting attributes based on string-based user input probably happens more often than assigning Ruby values :)
I agree you wouldn't have to worry about setting an int column to a symbol though or boolean column to a hash, though.","1","2014-05-25T23:58:48Z"
"246029","14564","44149370","1529387","sgrif","By normal, I mean explicitly doing `user.admin = true`, or any direct attribute assignment.","1","2014-05-26T00:00:45Z"
"246030","14816","47275356","47848","rafaelfranca",":shipit:!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
Really awesome work as usual :clap: :clap: :clap: :clap:","1","2014-06-26T20:25:27Z"
"246031","14816","47276092","3009","fnando","<3 <3 <3
Thanks a lot, @senny!","1","2014-06-26T20:31:31Z"
"246032","14816","47276786","279344","fabianoleittes","Good work @senny, tks! :+1: ","1","2014-06-26T20:37:41Z"
"246033","14816","47277229","332276","shamanime","Nicely done! :+1: :shipit: ","1","2014-06-26T20:41:32Z"
"246034","14816","47288676","5402","senny","thanks guys :heart: ","1","2014-06-26T22:32:03Z"
"246035","14816","47312918","1322","thibaudgg","Nice, really useful. Thanks from Switzerland @senny!","1","2014-06-27T06:49:19Z"
"246036","14816","47347336","14680","tilsammans","Well done, love this. If anything can we make sure all the work by @matthuhiggins is being incorporated. I use Foreigner in all apps, would be best to have a smooth transition between the two.","1","2014-06-27T14:01:05Z"
"246037","14816","47349582","5402","senny","@tilsammans as described [above](https://github.com/rails/rails/pull/15606#issuecomment-45721221) you can transition to this. There will be small differences in the API and especially in the naming of foreign keys.
A lot of this PR is based on the work of @matthuhiggins and his work on foreigner. Hopefully we can improve this first draft down the line. :heart: ","1","2014-06-27T14:15:34Z"
"246038","14816","47360066","22061","dosire","Thanks for getting this into rails Yves! <3","1","2014-06-27T15:24:19Z"
"246039","14816","47368529","354185","robin850","Awesome work here! :heart:","1","2014-06-27T16:15:49Z"
"246040","14816","47375938","8185","matthuhiggins","Great stuff. I gladly relinquish my technical debt to Rails!","1","2014-06-27T17:15:30Z"
"246041","14816","48807792","38747","Krule","Finally! Thank you. :heart: ","1","2014-07-12T10:23:21Z"
"246042","14922","94266046","2741","dhh","I agree that we don't have a solid convention here that'll just work for most people most of the time. I've done collection routes myself quite a few times and never found that magical line that leads to extraction. ? on closing. Thanks for all the work exploring this.
> On Apr 7, 2015, at 16:55, Claudio B. <notifications@github.com> wrote:
>
> Hello again! Let me recap the status of this PR.
>
> Rails does not natively support collection routing
> Four years, @dhh came up with a gist suggesting how methods like update_many and destroy_many could be added to Rails to benefit the community
> Evolving from that initial idea, a Google Summer of Code 2013 project was run by @ujjwalt (mentored by @pixeltrix) which resulted in an original PR
> A year ago, the PR was submitted to rails/rails and it became the PR you are reading now
> Why did an idea that is simple to explain (provide methods that affect a collection or RESTful resources) took a long time to implement? Because of its subtleties.
>
> Things that were not evident in the original idea turned into big questions along the way. The following ones are extracted from the discussion notes of this same PR:
>
> Future work will include reducing replace and update_many to single line atomic database operations using ActiveRecord.
> We thought about the choice of using ""replace"" vs ""replace_many""
> PUT on collection [...] might be rarely used but it's there in case you need to.
> any specific integration with ActionView [...] indeed that's the next step. But we didn't want to jump ahead and implement soemthing that is dependent on a functionality that's not yet integrated.
> we also need to update rails/jbuilder#157 to cater to building collection responses.
> It is clear that is PR is onto something, but it looks like it is too big to be accepted.
>
> Are we able to merge just a small part of this PR into rails/rails? For instance: what if we started by just changing Rails to route a request like GET /posts/1,3,4 to posts#index (with a collection of ids), rather than to posts#show?
>
> That's what I suggested in this gist, and even such a small change raised more questions (see the discussion below the gist). As I wrote there:
>
> The difference in opinions is probably the reason why the original PR has been open for 9 months, and my desire is now to move forward: whether by accepting it, or coming to the conclusion that Rails is better off rejecting it.
>
> to which @ujjwalt replied:
>
> Agreed. I have also been waiting for a long time for this. I developed this as part of GSoC where it was proposed by the core team itself so all this while I've been thinking that this is something we've always wanted. A closure on it would be good.
>
> So what should the next step be?
>
> I asked several members of the Rails core team what they think about it, and it became more evident that trying to merge this PR into Rails 5 is beyond the current expectations. There are gems out there that let people deal with collection routing, and the changes suggested by the current PR might take on too many edge-cases to be beneficial.
>
> I think @ujjwalt and @pixeltrix did a great job in trying to assess the scope of Collection Routing in Rails. My personal suggestion is that we close this PR. Being on GitHub, we will always be able to look back and eventually implement portions of it, but I don't think there is real value in leaving it open now.
>
> @dhh @pixeltrix I leave this to you! Thanks
>
> —
> Reply to this email directly or view it on GitHub.
>
","1","2015-04-19T11:18:29Z"
"246043","14922","94306032","47848","rafaelfranca","Thank you so much for the work on this.","1","2015-04-19T19:14:41Z"
"246044","14922","95929583","2741","dhh","Actually, I just had to do yet another set of bulk controllers in the past week, and I'm thinking we can get a lot of bang for just a few bucks by focusing on just the routing part, and just focus on the comma-separated list. Here's a proposal that also unifies the naming around ""bulk"":
```ruby
resources :posts, bulk: true
class PostsController
# GET /posts/1,4,5
def show_bulk
end
# GET /posts/1,4,5/edit
def edit_bulk
end
# PATCH/PUT /posts/1,4,5
def update_bulk
end
# DELETE /posts/1,4,5
def destroy_bulk
end
end
```","1","2015-04-24T13:13:02Z"
"246045","14922","95930167","660290","ujjwalt","@dhh: I can make those changes and push them in a couple of days. What say?
On Fri, 24 Apr 2015 at 6:44 pm, David Heinemeier Hansson <
notifications@github.com> wrote:
> Actually, I just had to do yet another set of bulk controllers in the past
> week, and I'm thinking we can get a lot of bang for just a few bucks by
> focusing on just the routing part, and just focus on the comma-separated
> list. Here's a proposal that also unifies the naming around ""bulk"":
>
> resources :posts, bulk: true
> class PostsController
> # GET /posts/1,4,5
> def show_bulk
> end
>
> # GET /posts/1,4,5/edit
> def edit_bulk
> end
>
> # PATCH/PUT /posts/1,4,5
> def update_bulk
> end
>
> # DELETE /posts/1,4,5
> def destroy_bulk
> endend
>
> —
> Reply to this email directly or view it on GitHub
> <https://github.com/rails/rails/pull/15719#issuecomment-95929583>.
>
","1","2015-04-24T13:15:45Z"
"246046","14922","95932985","2741","dhh","I'd be happy to review that, Ujjwal. I think part of the problem here was
trying to solve too wide a birth of use cases up front. Let's nip away at
this in bite sizes.
On Fri, Apr 24, 2015 at 3:16 PM, Ujjwal Thaakar <notifications@github.com>
wrote:
> @dhh: I can make those changes and push them in a couple of days. What say?
> On Fri, 24 Apr 2015 at 6:44 pm, David Heinemeier Hansson <
> notifications@github.com> wrote:
>
> > Actually, I just had to do yet another set of bulk controllers in the
> past
> > week, and I'm thinking we can get a lot of bang for just a few bucks by
> > focusing on just the routing part, and just focus on the comma-separated
> > list. Here's a proposal that also unifies the naming around ""bulk"":
> >
> > resources :posts, bulk: true
> > class PostsController
> > # GET /posts/1,4,5
> > def show_bulk
> > end
> >
> > # GET /posts/1,4,5/edit
> > def edit_bulk
> > end
> >
> > # PATCH/PUT /posts/1,4,5
> > def update_bulk
> > end
> >
> > # DELETE /posts/1,4,5
> > def destroy_bulk
> > endend
> >
> > —
> > Reply to this email directly or view it on GitHub
> > <https://github.com/rails/rails/pull/15719#issuecomment-95929583>.
>
> >
>
> —
> Reply to this email directly or view it on GitHub
> <https://github.com/rails/rails/pull/15719#issuecomment-95930167>.
>
","1","2015-04-24T13:32:12Z"
"246047","14922","95934094","10766","morgoth","@dhh How would you handle creating many records? Would it be `POST /posts/create_many` or maybe `POST /posts/bulk`?","1","2015-04-24T13:35:48Z"
"246048","14923","46085665","1529387","sgrif","Thanks for working on this. While I can see why this could make sense, I don't think it fills as common of a use case as `save!`. For that reason, I am :-1: on adding a new method to `ActiveRecord`","1","2014-06-14T11:43:40Z"
"246049","14923","46089429","621238","prathamesh-sonpatki","I think the only case where `save!` will not call validations is when we pass `validate: false`. (But that will be intention of the user to not call validations.) So `save!` will call cover this usecase.","1","2014-06-14T14:34:25Z"
"246050","14923","46091861","560664","schuetzm","@sgrif: I've looked at my last Rails projects, and in 4 out of 9 I use constructions like the following, sometimes several times:
```
unless @record.valid?
raise ActiveRecord::RecordInvalid.new(@record)
end
```
So this is a recurring pattern at least for me, and I think it's worth to support a DRYer alternative. Just as importantly IMO, it would be an inconsistency in the otherwise regular pairs of exception-less and exception-throwing methods like `save`, `update`, `create`, `destroy`, `find_by`, ...
@prathamesh-sonpatki: Well, `save!` saves the record. `validate(!)` is for validation without having to save.","1","2014-06-14T16:04:26Z"
"246051","14923","46092383","2394703","seuros",":+1: ","1","2014-06-14T16:23:53Z"
"246052","14923","46092438","1529387","sgrif","It seems like any code that would use this method would be using exceptions for control flow, since `validate` does no real work. ","1","2014-06-14T16:25:56Z"
"246053","14923","46092555","2394703","seuros","@sgrif, you are right.
My previous was meant to be :-1:
flow control should not use exceptions, throw/catch are meant for this.","1","2014-06-14T16:30:21Z"
"246054","14923","46093272","560664","schuetzm","@sgrif It does real work: it sets up the record's `errors` member.
@seuros That's an often repeated mantra, but it's wrong. Exceptions *are* mostly flow control (their other significant functionality is that they have a payload). In fact, they are used for this purpose all over the place in Rails, just think about the various HTTP error codes that can be returned by throwing the appropriate kinds of exceptions (404, 403, 503), or automatic rollback of transactions. Web apps lend themselves very well for this use pattern.","1","2014-06-14T16:54:31Z"
"246055","14923","46093424","2394703","seuros","@schuetzm , can you show us a case where this used ?","1","2014-06-14T16:59:10Z"
"246056","14923","46094201","560664","schuetzm","Sure. One example is a sign-up form, where users can enter their email address, which is then validated by sending them a confirmation email. The app doesn't create an actual record in the database until the user has confirmed their address by clicking on the confirmation link with a unique token. However, there are other data the users have to enter, like name, profession, date of birth. These all have to be verified (and the email address has to be checked for uniqueness) before the confirmation email is sent. If there's an error, I want an `ActiveRecord::RecordInvalid` exception as if it were actually saved, in order to get the usual error handling (in my case that's an `around_filter` which propagates the error message back to the client and displays them in the form).
In another example, I have a multistep ""wizard"" form. After the first step, I need to download some things from a remote URL on the server side, and afterwards display the next wizard step *without saving*, but this should only happen if the data in the form entered so far is valid. The actual saving happens only after all wizard steps have been completed.
The common theme is that sometimes data needs to be validated and the same error handling needs to happen as if it were saved, but without actually doing the saving.","1","2014-06-14T17:30:51Z"
"246057","14923","46094668","55829","chancancode","cc @dhh","1","2014-06-14T17:48:35Z"
"246058","14923","46741046","1034","matthewd","xref #8639","1","2014-06-21T01:30:31Z"
"246059","14923","47380413","47848","rafaelfranca","I merged this same feature as https://github.com/rails/rails/pull/8639. I credited both for it. Thank you so much.","1","2014-06-27T17:55:02Z"
"246060","14924","46083980","3387","fxn","This sample app is never in sync, I would consider deleting it.","1","2014-06-14T10:13:45Z"
"246061","14924","46084064","266217","sachin87","ok.","1","2014-06-14T10:17:46Z"
"246062","14924","46084160","3387","fxn","@rafaelfranca @zzak what do you think?","1","2014-06-14T10:22:41Z"
"246063","14924","46084370","266217","sachin87","by the way i think that any source code that i get from rails repository is a part of rails, and i changed this because it should be not be confusing for new rails developers, if they try to compare newly generated application it with this sample application.","1","2014-06-14T10:33:01Z"
"246064","14924","46084596","146214","vijaydev","@fxn I'm +1 for removing it. ","1","2014-06-14T10:46:48Z"
"246065","14924","46088796","5402","senny","let's remove it.","1","2014-06-14T14:06:51Z"
"246066","14924","46088828","47848","rafaelfranca",":+1: for removing. Try to keep it in sync would only make the release
process harder.
On Jun 14, 2014 11:06 AM, ""Yves Senn"" <notifications@github.com> wrote:
> let's remove it.
>
> —
> Reply to this email directly or view it on GitHub
> <https://github.com/rails/rails/pull/15721#issuecomment-46088796>.
>","1","2014-06-14T14:08:46Z"
"246067","14924","46089121","5402","senny","@sachin87 thank you for reporting. I removed the sample application.","1","2014-06-14T14:21:16Z"
"246068","14925","46085808","1529387","sgrif","These types of pull requests are nitpicky, and waste the core team's valuable time. This does not address any actual issues with the documentation. ","1","2014-06-14T11:50:54Z"
"246069","14925","46085964","1928523","akshay-vishnoi","As @fxn mentioned in #15555:
```
We always try to keep an eye on the way other projects spell their name and
follow their spelling, for consistency, and for respect.
```","1","2014-06-14T11:58:29Z"
"246070","14925","46085993","1928523","akshay-vishnoi","@sgrif : I know this is a not a BIG task, that's why I have tried to mark all spots of MySQL in a single PR, so as to reduce noise in future.
Thanks","1","2014-06-14T12:00:01Z"
"246071","14925","46145093","1928523","akshay-vishnoi","Thank you Sir. :green_heart: ","1","2014-06-16T06:34:38Z"
"246072","14925","46152943","3387","fxn","Yeah, welcome, we want top-quality docs and comments, and ""Mysql"" is not top-quality (in my book :).","1","2014-06-16T08:31:52Z"
"246073","14925","46161919","1928523","akshay-vishnoi","Okay I will not raise PR regarding naming of Other Libraries as they are not necessary, in future.","1","2014-06-16T10:16:27Z"
"246074","14925","46166633","3387","fxn","@akshay-vishnoi no, no, please do correct any misspellings you see, specially in the name of other projects.
In my mind paying attention to the way other projects spell their names is important. ""SQLite"" is written exactly that way, and for me writing that correctly is the minimum expression of respect you can have.
Just try to collect them in one single unit as you did in this one.
","1","2014-06-16T11:18:59Z"
"246075","14925","46167425","1928523","akshay-vishnoi","Hey okay, Sorry i misunderstood your last message. Okay Thanks for the support. I will try to cover them in single PR. :smile:
Also @sgrif 's concern is valid. So is there a way out for this?","1","2014-06-16T11:29:53Z"
"246076","14926","46085829","1529387","sgrif","It was correct before. ","1","2014-06-14T11:51:44Z"
"246077","14926","46086043","1928523","akshay-vishnoi","@sgrif - Hey I think Its correct. Its mentioned in the Rails guides. Please visit the [link](http://guides.rubyonrails.org/api_documentation_guidelines.html#wording)","1","2014-06-14T12:02:38Z"
"246078","14926","46115442","1928523","akshay-vishnoi","@sgrif : Did I mention the wrong link? I was expecting atleast a reply if I am wrong. This is not cool. :disappointed:.","1","2014-06-15T13:13:47Z"
"246079","14926","46142188","1928523","akshay-vishnoi","Thanks :green_heart:
Hey could you also look at #15722 ","1","2014-06-16T05:28:40Z"
"246080","14927","46087997","1080678","eileencodes","@akshay-vishnoi I meant to comment on the PR. Commented on the wrong open tab.","1","2014-06-14T13:30:31Z"
"246081","14927","46088044","1928523","akshay-vishnoi","@eileencodes - no problem, I have updated changes. You can review them. Thanks","1","2014-06-14T13:33:07Z"
"246082","14927","46088414","1928523","akshay-vishnoi","@eileencodes - Updated.. Please check again.","1","2014-06-14T13:49:14Z"
"246083","14929","46612616","47848","rafaelfranca","Hmm, maybe this will make the upgrade path more painful. WDYT about keeping the default [:datetime] and generating [:datatime, :time] for new applications?","1","2014-06-19T20:30:41Z"
"246084","14929","46627031","1529387","sgrif","I have no strong feelings, I'll make the change.","1","2014-06-19T22:50:50Z"
"246085","14929","46634614","1034","matthewd","If we feel that [:datetime, :time] should be the default going forward, perhaps we should output a deprecation warning if it's not explicitly configured one way or the other? (While still defaulting to the backward-compatible [:datetime] setting, for now.)","1","2014-06-20T00:52:04Z"
"246086","14929","46637649","1529387","sgrif","I have no strong feelings on what the default should be.
On Jun 19, 2014 6:52 PM, ""Matthew Draper"" <notifications@github.com> wrote:
> If we feel that [:datetime, :time] should be the default going forward,
> perhaps we should output a deprecation warning if it's not explicitly
> configured one way or the other? (While still defaulting to the
> backward-compatible [:datetime] setting, for now.)
>
> —
> Reply to this email directly or view it on GitHub
> <https://github.com/rails/rails/pull/15726#issuecomment-46634614>.
>","1","2014-06-20T01:53:22Z"
"246087","14929","47208045","47848","rafaelfranca","@matthewd's plan is good to me.","1","2014-06-26T09:59:57Z"
"246088","14929","47228030","1529387","sgrif","I've changed the default back to `[:datetime]`, and emitted a deprecation warning. I opted to go slightly more conservatively than suggested, since `:time` columns are not terribly commonly used, and I'd rather not have every user get a deprecation warning. The way I went about implementing is slightly hacky, so I'd appreciate another review.","1","2014-06-26T13:53:59Z"
"246089","14930","46197052","833383","arthurnn",":+1: :ship: ","1","2014-06-16T15:56:10Z"
"246090","14930","46372208","1034","matthewd","Thanks! :+1:","1","2014-06-17T22:08:24Z"
"246091","14931","46196912","833383","arthurnn","LGTM :+1: ","1","2014-06-16T15:55:01Z"
"246092","14933","46219245","5402","senny","@aditya-kapoor I think it would be better to document this in the API than in the guide. The guide do not need to cover every possible case. It's enough if they give you a sense of what's possible. The details should be in the API docs.","1","2014-06-16T18:55:37Z"
"246093","14933","46219725","1955930","aditya-kapoor","I agree to this but it would be beneficial to add this case though..Many people start with the guides first and then move on to API. I think this case best suits here than in API doc. ","1","2014-06-16T18:59:12Z"
"246094","14933","46222327","277819","zzak","@senny :+1: We should cover this in the API docs if it's not already covered by the `count` method.
Also, this was already removed manually from 53c26fc which was originally proposed in #15459
Please do your homework before submitting patches, thanks!","1","2014-06-16T19:19:35Z"
"246095","14933","46222794","1955930","aditya-kapoor","OK..@zzak adding them in the API docs...:+1:..Apologies for ignoring this...","1","2014-06-16T19:23:18Z"
"246096","14935","46097145","1034","matthewd","@rafaelfranca thoughts?
This is tricky... I'd kinda like to have a balance of the two forms, because it's perfectly reasonable to have a video living in `public/videos` instead of `app/assets/videos`, say.
Perhaps we should leave the current examples using `/videos` and friends, but for several (most?) of these helpers, also include an additional example that actually describes its context (""with `trailer.ogg` in `app/assets/videos`:"")?
Then again, with the default configuration (even in development, in master), `/assets/trailer.ogg` is a lie no matter what: the real path would be `/assets/trailer-123assetdigest789.ogg`.","1","2014-06-14T19:22:55Z"
"246097","14935","46126117","47848","rafaelfranca","I'd keep this as it is now. I agree videos are more reasonable to be in `public/videos`. Same with audio.
Images, javascript and stylesheets are more common to be inside `app/assets` so I would change them.","1","2014-06-15T20:02:55Z"
"246098","14935","46205218","1930730","kuldeepaggarwal","@rafaelfranca so should I close this PR or revert the changes for audio, video and fonts... But I think font should be in assets folder..","1","2014-06-16T17:02:10Z"
"246099","14935","46206367","47848","rafaelfranca","fonts doesn't need to be precompiled, I usually keep them out the pipeline, so I'd not include in the assets folder.","1","2014-06-16T17:11:09Z"
"246100","14935","46206711","1930730","kuldeepaggarwal","@rafaelfranca But have added fonts in asset precompile list in my production app and its going great. So i think we should place fonts in assets folder. Rest is team member decision.","1","2014-06-16T17:14:17Z"
"246101","14935","46207196","47848","rafaelfranca","Yes, it would fine if you put there but I believe our decision is to keep out the assets folder. At least for documentation propose.","1","2014-06-16T17:18:00Z"
"246102","14935","46208257","1930730","kuldeepaggarwal","okay will update the PR","1","2014-06-16T17:27:10Z"
"246103","14935","46209499","1930730","kuldeepaggarwal","@rafaelfranca done...","1","2014-06-16T17:37:42Z"
"246104","14935","46878560","1930730","kuldeepaggarwal","Thank you so much for merging... :green_heart:","1","2014-06-23T17:51:44Z"
"246105","16028","57894996","3124","tenderlove","?????❤????!
--
Aaron Patterson
http://tenderlovemaking.com/
I'm on an iPhone so I apologize for top posting.
> On Oct 4, 2014, at 1:25 AM, Jeremy Kemper <notifications@github.com> wrote:
>
> This is driven by @fxn's work on StringPool to deduplicate commonly used strings: https://github.com/rails/rails/compare/fxn/string-pools
>
> The cases covered here are a partial treatment, guided by object allocation profiling to reveal hotspots in common Basecamp actions.
>
> When in doubt, don't. This technique is ugly. Profile first and justify.
> Keep string constants close to their usage. No long lists of random strings. Keep it crystal clear what relies on the strings and why.
> Only share toplevel string constants for very commonly reused strings, like the empty string, underscore, spaces, etc.
> Don't reference toplevel string constants between libraries. Reference constants within the same library. Duplicated constants are OK.
> Work in progress:
>
> Merge @fxn's work: https://github.com/rails/rails/compare/fxn/string-pools
> Merge @tenderlove's work: https://github.com/rails/rails/pull/12879/files
> Eliminate constants that are used as string keys in Hash literals, which are automatically deduped in Ruby 2.1
> Eliminate constants that are used as string keys in Hash lookup and assignment, which are automatically deduped in Ruby 2.2
> You can merge this Pull Request by running
>
> git pull https://github.com/jeremy/rails slimfast/reuse-constant-strings
> Or view, comment on, or merge it at:
>
> https://github.com/rails/rails/pull/17173
>
> Commit Summary
>
> Reference string constants rather than repeatedly allocating the same string.
> File Changes
>
> M actionpack/lib/action_dispatch/http/cache.rb (23)
> M actionpack/lib/action_dispatch/http/filter_redirect.rb (12)
> M actionpack/lib/action_dispatch/http/headers.rb (9)
> M actionpack/lib/action_dispatch/http/mime_negotiation.rb (27)
> M actionpack/lib/action_dispatch/http/mime_type.rb (13)
> M actionpack/lib/action_dispatch/http/parameter_filter.rb (1)
> M actionpack/lib/action_dispatch/http/parameters.rb (14)
> M actionpack/lib/action_dispatch/http/request.rb (8)
> M actionpack/lib/action_dispatch/http/response.rb (15)
> M actionpack/lib/action_dispatch/http/url.rb (56)
> A actionpack/lib/action_dispatch/internal/constants.rb (31)
> M actionpack/lib/action_dispatch/journey/nodes/node.rb (28)
> M actionpack/lib/action_dispatch/routing/polymorphic_routes.rb (3)
> M actionpack/lib/action_dispatch/routing/route_set.rb (4)
> M actionview/lib/action_view/helpers/tag_helper.rb (20)
> M actionview/lib/action_view/helpers/tags/base.rb (83)
> M actionview/lib/action_view/log_subscriber.rb (21)
> M activerecord/lib/active_record/connection_adapters/abstract/query_cache.rb (12)
> M activerecord/lib/active_record/connection_adapters/abstract_adapter.rb (7)
> M activerecord/lib/active_record/relation/merger.rb (4)
> M activerecord/lib/active_record/relation/predicate_builder.rb (16)
> M activesupport/lib/active_support/cache.rb (14)
> M activesupport/lib/active_support/core_ext/object/acts_like.rb (6)
> M activesupport/lib/active_support/core_ext/string/filters.rb (18)
> M activesupport/lib/active_support/inflector/methods.rb (24)
> M activesupport/lib/active_support/number_helper/number_converter.rb (7)
> M activesupport/lib/active_support/string_inquirer.rb (10)
> M activesupport/lib/active_support/subscriber.rb (2)
> Patch Links:
>
> https://github.com/rails/rails/pull/17173.patch
> https://github.com/rails/rails/pull/17173.diff
> —
> Reply to this email directly or view it on GitHub.","1","2014-10-04T05:09:59Z"
"246106","16028","57895426","277819","zzak","You could say this pull request is... frozen. :snowflake:
","1","2014-10-04T05:34:35Z"
"246107","16028","57895560","567626","vipulnsward","Any preliminary result's for perf/ memory improvements?","1","2014-10-04T05:42:59Z"
"246108","16028","57895757","14005","fedesoria",":+1: ","1","2014-10-04T05:54:19Z"
"246109","16028","57896229","3387","fxn",":heart: :heart: :heart: :heart: :heart: ","1","2014-10-04T06:23:52Z"
"246110","16028","58315332","5518","huacnlee","So many 'str'.freeze, maybe this can be a new syntax in next Ruby version, like this:
```ruby
# from ''.freeze to:
$""str""
$'str'
{str}
<str>
:str:
```","1","2014-10-08T06:18:59Z"
"246111","16028","58985878","1659391","lidonghua","@huacnlee Do you mean this one? `""str""f`
http://tmm1.net/ruby21-fstrings/
I'd once seen it in ko1's slide.","1","2014-10-14T03:30:58Z"
"246112","16028","159057787","1529387","sgrif","Seems like this PR is no longer valid for 5.0, since we're only support 2.2 and later. I believe most of these have already been changed to frozen string literals on master. ","1","2015-11-23T20:39:39Z"
"246113","16030","57899906","290596","eval","@aantix nice! I had this itch too and wrote https://github.com/eval/envied#envied-","1","2014-10-04T09:42:27Z"
"246114","16030","59389019","4600","aantix","@schneems Finding a way to ensure that third party environment variables are set before deployment has caused us issues in the past with Heroku. Any comments on this PR?","1","2014-10-16T16:22:47Z"
"246115","16030","59390872","2394703","seuros","I think it should raise after checking all variables
```
Must define the environment variable(s) API_KEY, GITHUB_SECRET, TWITTER_SECRET
```","1","2014-10-16T16:34:55Z"
"246116","16030","59395847","4600","aantix","@seuros Agree. I made the appropriate changes.","1","2014-10-16T17:08:16Z"
"246117","16030","59398360","4600","aantix","Made the suggested changes.","1","2014-10-16T17:26:45Z"
"246118","16030","59401650","59744","schneems","Generally I use `ENV.fetch(""FOO"")` when I really want an environment variable to be present. What I really like about this approach is that I might get one error that `AWS_SECRET` isn't set, and then the next time I try to boot, i'll get a different error. In this PR all the critical vars are listed up front which is a really good experience.","1","2014-10-16T17:50:05Z"
"246119","16030","59422472","2394703","seuros","I think this need a Changelog entry.
","1","2014-10-16T20:10:57Z"
"246120","16030","59428551","4600","aantix","Added Changelog entry.","1","2014-10-16T20:52:38Z"
"246121","16030","59460794","1529387","sgrif","I agree that this is redundant with Ruby. Use `#fetch` for required env variables.","1","2014-10-17T03:06:25Z"
"246122","16030","59460829","1529387","sgrif","That said this certainly gives a nicer error message.","1","2014-10-17T03:06:58Z"
"246123","16030","59523592","4600","aantix","@sgrif The fetch is effective but the issue is that the missing env only triggers the exception when fetched. For lazy initializations, the critical path may not be hit until much after system startup. This is an effort to formally declare these envs up front and fail (if missing) quickly.","1","2014-10-17T14:47:39Z"
"246124","16030","62869465","22904","andyjeffries","I agree with @aantix, having this fail early is much better than only triggering it on some edge case/rare path in your app. I like the patch/idea.","1","2014-11-13T10:17:03Z"
"246125","16030","70813976","2394703","seuros","@aantix , could you rebase ?","1","2015-01-21T10:19:29Z"
"246126","16030","70859659","4600","aantix","Rebased.","1","2015-01-21T15:40:54Z"
"246127","16030","71140300","2741","dhh","Not a fan of promoting free-floating ENVs like this. My recommendation would be to let this flow through config/secrets.yml like so:
```yml
development:
secret_key_base: x
stuff: <%= ENV.fetch 'stuff' %>
```
That achieves the same thing, and it bundles all your secrets together to be accessed via Rails.application.secrets.","1","2015-01-23T02:56:23Z"
"246128","16030","71140434","2741","dhh","We could even explain this pattern in config/secrets.yml as a comment at the top.","1","2015-01-23T02:58:08Z"
"246129","16030","71161479","22904","andyjeffries","The only problem with the much simpler mechanism of putting it in secrets.yml is that it doesn't enforce the presence of those settings. That's what this ticket is about, catching deployments to new environments/systems where you haven't configured the environment properly. So if the comment looked more like the one below I'd be in favour:
```
development:
secret_key_base: x
# To use ENVironment variables, add code like this:
# your_value: <%= ENV.fetch 'YOUR_VALUE' rescue KeyError raise ActiveSupport::MissingEnvVariable.new(""YOUR_VALUE"") %>
```
But this then borders on just educating people on a good way of doing it (which could be done in a blog post/Rails docs) rather than having the Framework help people do something that is a common pattern.
(edited: I forgot fetch raises an error, but I'd still prefer this to be a specific non-obvious error rather than just KeyError)","1","2015-01-23T08:25:54Z"
"246130","16030","71234881","2741","dhh","Fetch raises automatically and secrets.yml is evaluated at boot. So if you ENV.fetch something that isn't there, it's not going to boot. Education for this usage can go at the top of secrets.yml.
> On Jan 23, 2015, at 03:26, Andy Jeffries <notifications@github.com> wrote:
>
> The only problem with the much simpler mechanism of putting it in secrets.yml is that it doesn't enforce the presence of those settings. That's what this ticket is about, catching deployments to new environments/systems where you haven't configured the environment properly. So if the comment looked more like the one below I'd be in favour:
>
> development:
> secret_key_base: x
> # To use ENVironment variables, add code like this:
> # your_value: <%= ENV.fetch 'YOUR_VALUE' || raise ActiveSupport::MissingEnvVariable.new(""YOUR_VALUE"") %>
> But this then borders on just educating people on a good way of doing it (which could be done in a blog post/Rails docs) rather than having the Framework help people do something that is a common pattern.
>
> —
> Reply to this email directly or view it on GitHub.
> ","1","2015-01-23T17:59:08Z"
"246131","16030","71250770","4600","aantix","The secrets.yml approach feels a bit strange just because you're specifying the key name twice (once for the secrets.yml entry and once for the ENV fetch).
My hunch is that developer would keep the secret key name consistent with the ENV var name. What about an (optional) array in the secrets.yml that will automatically map the corresponding ENV value to a secret entry?
E.g.
```yaml
required_env_vars:
- TWITTER_API_KEY
- ROLLBAR_API_KEY
```
Using the logic in the original PR, the above required_env_vars would be checked for their existence upon startup. It's one nice consolidated list of external ENVs.
The developer would then access the keys via the conventional
```ruby
Rails.application.secrets[:twitter_api_key]
```","1","2015-01-23T19:31:20Z"
"246132","16030","71260222","2741","dhh","The repetition really doesn't bother me because you are pulling something in from the outside world. To me, that's similar to person.name = params[:person][:name] or whatever.
Further more, this is not an area that needs excessive comfort. You're not going to have neither dozens of ENVs nor adding/removing them constantly.
> On Jan 23, 2015, at 14:32, Jim Jones <notifications@github.com> wrote:
>
> The secrets.yml approach feels a bit strange just because you're specifying the key name twice (once for the secrets.yml entry and once for the ENV fetch).
>
> My hunch is that developer would keep the secret key name consistent with the ENV var name. What about an (optional) array in the secrets.yml that will automatically map the corresponding ENV value to a secret entry?
>
> E.g.
>
> required_env_vars:
> - TWITTER_API_KEY
> - ROLLBAR_API_KEY
> Using the logic in the original PR, the above required_env_vars would be checked for their existence upon startup. It's one nice consolidated list of external ENVs.
>
> The developer would then access the keys via the conventional
>
> Rails.application.secrets[:twitter_api_key]
> —
> Reply to this email directly or view it on GitHub.
> ","1","2015-01-23T20:29:37Z"
"246133","16030","85163310","6321","pixeltrix","Turns out that you can't use `fetch` in `secrets.yml` as it would blow up in development when `secrets.yml` is loaded. Also `secrets.yml` is lazily loaded so it may appear as though the app has booted after a `cap deploy`.
Probably the simplest way to achieve the desired effect is to add something like the following to `config/environment.rb`:
``` ruby
# Load the Rails application.
require File.expand_path('../application', __FILE__)
if Rails.env.production?
%w[SECRET_KEY_BASE API_KEY].each do |var|
raise RuntimeError, ""Missing environment variable: #{var}"" unless ENV.key?(var)
end
end
# Initialize the Rails application.
Rails.application.initialize!
```
Some people would argue that it's duplicating the list of vars since they'd be defined in a .env file but that's somewhat application dependent - not everyone uses .env files.","1","2015-03-23T19:40:47Z"
"246134","16032","57906002","1930730","kuldeepaggarwal","@eileencodes :+1: ","1","2014-10-04T13:43:25Z"
"246135","16032","57907592","1080678","eileencodes","I'll reopen this during rails 5. ","1","2014-10-04T14:44:40Z"
"246136","16032","58222176","47848","rafaelfranca","I have a branch removing this support and also removing the use of instance on these classes. https://github.com/rails/rails/tree/remove-deprecated-finders-support
It is ready since the day I had to put the support back :smile:","1","2014-10-07T17:18:34Z"
"246137","16032","58226031","1080678","eileencodes",":+1: no worries, sorry to clutter the issue tracker, I'll delete the branch","1","2014-10-07T17:39:50Z"
"246138","16033","57907186","47848","rafaelfranca","Unless I'm missing something Rails 5 didn't started to be developed. Opening pull request now will only give us more troubles than helping. ","1","2014-10-04T14:29:57Z"
"246139","16033","57907588","1080678","eileencodes","Sorry @rafaelfranca that's my fault. I opened a deprecated finders PR because Aaron had asked me to work on removing them from association builder. I might have done it preemptively. It looks like @kuldeepaggarwal saw that and started working on other ones. Sorry for causing an inconvenience :smile: ","1","2014-10-04T14:44:24Z"
"246140","16033","57907717","1930730","kuldeepaggarwal","@rafaelfranca Sorry for creating trouble on issue tracker. I will create PR once Rails 5 gets started to be developed.
@eileencodes Thank you for presenting my point of view. :smile: ","1","2014-10-04T14:48:57Z"
"246141","16034","57922272","277819","zzak","@eileencodes Excellent detective work! :shipit: ","1","2014-10-05T00:02:16Z"
"246142","16035","57916825","1034","matthewd","I'm not sure how I feel about this implementation.
On one hand, it seems silly to be doing i18n lookups for st/nd/rd/th, when English is the only language that uses that particular pattern.
On the other, maybe this is a logical extension of our current ""you can sorta kinda localize to something that works sufficiently like English"" inflection policy.
So, as discussed, I'm tentatively :+1: to the *idea* of supporting locale on these methods, given that we do for others... but this seems an awkward solution for [other actual languages](http://www.unicode.org/cldr/charts/latest/supplemental/language_plural_rules.html#Ordinal-Integer).","1","2014-10-04T20:03:04Z"
"246143","16035","57926864","242532","egilburg","Some languages may have ordinal suffix but not varying one, or perhaps not even a suffix.
I think a more robust solution would pass the integer to the i18n string as a value, as in:
In Ruby:
```ruby
i18n_params = { scope: 'number.ordinals.nth', number: number }
I18n.translate(modulo, i18n_params, default: I18n.t('default', i18n_params))
```
In `.yml` file:
```yml
ordinals:
nth:
1: ""%{number}st""
2: ""%{number}nd""
3: ""%{number}rd""
4: ""%{number}th""
default: ""%{number}th""
```
This way, other languages can have fine-tune control over implementation, or just have a general default if needed.
Of course it gets more complex in real life (e.g. some languages have varying ordinal suffixes based on singular/plural, or masculine/feminine noun), but starting somewhere is a good step.","1","2014-10-05T05:04:49Z"
"246144","16035","57976417","1930730","kuldeepaggarwal","@egilburg I like the idea :+1: . But I think we should wait for more views.","1","2014-10-06T05:38:26Z"
"246145","16036","57918451","1930730","kuldeepaggarwal","`0` in ruby is true, and `nil` is false. So the previous implementation was correct. In ruby, predicate methods should return truthy values. So, I am :-1: for this change.","1","2014-10-04T21:05:18Z"
"246146","16036","57918726","3486276","arantir","Great, found bug in my project though.
Thank for the tip about conversion. Never stop learning =)
Sorry to trouble.","1","2014-10-04T21:15:52Z"
"246147","16037","57933536","77592","vais","When the problem of `String#strip` not working with unicode gets fixed in ruby as documented in [this thread](https://www.ruby-forum.com/topic/4410833), the regular expression to handle unicode whitespace can be removed, so `String#blank?` can go back to [DHH's original implementation](https://github.com/rails/rails/blob/df95567598677a9c109146df8531674e70c2eb80/activesupport/lib/active_support/core_ext/blank.rb#L28:L32):
```ruby
class String
def blank?
empty? || strip.empty?
end
end
```
","1","2014-10-05T11:41:34Z"
"246148","16037","57954891","5213","SamSaffron","I am not sure if ascii_only is enough of a check ...
see last test here https://github.com/SamSaffron/fast_blank/blob/master/spec/fast_blank_spec.rb#L44-L49","1","2014-10-05T22:27:06Z"
"246149","16037","57954914","5213","SamSaffron","note, fast blank totally removes the perf issue, so simplest thing is just to push the change in MRI forward and depend on fast blank for now. ","1","2014-10-05T22:27:54Z"
"246150","16037","57956610","77592","vais","@SamSaffron Re: https://github.com/SamSaffron/fast_blank/blob/master/spec/fast_blank_spec.rb#L44-L49
```
sushi:~ vais$ pry
[1] pry(main)> ""\u0000"".ascii_only?
=> true
[2] pry(main)> ""\u0000"".empty?
=> false
[3] pry(main)> ""\u0000"".strip.empty?
=> true
[4] pry(main)> `ruby -v`
=> ""ruby 2.0.0p247 (2013-06-27 revision 41674) [x86_64-darwin12.4.0]\n""
[5] pry(main)>
```
So, if `""\u0000"".strip.empty? => true` then what am I missing? I.e. how is `ascii_only?` not enough of a check?","1","2014-10-05T23:30:07Z"
"246151","16037","57957774","5213","SamSaffron","ahh so you are using strip ... that is a bit of a problem, it creates a
duplicate string.
On Mon, Oct 6, 2014 at 10:30 AM, Vais Salikhov <notifications@github.com>
wrote:
> @SamSaffron <https://github.com/SamSaffron> Re:
> https://github.com/SamSaffron/fast_blank/blob/master/spec/fast_blank_spec.rb#L44-L49
>
> sushi:~ vais$ pry
> [1] pry(main)> ""\u0000"".ascii_only?
> => true
> [2] pry(main)> ""\u0000"".empty?
> => false
> [3] pry(main)> ""\u0000"".strip.empty?
> => true
> [4] pry(main)> `ruby -v`
> => ""ruby 2.0.0p247 (2013-06-27 revision 41674) [x86_64-darwin12.4.0]\n""
> [5] pry(main)>
>
> So, if ""\u0000"".strip.empty? => true then what am I missing? I.e. how is
> ascii_only? not enough of a check?
>
> —
> Reply to this email directly or view it on GitHub
> <https://github.com/rails/rails/pull/17182#issuecomment-57956610>.
>","1","2014-10-06T00:15:52Z"
"246152","16037","57962867","77592","vais","Yep, `empty? || strip.empty?`, so in the case of a non-empty string, `strip` will make an extra copy. Using `strip!` is obviously out of the question. But the bottom line is even this case is still around 140% faster than using a regular expression. How would one even begin to assess if the extra GC pressure is worth the speed increase?
Anyway, I am here to learn, so thank you @SamSaffron for taking the time to comment!","1","2014-10-06T01:50:43Z"
"246153","16037","57968558","77592","vais","Ok, I see - because `strip` copies the string, performance on long strings is atrocious:
```
LONG_STRING = ""s"" * (64 * 1024)
...
improved: 9393.5 i/s - 79.44x slower
...
```
In fact, on my machine 11 bytes is the magic break-even point. Any string longer than that, and the regular expression wins the race.
```ruby
require 'benchmark/ips'
require 'active_support/all'
LONG_STRING = ""s"" * (64 * 1024)
class String
def improved_blank?
return empty? || strip.empty? if ascii_only?
BLANK_RE === self
end
end
Benchmark.ips do |x|
x.report('original') { LONG_STRING.blank? }
x.report('improved') { LONG_STRING.improved_blank? }
x.compare!
end
```
```
Calculating -------------------------------------
original 30214 i/100ms
improved 880 i/100ms
-------------------------------------------------
original 746205.5 (±19.8%) i/s - 3625680 in 5.026125s
improved 9393.5 (±5.1%) i/s - 47520 in 5.072520s
Comparison:
original: 746205.5 i/s
improved: 9393.5 i/s - 79.44x slower
```
So, the code would have to be something like this:
```ruby
MAGIC_NUMBER = 12
def blank?
return empty? || strip.empty? if ascii_only? && self.length < MAGIC_NUMBER
BLANK_RE === self
end
```
But what the magic number is probably depends on the machine. Seems like the whole thing is hardly worth it at this point.
","1","2014-10-06T02:58:10Z"
"246154","16037","57971509","77592","vais","Wow, could it actually be this thing: http://patshaughnessy.net/2012/1/4/never-create-ruby-strings-longer-than-23-characters
> The third and last way that MRI Ruby 1.9 saves string data is by embedding the characters into the RString structure itself
> ...
> How do Embedded Strings work? Well, the key is the size of the ary array, which is set to RSTRING_EMBED_LEN_MAX+1. If you’re running a 64-bit version of Ruby RSTRING_EMBED_LEN_MAX is set to 24. That means a short string like this will fit into the RString array
> ...
> On a 64 bit machine, sizeof(VALUE) is 8, leading to the limit of 23 characters. This will be smaller for a 32 bit machine
My `MAGIC_NUMBER = 12` comes from running the benchmark on a 32-bit Windows machine.","1","2014-10-06T03:19:53Z"
"246155","16037","58123486","5213","SamSaffron","Given all this huge complexity, I think a much better approach is just to use the fast_blank gem if you want fast blank on MRI and push for a change in MRI that corrects empty.
Lack of parity between blank and empty for strings is really bad, it serves zero purpose. ","1","2014-10-07T01:07:53Z"
"246156","16037","58208324","77592","vais","This was a fun experiment, but yeah, I agree, it's best to leave `String#blank?` alone.","1","2014-10-07T15:58:30Z"
"246157","16038","57935300","2394703","seuros","Thank you","1","2014-10-05T13:01:52Z"
"246158","16038","57970191","621238","prathamesh-sonpatki","Thank you!","1","2014-10-06T03:10:03Z"
"246159","16039","58196864","43970","fillman","Hey @josevalim, I see the last commit belongs to you, so maybe you can comment on this? Would appreciate some feedback.","1","2014-10-07T14:51:47Z"
"246160","16040","57957931","2103728","brocktimus","I've done more digging and its more subtle than just ""duplicated column"". It seems to be caused when there are multiple references to a single object in the bind_values array on Postgres.
I can only reproduce issue by scopes which reference themselves implicitly (like leaves test). That one can be fixed by unscoped, unsure if all cases can. This works on all other DBs, just not Postgres.
This snippet is taken from a simple test case I have outside fo the AR test suite. Also explains why I'm having a hard time replicating it reliably.
Output from Postgres which failed
```
[8] pry(#<Comment::ActiveRecord_AssociationRelation>)> bvs
=> [[#<ActiveRecord::ConnectionAdapters::PostgreSQLColumn:0x007fefd5b389a0
@array=false,
@cast_type=#<ActiveRecord::ConnectionAdapters::PostgreSQL::OID::Integer:0x007fefd5b38ab8 @limit=nil, @precision=nil, @scale=nil>,
@default=nil,
@default_function=nil,
@name=""article_id"",
@null=true,
@sql_type=""integer"">,
1],
[#<ActiveRecord::ConnectionAdapters::PostgreSQLColumn:0x007fefd5b389a0
@array=false,
@cast_type=#<ActiveRecord::ConnectionAdapters::PostgreSQL::OID::Integer:0x007fefd5b38ab8 @limit=nil, @precision=nil, @scale=nil>,
@default=nil,
@default_function=nil,
@name=""article_id"",
@null=true,
@sql_type=""integer"">,
1]]
[9] pry(#<Comment::ActiveRecord_AssociationRelation>)> bvs.first.object_id
=> 70334031546780
[10] pry(#<Comment::ActiveRecord_AssociationRelation>)> bvs.last.object_id
=> 70334031546780
```
Output from sqlite3 which passed.
```
[1] pry(#<Comment::ActiveRecord_AssociationRelation>)> bvs
=> [[#<ActiveRecord::ConnectionAdapters::Column:0x007fa8933c5170
@cast_type=#<ActiveRecord::Type::Integer:0x007fa8933c4388 @limit=nil, @precision=nil, @scale=nil>,
@default=nil,
@default_function=nil,
@name=""article_id"",
@null=true,
@sql_type=""integer"">,
1],
[#<ActiveRecord::ConnectionAdapters::Column:0x007fa8933c5170
@cast_type=#<ActiveRecord::Type::Integer:0x007fa8933c4388 @limit=nil, @precision=nil, @scale=nil>,
@default=nil,
@default_function=nil,
@name=""article_id"",
@null=true,
@sql_type=""integer"">,
1]]
[2] pry(#<Comment::ActiveRecord_AssociationRelation>)> bvs.first.object_id
=> 70180993730220
[3] pry(#<Comment::ActiveRecord_AssociationRelation>)> bvs.last.object_id
=> 70180993730220
```
I suspecting if we can prevent it being duplicated in the bind_values array, then the problem goes away. Unsure if there would be any unintended consequences there. I'll dive down rabbit hole more later, any help appreciated :-).","1","2014-10-06T00:21:25Z"
"246161","16040","58036044","2103728","brocktimus","Correction, its the duplicated ```Arel::Nodes::BindParam``` (or subclass) within the ast. Then replace is being called on the same object twice, overwriting previous substitution.
So current thinking is creating a new instance in the PredicateBuilder::Relation would be correct. However experiments seem to indicate this is problematic since the ""pointing to same object twice"" probleme exists all the way up the tree. So we just end up mutating both each time and they're still as duplicated as always.
Other options would be the removal of the duplicated bind value without breaking a whole bunch of things. Could be problematic because that sounds like it would break the binds and numeric indexing.","1","2014-10-06T15:37:29Z"
"246162","16040","58193338","2103728","brocktimus","OK I think this one is beyond me :confused:. Still happy to continue + do the leg work if anyone can point me in a direction. But tweaking bind params within the scope of ```#build_arel``` doesn't seem to be able to fix it.","1","2014-10-07T14:31:13Z"
"246163","16040","73809350","2103728","brocktimus","Fixed in ac1fbc1. Going to do less messy new PR for old test that would have failed.","1","2015-02-10T23:47:58Z"
"246164","16040","73809558","1529387","sgrif","I wouldn't worry about it for 4.1
On Tue, Feb 10, 2015, 4:48 PM brocktimus <notifications@github.com> wrote:
> Fixed in ac1fbc1
> <https://github.com/rails/rails/commit/ac1fbc1734a86d000a9da2b016b523c11a3c7781>.
> Going to do less messy new PR for old test that would have failed.
>
> —
> Reply to this email directly or view it on GitHub
> <https://github.com/rails/rails/pull/17185#issuecomment-73809350>.
>
","1","2015-02-10T23:49:44Z"
"246165","16040","73810048","2103728","brocktimus","Yeah I didn't care so much about it, was more wondering if there was a test covering it now on master?","1","2015-02-10T23:53:34Z"
"246166","16040","73810296","1529387","sgrif","The code is different enough on master that this edge case wouldn't make
sense. Its tested on arel
On Tue, Feb 10, 2015, 4:54 PM brocktimus <notifications@github.com> wrote:
> Yeah I didn't care so much about it, was more wondering if there was a
> test covering it now on master?
>
> —
> Reply to this email directly or view it on GitHub
> <https://github.com/rails/rails/pull/17185#issuecomment-73810048>.
>
","1","2015-02-10T23:55:53Z"
"246167","16040","73810557","2103728","brocktimus","Yay, thanks for all the hard work you've been doing on AR :heart:.","1","2015-02-10T23:57:49Z"
"246168","16041","57983814","4335742","tgxworld","@matthewd Could you have a look at this? Thanks :smile: ","1","2014-10-06T07:46:34Z"
"246169","16041","58611499","4335742","tgxworld","For a bit more information, the code used to just take the last value from the array (https://github.com/rails/rails/pull/15683/files#diff-a1a584ca75e21b3e2a45b6a4e2d0e9cfL467). Now that this has changed, the token is always expected to be at the `1` index of the array. Therefore, we will just include `token=` early in the params.","1","2014-10-10T04:33:01Z"
"246170","16041","63852384","671800","apotema","Is there a rails 4.2.0.betaX with this fix ?","1","2014-11-20T18:09:01Z"
"246171","16041","63852619","47848","rafaelfranca","@apotema no, it was not merged yet.","1","2014-11-20T18:10:26Z"
"246172","16041","63852880","671800","apotema","Thanks @rafaelfranca ","1","2014-11-20T18:12:11Z"
"246173","16042","57999442","15688","thedarkone",":+1:
However thinking about it, for development, you could use something like this:
```ruby
class MiddlewareTester
def initialize(app, tested_middleware_const_name, require_path = nil)
@app = app
@tested_middleware_const_name = tested_middleware_const_name
@require_path = require_path
end
def call(env)
load(@require_path) if @require_path # might be brittle
tested_middleware_const_name.constantize.new(@app).call(env)
end
end
```","1","2014-10-06T10:31:17Z"
"246174","16042","58029150","25862","Bounga","Why does Travis build failed on a guide update?","1","2014-10-06T14:55:41Z"
"246175","16042","58211233","25862","Bounga","So it is not good enough to be included in the guide?","1","2014-10-07T16:16:53Z"
"246176","16042","58216933","2394703","seuros","Travis sometime timeout, please add [ci skip] in your commit message when sending doc.
Please squash your commit now. Look good to merge.","1","2014-10-07T16:49:38Z"
"246177","16042","58256439","2394703","seuros","@Bounga Please rebase/squash commits..","1","2014-10-07T20:33:29Z"
"246178","16042","58320815","25862","Bounga","@seuros Sorry about the rebase/squash lag. I was new to that so I had to dig about the good way to do it.
The guide (http://guides.rubyonrails.org/contributing_to_ruby_on_rails.html#contributing-to-the-rails-code) is missing a little tip about the command `git rebase -i` which is how to select the number of commits to rebase: `git rebase -i HEAD~4` for example.","1","2014-10-08T07:34:09Z"
"246179","16042","58321868","2394703","seuros","Thank you.","1","2014-10-08T07:45:39Z"
"246180","16043","58048378","277819","zzak","LGTM! (please remember `[ci skip]` in the commit message next time)
I will let @senny comment regarding `queue_adapters.rb`.
Thanks! <3","1","2014-10-06T16:50:58Z"
"246181","16043","58143814","5402","senny","@jipiboily Let's keep the note as is for the time being and update it as soon as we have a released version of queue_classic that does support it.
Thanks for the patch! :yellow_heart: ","1","2014-10-07T06:47:08Z"
"246182","16045","58119807","277819","zzak","I thought that @fxn fixed some of the link issues, but maybe these are unrelated.","1","2014-10-07T00:16:04Z"
"246183","16045","58129338","1034","matthewd","Yes, adjacent but unrelated. (Namely, he made http://api.rubyonrails.org/v4.2.0/classes/ActiveJob/QueueAdapters.html work.)
As we wouldn't want the released 4.2.0's README pointing at `edgeapi`, it would need to be changed to `api` shortly *before* release, not after it... and that's kinda where we are.
So I don't think this should change.","1","2014-10-07T02:44:42Z"
"246184","16045","58143962","5402","senny","The links in the documentation will become valid when a stable version is released. Until that point it might be the case that some links are not working as expected. We rather keep them that way than having to change em after the release.
Thank you.","1","2014-10-07T06:49:14Z"
"246185","16047","58197260","47848","rafaelfranca","Could you prepare some benchmarks?","1","2014-10-07T14:53:56Z"
"246186","16047","58198059","531650","larrylv","OK. I will provide the benchmark results later.","1","2014-10-07T14:58:32Z"
"246187","16047","58200776","531650","larrylv","``` ruby
require 'active_support'
require 'benchmark/ips'
require 'erb'
Benchmark.ips do |x|
TEST_STRING = ""this is a string"".freeze
x.report(""use-string-method"") {
class String
def html_safe?
false
end
end
ERB::Util.html_escape TEST_STRING
}
x.report(""use-object-method"") {
class Object
def html_safe?
false
end
end
ERB::Util.html_escape TEST_STRING
}
end
```
```
Calculating -------------------------------------
use-string-method 18803 i/100ms
use-object-method 16376 i/100ms
-------------------------------------------------
use-string-method 289081.9 (±8.4%) i/s - 1447831 in 5.052821s
use-object-method 259072.7 (±11.2%) i/s - 1277328 in 5.014466s
```
","1","2014-10-07T15:14:16Z"
"246188","16047","58201970","47848","rafaelfranca","I think the improvement is inside the standard deviation so both implementations may have the same performance.
@jeremy @matthewd WDYT?","1","2014-10-07T15:21:35Z"
"246189","16047","58204460","1034","matthewd","That benchmark isn't measuring what you think it is. Any way I look at this, I get exactly the result I expect: [no measurable difference](https://gist.github.com/matthewd/45ed912fe6443d73bb6f).
To me, this falls into the category of ""extraordinary claims require extraordinary evidence"", and I don't see any.","1","2014-10-07T15:36:17Z"
"246190","16047","58205086","531650","larrylv","Seems like this doesn't improve any performances. I'm just gonna close this one. Sorry.","1","2014-10-07T15:39:55Z"
"246191","16312","75088588","754770","mtparet",":+1: I have currently to monkey patch activerecord to correctly create table from the schema and with the rights options (We're verifying that we able to store utf8bm4 character like ? for example.","1","2015-02-19T16:47:41Z"
"246192","16312","98474750","12642","kamipo","@rafaelfranca Could you merge the changes?","1","2015-05-03T12:16:10Z"
"246193","16312","98611121","754770","mtparet",":+1: ","1","2015-05-04T07:39:50Z"
"246194","16314","62343915","160941","guilleiguaran","/cc @jeremy ","1","2014-11-10T05:43:39Z"
"246195","16314","62350188","55829","chancancode","Nice! If we make this more conservative, we can probably get away with sneaking this into 4.2:
1. Add a new configuration option called `generate_weak_etags` or something that defaults to `false` (similar to [this one](https://github.com/rails/rails/blob/89397d09ebb7ca4089f17820d05d5eb223913652/activerecord/lib/active_record/transactions.rb#L21-L22))
2. In `#etag=`, check the value of that option. If it's truthy, processed with generating a weak etag (similar to [here](https://github.com/rails/rails/blob/89397d09ebb7ca4089f17820d05d5eb223913652/activerecord/lib/active_record/transactions.rb#L238-L240))
3. Otherwise, generate a strong etag like we used to, but print a deprecation warning message saying that the defualt will flip in Rails 5 (similar to [this one](https://github.com/rails/rails/blob/89397d09ebb7ca4089f17820d05d5eb223913652/activerecord/lib/active_record/transactions.rb#L6-L14))
This seems like an overall improvement to the situation and a good halfway point. Ideally though, we should also figure out the final API we would like to achieve with this (though I'm not sure if something like that is still appropriate for 4.2 at this time)...
1. Weak etag is a good default for the 90% cases (it seems quite difficult, at least at the controller level, to determine if the response would meet the byte-level equivalence requirement... given all the things that goes on in a typical Rails stack)
2. That said, there are probably cases that you would like to explicitly make the etag a strong one, such as the `send_file` use case @jeremy brought up.
With the current API, I'm not sure what's the best way to achieve point 2, and I'd love to hear ideas :smile:","1","2014-11-10T07:33:54Z"
"246196","16314","62412728","242532","egilburg","""Sorry, Diff contents are not available for this pull request.""
First time I'm seeing this, why?","1","2014-11-10T16:41:34Z"
"246197","16314","62430534","47848","rafaelfranca","Good question. I'm seeing this too.","1","2014-11-10T18:31:23Z"
"246198","16314","62430843","55829","chancancode","Yeah, I have no idea, I had to pull the branch locally to check the diff","1","2014-11-10T18:33:17Z"
"246199","16314","62442016","160941","guilleiguaran","Same here, I checked the changes in https://github.com/rails/rails/pull/17573.diff","1","2014-11-10T19:43:27Z"
"246200","16314","62615822","138240","zerothabhishek","[Sorry about the late response.]
There was an error in the earlier code, hence the new commit.
---
I'm a bit of a noob here, but from what I've seen in the code, our current behavior resembles weak etags more. Even though the etags emitted look strong. I could not find any code that actually creates an etag based off the entire response body. Here's an example to illustrate -
In the classic blog post application, we can write the `PostsController#show` as follows to take advantage of etags -
def show
fresh_when(@post)
end
And then here's what we see from the browser -
Request | Response | Comment
----------- | -------------- | -----------
GET /posts/1 | 200 | first request, no cache
GET /posts/1 | 304 | subsequent request, no change to `@post`, uses cache
_Edit app/views/posts/show.html.erb_ | |
GET /posts/1 | 200 | `@post` view changed, cache invalid, regenerate
GET /posts/1 | 304 | cache as usual
_Edit app/view/layouts/application.html.erb_ | |
__GET /posts/1__ | __304__ | __view changed, still uses cache__
The same happens when using the `stale?` method and the controller wide `etag`. So it looks like etag generation and verification does not take the full response body into account. And If I am correct so far, we will need to introduce support for strong etags.
I too feel that strong etags are important for cases like `send_file`. The `send_file` doesn't use any etags as of now, and I'm tempted to have them added, but am not sure if its a good idea.
","1","2014-11-11T20:31:47Z"
"246201","16314","134542667","324213","fabn","I'm having a lot of cache misses because of this behavior. I'm using nginx as reverse proxy and when a page is requested with `Accept-Encoding: deflate, gzip` (i.e. always) it automatically changes the generated strong etag by adding the prefix `W/`. Then following requests sent by user with the same browser won't match rails default etag causing 200 instead of 304 even if the response is the same.
`Rack::ETag` [already](https://github.com/rack/rack/commit/12528d4567d8e6c1c7e9422fee6cd8b43c4389bf) do this and I think it's very important to have rails following this behavior for the reasons explained [here](https://github.com/rack/rack/issues/681#issue-32629619)
As a quick alternative the [etag_matches?](https://github.com/rails/rails/blob/a1ff5585bd537bf5005cca11442566abb7422311/actionpack/lib/action_dispatch/http/cache.rb#L30) method can be changed to strip any `W/` prefix before matching, but I don't know what side effects this can cause.
I'm going to try [rails_weak_etags](https://github.com/johnnaegle/rails_weak_etags) middleware to see if it solves my issues.","1","2015-08-25T09:56:55Z"
"246202","16314","141511898","909587","felixbuenemann","LGTM. What's missing to get this merged?
I don't think there needs to be a configuration options, because the way etags are calculated is already weak validation and Rack::ETag even weakens it's strong etags (a body digest is considered a strong validator based on RFC 7232 Section 2.1, while determining the etag from arbitrary data is considered a weak validator).
The current problem without this patch is that NGINX weakens strong ETags when it changes the content encoding (gzip). So right now `fresh_when` and `stale?` are useless on NGINX with gzip enabled.
Another approach would be to consider a weakened etag equivalent to the strong etag sent by action dispatch (but I think sending weak etags as proposed here is the correct approach):
```ruby
module ActionDispatch
module Http
module Cache
module Request
NORMALIZE_ETAG = /^(?:W\/)?\""|\""$/.freeze
def if_none_match_etags
(if_none_match ? if_none_match.split(/\s*,\s*/) : []).collect do |etag|
etag.gsub(NORMALIZE_ETAG, """")
end
end
def etag_matches?(etag)
if etag
etag = etag.gsub(NORMALIZE_ETAG, """")
if_none_match_etags.include?(etag)
end
end
end
end
end
end
```
I'm currently using the above code as a monkey patch with rails 4.2.4 to fix If-None-Match on NGINX 1.8.","1","2015-09-18T17:18:27Z"
"246203","16314","141642466","324213","fabn","I installed [rails_weak_etags](https://github.com/johnnaegle/rails_weak_etags) and everything work like a charm, no monkey patch needed, just a middleware.
In any case it would be very nice to have this merged (and backported to rails 4.x)","1","2015-09-19T09:54:18Z"
"246204","16314","158546341","48100","bboe","Is there any status update on this issue? The `rails_weak_etags` gem appears to solve the problem, but it seems like the current strong ETAG behavior is a bug in rails and should be fixed.","1","2015-11-20T22:42:37Z"
"246205","16314","162329440","833383","arthurnn","FWIW the last big rails projects I worked on, they all had a middleware to do something like this.
","1","2015-12-06T17:05:13Z"
"246206","16315","62412514","199","jeremy",":+1: to the concept. This is a great way to reduce the size of large indexes on ascii columns.","1","2014-11-10T16:40:27Z"
"246207","16316","62553513","47848","rafaelfranca","I don't think any association accept constant as `class_name`. Could you show examples where this is working?","1","2014-11-11T14:27:00Z"
"246208","16316","62554241","47848","rafaelfranca","All our code use string as `class_name` value and we should only accept string. Accepting constants may trigger the autoload of the class that may cause circular dependency in development.","1","2014-11-11T14:32:14Z"
"246209","16316","62559965","7878085","shikshachauhan","Please check this [link](https://github.com/rails/rails/blob/master/activerecord/lib/active_record/reflection.rb#L142), here we apply `to_s` to class name. So due to this, following code also works:
```
has_many :my_posts, class_name: Post
```
I have confirmed this on master.","1","2014-11-11T15:10:29Z"
"246210","16316","62566596","47848","rafaelfranca","Right. It was introduced at https://github.com/rails/rails/commit/e6cc2ea201857a5f3700f589336df2880564cfea but the original idea was only to accept symbols. I don't think we should accept constants, but we are doing right now. Even that it is supported I don't think we should advertise the usage. So could you please remove the test with constant and keep only the symbol case?","1","2014-11-11T15:51:19Z"
"246211","16316","62672900","7878085","shikshachauhan","Can you please explain how circular dependency will arise in Development Environment.
I have tried the following code.
```rb
# in post.rb
class Post < ActiveRecord::Base
belongs_to :user, class_name: User
end
# in user.rb
class User < ActiveRecord::Base
has_many :posts, class_name: Post
end
```
And No Circular dependency was caused.","1","2014-11-12T05:38:03Z"
"246212","16316","62728220","47848","rafaelfranca","I don't remember right now but I got this problem several times in applications. Either way, I really prefer to not support officially constants.
See https://github.com/rails/rails/issues/6486 and https://github.com/rails/rails/pull/8357","1","2014-11-12T14:45:36Z"
"246213","16316","62844900","7878085","shikshachauhan","I have updated the pull request.","1","2014-11-13T05:46:54Z"
"246214","16316","62846271","1955930","aditya-kapoor","this is the undesired side effect of the converting to `to_s` and I full agree with @rafaelfranca on not advertising the usage of constants as option values for any of the options in associations.","1","2014-11-13T06:08:03Z"
"246215","16317","62359670","5402","senny","/cc @sgrif
@rafaelfranca @matthewd do you see a reasonable deprecation strategy or how do we usually deal with changes that affect adapters outside of our control.","1","2014-11-10T09:27:05Z"
"246216","16317","62552679","47848","rafaelfranca","I can't think a good way of keep compatibility without keep accepting `types` arguments.","1","2014-11-11T14:21:12Z"
"246217","16317","62552989","5402","senny","@rafaelfranca yea... not only we would need to keep accepting it but also keep passing it. Probably something adapter maintainers have to update to get compatibility. Let's wait for `5.0` though.","1","2014-11-11T14:23:20Z"
"246218","16319","62422395","47848","rafaelfranca","Could you improve the commit message explaining the change?","1","2014-11-10T17:39:57Z"
"246219","16319","62444451","88676","aderyabin","@rafaelfranca done!","1","2014-11-10T19:57:43Z"
"246220","16320","1393331","2704","geoffgarside","looks like you're only validating IP addresses as IPv4, so remote_ip will return nil for IPv6 addresses.
You could use the IPAddr class, but it is quite slow to raise an ArgumentError for values which aren't IPv4 or IPv6 addresses.","1","2011-06-18T13:26:41Z"
"246221","16320","1393377","29658","gazay","In request.remote_ip all trusted_proxies are ipv4, and all tests checks only ipv4. I think this commit can be added as first step, as second can be adding support for ipv6","1","2011-06-18T13:42:37Z"
"246222","16320","1393467","2704","geoffgarside","Have to admit I don't know what the v6 trusted proxies would be. while the tests only play against v4 addresses I don't think there is anything in the code to explicitly prohibit a v6 address like the regex does. Its just something I'm thinking about at the moment as I'm supposed to be adding v6 to a staging server next week. Its also not one of those things you can easily test in development mode as pow and passenger currently only listen on v4.","1","2011-06-18T14:27:52Z"
"246223","16320","1544082","4912","sikachu","I've added a comment into the commit. Do you mind fixing that and squash your commits together? In that case we can safely use `git bisect` and not found out that we actually find the 'failing test case' commit to be a first bad commit. ;)","1","2011-07-11T02:54:25Z"
"246224","16320","1551925","29658","gazay","I had problems with my fork - i renew it and made new pull request - #2035. There is no mistakes and it is only one commit.","1","2011-07-12T04:20:50Z"
"246225","16321","62459149","242532","egilburg","If you want this to be public API, should add a spec for `Table#name`","1","2014-11-10T21:33:35Z"
"246226","16321","62462809","191320","ccutrer","@egilburg done","1","2014-11-10T21:56:41Z"
"246227","16321","62554352","5402","senny","@ccutrer thank you :yellow_heart: ","1","2014-11-11T14:32:55Z"
"246228","16322","62555670","47848","rafaelfranca","It is more a documentation problem. It is fine to work in table definition, but I think add_column should be a raw method that just add column to the table. Lets fix the documentation and raise if any option that is not acceptable is present.","1","2014-11-11T14:41:58Z"
"246229","16322","62703377","88676","aderyabin","@dhh What is your opinion?","1","2014-11-12T11:13:39Z"
"246230","16322","62704757","94767","dgmike",":eyes: I have the same issue, we see the problem after the project started.","1","2014-11-12T11:26:02Z"
"246231","16322","62868664","22904","andyjeffries","@rafaelfranca I agree with you, creating a table is a whole approach, add_column is very specifically just adding a column. I'd vote for fixing the documentation.","1","2014-11-13T10:10:29Z"
"246232","16322","63053348","2741","dhh","I'll go with the majority opinion here. If the syntax for add_column and add_table was otherwise similar, I'd say we should have parity. But they're not really, so that's not a trumping concern.","1","2014-11-14T12:07:07Z"
"246233","16324","62498261","160941","guilleiguaran","can't we move this code to another place (for example a Rakefile or a test_helper)?","1","2014-11-11T03:49:10Z"
"246234","16324","62498630","142914","bf4","@guilleiguaran (if you're asking me) I think a test helper would be good for the 'work around' commit. The 'tmpdir' one though is really a patch until it is fixed upstream. Is there a test helper shared by all action/active gems?
I could also split this into two issues, since they're not really related.
","1","2014-11-11T03:55:17Z"
"246235","16324","62506935","10135","headius","Please be sure to file JRuby issues for these problems, if they actually turn out to be JRuby's fault. I'm not sure the jira.codehaus.org bug you mentioned is actually relevant to either of these.
The first one seems to be a missing require in ar-jdbc's Rakefile, but we might want to investigate why it doesn't happen when we use rake directly.
The second one might be behavioral difference in File.expand_path. We're using the same tmpdir logic as MRI, which includes File.expand_path...and perhaps that's expanding symlinks (like tmp dir symlinks on OS X) when it should not?","1","2014-11-11T06:17:05Z"
"246236","16324","62616323","45967","kares","fixed on AR-JDBC's master. have to say I'm not sure if the gem extension (.jar) building always works as expected. if not I would recommend simply not pointing to master since it's a development branch just like Rails' ... there's 1-3-stable for the 1.3.x line ~ same in terms on 4.2 compatibility (or making it work in another PR at ours :)","1","2014-11-11T20:35:40Z"
"246237","16324","62622210","160941","guilleiguaran","@kares @headius thank you guys for clarification and help, can this be closed? <3","1","2014-11-11T21:17:57Z"
"246238","16324","62666188","142914","bf4","The second commit does fix some failing tests, at least locally, so let's keep it open and I'll investigate a bit more.
I rebased the first to specify 1-3-stable, per above, and removed the TMPDIR commit so we can see the failures on CI that I was seeing locally.","1","2014-11-12T03:45:50Z"
"246239","16324","62834773","142914","bf4","Based on the 'successful' build, I think this PR is sufficient as is. I'll create new PR's for specific JRuby issues.
[Travis results summary of JRuby failure types](https://gist.github.com/bf4/bfb08415fde03f46601f)","1","2014-11-13T03:12:21Z"
"246240","16324","124509168","3948","arunagw","Can we close/update this? And check with latest version?","1","2015-07-24T12:49:00Z"
"246241","16324","124521191","142914","bf4","I can take a look. Sorry, been meaning to follow up.
>
","1","2015-07-24T13:31:47Z"
"246242","16326","1393226","9582","josevalim","This is not the same because the previous version returned a copy of the same object. Now we are setting it to always be an OutputBuffer.","1","2011-06-18T12:51:32Z"
"246243","16326","1393500","29658","gazay","Previous version returned not copy of object - it return only instance of class of this object without calling initialize. Thats why warning is - @dirty initializes only in initialize and initialize_copy. But i understand about different classes and make new pull request https://github.com/rails/rails/pull/1760","1","2011-06-18T14:42:05Z"
"246244","16329","62729566","47848","rafaelfranca","Could you add a test case?","1","2014-11-12T14:53:12Z"
"246245","16329","63015566","7728","calvincorreli","Test case added. Sorry took a while to get the whole test setup going. I wanted to make sure I could run the test myself before submitting it.","1","2014-11-14T06:22:42Z"
"246246","16330","62719959","6321","pixeltrix","Doesn't this need a regression test? Also a CHANGELOG entry would be nice, thanks.","1","2014-11-12T13:51:27Z"
"246247","16330","62744717","3124","tenderlove","We definitely need a regression test.","1","2014-11-12T16:18:24Z"
"246248","16330","62754070","1148215","jordimassaguerpla","without this commit this test fails:
StaticTest#test_handles_urls_with_bad_encoding
which is already in the source code.
Isn't that enough?","1","2014-11-12T17:10:02Z"
"246249","16330","62755608","1148215","jordimassaguerpla","@pixeltrix : regarding the CHANGELOG, you mean like a line at the top of the file?","1","2014-11-12T17:19:35Z"
"246250","16330","62787360","6321","pixeltrix","> without this commit this test fails:
If the test already fails how did the regression get introduced? :worried:
> regarding the CHANGELOG, you mean like a line at the top of the file?
Yes","1","2014-11-12T20:26:32Z"
"246251","16330","62870949","1148215","jordimassaguerpla","@pixeltrix : the regression was introduced with
https://github.com/rails/rails/commit/3437f260a5903b651bf8b8f751345fb288fa9052
","1","2014-11-13T10:29:48Z"
"246252","16330","62877453","6321","pixeltrix","@jordimassaguerpla that commit is only listed in 3-2-stable but the original report talks about 3.2.20 so I'm slightly confused but doing a compare shows it's there. @tenderlove did you do the 3.2.20 security release? If so did you run the tests?","1","2014-11-13T11:28:54Z"
"246253","16330","62904477","1148215","jordimassaguerpla","@pixeltrix : see the list of latest commits in 3-2-stable
https://github.com/rails/rails/commits/3-2-stable
You'll see tenderlove bumped the version to 3.2.20","1","2014-11-13T15:14:46Z"
"246254","16330","63285565","1148215","jordimassaguerpla","@tenderlove : should we expect a 3.2.21 release with this fix? I'd like to package rubygem-actionpack-3_2 with the security fix in 3.2.20 for openSUSE but don't know if I should wait and include this fix as well....","1","2014-11-17T10:32:02Z"
"246255","16330","76080987","47848","rafaelfranca","Is this still reproduced in the current 3-2-stable branch?","1","2015-02-25T23:04:47Z"
"246256","16330","76144559","1148215","jordimassaguerpla","tenderlove fixed it with commit
https://github.com/rails/rails/commit/307402febd448646df796e7dabbbaa5734f641aa
I really wanted to have a commit in rails :( ;)","1","2015-02-26T09:10:24Z"
"246257","16332","62737810","47848","rafaelfranca","I think that maybe is better to speicify what are the supported options and not the unsupported. @fxn WDYT?","1","2014-11-12T15:40:46Z"
"246258","16332","62872098","88676","aderyabin","@rafaelfranca, Done.
I specify allowed options, note that index is not supported and save reference because there are lot of useful information.","1","2014-11-13T10:39:42Z"
"246259","16332","62873307","3387","fxn","Hey I'll try to give feedback tonight.","1","2014-11-13T10:49:29Z"
"246260","16332","62972843","3387","fxn","Historically `t.column` was the original way to create columns in migrations and `add_column` is assumed to be the same thing for existing tables. Both methods should be equal except for that, and that's why the documentation refers to `column`, because their documentation should be equal mod the table and you do not want to maintain both of them in sync.
The `:index` option for `column` is really recent (see https://github.com/rails/rails/commit/9a0d35e8) and new in 4.2 if I am not mistaken.
In my opinion, if we are fine with allowing column creation in new tables to be able to also create an index, then the same criteria should be applied to newly created columns for existing tables. The interface should be equal.
I have no strong opinion about allowing `:index` or not, indeed I agree with @rafaelfranca (in the referenced ticket) that creating a column could well be restricted to do that and nothing else. I would be fine reverting that change, but in either case, I do believe both APIs should be in sync and in consequence the API of `add_column` should be able to delegate to the docs of `column` as it does today.
","1","2014-11-13T21:51:35Z"
"246261","16332","62976934","88676","aderyabin","I agree with @fxn about equal interface.
I didn't see a problem about multi actions in `add_column` (add field and add index). It works perfect for `add_reference` [now](https://github.com/rails/rails/blame/0edf4b55b536a9d5e29519fbda3f61eb4f1035da/activerecord/lib/active_record/connection_adapters/abstract/schema_statements.rb#L642). There are 3 actions (add 2 fields and add index).","1","2014-11-13T22:17:41Z"
"246262","16332","63064233","22904","andyjeffries","Duplicate of #17584?","1","2014-11-14T13:30:02Z"
"246263","16332","63064575","3387","fxn","@andyjeffries my comment referred to #17584 without linking.","1","2014-11-14T13:33:05Z"
"246264","16332","63064693","3387","fxn","@dhh the thread is split in these two issues.","1","2014-11-14T13:34:07Z"
"246265","16333","724911","52642","spastorino","Please patch it directly in https://github.com/lifo/docrails. Everyone can push there and is the official repo for docs, thanks.","1","2011-01-31T14:47:17Z"
"246266","16334","2340517","199","jeremy","I don't understand this fix. Could you explain? Is there a cleaner way to ensure `@dirty` is initialized?","1","2011-10-09T20:43:32Z"
"246267","16334","2341617","29658","gazay","Nope, now i don't think so. I found your last commit for this method (https://github.com/rails/rails/commit/b3318bd937a238ad2def93cb3bfa5b572f80a8a8) and so I understand it was made to keep encoding in new OutputBuffer object. But now all data is stored in rails3 in one encoding - UTF-8 by default (automatic encoding in OutputBuffer#initialize for example), so maybe here OutputBuffer.new will be ok.","1","2011-10-09T22:54:57Z"
"246268","16334","2416309","29658","gazay","Updated flushing buffer","1","2011-10-15T16:58:18Z"
"246269","16334","2416639","199","jeremy","Where's the @dirty warning coming from? Is there a simpler way to suppress it rather than changing this implementation?","1","2011-10-15T18:09:26Z"
"246270","16334","3280263","3948","arunagw","What's going on with this PR?? @gazay can you see if this PR still required ??","1","2011-12-27T09:43:55Z"
"246271","16334","3282133","29658","gazay","It's ok, no warnings now.","1","2011-12-27T15:19:25Z"
"246272","16335","63076470","1191","al2o3cr","Couple thoughts:
* does this behavior persist if you rename the `references` association to something else? It's dangerously close to a method name on `Relation`...
* does this behavior persist if you explicitly specify `inverse_of` on the associations? I believe there's code to guess this in most cases, but it may not be working here.","1","2014-11-14T15:05:45Z"
"246273","16335","63076701","1191","al2o3cr","Also, your code is using a `class` option to `has_many` that doesn't exist. Use `class_name` instead, though I don't think it's relevant to the behavior here.","1","2014-11-14T15:07:23Z"
"246274","16335","63169779","1940892","afunction","1. Actually, This issue found out by my project, following code is my real project models.
```ruby
class Album < ActiveRecord::Base
has_many :album_photoships
has_many :photos, through: :album_photoships
end
class AlbumPhotoships < ActiveRecord::Base
belongs_to :album
belongs_to :photo
end
class Photo < ActiveRecord::Base
has_many :album_photoships
has_many :albums, through: :album_photoships
end
```
In my project :album_photoships in Photo model with same problem.
when i run `@album.photos.new.save` it will not save association to `AlbumPhotoships`, but i use `@album.photos.create` will works. or i change the association name without (s) in Photo model will works too. so i don't think the problem is `references` too common for association name.
2. I have not try to use `inverse_of` options, i will try later.
3. I use class option instead of class_name option. because the tests in activerecord needs many models for different situation, so i have to create the models in my test block, if i don't assign class option it will not found global class `Reference`.
","1","2014-11-15T11:51:27Z"
"246275","16335","63226038","1191","al2o3cr","@afunction - Oops, missed the `class` option as it's not in the public API :)
I suspect the presence of a plural-named model (`AlbumPhotoships`) is confusing the automatic `inverse_of` code. Renaming that model to the singular (`AlbumPhotoship`) may also change the behavior...","1","2014-11-16T16:31:37Z"
"246276","16336","65387148","12642","kamipo","The charset of `version` column in `schema_migrations` table is depend
on the database default charset and collation rather than the encoding
of the connection.
How to reproduce:
```bash
# rails new apps default encoding: utf8
$ rails new foo -d mysql && cd foo
# existing database charset utf8mb4
$ mysql -u root -e ""CREATE DATABASE foo_development CHARACTER SET utf8mb4""
# create index fails
$ rake db:migrate
rake aborted!
ActiveRecord::StatementInvalid: Mysql2::Error: Index column size too large. The maximum column size is 767 bytes.: CREATE UNIQUE INDEX `unique_schema_migrations` ON `schema_migrations` (`version`)
```
","1","2014-12-03T10:34:13Z"
"246277","16336","65466893","12642","kamipo","@fxn What do you think about this matter?","1","2014-12-03T19:01:27Z"
"246278","16336","65693597","3387","fxn","@kamipo since we cannot do this for 4.2, I'll prioritize some stuff I want to have for 4.2, but I'll come back later to this this PR. Thanks!
","1","2014-12-04T20:02:07Z"
"246279","16336","73825958","12642","kamipo","A part of the PR was merged by #18602.","1","2015-02-11T02:42:22Z"
"246280","16336","76079218","47848","rafaelfranca","Could you rebase it?","1","2015-02-25T22:54:17Z"
"246281","16336","76081328","12642","kamipo","Rebased on master!","1","2015-02-25T23:06:52Z"
"246282","16338","62868450","22904","andyjeffries","Have you got a reference for this?
For example Mailchimp's article on top 10 spam triggers doesn't list it (https://blog.mailchimp.com/most-common-spam-filter-triggers/) and another article says that most email applications strip them anyway (http://kb.mailchimp.com/templates/code/common-html-mistakes)
I'm not saying you're wrong, but is there any article from a decent source that we can view to see if it really makes a difference and if there's anything else we should be doing.","1","2014-11-13T10:08:34Z"
"246283","16338","62918875","948625","runephilosof","Spamassassin punishes it http://wiki.apache.org/spamassassin/Rules/HTML_MIME_NO_HTML_TAG
On 13. nov. 2014 11.09.21 CET, Andy Jeffries <notifications@github.com> wrote:
>Have you got a reference for this?
>
>For example Mailchimp's article on top 10 spam triggers doesn't list it
>(https://blog.mailchimp.com/most-common-spam-filter-triggers/) and
>another article says that most email applications strip them anyway
>(http://kb.mailchimp.com/templates/code/common-html-mistakes)
>
>I'm not saying you're wrong, but is there any article from a decent
>source that we can view to see if it really makes a difference and if
>there's anything else we should be doing.
>
>---
>Reply to this email directly or view it on GitHub:
>https://github.com/rails/rails/pull/17606#issuecomment-62868450
--
Mvh
Rune Schjellerup Philosof","1","2014-11-13T16:18:00Z"
"246284","16338","62920121","22904","andyjeffries","Fair enough. Thanks for the link.","1","2014-11-13T16:25:27Z"
"246285","16338","63063952","22904","andyjeffries","@dhh any thoughts? Seems like a simple enough tweak, does no harm, may have some benefit and the patch is simple (there are no tests currently in railties for the structure of the generated HTML, so none added in this page).","1","2014-11-14T13:27:17Z"
"246286","16407","63925311","55829","chancancode","You can revert https://github.com/rails/rails/commit/c7f0cd6a79e6ee060df982dc0834365b63e53a2c on your branch to find out ??","1","2014-11-21T05:11:39Z"
"246287","16407","64521747","47848","rafaelfranca","@joshk Awesome! Need any help with this one?","1","2014-11-26T06:46:44Z"
"246288","16407","64958479","8701","joshk","Hey @rafaelfranca
I'll close this PR and open a new one so it is free of merge conflicts (its the easiest way)
And manually revert the commit so everything runs and we can see how slow things are.
Truth be told, I don't think we will see a perf improvement until we get stuff running in tmpfs, which won't be for a while for us.
Feel free to ping me anytime about this, as I would love to help improve the build times :)
High 5","1","2014-11-29T17:15:34Z"
"246289","16408","63924480","8701","joshk","This looks to be slower, closing for now.","1","2014-11-21T04:54:25Z"
"246290","16409","725621","959","glv","Tried this again due to carelessly screwing up the previous pull request. (Thanks to Matthew McCullough for helping me recover.)","1","2011-01-31T18:04:02Z"
"246291","16409","728659","52642","spastorino","Applied, thanks.","1","2011-02-01T14:40:12Z"
"246292","16411","63939391","5402","senny","@ShunsukeAida I agree with your assessment. I added a changelog entry and changed the patch a bit to keep the log directory (and the `.keep` file) under version control. Thank you :yellow_heart: ","1","2014-11-21T08:29:10Z"
"246293","16414","64031917","833383","arthurnn","thanks.. as far as I can tell this is more consistent with the rest of the docs.","1","2014-11-21T20:21:34Z"
"246294","16416","64263607","20515","scambra","I have added fix for #15244 here because is a related issue with preloading habtm associations","1","2014-11-24T21:01:03Z"
"246295","16416","64939645","20515","scambra","@sgriff are you ok with changes?","1","2014-11-29T03:01:59Z"
"246296","16416","65003485","20515","scambra","It should be a pull request for 4-2-stable, but I don't find how to change it","1","2014-11-30T22:31:56Z"
"246297","16416","65003729","20515","scambra","I have added #17859 against 4-2-stable branch","1","2014-11-30T22:37:56Z"
"246298","16416","68706273","47848","rafaelfranca","@scambra is this issue at master too? If so the PR should point to master","1","2015-01-05T13:18:56Z"
"246299","16416","69023292","20515","scambra","I have added #18383 against master","1","2015-01-07T13:47:21Z"
"246300","16416","70981785","20515","scambra","can #18383 be merged to master and 4.2?","1","2015-01-22T07:33:41Z"
"246301","16416","71044036","47848","rafaelfranca","Closing in favor of #18383","1","2015-01-22T16:03:09Z"
"246302","16418","71044612","47848","rafaelfranca","Closing in favor of #18383","1","2015-01-22T16:06:26Z"
"246303","16420","64080658","4335742","tgxworld","Introduced in https://github.com/rails/rails/commit/8d61463f34fd0bb7bad446f2d43aaa63fee61563","1","2014-11-22T13:44:56Z"
"246304","16421","64084509","3948","arunagw","thanks","1","2014-11-22T15:52:18Z"
"246305","16422","64102755","833383","arthurnn","[fixes #16928]","1","2014-11-23T01:34:58Z"
"246306","16422","64102911","277819","zzak","LGTM :shipit: ","1","2014-11-23T01:42:21Z"
"246307","16425","64283765","1529387","sgrif","Can you squash this to a single commit, please?","1","2014-11-24T23:21:30Z"
"246308","16425","64288928","2731572","rzane","Absolutely. I've been working on getting all if the tests passing for Firebird for the past two days. I might have some more changes, so can we keep this one open for a bit longer?","1","2014-11-25T00:11:25Z"
"246309","16425","64289020","1529387","sgrif","Yes","1","2014-11-25T00:12:32Z"
"246310","16425","64289035","1529387","sgrif","Ping me when ready. ","1","2014-11-25T00:12:39Z"
"246311","16425","64289433","2731572","rzane","Great. Thanks!","1","2014-11-25T00:16:59Z"
"246312","16425","65539642","18359","mariuz","I guess https://github.com/rails/rails/pull/17424 can be closed ","1","2014-12-04T05:26:16Z"
"246313","16425","68743155","47848","rafaelfranca","Merged as f493a4122ebf44a44b93c02804d33a0e4121d6cd","1","2015-01-05T17:30:44Z"
"246314","16425","68751300","2731572","rzane","Thanks. Sorry I got distracted!","1","2015-01-05T18:23:29Z"
"246315","16426","64106263","277819","zzak","There's other places this middleware is mentioned, can you check?
```
~/code/rails => git grep 'ActionDispatch::Head'
guides/source/configuring.md:217:* `ActionDispatch::Head` converts HEAD requests to GET requests and serves them as so.
guides/source/configuring.md:228:config.middleware.insert_before ActionDispatch::Head, Magical::Unicorns
guides/source/configuring.md:234:config.middleware.insert_after ActionDispatch::Head, Magical::Unicorns
guides/source/rails_on_rack.md:310:**`ActionDispatch::Head`**
railties/lib/rails/configuration.rb:21: # config.middleware.insert_before ActionDispatch::Head, Magical::Unicorns
railties/lib/rails/configuration.rb:25: # config.middleware.insert_after ActionDispatch::Head, Magical::Unicorns
```","1","2014-11-23T04:23:54Z"
"246316","16426","64106373","5356517","yui-knk","OK I can. Do you think `ActionDispatch::Head` is wrong and `Rack::Head` is correct ?","1","2014-11-23T04:28:03Z"
"246317","17379","74909165","2741","dhh","I weighed in before understand the issue on the other ticket, but after Rafael educating me, I'm ?","1","2015-02-18T17:38:09Z"
"246318","17379","74909525","11562","lukaszx0","I'm in! :+1:
On Wed, Feb 18, 2015 at 6:38 PM, David Heinemeier Hansson <
notifications@github.com> wrote:
> I weighed in before understand the issue on the other ticket, but after
> Rafael educating me, I'm [image: ?]
>
> —
> Reply to this email directly or view it on GitHub
> <https://github.com/rails/rails/pull/18992#issuecomment-74909165>.
>
","1","2015-02-18T17:39:55Z"
"246319","17379","74909997","55829","chancancode",":heart:","1","2015-02-18T17:42:34Z"
"246320","17379","74910323","26328","carlosantoniodasilva",":green_heart::yellow_heart::heart::blue_heart::purple_heart:","1","2015-02-18T17:44:19Z"
"246321","17379","74910727","9347","dmathieu",":100: ","1","2015-02-18T17:46:11Z"
"246322","17379","74912645","833383","arthurnn",":tada: ","1","2015-02-18T17:55:45Z"
"246323","17379","74912870","567626","vipulnsward","We should document, whats acceptable when updating the file in contributing guide.","1","2015-02-18T17:56:52Z"
"246324","17379","74912970","833383","arthurnn","Only issue I see about this is:
> This sometimes
returns a version that is not compatible with Rails anymore, making the
tests fail and the harder to identify the commit that introduced a bug.
The test will still fail on travis-ci, and it would be still hard to identify the problem.","1","2015-02-18T17:57:24Z"
"246325","17379","74913337","47848","rafaelfranca","@arthurnn at CI side it will still fail but if it is passing locally we will at least know it is because of of the dependencies.
@vipulnsward good point about documenting. I'll write something.","1","2015-02-18T17:59:13Z"
"246326","17476","153368148","350807","kaspth","@yuki24 nice! Have you sent a pull request to enable `public_file_server` as mentioned in the outdated diffs yet? ? ","1","2015-11-03T14:16:23Z"
"246327","17476","153385986","386234","yuki24","@kaspth Not yet. I'm not sure if I can work on it anytime soon, so feel free to send a PR if you could.","1","2015-11-03T15:18:38Z"
"246328","17476","153399100","59744","schneems","What was the idea?","1","2015-11-03T16:04:44Z"
"246329","17476","153506030","350807","kaspth","@yuki24 @schneems added a pull request at #22173 :grin:","1","2015-11-03T22:13:37Z"
"246330","17480","76574057","833383","arthurnn","https://github.com/rails/rails/pull/19140#issuecomment-76564708","1","2015-03-01T04:41:49Z"
"246331","17481","76564708","2394703","seuros","These links are meant to work in http://guides.rubyonrails.org/ so they are correct.","1","2015-03-01T02:40:36Z"
"246332","17482","76574037","833383","arthurnn","https://github.com/rails/rails/pull/19140#issuecomment-76564708","1","2015-03-01T04:41:15Z"
"246333","17483","76574017","833383","arthurnn","https://github.com/rails/rails/pull/19140#issuecomment-76564708","1","2015-03-01T04:40:25Z"
"246334","17483","76584660","350807","kaspth","Thanks for trying to improve Rails, but you've sent us 5 Pull Requests like this. In the future if you see the same pattern across that many files please stop and think if it's simply correct :wink:
I'm sure you'll get it next time :heart:","1","2015-03-01T06:50:23Z"
"246335","17484","76570626","94129","georgeclaghorn","These links do not need to be changed. The guides are intended to be read on [guides.rubyonrails.org](http://guides.rubyonrails.org), where the links work.","1","2015-03-01T03:50:02Z"
"246336","17484","76570717","160941","guilleiguaran","As @georgeclaghorn said, the links shouldn't changed here","1","2015-03-01T03:54:01Z"
"246337","17485","102372984","201687","jarthod","Just had this issue with latest version (4.2.1) hasn't this been released yet ?","1","2015-05-15T11:21:06Z"
"246338","17541","77729236","2741","dhh","?
> On Mar 7, 2015, at 15:36, Arthur Nogueira Neves <notifications@github.com> wrote:
>
> Does this report failures as it's running, or only at the end?
>
> Only at the end for now. Now that we have our reporter and a rails minitest plugin we will definitely do that too.
>
> —
> Reply to this email directly or view it on GitHub.
>
","1","2015-03-08T02:40:03Z"
"246339","17541","78107379","47848","rafaelfranca","Seems good to me but I don't know anything about the implementation. Maybe it is good to ask @zenspider's opinion about the implementation before merging.","1","2015-03-10T17:43:12Z"
"246340","17541","78126513","9832","zenspider","I've just taken a quick glance at this and I guess I don't get it. I can see that you're [using the plugin system][1] to put in a custom reporter (almost the same as the reporters provided in [seattlerb/minitest-sprint][3] btw) and that's perfect. But, I don't understand why [Rails::TestRunner][2] exists as a whole. Can you explain why it exists? It looks like it is a reinvented wheel.
Also, it looks like `run_test_file` tests the test mechanism by shelling out. That's heavy. Is there some reason for that?
[1]: https://github.com/rails/rails/pull/19216/files#diff-ea6c92bf87b30213dbd5eafb8431976cR5
[2]: https://github.com/rails/rails/pull/19216/files#diff-bef0ae2c16dacf77bfd2ba099af8a330R7
[3]: https://github.com/seattlerb/minitest-sprint","1","2015-03-10T19:15:40Z"
"246341","17541","78129403","833383","arthurnn","@zenspider the `Rails::TestRunner` exists for a few reasons:
- encapsulate the options we can receive on the runner i.e. `rails test file.rb`, file.rb is a parameter.
- wrapper to `find_method`, so we can find the test method if you pass a line number to the runner.
- Setup Rails configs, for instance `ENV[""RAILS_ENV""]`
Pretty much, its main responsibility, is to encapsulate the test options, so we can use it on the minitest plugin, but also on the rails command https://github.com/rails/rails/pull/19216/files#diff-d372de5c2ec1bba7b73aa34bb2d2a798R5 https://github.com/rails/rails/pull/19216/files#diff-47b9fc20bec6924b9946969a002d33c4R9
","1","2015-03-10T19:29:41Z"
"246342","17592","81963449","4727","brandonweiss","???
Thanks, @rafaelfranca!","1","2015-03-16T22:10:15Z"
"246343","17593","78255734","1080678","eileencodes","@yuroyoro can you post the benchmarks code so that we can run them?
Does this issue only exist in postgresql? or is that just the DB you tested with?","1","2015-03-11T12:45:16Z"
"246344","17593","78271760","18634","yuroyoro","@eileencodes I posted benchmarks code.
https://gist.github.com/yuroyoro/89fae1150e285658db45
> Does this issue only exist in postgresql? or is that just the DB you tested with?
I think it exists in any other database.
Here is a benchmark result running with sqlite3.
https://gist.github.com/yuroyoro/2efca870711fa5047a3b","1","2015-03-11T14:20:44Z"
"246345","17593","83695231","18634","yuroyoro","@rafaelfranca Why this pr was closed with unmerged?","1","2015-03-19T18:01:04Z"
"246346","17805","135778316","235844","gaurish","Thanks for reviewing ?
","1","2015-08-28T13:42:42Z"
"246347","17805","135825839","4912","sikachu","I know I'm late to the party, but I have a feeling that this promotes a feature to be used in the way that it's not intended to be.
What about actually adding [`assert_valid_keys`](http://api.rubyonrails.org/classes/Hash.html#method-i-assert_valid_keys) to ActionController::Parameters? We already have that on Hash, and it's currently the way to make sure a Hash has all the given keys. Adding this recursive functionality to `require` makes this method doing too much IMHO.","1","2015-08-28T16:30:42Z"
"246348","17805","135826840","3387","fxn","The apparently innocent patch had an important typo that wasn't catched by the tests, went through it in cbe7899f9d5fece4749f75828fd120d67056f356.
If correcting a patch about an API you don't agree with isn't team playing I don't know what it is! :smile: ","1","2015-08-28T16:34:57Z"
"246349","17806","91317329","1955930","aditya-kapoor","@zzak PR updated...:)","1","2015-04-09T18:20:09Z"
"246350","17806","91935539","59744","schneems","Thanks! :heart:","1","2015-04-11T22:24:34Z"
"246351","17807","88483791","27350","kou","What should I do as the next action for this pull request is merged?","1","2015-04-01T13:39:31Z"
"246352","17807","94436341","27350","kou","Is there any response?","1","2015-04-20T12:15:00Z"
"246353","17809","88394167","5402","senny","@kaspth Thank you for working on this :yellow_heart:
Can we make it work without `Minitest.autorun`? Part of the idea of the original runner was to have a simple interface to run a bunch of tests:
```ruby
Rails::TestRunner.run([""test/controllers"", ""test/mailers"", ""test/functional""])
```
When relying on `Minitest.autorun` the API feels unclear and relies on the require side-effects. There is a related issue #17708 and PR #19435.","1","2015-04-01T08:38:45Z"
"246354","17809","88481729","833383","arthurnn","I still think we should have a `TestRunner` class. maybe that class wont parse the options anymore. But it would be good to have the test runner logic in one class.","1","2015-04-01T13:33:15Z"
"246355","17809","90190685","350807","kaspth","Alright, updated here @senny @arthurnn","1","2015-04-06T18:36:40Z"
"246356","17809","90204850","5402","senny","@kaspth really liking this patch :yellow_heart: Can you post the help output when running with `-h`?","1","2015-04-06T19:22:48Z"
"246357","17809","90293718","9832","zenspider","@senny it already does.","1","2015-04-07T00:06:20Z"
"246358","17809","90299571","833383","arthurnn","I like where this is going too.. Thanks @kaspth ","1","2015-04-07T00:56:49Z"
"246359","17809","90380036","5402","senny","@zenspider I meant to post the output here to GitHub.","1","2015-04-07T06:04:19Z"
"246360","17809","90478380","9832","zenspider","""Runner"" == manager class. That's what MT4 had and why I explicitly did a rewrite for MT5. Manager classes are bad design and should be avoided where possible. I explicitly designed test classes (runnables, really) to be able to run themselves on purpose. This allows for different types of runnables (eg Test vs Benchmark). Having a test class that knows how to run its own tests makes sense. It's what tests do: run, so why externalize the functionality of it?
Avoid a ""Runner"" type class. You'll be better off in the long run.","1","2015-04-07T09:19:44Z"
"246361","17809","90478767","9832","zenspider","@kaspth Sorry, I missed your original question: you've removed 75 lines, of course I'm a fan.","1","2015-04-07T09:21:01Z"
"246362","17809","90488177","5402","senny","@zenspider I can see your `Runner`-argument for Minitest itself but this runner does nothing else than requiring the files. Someone needs to require the tests before they can run themselves. I'd like to have an interface in Rails to run a set of files and folders. The rest boils down to wether `Runner` is a good name for that.","1","2015-04-07T09:42:20Z"
"246363","17809","91871314","350807","kaspth","@zenspider Great to hear and, yes, I agree on removing the need for a runner and just use Minitest's `autorun` or `run` where appropriate.
@senny I'd be happy to go back to the `TestRequirer` name instead of `TestRunner`.","1","2015-04-11T15:51:38Z"
"246364","17809","91892654","350807","kaspth","@zenspider Writing the `FilterChain` is a bit cumbersome because we kind of have to hack Minitest. Would you consider letting others extend Minitest's filter in the same way reporters can?","1","2015-04-11T17:51:29Z"
"246365","17809","92078068","350807","kaspth","@senny I forgot to post the help output. Here it is:
```
minitest options:
-h, --help Display this help.
-s, --seed SEED Sets random seed
-v, --verbose Verbose. Show progress processing files.
-n, --name PATTERN Filter run on /pattern/ or string.
Known extensions: rails
Usage: bin/rails test [options] [file or directory]
You can run a single test by appending the line number to filename:
bin/rails test test/models/user_test.rb:27
-e, --environment [ENV] Run tests in the ENV environment
-b, --backtrace Show the complete backtrace
```
We should probably add more separators - currently it looks a bit cramped.","1","2015-04-12T15:12:57Z"
"246366","17809","92232139","5402","senny","@kaspth I agree, the output is pretty dense at the moment. Also, the usage (`Usage: bin/rails test [options] [file or directory]`) needs adjusting that it's possible to pass multiple files or directories:","1","2015-04-13T06:43:45Z"
"246367","17809","92467762","350807","kaspth","@senny I've tweaked the output to this:
```
minitest options:
-h, --help Display this help.
-s, --seed SEED Sets random seed
-v, --verbose Verbose. Show progress processing files.
-n, --name PATTERN Filter run on /pattern/ or string.
Known extensions: rails
Usage: bin/rails test [options] [files or directories]
You can run a single test in file by appending the line number:
bin/rails test test/models/user_test.rb:27
Rails options:
-e, --environment [ENV] Run tests in the ENV environment
-b, --backtrace Show the complete backtrace
```","1","2015-04-13T19:18:45Z"
"246368","17809","92474142","5402","senny","@kaspth looking better already. What do you think about a section similar to the one about the line number but describing to run multiple directories. Something along the lines of:
```
Usage: bin/rails test [options] [files or directories]
You can run a single test in file by appending the line number:
bin/rails test test/models/user_test.rb:27
You can run multiple files and directories at the same time by passing multiple arguments:
bin/rails test test/models test/controllers test/integration/login_test.rb
Rails options:
-e, --environment [ENV] Run tests in the ENV environment
-b, --backtrace Show the complete backtrace
```","1","2015-04-13T19:41:21Z"
"246369","17809","92485341","350807","kaspth","@senny Yeah, that's great. I've added it.","1","2015-04-13T20:16:47Z"
"246370","17809","94276667","350807","kaspth","@senny @arthurnn Alright, I've added the ability to mix files and line filters as people please.
Something crazy like this should work:
```
test/controllers test/models/account_test.rb test/models/post_test.rb:4
```
Potentially we could output the failures on a single line, so you could copy that and run all the failing tests at once. But I don't know how useful that is.
I've also changed the code to not augment Minitest when there's no line filters.
However, when there's at least one line filter, we need to create filters for every file. If we didn't, running tests like:
```
test/models/account_test.rb test/models/post_test.rb:4
```
would only run the filter with the line on it. I feel like we should be able to avoid creating those extra filters, but I haven't been able to figure it out.
","1","2015-04-19T13:26:21Z"
"246371","17809","94282124","350807","kaspth","I really don't understand the two test failures in Railties: https://travis-ci.org/rails/rails/builds/59126781. When I inspect the files required in those tests, they require the correct scaffolded files. And they require `test_helper` which requires `rails/test_help` which then calls `Minitest.autorun`.
Could ARGV being long gone in the rake test task be a factor in this?","1","2015-04-19T14:28:42Z"
"246372","17809","98838131","350807","kaspth","@senny @arthurnn Alright, I think I got this now :smile:
I've moved away from `autorun` and fixed the errors in `rake_test.rb`. What should we do about `active_support/testing/autorun`? Can we outright remove it or do we have to deprecate?","1","2015-05-04T20:20:38Z"
"246373","17809","98846490","350807","kaspth","Hm, now the generator tests are failing: https://travis-ci.org/rails/rails/jobs/61201646.
I'll look into them tomorrow (might be related to the lingering autorun @senny spotted).","1","2015-05-04T20:51:04Z"
"246374","17809","98849003","5402","senny","@kaspth :+1: ping me and I'll take another look. Really happy to see this coming along. Great work :yellow_heart: ","1","2015-05-04T21:02:29Z"
"246375","17809","99195078","350807","kaspth","@senny I've been trying to debug why the generator tests are failing, but so far I've gone nowhere.
It seems the tests aren't run at all.
The generator generates an engine with a Rakefile with a standard rake test task. Which leaves me befuddled as to why the tests aren't run. Do you have any ideas?","1","2015-05-05T19:25:45Z"
"246376","17809","99347985","5402","senny","@kaspth I can probably take a look later today.","1","2015-05-06T07:02:45Z"
"246377","17809","99361971","5402","senny","@kaspth investigated a bit. The issue is the [removed autorun line in `test_help.rb`](https://github.com/rails/rails/pull/19571/files#diff-96b8e5694f7954d018d9958ef89f4049L6). As these tests are run using `Rake::TestTask`'s they expect that autorun will be required at some point.","1","2015-05-06T07:53:26Z"
"246378","17809","99957340","166304","zamith","Hey guys,
First of all let me say that it is great to finally have a runner bundled with rails that can compete with the one from RSpec.
Also, as the maintainer of [m](https://github.com/qrush/m), I feel obligated to ask if there is something I can do to help out.
One thing I noticed is that this is very Minitest 5 specific, Rails 5 drops support for any previous version?
Thanks for the awesome job. :+1: ","1","2015-05-07T17:48:30Z"
"246379","17809","102010841","350807","kaspth","@senny @arthurnn Alright, we're green: https://travis-ci.org/rails/rails/builds/62535266 - it's kind of a bummer that GitHub doesn't show Travis runs for force pushes anymore :cry:","1","2015-05-14T11:49:22Z"
"246380","17809","102011241","350807","kaspth","@zamith Just checking in the Gemfile we still accept versions below 5: https://github.com/rails/rails/blob/master/Gemfile#L65. But this pull request definitely relies heavily on the Minitest 5 extension system.
Personally, I think it would be great move to 5+ to move the community forward like we're doing with Ruby versions. What do you think, @arthurnn @senny?","1","2015-05-14T11:53:46Z"
"246381","17809","102035905","166304","zamith","Yes, I agree. And I think that's the Rails philosophy, keep pushing the community forward. I'll keep `M` around for backwards compatibility, and non-Rails programs. It will also greatly diminish the complexity of the code base, because support all the versions of minitest and test::unit is a pain. ","1","2015-05-14T13:24:28Z"
"246382","17809","102035924","1034","matthewd","https://github.com/rails/rails/blob/master/activesupport/activesupport.gemspec#L26 -- we've been requiring minitest 5.1+ since Rails 4.1.","1","2015-05-14T13:24:38Z"
"246383","17812","87413144","193936","simi","@dv https://github.com/rails/rails/commit/dd7bd8c023696657a600ee5dba16bfe5def876bf is not needed since it should be removed in master.","1","2015-03-29T13:25:42Z"
"246384","17812","87414873","44360","dv","What should be removed in master, @simi? Trying to load `core_ext` from `master` branch makes it complain:
```active_support/core_ext/module/deprecation.rb:21:in `deprecate': uninitialized constant ActiveSupport::Deprecation (NameError)```
https://github.com/rails/rails/commit/dd7bd8c023696657a600ee5dba16bfe5def876bf fixes that error, and then I bump into the error as described in PR.","1","2015-03-29T13:40:32Z"
"246385","17812","87415988","193936","simi","Those requires for `active_support/deprecation` in https://github.com/rails/rails/commit/dd7bd8c023696657a600ee5dba16bfe5def876bf are not needed in master since those deprecations are removed.","1","2015-03-29T13:44:08Z"
"246386","17812","87426050","47848","rafaelfranca","Thank you for the pull request. Before requiring any file of a rails framework you must require the top level file. In your case you must require active_support first. ","1","2015-03-29T15:02:33Z"
"246387","17812","87431692","44360","dv","Ah that makes sense. It used to work though, probably by accident. Thanks for clarifying!","1","2015-03-29T15:54:02Z"
"246388","17813","88061095","2741","dhh","Rocking! I'll let @jeremy chime in on anything on the implementation.","1","2015-03-31T12:03:04Z"
"246389","17813","164287514","1651750","mtomov","Hello, and thank you for this amazing piece of smart logic. I am surprised to see that you were able to extend the previous implementation to work with different partials now in so very few lines, and without deleting code.
What is the hold-up on merging this onto master?
And, I also agree that the `collection_without_template` has to have its name changed, as when I was looking at the code, it was very difficult to understand that there is actually a template, but it is dynamically invoked.
Thank you again, brilliant stuff.","1","2015-12-13T18:52:39Z"
"246390","17813","164293481","350807","kaspth","Thanks for the kind words :grin:
Partly because I didn't want to just throw more lines into the collection rendering (they feel too tackled on for my taste).
Hm, I also remember it as being that cache might not be invalidated, but seems my last comment was me being concerned that it wrote to the cache more than once.","1","2015-12-13T19:57:33Z"
"246391","17814","87462216","242532","egilburg","`type` is not a hardcoded keyword, it's the default inheritnace column but users can choose a different column instead and treat `type` like any other column.
http://api.rubyonrails.org/classes/ActiveRecord/ModelSchema/ClassMethods.html#method-i-inheritance_column","1","2015-03-29T19:49:11Z"
"246392","17814","87516017","441111","paulociecomp","@egilburg thanks for the feedback. I had not thought about that. I did some changes. I don't know if this feature will be accepts any way. Waiting more feedbacks. ","1","2015-03-30T02:24:37Z"
"246393","17814","87516885","47848","rafaelfranca","If we are doing this how would you create a table that works with STI using generators?","1","2015-03-30T02:27:50Z"
"246394","17814","87690265","441111","paulociecomp","@rafaelfranca it just display a warning. We can use STI normally.","1","2015-03-30T13:59:44Z"
"246395","17814","87701507","441111","paulociecomp","@rafaelfranca @shunsukeaida now i get it. Sorry. I didn't realize it. Do you have any suggestions?","1","2015-03-30T14:28:25Z"
"246396","17814","87736407","1034","matthewd","I'm :-1: on this in general.
I understand it would be frustrating if you've just created a model without realising that `type` is magical. But if we wanted to solve this, would the generator really be the right layer to do it?
And then there's the fact that the warning makes it feel like you're doing something ""wrong"", even when you actually intend to make an inheritance column.","1","2015-03-30T16:05:24Z"
"246397","17814","87736883","47848","rafaelfranca","Agree with @matthewd about ""fell like you're doing something wrong""","1","2015-03-30T16:07:23Z"
"246398","17814","87743619","441111","paulociecomp","@matthewd @rafaelfranca makes sense. Thanks.","1","2015-03-30T16:34:13Z"
"246399","17815","152325997","1529387","sgrif","I don't like that this returns an array of arrays, instead of some appropriate data structure. I would expect this to be a struct made of two `Point`s. However, the `point` type also returns an array, which means we need to fix that, and have a deprecation cycle. I'd rather hold off on supporting the other geometric types until we do that.","1","2015-10-29T21:04:15Z"
"246400","17817","87473529","1529387","sgrif","Please re-open this against master.","1","2015-03-29T20:42:22Z"
"246401","17817","87473569","1529387","sgrif","Actually, this is more than sufficiently tested by the YAML serialization tests.","1","2015-03-29T20:43:08Z"
"246402","17818","87473692","1529387","sgrif","Sorry, I should have thought it through before asking you to re-open. As I mentioned on the other PR, I think this is more than sufficiently tested by the YAML serialization tests (which is what these methods are meant to support)","1","2015-03-29T20:44:56Z"
"246403","17818","87473911","123855","raysrashmi","But I think there was no test for public API. ","1","2015-03-29T20:46:41Z"
"246404","17819","87570467","5402","senny","@kirs in the original PR we have discussed this already. We decided to keep it simple and only support directory and file arguments. You can follow the discussion here https://github.com/rails/rails/pull/19216#issuecomment-77392037","1","2015-03-30T06:38:44Z"
"246405","17819","87571070","522155","kirs","Got it.","1","2015-03-30T06:43:28Z"
"246406","17820","87491255","1529387","sgrif","/cc @rafaelfranca ","1","2015-03-29T22:35:49Z"
"246407","17821","87831436","77895","mechanicles","@rafaelfranca Sorry I don't know to whom to address this PR currently. So I pinged you.
Actually yesterday I sent this PR. But today morning, I saw that Travis CI got failed. I checked that and my PR got failed mostly for jruby and rbx related builds. Today I rebased with master and did force push to my branch. But now Travis doesn't show any status. Let me know if I missed something.","1","2015-03-30T21:05:53Z"
"246408","17821","87831737","47848","rafaelfranca","No problem, Is this PR fixing any issue?","1","2015-03-30T21:07:23Z"
"246409","17821","87834975","77895","mechanicles","@rafaelfranca I just checked that is there any similar issues to this issue. But didn't get any. Actually I found this issue while testing this file `activerecord/test/cases/associations/eager_test.rb` and found that eager loading is not working for some finder methods if we use `default_scope` as class method.","1","2015-03-30T21:22:53Z"
"246410","17821","88118254","77895","mechanicles","@rafaelfranca I'm not getting your point. Could you elaborate more on it?.
Also one more thing, I have added `respond_to?(:default_scope)` in two places in this PR. We already have a method `scope_attributes?` in [scoping/default.rb](https://github.com/rails/rails/blob/master/activerecord/lib/active_record/scoping/default.rb#L37-L39). I think, it's good place to move `respond_to?(:default_scope)` over there.
something like this,
```
# Are there attributes associated with this scope?
def scope_attributes? # :nodoc:
super || default_scopes.any? || respond_to?(:default_scope)
end
```
Let me know your thoughts","1","2015-03-31T14:53:02Z"
"246411","17821","88140146","77895","mechanicles","@rafaelfranca Also it is not just about eager loading. Actually problem is, if we define `default_scope` as class method, then it doesn't work for finder methods `find` and `find_by`.
```
class Post
def self.default_scope
where(published: true)
end
end
```
Suppose posts table has columns like `category` and `published`.
If we try to search a post like,
```
Post.find_by(category: 'rails')
```
Then here 'default_scope' doesn't work. It doesn't not load `published: true` in the query.","1","2015-03-31T15:50:23Z"
"246412","17821","88164756","47848","rafaelfranca","Right, now I get the problem.
Yeah, I think we should move the `respond_to?` to that method.","1","2015-03-31T16:40:36Z"
"246413","17821","88191586","77895","mechanicles","@rafaelfranca I have update code and moved `respond_to?(:default_scope)` to `scope_attributes?` method.","1","2015-03-31T18:05:43Z"
"246414","17823","87520856","47848","rafaelfranca","I can see that both commits allocates fewer arrays but it would be really great if we know how many. Could you try to benchmark it?","1","2015-03-30T02:44:58Z"
"246415","17823","87521162","1535036","tamird","I'd love to - is there any prior art you can point me to?","1","2015-03-30T02:46:39Z"
"246416","17823","87524132","47848","rafaelfranca","Maybe @sgrif can help you","1","2015-03-30T02:58:54Z"
"246417","17823","87643598","4335742","tgxworld","@tamird This might help. https://github.com/eileencodes/integration_performance_test/blob/master/test/integration/documents_allocations_create_test.rb. ","1","2015-03-30T11:47:05Z"
"246418","17823","88135602","1535036","tamird","@rafaelfranca:
allocation_test.rb:
```ruby
require 'cases/helper'
require 'models/post'
require 'active_record/relation/record_fetch_warning'
module ActiveRecord
class AllocationBenchmark < ActiveRecord::TestCase
fixtures :posts
def test_allocation
arrays = []
where_clauses = []
from_clauses = []
hashes = []
10.times do
Post.all.to_a
arrays << ObjectSpace.each_object(Array).count
where_clauses << ObjectSpace.each_object(Relation::WhereClause).count
from_clauses << ObjectSpace.each_object(Relation::FromClause).count
hashes << ObjectSpace.each_object(Hash).count
end
puts 'arrays: ' << arrays.each_cons(2).map { |left, right| right - left }.inspect
puts 'where_clauses: ' << where_clauses.each_cons(2).map { |left, right| right - left }.inspect
puts 'from_clauses: ' << from_clauses.each_cons(2).map { |left, right| right - left }.inspect
puts 'hashes: ' << hashes.each_cons(2).map { |left, right| right - left }.inspect
end
end
end
```
master (fd94aa4d57a7552ad40c13226caba5b022800326):
```
arrays: [94, 94, 94, 94, 94, 94, 94, 94, 94]
where_clauses: [4, 4, 4, 4, 4, 4, 4, 4, 4]
from_clauses: [2, 2, 2, 2, 2, 2, 2, 2, 2]
hashes: [75, 75, 75, 75, 75, 75, 75, 75, 75]
```
d427e9e7e527aa609c96a5c1450983fb67a29f43:
```
arrays: [94, 94, 94, 94, 94, 94, 94, 94, 94]
where_clauses: [4, 4, 4, 4, 4, 4, 4, 4, 4]
from_clauses: [2, 2, 2, 2, 2, 2, 2, 2, 2]
hashes: [75, 75, 75, 75, 75, 75, 75, 75, 75]
```
c150db9019179b00264c3c6d12320187a90327e6:
```
arrays: [91, 91, 91, 91, 91, 91, 91, 91, 91]
where_clauses: [4, 4, 4, 4, 4, 4, 4, 4, 4]
from_clauses: [2, 2, 2, 2, 2, 2, 2, 2, 2]
hashes: [75, 75, 75, 75, 75, 75, 75, 75, 75]
```
267d7df3e0236b481b33689f5f1d3579367c7115:
```
arrays: [87, 87, 87, 87, 87, 87, 87, 87, 87]
where_clauses: [2, 2, 2, 2, 2, 2, 2, 2, 2]
from_clauses: [1, 1, 1, 1, 1, 1, 1, 1, 1]
hashes: [75, 75, 75, 75, 75, 75, 75, 75, 75]
```
67fd2ec02bcd52cfd8064eba27aeacf7d96d2f8f:
```
arrays: [87, 87, 87, 87, 87, 87, 87, 87, 87]
where_clauses: [2, 2, 2, 2, 2, 2, 2, 2, 2]
from_clauses: [1, 1, 1, 1, 1, 1, 1, 1, 1]
hashes: [75, 75, 75, 75, 75, 75, 75, 75, 75]
```","1","2015-03-31T15:33:46Z"
"246419","17823","88980969","1535036","tamird","Well, I pushed a commit to implement @matthewd's suggestion, and then introduced some instrumentation to benchmark...the results are puzzling.
bench.rb:
```ruby
require 'cases/helper'
require 'models/post'
require 'benchmark/ips'
module ActiveRecord
class RecordFetchWarningTest < ActiveRecord::TestCase
fixtures :posts
def test_bench
num = 3
permutations = (0..num).flat_map { |i| ([true] * i + [false] * (num - i)).permutation.to_a.uniq }
Benchmark.ips do |bm|
permutations.each do |permutation|
$set_array, $set_clause, $set_hash = *permutation
relation = Post.all
relation.load
second_relation = Post.all
second_relation.load
bm.report(""spawn: set_array: #{$set_array}, set_clause: #{$set_clause}, set_hash: #{$set_hash}"") { relation.spawn }
end
bm.compare!
end
Benchmark.ips do |bm|
permutations.each do |permutation|
$set_array, $set_clause, $set_hash = *permutation
relation = Post.all
relation.load
second_relation = Post.all
second_relation.load
bm.report(""merge: set_array: #{$set_array}, set_clause: #{$set_clause}, set_hash: #{$set_hash}"") { relation.merge(second_relation) }
end
bm.compare!
end
end
end
end
```
Minor diff:
```diff
diff --git a/activerecord/lib/active_record/relation/from_clause.rb b/activerecord/lib/active_record/relation/from_clause.rb
index ee2fc4e..597307f 100644
--- a/activerecord/lib/active_record/relation/from_clause.rb
+++ b/activerecord/lib/active_record/relation/from_clause.rb
@@ -25,7 +25,11 @@ module ActiveRecord
end
def self.empty
+ if $set_clause
@empty ||= new(nil, nil).freeze
+ else
+ new(nil, nil)
+ end
end
end
end
diff --git a/activerecord/lib/active_record/relation/query_methods.rb b/activerecord/lib/active_record/relation/query_methods.rb
index 0416cb8..b349bb4 100644
--- a/activerecord/lib/active_record/relation/query_methods.rb
+++ b/activerecord/lib/active_record/relation/query_methods.rb
@@ -54,7 +54,11 @@ module ActiveRecord
Relation::MULTI_VALUE_METHODS.each do |name|
class_eval <<-CODE, __FILE__, __LINE__ + 1
def #{name}_values # def select_values
+ if $set_array
@values[:#{name}] || FROZEN_EMPTY_ARRAY # @values[:select] || []
+ else
+ @values[:#{name}] || []
+ end
end # end
#
def #{name}_values=(values) # def select_values=(values)
@@ -100,7 +104,11 @@ module ActiveRecord
FROZEN_EMPTY_HASH = {}.freeze
def create_with_value # :nodoc:
+ if $set_hash
@values[:create_with] || FROZEN_EMPTY_HASH
+ else
+ @values[:create_with] || {}
+ end
end
alias extensions extending_values
diff --git a/activerecord/lib/active_record/relation/where_clause.rb b/activerecord/lib/active_record/relation/where_clause.rb
index f6613e4..8e8e2c1 100644
--- a/activerecord/lib/active_record/relation/where_clause.rb
+++ b/activerecord/lib/active_record/relation/where_clause.rb
@@ -81,12 +81,16 @@ module ActiveRecord
end
def self.empty
+ if $set_clause
@empty ||= begin
empty = new([], [])
# This method memoizes, which will blow up on a frozen object
empty.send(:referenced_columns)
empty.freeze
end
+ else
+ new([], [])
+ end
end
protected
```
Results:
```
Calculating -------------------------------------
spawn: set_array: false, set_clause: false, set_hash: false
28.743k i/100ms
spawn: set_array: true, set_clause: false, set_hash: false
25.634k i/100ms
spawn: set_array: false, set_clause: true, set_hash: false
22.658k i/100ms
spawn: set_array: false, set_clause: false, set_hash: true
26.748k i/100ms
spawn: set_array: true, set_clause: true, set_hash: false
26.060k i/100ms
spawn: set_array: true, set_clause: false, set_hash: true
26.109k i/100ms
spawn: set_array: false, set_clause: true, set_hash: true
27.297k i/100ms
spawn: set_array: true, set_clause: true, set_hash: true
24.451k i/100ms
-------------------------------------------------
spawn: set_array: false, set_clause: false, set_hash: false
525.659k (± 6.3%) i/s - 2.644M
spawn: set_array: true, set_clause: false, set_hash: false
450.370k (± 8.2%) i/s - 2.256M
spawn: set_array: false, set_clause: true, set_hash: false
462.342k (± 7.8%) i/s - 2.311M
spawn: set_array: false, set_clause: false, set_hash: true
440.271k (± 9.9%) i/s - 2.193M
spawn: set_array: true, set_clause: true, set_hash: false
443.915k (±12.1%) i/s - 2.189M
spawn: set_array: true, set_clause: false, set_hash: true
447.401k (± 7.5%) i/s - 2.245M
spawn: set_array: false, set_clause: true, set_hash: true
470.791k (± 6.6%) i/s - 2.348M
spawn: set_array: true, set_clause: true, set_hash: true
477.696k (± 4.4%) i/s - 2.396M
Comparison:
spawn: set_array: false, set_clause: false, set_hash: false: 525659.4 i/s
spawn: set_array: true, set_clause: true, set_hash: true: 477696.1 i/s - 1.10x slower
spawn: set_array: false, set_clause: true, set_hash: true: 470791.4 i/s - 1.12x slower
spawn: set_array: false, set_clause: true, set_hash: false: 462342.2 i/s - 1.14x slower
spawn: set_array: true, set_clause: false, set_hash: false: 450370.3 i/s - 1.17x slower
spawn: set_array: true, set_clause: false, set_hash: true: 447401.4 i/s - 1.17x slower
spawn: set_array: true, set_clause: true, set_hash: false: 443915.3 i/s - 1.18x slower
spawn: set_array: false, set_clause: false, set_hash: true: 440271.2 i/s - 1.19x slower
Calculating -------------------------------------
merge: set_array: false, set_clause: false, set_hash: false
1.958k i/100ms
merge: set_array: true, set_clause: false, set_hash: false
1.965k i/100ms
merge: set_array: false, set_clause: true, set_hash: false
1.979k i/100ms
merge: set_array: false, set_clause: false, set_hash: true
1.995k i/100ms
merge: set_array: true, set_clause: true, set_hash: false
1.997k i/100ms
merge: set_array: true, set_clause: false, set_hash: true
1.986k i/100ms
merge: set_array: false, set_clause: true, set_hash: true
1.976k i/100ms
merge: set_array: true, set_clause: true, set_hash: true
1.971k i/100ms
-------------------------------------------------
merge: set_array: false, set_clause: false, set_hash: false
20.834k (± 4.3%) i/s - 105.732k
merge: set_array: true, set_clause: false, set_hash: false
20.933k (± 3.2%) i/s - 106.110k
merge: set_array: false, set_clause: true, set_hash: false
19.273k (± 7.0%) i/s - 96.971k
merge: set_array: false, set_clause: false, set_hash: true
19.175k (± 7.3%) i/s - 95.760k
merge: set_array: true, set_clause: true, set_hash: false
19.283k (± 7.3%) i/s - 97.853k
merge: set_array: true, set_clause: false, set_hash: true
19.493k (± 5.3%) i/s - 97.314k
merge: set_array: false, set_clause: true, set_hash: true
19.517k (± 5.7%) i/s - 98.800k
merge: set_array: true, set_clause: true, set_hash: true
19.850k (± 5.9%) i/s - 100.521k
Comparison:
merge: set_array: true, set_clause: false, set_hash: false: 20933.3 i/s
merge: set_array: false, set_clause: false, set_hash: false: 20833.9 i/s - 1.00x slower
merge: set_array: true, set_clause: true, set_hash: true: 19849.9 i/s - 1.05x slower
merge: set_array: false, set_clause: true, set_hash: true: 19516.6 i/s - 1.07x slower
merge: set_array: true, set_clause: false, set_hash: true: 19493.4 i/s - 1.07x slower
merge: set_array: true, set_clause: true, set_hash: false: 19283.4 i/s - 1.09x slower
merge: set_array: false, set_clause: true, set_hash: false: 19272.8 i/s - 1.09x slower
merge: set_array: false, set_clause: false, set_hash: true: 19175.3 i/s - 1.09x slower
```","1","2015-04-02T17:27:29Z"
"246420","17823","102453899","1535036","tamird","Well this is bizarre. If I run the benchmarks in reverse (with the caching on first), the results are reversed (caching is fastest). Any ideas?","1","2015-05-15T16:32:06Z"
"246421","17823","163678389","1535036","tamird","Closing in favour of #22550.","1","2015-12-10T16:28:36Z"
"246422","17923","91940188","59744","schneems","Awesome thanks ?❤️","1","2015-04-11T23:10:15Z"
"246423","17923","91940909","386234","yuki24","Thanks!","1","2015-04-11T23:12:06Z"
"246424","17923","91993974","2415484","jonatack","Nice! TIL `each_codepoint`.","1","2015-04-12T05:19:17Z"
"246425","17924","92006057","738921","idoo","What about CHANGELOG ?","1","2015-04-12T07:58:19Z"
"246426","17924","92007732","5402","senny","@y-yagi thanks :+1: ","1","2015-04-12T08:21:29Z"
"246427","17924","92022559","987638","y-yagi","@senny Thanks!","1","2015-04-12T09:32:12Z"
"246428","17924","92025133","5402","senny","@idoo Other than with code changes we don't add changelog entries for minor updates in the guides.","1","2015-04-12T09:45:44Z"
"246429","17925","92088092","55829","chancancode","Thanks!","1","2015-04-12T17:04:21Z"
"246430","17926","92257502","5402","senny","@kmcphillips what about defining a method like `admin_form_for`, which adds the `:builder` option? In what area do you think that is insufficient?","1","2015-04-13T07:55:43Z"
"246431","17926","92401722","325","edward","@senny it’s not that writing a wrapper like `admin_form_for` would be insufficient (since it would work), but that setting a default form builder at a controller/resource level feels like something that should be part of Rails already, given that you can already override the default view/layout a controller uses.
The background to this patch is that we’re starting to use more custom form builders in Shopify (a rather large Rails project) and are hitting a complexity wall with the workarounds mentioned above.","1","2015-04-13T15:28:24Z"
"246432","17926","92403413","84159","kmcphillips","Overriding a custom `admin_form_for` helper works of course, but it's another instance of having to remember to opt in. May as well just pass the builder in each time.
Rails allows you to scope nearly everything cleanly to split an app into sections, with this notable exception. Especially since you have the ability to override the form builder globally.
Shopify isn't the first project where I have wanted this feature either, FWIW.","1","2015-04-13T15:34:40Z"
"246433","17926","92408193","47848","rafaelfranca","About the feature, I can see as it can be useful. This would be similar to when we define which helper module is loaded by controller (if we disable the global require).
About the implementation, this is coupling Action View with Action Controller. How about instead making Action View asking Action Controller what is the form builder, we do not set it when creating the `ActionView::Base` instance at controller level?","1","2015-04-13T15:47:44Z"
"246434","17926","92408487","47848","rafaelfranca","Also I can see how Simple Form can benefits of this feature.","1","2015-04-13T15:49:04Z"
"246435","17926","92408991","84159","kmcphillips","@rafaelfranca Agree. Don't like the coupling. I'll look at refactoring it to Action View.","1","2015-04-13T15:51:15Z"
"246436","17926","92500748","47848","rafaelfranca","Given we will have a default form builder per action view instance and it
can be configured at controller level I wonder if we can deprecate the
application level configuration. If you want to define a application level
default form builder after this feature you could just define it in
ApplicationController.
Another thing, maybe we should call the singleton method
`default_form_builder`.
On Mon, Apr 13, 2015, 12:51 Kevin McPhillips <notifications@github.com>
wrote:
> @rafaelfranca <https://github.com/rafaelfranca> Agree. Don't like the
> coupling. I'll look at refactoring it to Action View.
>
> —
> Reply to this email directly or view it on GitHub
> <https://github.com/rails/rails/pull/19736#issuecomment-92408991>.
>
","1","2015-04-13T21:13:55Z"
"246437","17926","92564987","84159","kmcphillips","@rafaelfranca Great feedback.
I think it's a great idea to deprecate the global `ActionView::Base.default_form_builder` config, though I'd do that in a separate pull request.
I'll rename the method to be `default_form_builder` to be consistent. I like that.
About the implementation.
I can delegate `:default_form_builder, to: :controller` here. This is called when `ActionView::Base` is initialized:
https://github.com/rails/rails/blob/8ac458ad2e252ba041d9f4e42b94bd5997a622be/actionview/lib/action_view/helpers/controller_helper.rb#L10-11
That makes the implementation in the `ActionView::Helper::FormHelper` much cleaner:
```ruby
def default_form_builder_class
builder = default_form_builder || ActionView::Base.default_form_builder
```
And that works.
But when the view is not an instance of `ActionView::Base` and/or does not include `ActionView::Helpers::ControllerHelper` it raises since the method is not defined. For example, this test then fails:
https://github.com/rails/rails/blob/8ac458ad2e252ba041d9f4e42b94bd5997a622be/actionview/test/template/erb/helper.rb
I'm not sure if that means this test is broken, or if this is a valid case.
I can do `self.respond_to?(:default_form_builder)` but I think that's not any better.
What do you think?","1","2015-04-14T02:27:08Z"
"246438","17926","92569040","47848","rafaelfranca","I think instead of delegating we should do the same we do with `request` and `config` https://github.com/rails/rails/blob/8ac458ad2e252ba041d9f4e42b94bd5997a622be/actionview/lib/action_view/helpers/controller_helper.rb#L14-17.
And we define:
```ruby
def default_form_builder_class
builder = @_default_form_builder || ActionView::Base.default_form_builder
```
Or use a `attr_internal` as we do with `request` but defined in `FormHelper` module.
I think this would fix the problem with the custom view context.","1","2015-04-14T02:45:21Z"
"246439","17926","92589818","84159","kmcphillips","Ok, updated.
I also added tests to both the `actionpack` and `actionview` sides to make sure the values are passed through as expected.","1","2015-04-14T03:45:21Z"
"246440","17926","92907556","47848","rafaelfranca","Awesome!","1","2015-04-14T15:24:53Z"
"246441","17926","92955853","26328","carlosantoniodasilva","Just to add to the discussion, deprecating the AV config might not be an option if we want people to actually use it decoupled (which means there will be no controller default to inherit from).","1","2015-04-14T16:28:28Z"
"246442","17926","92978024","47848","rafaelfranca","@carlosantoniodasilva yeah, I thought that when I was merging it and forget to comment here.","1","2015-04-14T16:55:06Z"
"246443","17926","92978947","26328","carlosantoniodasilva",":+1:
On Tue, Apr 14, 2015 at 1:56 PM, Rafael Mendonça França <
notifications@github.com> wrote:
> @carlosantoniodasilva <https://github.com/carlosantoniodasilva> yeah, I
> thought that when I was merging it and forget to comment here.
>
> —
> Reply to this email directly or view it on GitHub
> <https://github.com/rails/rails/pull/19736#issuecomment-92978024>.
>
--
At.
Carlos Antonio
","1","2015-04-14T16:56:49Z"
"246444","17926","93021245","84159","kmcphillips","Super great. Thanks! :rocket: :crescent_moon: ","1","2015-04-14T19:02:26Z"
"246445","17926","96015882","1753245","intrip","Nice job everybody. ","1","2015-04-24T18:04:03Z"
"246446","17926","110515906","76367","md5","Any chance this will end up in a 4.2.x release?","1","2015-06-09T21:55:16Z"
"246447","17926","110517695","47848","rafaelfranca","No. New features are not added to stable releases","1","2015-06-09T22:01:50Z"
"246448","17926","110518182","76367","md5","I looked around for a Rails release roadmap, but I didn't find one. Should I expect this in a 4.3.x release or something else?","1","2015-06-09T22:04:40Z"
"246449","17926","110519028","47848","rafaelfranca","It will be in the Rails 5 release","1","2015-06-09T22:06:54Z"
"246450","17927","96052095","152152","derekprior","As you mentioned in the linked issue, if the instance variable is present, we should just pass that rather than the symbol. What do you think about closing this?","1","2015-04-24T20:16:50Z"
"246451","17927","96063478","1840945","meinac","You are right, I'm closing this one.","1","2015-04-24T21:01:39Z"
"246452","17929","92158802","1529387","sgrif","I think so, but I'll take a closer look on Monday. I'd appreciate holding off on merging until I can dig into this. ","1","2015-04-13T01:06:41Z"
"246453","17929","107028566","25882","keithpitt","I also noticed today that `update_columns` behaves this way as well. I'm using `update_columns` to update usage of an API token in our app (when ever the token is used, we store the user agent, time and ip address).
I'm listing the current entries inside the statement pool in the below screenshot, and you'll see 3 entries that could have used the cache, but didn't:
","1","2015-05-30T11:39:41Z"
"246454","17929","107059471","1034","matthewd","@keithpitt https://github.com/rails/rails/blob/50914b918e57359193e873e285bcfe38dff12b81/activerecord/lib/active_record/persistence.rb#L312 :wink:
@sgrif so [this](https://github.com/rails/rails/blob/50914b918e57359193e873e285bcfe38dff12b81/activerecord/test/cases/relations_test.rb#L1006) is [failing](https://travis-ci.org/rails/rails/jobs/64696181#L409) because I'm incorrectly building upon an assumption in 16ce2eecd3eb23034555bb37b29c12985243d908 -- that bind values always occur in a fixed order. Specifically, the `SET` clause's binds may be needed before or after the joins' binds, depending on the SQL dialect:
```sql
-- PostgreSQL (works)
UPDATE ""posts"" SET ""title"" = $1 WHERE ""posts"".""id"" IN (SELECT ""posts"".""id"" FROM ""posts"" INNER JOIN ""taggings"" ON ""taggings"".""taggable_id"" = ""posts"".""id"" AND ""taggings"".""taggable_type"" = $2 WHERE ""taggings"".""tag_id"" = $3)
[[""title"", ""rofl""], [""taggable_type"", ""Post""], [""tag_id"", 1]]
-- MySQL (fails)
UPDATE `posts` INNER JOIN `taggings` ON `taggings`.`taggable_id` = `posts`.`id` AND `taggings`.`taggable_type` = ? SET `title` = ? WHERE `taggings`.`tag_id` = ?
[[""title"", ""rofl""], [""taggable_type"", ""Post""], [""tag_id"", 1]]
```
Any ideas?","1","2015-05-30T16:24:40Z"
"246455","17929","107102872","1529387","sgrif","Blech... I basically see three options here, then.
- Move the behavior to the connection adapter
- Add a predicate like `set_appears_before_joins?` to the connection adapter
- Not use binds here","1","2015-05-31T00:12:32Z"
"246456","17929","149692220","1529387","sgrif","This should be fixed in https://github.com/rails/rails/commit/cbcdecd2c55fca9613722779231de2d8dd67ad02, as the statement will no longer be cached.","1","2015-10-20T20:26:32Z"
"246457","17930","92324520","1080678","eileencodes","@tgxworld Thanks for fixing. Do you know when this stopped working? Was just curios if you already did a bisect.","1","2015-04-13T11:47:18Z"
"246458","17930","92329549","4335742","tgxworld","@eileencodes I didn't do a bisect for this one as I didn't want to guess which version broke it. I fixed this by looking along the callstack of the request and seeing where the trailing slash was being removed.","1","2015-04-13T12:06:46Z"
"246459","17930","97830404","4335742","tgxworld","@eileencodes Instead of trying to keep the trailing slash in `ORIGINAL_PATH_INFO`, do you think it'll be better to just update `current_page?` to ignore the trailing slash in the url strings? `/pages/` vs `/pages` has the same semantic if we're just concerned with whether we're currently on the right page.
cc/ @rafaelfranca ","1","2015-04-30T15:07:30Z"
"246460","17930","98568316","47848","rafaelfranca","> do you think it'll be better to just update current_page? to ignore the trailing slash in the url strings?
Seems good","1","2015-05-04T02:20:19Z"
"246461","17930","99280829","4335742","tgxworld","@rafaelfranca I ran into problems with how I would add a test for this. `current_page?` works correctly but the trailing slash is removed as a result of what ActionPack does to the request. Should I be adding an integration tests under ActionView here?
Thank you in advance!","1","2015-05-06T01:21:41Z"
"246462","17931","92254716","1144873","greysteil","@senny - I presume this is the right approach in the absence of migration versioning?","1","2015-04-13T07:45:18Z"
"246463","17931","92255250","5402","senny",":+1: applied without the CHANGELOG entry. We don't do them for documentation changes.
@greysteil Thank you for your work :yellow_heart: ","1","2015-04-13T07:49:25Z"
"246464","17931","92258266","5402","senny","Backported to `4-2-stable`. Stable docs will update with the next `4.2.x.` release.","1","2015-04-13T07:57:21Z"
"246465","17934","92562224","1529387","sgrif","@zzak WDYT? I think this is a generally decent convention, but not sure about having it in the docs like this.","1","2015-04-14T02:15:03Z"
"246466","17934","92586435","277819","zzak","It's probably good that we have a recommended way for doing this in the guides.","1","2015-04-14T03:35:55Z"
"246467","17934","92659072","5402","senny","Related to #16835, #11761 and #14208.
/cc @fxn ","1","2015-04-14T07:03:12Z"
"246468","17934","92668258","3387","fxn","Unsure about this addition. It goes against the true idea of migrations, which is that they are transient and expected to be deleted.","1","2015-04-14T07:13:50Z"
"246469","17934","92974447","50139","smathy","@fxn, this is not really an addition, it's a restoration of something that was taken out because the examples given were faulty.
Even with idea of transient migrations, the use case is still valid. A transaction does not immediately disappear, and yet a model or code in a model that a migration depends on can be removed at any time. Obviously the longer the migration is being used, the more likely the problem is to occur, but especially with migrations that remove things, these sorts of problems often arise for the very next user of that migration.","1","2015-04-14T16:49:02Z"
"246470","17934","93567859","3387","fxn","I see the theoretical issue. But in practice, if you follow that workflow discipline the issue appears so rarely that I don't think Rails has to endorse this practice. The remote chance does not justify the cost for my taste.
If the guide says this, it means we mean it, it means that's what we recommend people to do, and it is what the core team would do in their own projects. That is not the case.
That's not to say you have to see it the same way, you may prefer to be that defensive as a rule and enforce that in your own projects. That'd be of course fine.
Thanks for the patch anyway!","1","2015-04-15T20:59:24Z"
"246471","17934","93571119","50139","smathy","Hey thanks, makes sense.
Followup question - are there existing issues about making those workflow disciplines (I assume you're referring to the idea of transient migrations) a clear recommendation in the migration guide? I wasn't able to find anything clear in the guides taking that stance, only a hint of it in the Schema Dump section.","1","2015-04-15T21:12:54Z"
"246472","17934","93648551","3387","fxn","I believe right now the only spot is the header of [schema dumps](https://github.com/rails/rails/blob/master/activerecord/lib/active_record/schema_dumper.rb#L59-L69), but yes, this guide should include a section about it.","1","2015-04-16T05:40:43Z"
"246473","17935","92491875","200498","arjes","This spec isn't failing locally, reopening.","1","2015-04-13T20:40:16Z"
"246474","17935","92561845","1529387","sgrif","Please squash into a single commit","1","2015-04-14T02:11:59Z"
"246475","17935","92561851","1529387","sgrif","/cc @senny ","1","2015-04-14T02:12:04Z"
"246476","17935","92796486","200498","arjes","@sgrif I'd like some more feedback on a few of your comments before I re-submit with the updates. Thanks for the feedback.","1","2015-04-14T12:37:01Z"
"246477","17935","94911227","200498","arjes","Squashed & Rebased. Waiting for feedback on remaining items.","1","2015-04-21T19:19:53Z"
"246478","17935","149731158","1529387","sgrif","Sorry to close after all of this, but I just realized this is against 4-2-stable. Can you re-open against master? ","1","2015-10-20T23:23:24Z"
"246479","17936","92561572","1529387","sgrif","Thanks for the patch, but this causes the tests to fail, and is ultimately a cosmetic change which we do not accept.","1","2015-04-14T02:08:45Z"
"246480","17937","92678726","6321","pixeltrix","@y-yagi thanks!","1","2015-04-14T07:45:30Z"
"246481","17937","92685253","987638","y-yagi","@pixeltrix Thanks!","1","2015-04-14T08:05:20Z"
"246482","17937","93019866","833383","arthurnn",":+1: ","1","2015-04-14T18:57:53Z"
"246483","17938","92595948","386234","yuki24","For some reason the build status didn't show up here, but [it's green :white_check_mark: on travis](https://travis-ci.org/rails/rails/builds/58384462).","1","2015-04-14T04:42:44Z"
"246484","17938","92748218","522155","kirs","Nice catch! Looks good for me.","1","2015-04-14T10:17:22Z"
"246485","17938","92985908","47848","rafaelfranca","@carlosantoniodasilva :shipit: ","1","2015-04-14T17:18:24Z"
"246486","17938","92986047","26328","carlosantoniodasilva","thanks! :green_heart::yellow_heart::heart::blue_heart::purple_heart:","1","2015-04-14T17:18:45Z"
"246487","17939","92793497","1034","matthewd","Err, why bump the dependency?
It's a security release, so there aren't many good reasons for someone to want to run 2.2.1... but we're not the Version Police. :-1:","1","2015-04-14T12:30:32Z"
"246488","17939","92794972","10766","morgoth","I believe this bump will be required for https://github.com/rails/rails/pull/19752","1","2015-04-14T12:33:25Z"
"246489","17939","92795349","350807","kaspth","@matthewd We've deprecated `alias_method_chain` in favor of prepend, but there was bug when calling super which means we wouldn't be able to follow through with the recommendation. So, we update the version.","1","2015-04-14T12:34:07Z"
"246490","17939","92795927","1034","matthewd","@kaspth that's why we required 2.2.1, not 2.2.2, though.. right?","1","2015-04-14T12:35:30Z"
"246491","17939","92796224","1034","matthewd","(or was that a different bug?)","1","2015-04-14T12:35:58Z"
"246492","17939","92796560","350807","kaspth","No, 2.2.1 caused a segmentation fault with some form of keyword arguments (right, @eileencodes?).","1","2015-04-14T12:37:33Z"
"246493","17939","92806838","1080678","eileencodes","Yea 2.2.1 was causing a segmentation fault ","1","2015-04-14T12:51:52Z"
"246494","17939","92818098","2415484","jonatack","[http://svn.ruby-lang.org/repos/ruby/tags/v2_2_2/ChangeLog](http://svn.ruby-lang.org/repos/ruby/tags/v2_2_2/ChangeLog)
```
Mon Apr 13 00:16:32 2015 Nobuyoshi Nakada <nobu@ruby-lang.org>
* vm_eval.c (vm_call_super): search next super class from the
original class, to get rid of infinite recursion with
prepending. a patch by Seiei Higa <hanachin AT gmail.com> at
[ruby-core:68434]. [ruby-core:68093] [Bug #10847]
Mon Apr 13 00:09:48 2015 Koichi Sasada <ko1@atdot.net>
* class.c (rb_prepend_module): need a WB for klass -> origin.
```
","1","2015-04-14T13:10:10Z"
"246495","17939","92818987","2415484","jonatack","[https://bugs.ruby-lang.org/issues/10847](https://bugs.ruby-lang.org/issues/10847)","1","2015-04-14T13:12:44Z"
"246496","17939","92823667","2415484","jonatack","The bug fix appears to have been backported to the `ruby_2_2` and `ruby_2_1` branches.","1","2015-04-14T13:18:36Z"
"246497","17939","92831626","1034","matthewd",":+1:, if we're actually depending on the newer version / about to depend on the newer version, this is fine. My issue was that the PR originally presented as ""hey there's a new version, let's require it"" with no justification / explanation.","1","2015-04-14T13:25:52Z"
"246498","17940","92582241","2415484","jonatack","and #19753 too :smile:","1","2015-04-14T03:27:31Z"
"246499","17941","92657308","5402","senny","@yuki24 thank you :yellow_heart: ","1","2015-04-14T06:57:43Z"
"246500","17941","92658114","2415484","jonatack","Cool :+1: ","1","2015-04-14T07:01:34Z"
"246501","17941","92986568","47848","rafaelfranca","I think @sgrif rejected something similar","1","2015-04-14T17:19:42Z"
"246502","17941","92988577","1529387","sgrif","Yes. I don't have the original PR, but the reasoning basically comes down to:
- This means that types can no longer cast to/from `Set`, and reasonably work with `where` (we already have this problem for array/json types on pg, would rather not expand it)
- This adds precedent for every other `Enumerable`, and we can't target `Enumerable` directly.
- You shouldn't be getting a `Set` unexpectedly, and calling `#to_a` when you know you have a `Set` is reasonable.","1","2015-04-14T17:24:20Z"
"246503","17941","92991605","386234","yuki24","@sgrif So why not just adding `SetHandler `? `#to_a` doesn't work in the example below:
```ruby
Author.where(id: id_or_set_of_ids)
```
I use `Set` a lot because it's much faster than `Array`.","1","2015-04-14T17:36:57Z"
"246504","17941","92994360","47848","rafaelfranca","Found it https://github.com/rails/rails/issues/18723","1","2015-04-14T17:47:30Z"
"246505","17941","93002103","1529387","sgrif","> `#to_a` doesn't work in the example below:
Why not? Array has a to_a method. It seems like
```
Author.where(id: id_or_set_of_ids.to_a)
```
should work just fine?
> I use `Set` a lot because it's much faster than `Array`.
Sure, but converting a set to an array after doing the work in this case is a relatively cheap operation, especially when you're about to do a database operation. Ultimately one of the things I'd like to do is expose a public API that would let you do this in your own app if it occurs often enough, but I don't like having this in core because it removes the ability for types to use `Set` as a value with meaning other than a placeholder for an array.","1","2015-04-14T18:05:45Z"
"246506","18054","6499156","426690","softwaregravy","@carlosantoniodasilva
> this will raise more confusion than just raising an exception when the name gets too long
I disagree. As a user who hit this on unnamed indexes (auto-named), it was incredibly confusing because at the time I didn't know how Rails named indexes. Because of this we now always supply names to our indexes so we don't get in this mess again. Shame on me for having wordy table and column names.
> This will force the user to give the index a proper :name.
the alternative is that Rails chooses a bad one that may make your life more difficult down the road
IMHO, the name (manual or auto-generated) should be validated as 5 characters less than the actual max. This will prevent rails from throwing up when certain migrations would cause them to go over the limit by prefixing ""temp_"".
Having an index which is 59-64 characters long is an error, it's just a matter of how and when you hit it. This argument put forth on this thread is that it is better to catch the error when trying to create the index in the first place than wait for it to blow up later.","1","2012-06-22T02:11:13Z"
"246507","18054","6506891","26328","carlosantoniodasilva","> I disagree. As a user who hit this on unnamed indexes (auto-named), it was incredibly confusing because at the time I didn't know how Rails named indexes.
Not sure I was clear enough, I believe that having two indexes being automatically truncated with the same name may be confusing for us developers when catching such issue.
> This will prevent rails from throwing up when certain migrations would cause them to go over the limit by prefixing ""temp_"".
I don't see Rails prefixing things with `temp_`.
> Having an index which is 59-64 characters long is an error, it's just a matter of how and when you hit it. This argument put forth on this thread is that it is better to catch the error when trying to create the index in the first place than wait for it to blow up later.
Exactly, the idea is that Rails will raise in case the index name gets longer than that, to avoid possible problems later. This should happen *during migration* time, not later on. So, when you add an index, and run your migration, it should blow up with an exception saying the name is too long, no matter if it was automatically generated or manually added. If it was manually, you just go there and change. If it was automatically, you have to add a manual `:name`. That's my thought, of course there may be other approaches, but I feel ok with that.","1","2012-06-22T12:52:21Z"
"246508","18054","6511829","426690","softwaregravy","RE truncation
seems we're having 2 conversations: 1) is it really a problem? 2) is the fix what we should be doing?
I am trying to assert that it is really a problem, and that we shouldn't leave what's there. I wasn't specifically trying to defend the solution of truncation.
> I don't see Rails prefixing things with temp_.
I'll have to go look. Maybe it's postgres / mysql itself that does this? Regardless, I hit this problem not when creating an index but much later when changing the table and the index got auto-renamed to temp_[previous name here]. So we need index names to be shorter than any auto-renaming done under the hood.","1","2012-06-22T16:18:44Z"
"246509","18054","6525291","26328","carlosantoniodasilva","@softwaregravy agree with you. We definitely need to check if the current implementation is really a problem or not, and in my opinion the idea of raising when you run the migration is ok.
I'm not aware of an auto-rename feature in these databases, so if you want/can take a look it'd be great. Thanks!","1","2012-06-23T14:21:41Z"
"246510","18054","9009916","840464","frodsan","@carlosantoniodasilva any news on this? Seems like a feature request.","1","2012-09-30T01:28:54Z"
"246511","18054","9853320","426690","softwaregravy","@carlosantoniodasilva So, I'm sorry this took so long. Here's an example reproducing the error I was describing. https://github.com/softwaregravy/RailsIndexErrorExample
In my experience, this comes up when you do not specifically name your indices, but let rails name them. When you do a compound index over 2-3 columns, it gets much more likely to get to the 59 character limit.","1","2012-10-29T00:11:40Z"
"246512","18054","10630915","43041","danielfone","I ran into this problem just days ago (and coincidentally, codetriage.com sent me to this issue).
I believe this boils down to the belief that **rails shouldn't auto-generate index names that are longer than the allowed length for the adapter**. Whether or not this belief is shared, I think the behaviour this pull request introduces is dangerous for the reason outlined above by @Fryguy and reiterated by @carlosantoniodasilva.
Perhaps we close this PR and alternative suggestions can be raised in a separate issue?
For reference, the current behaviour is:
```
vagrant@rails-dev-box:/vagrant/index_test$ bundle exec rails generate scaffold AReallyReallyReallyLongModelName another_long_model_name:references
invoke active_record
create db/migrate/20121122104817_create_a_really_really_really_long_model_names.rb
[...]
vagrant@rails-dev-box:/vagrant/index_test$ bundle exec rake db:migrate
== CreateAReallyReallyReallyLongModelNames: migrating ========================
-- create_table(:a_really_really_really_long_model_names)
rake aborted!
An error has occurred, this and all later migrations canceled:
Index name 'index_a_really_really_really_long_model_names_on_another_long_model_name_id' on table 'a_really_really_really_long_model_names' is too long; the limit is 64 characters
[...]
/vagrant/rails/activerecord/lib/active_record/railties/databases.rake:48:in `block (2 levels) in <top (required)>'
Tasks: TOP => db:migrate
(See full trace by running task with --trace)
","1","2012-11-22T11:04:35Z"
"246513","18127","141827540","199","jeremy","Thank you ?","1","2015-09-20T19:58:12Z"
"246514","18127","141888710","5402","senny","@kamipo @jeremy thank you :yellow_heart: ","1","2015-09-21T06:29:09Z"
"246515","18127","143421418","78","indirect",":tada: :confetti_ball: ","1","2015-09-26T11:05:30Z"
"246516","18130","112160297","833383","arthurnn","Honestly, I think we can remove that `@hi` definition.
It is there since the first commit of rails https://github.com/rails/rails/blame/8925e89/actionpack/test/controller/action_pack_assertions_test.rb#L292 . I would say, nowadays, that it is just assert nothing.","1","2015-06-15T18:19:37Z"
"246517","18131","98776438","47848","rafaelfranca","cc @matthewd ","1","2015-05-04T16:48:34Z"
"246518","18131","98776971","1034","matthewd","It seems a bit silly for us to copy the whole original hash, only to then delete all its keys as we ""repopulate"" it. But I guess that's necessary to maintain ivars, etc.","1","2015-05-04T16:51:14Z"
"246519","18132","112160610","833383","arthurnn","What was the issue? do you have the stacktrace?
thanks","1","2015-06-15T18:20:43Z"
"246520","18132","112161691","13248","steved","Without `load_config`, the migrations paths are only set to that applications' paths so this task won't properly exit if any engines have pending migrations. Plus its inconsistent with other tasks in this file.","1","2015-06-15T18:26:06Z"
"246521","18132","112165115","833383","arthurnn","thanks","1","2015-06-15T18:37:21Z"
"246522","18133","98838164","47848","rafaelfranca","Could you explain what is the use case and why you don't use a webserver like nginx to do this?","1","2015-05-04T20:20:43Z"
"246523","18133","98850671","31698","eliotsykes","Production Heroku deploy without Apache/nginx. There’s a CDN fronting all requests to the app. `ActionDispatch::Static` serves assets to the CDN.
The app has one other deployment scenario, as a PhoneGap app, which, in this case, it is easier to have its `index.html` be at `public/index.html`.
The Rails app has a different `index.html` which isn’t named `index.html`, its named `index.rails.html`.
A `static_index` option simplifies using this app’s public directory as both a web app and a PhoneGap/Cordova app:
```
config.static_index = ""index.rails""
```
(The current workaround is to use rack-rewrite.)
","1","2015-05-04T21:10:14Z"
"246524","18133","106168988","47848","rafaelfranca","Could you add a CHANGELOG entry?","1","2015-05-28T04:48:43Z"
"246525","18133","106235215","31698","eliotsykes","Thanks @rafaelfranca, sure thing, jump to added CHANGELOG entries at links below:
- [railties/CHANGELOG.md](https://github.com/eliotsykes/rails/commit/3ff39494cdea67502dbd6465358eca3e14a84d6b#diff-1846d4882fa63eb5b1271541995cbfdcR1)
- [actionpack/CHANGELOG.md](https://github.com/eliotsykes/rails/commit/3ff39494cdea67502dbd6465358eca3e14a84d6b#diff-c909acd0bcbfca7336cca93598e7c65aR1)","1","2015-05-28T08:46:47Z"
"246526","18134","115872783","4912","sikachu","@egilburg @carlosantoniodasilva would you mind give this PR another look and maybe merge it? Thanks!","1","2015-06-26T20:30:50Z"
"246527","18134","115959022","47848","rafaelfranca","Awesome! Thank you @sikachu ","1","2015-06-27T04:45:36Z"
"246528","18135","98860164","36869","imanel","/cc @matthewd ","1","2015-05-04T21:57:05Z"
"246529","18135","98865567","36869","imanel","As for deprecation notice - it shows for anyone using this flag since [I18n v0.5.1](https://github.com/svenfuchs/i18n/commit/68e9a371726d133b34b291642ba63b1bbdbe106f) that was included in [Rails 3.0.6](https://rubygems.org/gems/actionpack/versions/3.0.6).","1","2015-05-04T22:12:50Z"
"246530","18137","98889225","15688","thedarkone","I think there are plans for Rails to begin using `concurrent-ruby` gem, but we aren't there yet. Adding a new `gem` dependency to Rails is a big step...","1","2015-05-05T00:12:33Z"
"246531","18137","98942916","47848","rafaelfranca","@thedarkone we already discussed it and we are good to include this gem as dependency. But, apart for that we are not making the gem a rails dependency with this change, we are just using it in rails tests.
@qingwenp I'm afraid that we can't remove the Latch class without deprecating so, could you deprecate it?","1","2015-05-05T04:08:44Z"
"246532","18137","98943078","47848","rafaelfranca","@qingwenp the tests are also broken. Could you take a look?","1","2015-05-05T04:11:09Z"
"246533","18137","101003471","10526226","qingwenp","@rafaelfranca I added the latch.rb back, and I guess now the tests are passing?","1","2015-05-11T18:15:21Z"
"246534","18137","101018949","3827363","dyxliang","@rafaelfranca I am also working with qingwenp on this change, if we remove the latch.rb, how do we go about deprecating it?","1","2015-05-11T19:07:24Z"
"246535","18137","117910600","3303032","ianks","Are we planning on using concurrent-ruby-ext as well? It offers significant performance improvements, especially wrt to atomic data types. Another side-bonus is it will off the concurrent-ruby gem a ton of much needed battle testing for free ?","1","2015-07-02T05:27:37Z"
"246536","18137","117911116","3303032","ianks","Also, we can probably add some alias methods at concurrent-ruby to match the current latch API","1","2015-07-02T05:29:03Z"
"246537","18137","121327880","47848","rafaelfranca","Closed by #20866","1","2015-07-14T18:14:36Z"
"246538","18138","104040909","833383","arthurnn","thanks.","1","2015-05-20T21:13:19Z"
"246539","18139","99365845","5402","senny","@mohnish good catch. Thank you :yellow_heart: ","1","2015-05-06T08:02:02Z"
"246540","18139","99533091","138171","mohnish",":green_heart: ","1","2015-05-06T16:42:13Z"
"246541","18142","98987172","1034","matthewd","This feels like we're actively neutering the method-redefined warning, whereas in other places, I think we're more often just acknowledging that we know we're knowingly overriding an existing method (like [here](https://github.com/rails/rails/blob/918aa6e87813c5c7687e5d460c5cd62ba3919536/activesupport/lib/active_support/core_ext/class/attribute.rb#L85)).
I guess that leaves me curious about exactly which methods were being redefined, when we suppressed the warning with 6b135f7e465a6cd1c8162432f6e0caa820316c44.","1","2015-05-05T08:01:48Z"
"246542","18142","99000297","6321","pixeltrix","@matthewd looking at #55 it seems that the original intention was to clean up the warnings - I don't think much thought was given to why the warnings were there. In this case I'm not even sure where `class_attribute` is being called from - I'll investigate to see why it's being called twice.","1","2015-05-05T09:00:21Z"
"246543","18142","99393987","6321","pixeltrix","@matthewd it turns out that the warnings are due to [this block of code][1] in `sprockets-rails`. Obviously this should be fixed there so that deals with the warnings, however the block passed to new is still only called the once so there's still that question to answer.
[1]: https://github.com/rails/sprockets-rails/blob/master/lib/sprockets/railtie.rb#L150-L160","1","2015-05-06T09:18:42Z"
"246544","18142","99694337","26328","carlosantoniodasilva","I don't think we have any specific behavior defined for multiple applications being instantiated - I know we'd like to get there some day, but I haven't seen a case either.
I'm fine with trying to remove the methods before defining them again to avoid the warnings.","1","2015-05-07T03:00:28Z"
"246545","18143","104331927","1201508","keepcosmos","@senny Could you give me feedback? I think it is just missing option. ","1","2015-05-21T16:01:03Z"
"246546","18143","105423039","5402","senny","@keepcosmos added a few minor comments. Also please make sure that the PR only includes a single commit. Currently you also have a merge commit included: ""Merge branch 'master' into add-extend-option-on-habtm"" (64793c17fd7d7b4cdddde1187d71230a4775f3fe).","1","2015-05-26T07:21:04Z"
"246547","18143","105522791","1201508","keepcosmos","@senny I accept your advice. Thanks! :smile: ","1","2015-05-26T13:21:12Z"
"246548","18143","105523286","5402","senny","@keepcosmos thank you :yellow_heart: ","1","2015-05-26T13:23:39Z"
"246549","18144","98995672","3387","fxn",":+1: ","1","2015-05-05T08:43:02Z"
"246550","18144","99355857","3387","fxn","@kamipo do you see these queries anywhere logged?","1","2015-05-06T07:36:32Z"
"246551","18144","99364474","12642","kamipo","@fxn I wrote the `log_statement = 'all'` in `postgresql.conf`, then watch the server side query log file.
Before:
```
LOG: execute <unnamed>: SELECT t.oid, t.typname
FROM pg_type as t
WHERE t.typname IN ('int2', 'int4', 'int8', 'oid', 'float4', 'float8', 'bool')
LOG: execute <unnamed>: SELECT t.oid, t.typname, t.typelem, t.typdelim, t.typinput, r.rngsubtype, t.typtype, t.typbasetype
FROM pg_type as t
LEFT JOIN pg_range as r ON oid = rngtypid
WHERE
t.typname IN ('int2', 'int4', 'int8', 'oid', 'float4', 'float8', 'text', 'varchar', 'char', 'name', 'bpchar', 'bool', 'bit', 'varbit', 'timestamptz', 'date', 'money', 'bytea', 'point', 'hstore', 'json', 'jsonb', 'cidr', 'inet', 'uuid', 'xml', 'tsvector', 'macaddr', 'citext', 'ltree', 'interval', 'path', 'line', 'polygon', 'circle', 'lseg', 'box', 'time', 'timestamp', 'numeric')
OR t.typtype IN ('r', 'e', 'd')
OR t.typinput::varchar = 'array_in'
OR t.typelem != 0
LOG: statement: SHOW TIME ZONE
LOG: statement: SELECT 1
LOG: execute <unnamed>: SELECT COUNT(*)
FROM pg_class c
LEFT JOIN pg_namespace n ON n.oid = c.relnamespace
WHERE c.relkind IN ('r','v','m') -- (r)elation/table, (v)iew, (m)aterialized view
AND c.relname = 'accounts'
AND n.nspname = ANY (current_schemas(false))
```
After:
```
LOG: execute <unnamed>: SELECT t.oid, t.typname
FROM pg_type as t
WHERE t.typname IN ('int2', 'int4', 'int8', 'oid', 'float4', 'float8', 'bool')
LOG: execute <unnamed>: SELECT t.oid, t.typname, t.typelem, t.typdelim, t.typinput, r.rngsubtype, t.typtype, t.typbasetype
FROM pg_type as t
LEFT JOIN pg_range as r ON oid = rngtypid
WHERE
t.typname IN ('int2', 'int4', 'int8', 'oid', 'float4', 'float8', 'text', 'varchar', 'char', 'name', 'bpchar', 'bool', 'bit', 'varbit', 'timestamptz', 'date', 'money', 'bytea', 'point', 'hstore', 'json', 'jsonb', 'cidr', 'inet', 'uuid', 'xml', 'tsvector', 'macaddr', 'citext', 'ltree', 'interval', 'path', 'line', 'polygon', 'circle', 'lseg', 'box', 'time', 'timestamp', 'numeric')
OR t.typtype IN ('r', 'e', 'd')
OR t.typinput::varchar = 'array_in'
OR t.typelem != 0
LOG: statement: SHOW TIME ZONE
LOG: statement: SELECT 1
LOG: execute <unnamed>: SELECT COUNT(*)
FROM pg_class c
LEFT JOIN pg_namespace n ON n.oid = c.relnamespace
WHERE c.relkind IN ('r','v','m') -- (r)elation/table, (v)iew, (m)aterialized view
AND c.relname = 'accounts'
AND n.nspname = ANY (current_schemas(false))
```","1","2015-05-06T07:58:51Z"
"246552","18144","99377810","1034","matthewd","A lot of these strings look like they could otherwise be frozen. Do we care about these spaces enough to warrant spending cycles cleaning them up?","1","2015-05-06T08:28:21Z"
"246553","18144","99389945","3387","fxn","I assumed in my thumbs up that they appeared in the app logs with more or less normal settings, but IMO that seems too unusual to deserve doing this.","1","2015-05-06T09:03:24Z"
"246554","18144","99415313","3387","fxn","Yeah, let's do nothing. Appreciate the patch anyway @kamipo.","1","2015-05-06T10:46:10Z"
"246555","18346","116099397","47848","rafaelfranca","@kaspth :shipit:, AR failures should not be caused by this PR.","1","2015-06-27T16:52:03Z"
"246556","18346","116132153","350807","kaspth","@rafaelfranca Alright, :see_no_evil:","1","2015-06-27T20:18:14Z"
"246557","18346","116132906","22282","davetron5000","Thanks everyone! ","1","2015-06-27T20:20:01Z"
"246558","18346","116133575","350807","kaspth","@davetron5000 Thanks for bringing this to our attention. Will you be following this up on the responders gem? :smile:","1","2015-06-27T20:21:32Z"
"246559","18346","116140108","22282","davetron5000","Yup","1","2015-06-27T20:51:10Z"
"246560","18403","108907528","109640","uberllama","What's funny is I actually like API uniformity. So my comment was more in context of disagreeing with uniq being removed from Relation than pluck being added to Enumerable. I don't think there's anything goblinesque about consistency. ?","1","2015-06-04T13:58:07Z"
"246561","18403","108913857","2741","dhh","I haven't dug in closer to the #uniq case. Will have another look at that.
But I don't think just because we can make reasonable trade-offs in one
case, like #pluck, that we necessarily can too in all other like-array
cases.
On Thu, Jun 4, 2015 at 3:59 PM, Yuval Kordov <notifications@github.com>
wrote:
> What's funny is I actually like API uniformity. So my comment was more in
> context of disagreeing with uniq being removed from Relation than pluck
> being added to Enumerable. I don't think there's anything goblinesque about
> consistency. [image: ?]
>
> —
> Reply to this email directly or view it on GitHub
> <https://github.com/rails/rails/pull/20350#issuecomment-108907528>.
>
","1","2015-06-04T14:26:21Z"
"246562","18403","108922024","5093358","kddeisz","It's actually more uniformity, because a lot of the relation/array duplications are also in calculations.rb. So there's that.","1","2015-06-04T14:47:50Z"
"246563","18403","109299290","8988","onomojo","Would be nice to allow the same syntax for multi column support that AR has","1","2015-06-05T13:51:48Z"
"246564","18403","109302925","350807","kaspth","@onomojo It already does: https://github.com/rails/rails/blob/master/activesupport/lib/active_support/core_ext/enumerable.rb#L82 :smile:","1","2015-06-05T14:01:24Z"
"246565","18403","109303145","5093358","kddeisz","@onomojo that was the next step here: https://github.com/rails/rails/pull/20362","1","2015-06-05T14:02:28Z"
"246566","18403","109303170","8988","onomojo","Ah ok, I was just looking at the PR. :+1: ","1","2015-06-05T14:02:36Z"
"246567","18403","112851277","29266","WizardOfOgz","I'm late to the party, but I have concerns with this addition. It seems to focus only on `Hash`s and plucking using hash keys. Should this not be implemented as `Hash#pluck` instead of `Enumerable#pluck`?
UPDATE: NM I didn't think this through clearly","1","2015-06-17T15:36:48Z"
"246568","18403","112858105","5093358","kddeisz","Plenty of things respond to [] that are both Enumerable and not hashes.
E.g. AR objects
On Wednesday, June 17, 2015, Andy Ogzewalla <notifications@github.com>
wrote:
> I'm late to the party, but I have concerns with this addition. It seems to
> focus only on Hashs and plucking using hash keys. Should this not be
> implemented as Hash#pluck instead of Enumerable#pluck?
>
> —
> Reply to this email directly or view it on GitHub
> <https://github.com/rails/rails/pull/20350#issuecomment-112851277>.
>
--
*Kevin D. Deisz*
*TrialNetworks* - part of DrugDev
Software Developer
383 Elliot Street, Suite G
Newton, MA 02464
+1 617.952.4071 x134 (office)
+1 703.615.0396 (mobile)
kdeisz@trialnetworks.com
","1","2015-06-17T15:52:19Z"
"246569","18403","112861008","29266","WizardOfOgz","NM, I wasn't thinking straight","1","2015-06-17T16:03:16Z"
"246570","18404","106651080","47848","rafaelfranca","Thanks","1","2015-05-29T01:35:22Z"
"246571","18405","106651286","47848","rafaelfranca","@mcshakes which version of Rails are you using? Because `ApplicationMailer` was added on Rails 4.2","1","2015-05-29T01:37:37Z"
"246572","18405","106651968","8164007","mcshakes","Ahh that could be. I'm using:
$ rails -v
Rails 4.1.4
Let me change versions and run the same generator","1","2015-05-29T01:40:07Z"
"246573","18405","106663585","8164007","mcshakes","So, when:
$ rails -v
Rails 4.2.1
I get:
$ bin/rails generate mailer UserMailer
create app/mailers/user_mailer.rb
create app/mailers/application_mailer.rb
invoke haml
create app/views/user_mailer
create app/views/layouts/mailer.text.haml
create app/views/layouts/mailer.html.haml
invoke minitest
create test/mailers/user_mailer_test.rb
create test/mailers/previews/user_mailer_preview.rb
My mistake, I was totally wrong. When using older versions, the application_mailer doesn't show up and you get the results I did. Thanks anyway peeps!","1","2015-05-29T02:43:28Z"
"246574","18405","106663949","47848","rafaelfranca","Thank you. You are welcome","1","2015-05-29T02:47:03Z"
"246575","18406","106752307","5402","senny","@arunagw thanks.","1","2015-05-29T09:10:20Z"
"246576","18408","112467797","833383","arthurnn","thoughts @rafaelfranca , as you merged the main PR.","1","2015-06-16T15:18:00Z"
"246577","18408","115390023","245662","huoxito","ops should have asked earlier forgot about this, @rafaelfranca any chance this could still get on 4.2.3?","1","2015-06-25T20:36:47Z"
"246578","18408","115396505","47848","rafaelfranca","I don't want to release a new RC for 4.2.3 since I was just releasing the final version. I'll release a new version on July 25, so maybe it is fine to wait?","1","2015-06-25T20:58:10Z"
"246579","18408","115398138","245662","huoxito","sure no worries thanks!","1","2015-06-25T21:04:23Z"
"246580","18409","107422021","1909242","ronakjangir47","/cc @rafaelfranca @arthurnn ","1","2015-06-01T12:26:21Z"
"246581","18409","107629766","1909242","ronakjangir47","@rafaelfranca Done with changes, please let me know if anything!","1","2015-06-01T16:37:26Z"
"246582","18409","107631880","1909242","ronakjangir47","Thanks @rafaelfranca ","1","2015-06-01T16:45:00Z"
"246583","18412","1552436","213","chuyeow","This is quite a special edge case because of the way BigDecimals are JSON-encoded as strings: https://github.com/rails/rails/blob/master/activesupport/lib/active_support/json/encoding.rb#L189
A more generic implementation would test whether the value is already surrounded by double quotes before adding the double quotes in `attrs << %{data-#{k.to_s.dasherize}=""#{v}""}` imo, but your version works so I can't argue :)
+1","1","2011-07-12T07:16:37Z"
"246584","18412","1552678","33329","davout","+1 for fixing the serialization directly at the JSON serialization level instead of this.","1","2011-07-12T08:15:57Z"
"246585","18412","1552738","124430","dmitriy-kiriyenko","+1 to that's JSON issue.","1","2011-07-12T08:30:58Z"
"246586","18412","1552797","73998","Bodacious","As far as I can see (from the comments on BigDecimal#as_json), decimal values need to be written as JSON strings.
``` ruby
# A BigDecimal would be naturally represented as a JSON number. Most libraries,
# however, parse non-integer JSON numbers directly as floats. Clients using
# those libraries would get in general a wrong number and no way to recover
# other than manually inspecting the string with the JSON code itself.
```
If we change this behaviour, wont it result in invalid values for decimal attributes in situations like:
``` ruby
@user.to_json # => ""{\""username\"":\""bodacious\"",\""decimal_atttibute\"": -123.456}""
```
Checking for double quotes and removing them would work but it's extra effort - As far as I can see, BigDecimals don't need to be encoded to JSON in this case","1","2011-07-12T08:43:17Z"
"246587","18412","1552807","213","chuyeow","Yes, I agree with Bodacious that we shouldn't change the JSON serialization of BigDecimal since it'd break other stuff.","1","2011-07-12T08:46:23Z"
"246588","18412","1552889","33329","davout","BigDecimal's are serialized as JSON strings instead of numerics as they should.
IMO the rationale behind it is flawed because it's just protecting developers against themselves.
It also breaks the principle of least surprise (Floats serialized as numerics, BigDecimals serialized as strings) which leads to surprising behaviour in other places.","1","2011-07-12T09:05:24Z"
"246589","18412","1553902","73998","Bodacious","On the subject of the Principle of Least Surprise - I opened this (related) issue a couple of weeks ago
https://github.com/rails/rails/issues/1914
Any feedback on that would be appreciated too","1","2011-07-12T12:35:31Z"
"246590","18412","1959494","73998","Bodacious","Still seeing this bug - I expected this to be acknowledged before Rails 3.1 was released?
Anybody else have any feedback?","1","2011-08-31T17:09:34Z"
"246591","18412","2301596","739974","CodeMeister","Appreciate it's a bit special case but it's a recurring problem.
Would like to see this patched in next release.
+1","1","2011-10-05T18:45:41Z"
"246592","18412","5400056","27786","steveklabnik","Since #1914 was closed, I'm imagining that this one should be, too. It also doesn't merge cleanly any more.","1","2012-04-28T20:45:35Z"
"246593","18412","5400819","47848","rafaelfranca","I guess not. I have this issue too.
cc/ @jeremy thoughts?","1","2012-04-28T22:26:16Z"
"246594","18412","5402326","199","jeremy","Agreed. Serializing BigDecimal as a string is ""more correct"" but far less useful.","1","2012-04-29T03:26:49Z"
"246595","18412","5402356","47848","rafaelfranca","Should we change the JSON serialization or the TagHelper?","1","2012-04-29T03:33:16Z"
"246596","18432","120755316","2741","dhh","Hey, hey. Yeah, all I wanted was that the cache we're already using in production for template digests to be used on a per-request basis in development. So the first lookup of a template within a request in development is computed, all subsequent lookups are not. ?","1","2015-07-12T19:21:44Z"
"246597","18432","122589798","350807","kaspth","@dhh Boom, got it :+1:. Way easier once I figured out there was already a cache.
I'm closing and reopening for Travis to run.","1","2015-07-18T20:05:59Z"
"246598","18432","122852889","2741","dhh","Badabing! Awesome. Thanks!","1","2015-07-20T11:15:44Z"
"246599","18433","107106373","1529387","sgrif","I'm at my wits end here. I've pinged travis on Twitter, but I think we should just change the test to skip...","1","2015-05-31T01:36:04Z"
"246600","18434","107114325","4401925","yoongkang","(The build is currently failing due to 0ef7e73).","1","2015-05-31T03:21:11Z"
"246601","18435","107148887","5402","senny","@y-yagi this seems like a good idea. I'm wondering why we didn't notice that those tests are not working. I vaguely remember that we have some tests in railties that run generated test files. Could you explore to write such a test?","1","2015-05-31T09:11:42Z"
"246602","18435","107173234","987638","y-yagi","@senny Thank you for the review! I added test to run generated test files.
At that time, fixture name problem occurs, I was fixed together.
","1","2015-05-31T12:48:28Z"
"246603","18435","107751379","987638","y-yagi","@senny Thank you for the review!
Move the test to the appropriate place, and has been deleted duplicate test.","1","2015-06-02T00:15:49Z"
"246604","18435","107971244","5402","senny","@y-yagi fantastic. Thank you :yellow_heart:
I added an entry to the changelog in the merge-commit.","1","2015-06-02T14:21:30Z"
"246605","18435","107973913","987638","y-yagi","@senny Thanks!","1","2015-06-02T14:31:58Z"
"246606","18436","107174325","31698","eliotsykes","Might be of interest to @uberllama, saw your related contributions here: https://github.com/rails/rails/pull/19832#issuecomment-104674321","1","2015-05-31T13:07:19Z"
"246607","18436","109544136","12772133","michelaungthein","please.please.the best of regard to me. please","1","2015-06-06T07:33:19Z"
"246608","18436","109550674","31698","eliotsykes","Closing and reopening PR to trigger a new CI build","1","2015-06-06T08:06:40Z"
"246609","18436","109610105","109640","uberllama","Sorry was out of town last week. Definite thumbs up, tho it would be great to abstract out the config instead of directly swapping middleware. PR link?","1","2015-06-06T16:18:11Z"
"246610","18436","109619232","31698","eliotsykes","Thanks for the response @uberllama - agreed about a config option being an improvement over recreating the middleware.
Here's the changes made so far for this PR: https://github.com/rails/rails/pull/20389/files if that's what you mean for the PR link.
There's no config option yet so suggestions welcome.","1","2015-06-06T17:19:56Z"
"246611","18436","109638291","109640","uberllama","Rack::Sendfile can use a value set via config.action_dispatch.x_sendfile_header. There are a couple other middlewares that do the same. So given that precedent we should be able to define something along the lines of config.action_dispatch.accept_camelcase_params and conditionally act on that within the ParamsParser middleware instead of having to do the swap business. ","1","2015-06-06T19:11:04Z"
"246612","18436","109660304","109640","uberllama","Okay, here's what I'm thinking:
actionpack/action_dispatch/railtie.rb: Add a new config:
```ruby
require ""action_dispatch""
module ActionDispatch
class Railtie < Rails::Railtie # :nodoc:
config.action_dispatch.accept_camelcase_params = false
..
initializer ""action_dispatch.configure"" do |app|
ActionDispatch::ParamsParser.accept_camelcase_params = app.config.action_dispatch.accept_camelcase_params
```
Then within `ActionDispatch::ParamsParser`:
```ruby
mattr_accessor :accept_camelcase_params
...
def parse_formatted_parameters(env)
case strategy
...
when :json
data = ActiveSupport::JSON.decode(request.raw_post)
data = {:_json => data} unless data.is_a?(Hash)
data = Request::Utils.deep_munge(data)
data.deep_transform_keys!(&:underscore) if accept_camelcase_params
data.with_indifferent_access
...
```
Then within application.rb you can just put `config.action_dispatch.accept_camelcase_params = true`.
Haven't tested this but looks reasonable. Let me know if you want me to put together a different PR or if you're comfortable trying this out.","1","2015-06-06T23:55:43Z"
"246613","18436","111852321","31698","eliotsykes","@uberllama Sorry for the delay in responding. I'm hoping we'll get some other voices in here who can tell us yes this is something welcome for Rails or otherwise so as not to spend too much time on it.
I like the idea of having a dedicated config, though I'm not sure about the `accept_camelcase_params` name.
The param keys are transformed and in a controller it'd not be possible to use camel-case to access the parameters, you'd have to use snake-case, but the `accept_camelcase_params` sounds like you could use the camel-case names in a controller.
Something along the lines of `config.action_dispatch.transform_camel_params_to_snake` or shorter `config.action_dispatch.transform_camel_params` perhaps.","1","2015-06-14T17:21:05Z"
"246614","18453","112208510","350807","kaspth","Great. @matthewd, you know what to do :smile:","1","2015-06-15T20:55:31Z"
"246615","18481","14914883","27786","steveklabnik","It does not need to be rebased, but it does need a CHANGELOG entry, and to squash the commits.","1","2013-03-14T17:01:36Z"
"246616","18481","19105408","700373","jokklan","+1 for this feature. @aratak would you have time to finish this PR? It seems so close to being finished!","1","2013-06-07T13:01:51Z"
"246617","18481","19256784","119619","arion","+1","1","2013-06-11T11:51:14Z"
"246618","18481","21973326","124580","isaacsloan","I would love to see this merged in. 1+","1","2013-08-01T22:05:05Z"
"246619","18481","23229175","354185","robin850","@aratak : Could you please just rebase once more and squash your commits with `git rebase -i HEAD~5` and change pick with rebase apart for the first line?","1","2013-08-25T15:03:17Z"
"246620","18481","25958141","161489","Undistraction","+1","1","2013-10-09T09:38:02Z"
"246621","18481","27852158","13087","JGailor","+1","1","2013-11-06T08:53:26Z"
"246622","18481","30567060","10137","ghost","+1","1","2013-12-14T11:33:52Z"
"246623","18743","120427163","1362793","jvanbaarsen","?I think your new line is way better! :+1: /cc @rafaelfranca ","1","2015-07-10T14:48:39Z"
"246624","18743","120427278","3387","fxn","Good catch!
The reword still doesn't quite click to me, because a ""behaviour"" does not ""behave"" itself. Indeed the existing behaviour is the bug, not caused by it.
Almost there, but let's refine!","1","2015-07-10T14:49:15Z"
"246625","18743","120430194","66243","mcfiredrill","@fxn I agree, saying that a ""behaviour"" ""behaves"" is a bit redundant and kind of awkward.
How about if I change the verb ""behave"" to ""work""? I pushed a commit with the change.
Or maybe ""function"" instead of ""works""?
Or maybe even ""malfunction"" ? :sweat:
","1","2015-07-10T15:00:54Z"
"246626","18784","121996810","2741","dhh","On the API side, I think `#in_batches(of: 100).each do` is the best proposal I've seen. Then we can deprecate find_in_batches. It's definitely much nicer just to get a new relation you can work on with all the capabilities we have. If you guys can work together on that, it'd be great ?","1","2015-07-16T15:40:47Z"
"246627","18784","122069949","364548","siadat","Thank you @bogdan, @matthewd, and @dhh, I appreciate your feedback! :+1:
I renamed the method and the size option as dhh suggested, so a usage example would be:
People.in_batches(of: 100) do |relation|
relation.update_all(on_the_dance_floor: true)
end
Let me know if I need to do anything else to get this merged.","1","2015-07-16T19:53:42Z"
"246628","18784","122075305","2741","dhh","Looks good on the API front. We should follow up with deprecations of find_each and find_in_batches. ","1","2015-07-16T20:12:49Z"
"246629","18784","122113984","364548","siadat","I added deprecation warnings to `#find_each` and `#find_in_batches` method definitions, and wrapped their tests with `assert_deprecated`.
Let me know if I did anything wrong, or if there is anything else that needs to be done.","1","2015-07-16T21:50:51Z"
"246630","18784","122248777","122436","bogdan","Ok lets start:
1. `in_batches` should have a `load` option that forces or not forces objects loading to optimise number of queries. Default for `load` I suppose should be `false`. The old behaviour of `find_in_batches` can be gained with `in_batches(load: true)`.
2. `find_each` should not be deprecated. Sometimes `find_each` is better then `in_batches` and sometimes isn't. `find_each` should be implemented using `in_baches(load: true)` so that it's behaviour remain the same. I can give examples why both methods should be in place if someone needs them
3. I am not sure that `in_batches do` is good idea. At least @dhh mentioned `#in_batches.each` as the best variant and I agree with that.
4. Maybe `find_each` should be transformed to something like `with_batches.each` for consistency with (3)","1","2015-07-17T11:12:36Z"
"246631","18784","122250929","2741","dhh","Bogdan, what's the case where `find_each` is an improvement over
`in_batches.each`? Also, can you explain the `load` option a bit more? I'm
not sure I'm getting the trade-offs. I agree that `in_batches.each` is
better than `in_batches do`.
On Fri, Jul 17, 2015 at 1:13 PM, Bogdan Gusiev <notifications@github.com>
wrote:
> Ok lets start:
>
> 1.
>
> in_batches should have a load option that forces or not forces objects
> loading to optimise number of queries. Default for load I suppose
> should be false. The old behaviour of find_in_batches can be gained
> with in_batches(load: true).
> 2.
>
> find_each should not be deprecated. Sometimes find_each is better then
> in_batches and sometimes isn't. find_each should be implemented using in_baches(load:
> true) so that it's behaviour remain the same. I can give examples why
> both methods should be in place if someone needs them
> 3.
>
> I am not sure that in_batches do is good idea. At least @dhh
> <https://github.com/dhh> mentioned #in_batches.each as the best
> variant and I agree with that.
> 4.
>
> Maybe find_each should be transformed to something like
> with_batches.each for consistency with (3)
>
> —
> Reply to this email directly or view it on GitHub
> <https://github.com/rails/rails/pull/20899#issuecomment-122248777>.
>
","1","2015-07-17T11:28:50Z"
"246632","18784","122252870","122436","bogdan","Ok All examples:
### Example 1
Here we want to update all records in batches because update whole table at once will lock table for writing:
``` ruby
User.in_batches.each do |relation|
relation.update_all(""disabled = true"")
end
```
### Example 2
Here we want to touch individual record at ruby level because of some logic (e.g. chain touch), but we want to improve performance with transaction for each batch, so can't use `find_each`.
`load: true` here reduces number of queries because we call `relation.last` inside `in_batches` and it makes 2 queries per batch iteration while `load: true` will force loading and `relation.last` will be performed by ruby on loaded relation.
``` ruby
User.in_batches(load: true).each do |relation|
User.transaction do
relation.each(&:touch)
end
end
```
### Example 3
Here we don't want to process each batch individually and only care about iterating for each record. `find_each` used as a shortcut to `in_batches.each { |r| r.each { ... }}`:
``` ruby
data = User.find_each.map do |user|
user.attributes.slice(:id, :email, :role).to_csv
end
```
Junior ruby developer would always use last one for all 3. Which is fine but slow. So `in_batches` is positioned as something advanced.
","1","2015-07-17T11:40:57Z"
"246633","18784","122255497","2741","dhh","For example #2, this should already work: `User.in_batches.load.each`. Don't think we need another option for it. Agree on Example #3. That's a nice convenience. First example should probably be `each do |batch|`, if used in docs, but yes.","1","2015-07-17T11:56:07Z"
"246634","18784","122255815","2741","dhh","Sorry, for example #2, I meant `User.in_batches.each { |batch| transaction { batch.load.each(&:touch) } }`.","1","2015-07-17T11:58:47Z"
"246635","18784","122255854","364548","siadat","@bogdan if I understand correctly, you are saying that when e.g. `load: true`, the method should return an Enumerator that yields arrays of loaded ActiveRecord::Relation objects ~~ActiveRecord objects (as opposed to ActiveRecord::Relation objects)~~. Because in that case `in_batches` method does not need to call `#last` anymore and could load the relation instead. This would result in one less database query for those who want to call `#to_a` to iterate over each ActiveRecord object, like `find_each` does. If that is the case, it could be a reason to keep `#find_each` for that purpose.","1","2015-07-17T11:59:04Z"
"246636","18784","122258009","122436","bogdan","Example 2: `User.in_batches.each { |batch| transaction { batch.load.each(&:touch) } ` will not save you a query because you need to know if the batch is empty or not before yield it. From the other hand you can not always force loading because you don't know if it will be needed inside `yield`.
See https://github.com/rails/rails/pull/20899/files#diff-f0b4abc491880e438bf01f3f795e6ec1R213
This is the query that `load: true` can avoid.
","1","2015-07-17T12:12:35Z"
"246637","18784","122258204","2741","dhh","Ah, I see. Fair enough!
On Fri, Jul 17, 2015 at 2:13 PM, Bogdan Gusiev <notifications@github.com>
wrote:
> Example 2: User.in_batches.each { |batch| transaction {
> batch.load.each(&:touch) } will not save you a query because you need to
> know if the batch is empty or not before yield it. From the other hand you
> can not always force loading because you don't know if it will be needed
> inside yield.
>
> See
> https://github.com/rails/rails/pull/20899/files#diff-f0b4abc491880e438bf01f3f795e6ec1R213
> This is the query that load: true can avoid.
>
> —
> Reply to this email directly or view it on GitHub
> <https://github.com/rails/rails/pull/20899#issuecomment-122258009>.
>
","1","2015-07-17T12:14:23Z"
"246638","18784","122277531","364548","siadat","@bogdan :+1: Thank you for your explanation.
I just realised that `#last` loads the relation because the limit is set. So we cannot avoid loading the relation if we are using `#last`.
To avoid loading, I think we could get the same results using `#offset`. In which case, if `load: false` then only a COUNT query is executed on each iteration.
What are your thoughts about this:
while true
relation_yielded = relation.offset(offset)
relation_yielded.load if load
break if !relation_yielded.any?
yield relation_yielded
offset += of
end
","1","2015-07-17T13:43:01Z"
"246639","18784","122287101","122436","bogdan","@siadat we can do it. But we need to ensure we don't break any test. In order to do that we need to implement `find_each` and `find_in_batches` using new `in_batches` method to ensure all it's concerns are covered in `in_batches`.
In other words: all methods should use `in_batches` method as the most basic method and they should not change their behaviour. We can deprecate anything only after that.
","1","2015-07-17T14:12:11Z"
"246640","18784","122309256","364548","siadat","@bogdan Thank you for helping out. I implemented `in_batches` using offset, and modified `find_in_batches` to use `in_batches` as well. I also updated the tests, and added two tests to ensure the `+:load+` option works as expected.
I feel good about this, because even if a programmer iterates through all records while forgetting to set `load: true`, the query that could have been avoided is a COUNT.
Let me know what you think.","1","2015-07-17T15:20:02Z"
"246641","18784","122313478","1034","matthewd","I don't think this is viable as long as it's subject to [some variation of] the problem I described in https://github.com/rails/rails/pull/20899#issuecomment-121970395.
Using offset also appears to have an unpleasant behaviour if a record is inserted while we're iterating: potentially skipping it (as would be the case with limit) seems fair enough... double-processing some other record (as with offset) seems less so.","1","2015-07-17T15:32:15Z"
"246642","18784","122331758","364548","siadat","@matthewd Thank you for your feedback. Could you explain the first problem a bit more. We are only overrunning a single COUNT query before stopping the iteration, i.e., the COUNT query that returns 0 when the offset is more than the number of matching records.
Regarding inserted records, we are ordering the query using the primary key as was the case in the original implementation. The original implementation would also process new records as well if it matched the conditions and was within the `+:end_at+` option. The only LIMITs applied were (and still are) the `+:end_at+` and the `+:batch_size+` (or the new `+:of+`) options. We are not double-processing new records if I am not mistaken. Again, please correct me if I am wrong.","1","2015-07-17T16:20:39Z"
"246643","18784","122466208","364548","siadat","Done. Thank you @egilburg!","1","2015-07-18T01:39:41Z"
"246644","18784","122508667","122436","bogdan","@siadat
1. ~~`in_batches` should have a `load` option~~
2. ~~`find_each` should be deprecated and implemented with `in_batches`~~
3. ~~`find_in_batches` should be deprecated and implemented with `in_batches`~~
4. `with_batches` is a new method with similar functionality as `find_each` but names of the options should be consistent with `in_batches`. (See Example 3 why)
@matthewd I don't see current implementation either makes the https://github.com/rails/rails/pull/20899#issuecomment-121970395 problem better or worse. This is yet another problem to solve some day.
","1","2015-07-18T07:30:02Z"
"246645","18784","122521032","364548","siadat","The query of the yielded relation could be changed by the programmer which might then result in unexpected matching rows. This is the case for any other method that returns a relation as well.
Would it make sense to ignore (or show a warning) if the yielded relation's query methods (#where, #order etc) are called?","1","2015-07-18T09:34:05Z"
"246646","18784","122527075","364548","siadat","@bogdan Regarding 4, I added `with_batches`, which is used like `find_each`:
User.with_batches(of: 100).each(&:touch)","1","2015-07-18T10:21:03Z"
"246647","18784","122529898","122436","bogdan","@siadat `with_batches` looks good.
> The query of the yielded relation could be changed by the programmer
Do you mean `#where!` and `#order!` relation modification methods? I feel I don't get it. Can you please make an example with code?
","1","2015-07-18T10:57:30Z"
"246648","18784","122530746","2741","dhh","Not liking with_batches. It's too close to in_batches and it doesn't
self-describe how they're different. find_each is clearly different.
On Saturday, July 18, 2015, Bogdan Gusiev <notifications@github.com> wrote:
> @siadat <https://github.com/siadat> with_batches looks good.
>
> The query of the yielded relation could be changed by the programmer
>
> Do you mean #where! and #order! relation modification methods? I feel I
> don't get it. Can you please make an example with code?
>
> —
> Reply to this email directly or view it on GitHub
> <https://github.com/rails/rails/pull/20899#issuecomment-122529898>.
>
","1","2015-07-18T11:13:28Z"
"246649","18784","122541749","364548","siadat","@bogdan This would be an example of problematic usage:
People.in_batches.each do |relation|
relation.where(age: 21).update_all('age = age + 1')
end
`relation.to_sql` would be something like this (as expected):
SELECT * FROM people LIMIT 0, 1000
However, the added `where(age: 21)` changes everything:
SELECT * FROM people WHERE age = 21 LIMIT 0, 1000
The programmer who wrote this would have probably meant to filter and narrow down the current batch. But the matching rows are changed completely because the added condition is applied before offset, not after it. Same thing happens even if we iterate each batch via `id > last_id_of_previous_batch` instead of offset.
One solution I could think of right now is this: we could load the primary key (e.g. id) of all matching rows, then create a new relation with them like this:
loop do
batch = relation.offset(offset)
batch.load if load
break if batch.none?
ids = batch.pluck(:id)
yield self.where(id: ids) # <- NOTE here
offset += of
end
This way the programmer would be free to do anything they want with the yielded relations. They could call `where`, `offset`, `order`, and all other query methods on it and the results would be exactly what is expected. If we do this, we could also revert back to the method of using last ids instead of offsets.
Let me know your thoughts about it.","1","2015-07-18T13:08:52Z"
"246650","18784","122543615","364548","siadat","@dhh I agree. I would prefer a more descriptive name.
Maybe we could borrow from `Enumerable#flat_map` and call it `flat_each` or `in_flat_batches`!","1","2015-07-18T13:24:37Z"
"246651","18784","122543874","122436","bogdan","@siadat I got it now. The solution for this problem definitely should not be part of this PR. We can not make it perfect just here.","1","2015-07-18T13:29:12Z"
"246652","18784","122549890","1529387","sgrif","Can we not just make `in_batches.flatten` be smart enough to do the right thing?","1","2015-07-18T14:34:51Z"
"246653","18784","122550144","2741","dhh","Feels too cumbersome given how common this case is. Whatever we end up doing shouldn't feel like a regression vs #find_each.
> On Jul 18, 2015, at 16:35, Sean Griffin <notifications@github.com> wrote:
>
> Can we not just make in_batches.flatten be smart enough to do the right thing?
>
> —
> Reply to this email directly or view it on GitHub.
>
","1","2015-07-18T14:41:01Z"
"246654","18784","122562171","1034","matthewd","@bogdan
> The solution for this problem definitely should not be part of this PR. We can not make it perfect just here.
(Again, as much as I would like to land this API,) I'm not going to introduce a brand new shiny foot-gun and just hope it gets fixed later.
@sgrif any ideas? My only thought so far is that we load the current relation (to get the last ID), then add a `where(id: range)` clause and *copy the loaded data to that new relation*. :confused:","1","2015-07-18T16:33:00Z"
"246655","18784","122567097","364548","siadat","Regarding my previous comment https://github.com/rails/rails/pull/20899#issuecomment-122541749, and as @bogdan advised, I submitted #20933 as an alternative implementation for `in_batches`.
Let me know what you think.","1","2015-07-18T17:14:34Z"
"246656","18785","847506","3387","fxn","Applied, thanks!","1","2011-03-08T15:08:19Z"
"246657","18786","1582889","52642","spastorino","can you do it for 3-1-stable too?","1","2011-07-15T21:27:20Z"
"246658","18787","122541218","1529387","sgrif","Duplicate of https://github.com/rails/rails/pull/20902","1","2015-07-18T12:59:30Z"
"246659","18788","123382625","11493","amatsuda","Confirmed that this actually is a :bug:
We cannot define an attribute or an association named `parents` because AR calls ActiveSupport's `Module#parents` inside the library code, and that causes infinite loop as @yui-knk reported.
But, isn't `parents` too general method name to prohibit?
We in fact use that method only once or twice in AR, so why don't we just stop using that method here, and allow the application developers to use that method name?
I mean, I'd rather suggest a fix like this. https://github.com/rails/rails/compare/rails:master...amatsuda:20901_alternate_fix
WDYT?","1","2015-07-21T15:54:28Z"
"246660","18788","143511861","5356517","yui-knk","I feel @amatsuda ' patch is better than mine because it enable user to use `parents` name.","1","2015-09-27T01:39:26Z"
"246661","18788","143511899","5356517","yui-knk","r? @senny","1","2015-09-27T01:40:50Z"
"246662","18788","143522706","55829","chancancode","@amatsuda's patch seems good to me. I wonder if those two methods are commonly called by external libraries though. We could do the same for `name` for example, but that would be setting our users up for some very strange bugs down the road. I *think* it seems okay in this case though.
Is there a good way to verify that besides GitHub search?","1","2015-09-27T06:00:07Z"
"246663","18788","143639112","833383","arthurnn","Dont we also need a regression test for this?","1","2015-09-28T04:26:48Z"
"246664","18788","143653737","5402","senny",":+1: on @amatsuda's approach. I wonder wether we should deprecate `parent` and `parents` in favor of `parent_module` and `parent_modules`.","1","2015-09-28T06:47:15Z"
"246665","18788","143739586","1529387","sgrif","I agree that we should deprecate and rename. These method names are far too vague to rely on not being overridden. I even wonder if it's worth changing it to `SomeModule.parents_of(target)`","1","2015-09-28T13:12:32Z"
"246666","18788","149545524","5402","senny","@yui-knk are you working on the rename and deprecation?","1","2015-10-20T12:08:56Z"
"246667","18788","149547407","5356517","yui-knk","@amatsuda Can I use you your patch about this?","1","2015-10-20T12:19:16Z"
"246668","18790","123853934","350807","kaspth","@dhh I got something that's working here too, but I still need to add documentation.
I don't know how necessary it is to add a cache to the wildcard lookup. I'll try doing some benchmarking.
@jeremy @rafaelfranca the implementation I've done feels, eh, not so nice to me. Can you review? :grin:","1","2015-07-22T20:34:21Z"
"246669","18790","124038162","2741","dhh","Awesome. I do think we'll need a cache, though. Otherwise every time that
template is eval'ed, you have to touch the filesystem. That won't fly.
On Wed, Jul 22, 2015 at 10:35 PM, Kasper Timm Hansen <
notifications@github.com> wrote:
> @dhh <https://github.com/dhh> I got something that's working here too,
> but I still need to add documentation.
>
> I don't know how necessary it is to add a cache to the wildcard lookup.
> I'll try doing some benchmarking.
>
> @jeremy <https://github.com/jeremy> @rafaelfranca
> <https://github.com/rafaelfranca> the implementation I've done feels, eh,
> not so nice to me. Can you review? [image: :grin:]
>
> —
> Reply to this email directly or view it on GitHub
> <https://github.com/rails/rails/pull/20904#issuecomment-123853934>.
>
","1","2015-07-23T09:57:36Z"
"246670","18790","124220203","350807","kaspth","@dhh I've added a changelog entry, documentation and, most importantly, caching :grin:","1","2015-07-23T19:38:59Z"
"246671","18790","124590311","350807","kaspth","I'm not sure where we document that custom trackers must support the `view_paths` argument to be able to use these wildcard dependencies.","1","2015-07-24T17:33:55Z"
"246672","18790","124590509","350807","kaspth",":runner: Travis :runner: ","1","2015-07-24T17:34:17Z"
"246673","18790","124871601","350807","kaspth","I've looked at how Haml and Slim register themselves and they both use the ERB tracker. Perhaps the trackers should implement `supports_view_paths` instead of having it as a configured that's used when registering, then it'll just work for Haml and Slim and possibly others.
I've talked myself into doing that. I'll change it now :+1:","1","2015-07-25T18:45:52Z"
"246674","18790","124952103","2741","dhh","Excellent! @rafaelfranca do you have any comments on the view handler implementation?","1","2015-07-26T07:05:41Z"
"246675","18790","125290856","47848","rafaelfranca",":shipit:","1","2015-07-27T18:07:34Z"
"246676","18790","125297174","350807","kaspth","Boom! Thanks everyone :tada: ","1","2015-07-27T18:28:16Z"
"246677","18810","123210039","2741","dhh","I'm not sure I understand the criticism either. This PR looks both well-implemented, tested, and benchmarked. Happy to evaluate another PR as well, but that shouldn't stop progress here. As long as we settle on the public API, we can continue to refine the implementation behind the scenes. I like the public API here, particularly if we get the batch delegator added as well ?","1","2015-07-21T08:19:13Z"
"246678","18810","123362102","122436","bogdan","@siadat I don't understand why the following have to happen:
``` ruby
relation_yielded = self.where(primary_key => ids).reorder(batch_order)
relation_yielded.instance_variable_set :@records, records
relation_yielded.instance_variable_set :@loaded, true
```
I've replaced these 3 lines with: `yielded_relation = batch_relation` and all tests passed. Can you explain why this is needed?
Same thing for the `load: false` the following does the job:
``` ruby
relation_yielded = batch_relation
```
Instead of:
``` ruby
relation_yielded = self.where(primary_key => ids).reorder(batch_order)
```
","1","2015-07-21T15:03:59Z"
"246679","18810","123517278","364548","siadat","@bogdan Thank you for reviewing the code. I just pushed a new test that will fail if you do that.
The relation_yielded is built using the record ids. It is not the same as the relation used internally to iterate through the records. E.g., if the internal relation to_sql is
```sql
... WHERE (""posts"".""id"" > 2) ORDER BY ""posts"".""id"" ASC LIMIT 2
```
the yielded relation should be
```sql
... WHERE ""posts"".""id"" IN (3, 4) ORDER BY ""posts"".""id"" ASC
```
This lets us call all query methods on yielded relations safely. Otherwise we would have to somehow ban the programmer from calling query methods, e.g. `where`, on the yielded relation because the result could match records outside the current batch. Please see my comment in the other PR https://github.com/rails/rails/pull/20899#issuecomment-122541749 and this PR's description for an example.
As for the reason why records are loaded like that (`instance_variable_set`), it is because records are already loaded and we want to avoid making an extra query.","1","2015-07-22T00:36:56Z"
"246680","18810","123642122","122436","bogdan","@siadat
The test doesn't test the actual end user scenario: it looks completely bound to the implementation you made inside: if we would resolve the same problem in a different way, your test will fail but it should not.
I don't like the implementation with `instance_variable_set`. It is a hack that breaks OOP principles and the motivation for such hacks should be extremely strong. I don't see such motivation here.
I vote for moving this code to a different PR and merge the code we all agree on because it will never be perfect....
","1","2015-07-22T09:35:42Z"
"246681","18810","123654517","2741","dhh","I appreciate the vigorous review, @bogdan, but my take is that @siadat has answered the concerns and explained why the implementation is needed the way it is. We're going to need more rigorous arguments against the current implementation from preventing it from being merged.","1","2015-07-22T10:26:41Z"
"246682","18810","123657374","364548","siadat","@bogdan Thank you for taking the time to review this PR :+1:
> The test doesn't test the actual end user scenario
The new test ensures that the returned relations are built to have all the primary keys explicitly specified in the condition. I think it does make a difference to the end-user whether the relation they are receiving is `where(id: [5, 6])` (this PR) or `offset(4).limit(2)` (the other PR). But I will welcome a better alternative to assert this.
> I don't like the implementation with instance_variable_set.
I agree, I don't like it as well, but it works! I've seen it done in other parts of rails. I would appreciate it if someone could review it and/or suggest an alternative. Maybe later we could add a private setter method for relations in order to allow building and manually loading records the OOP way.
I vote for the current PR, because it performs better than the other PR for large number of rows, it is as fast as the original `find_in_batches` (or faster, in case records are not loaded), and the yielded relations are more useful than the other PR's in my opinion.","1","2015-07-22T10:33:51Z"
"246683","18810","123661471","2741","dhh","That approach has my vote.
On Wed, Jul 22, 2015 at 12:34 PM, Sina Siadat <notifications@github.com>
wrote:
> @bogdan <https://github.com/bogdan> Thank you for taking the time to
> review this PR [image: :+1:]
>
> The test doesn't test the actual end user scenario
>
> The new test ensures that the returned relations are built to have all the
> primary keys explicitly specified in the condition. I think it does make a
> difference to the end-user whether the relation they are receiving is where(id:
> [5, 6]) (this PR) or where.offset(4).limit(2) (the other PR). But I will
> welcome a better alternative to assert this.
>
> I don't like the implementation with instance_variable_set.
>
> I agree, I don't like it as well, but it works! I've seen in done in other
> parts of rails. I would appreciate it if someone could review it and/or
> suggest an alternative. Maybe later we could add a private setter method
> for relations in order to allow building and manually loading records.
>
> I vote for the current PR, because it performs better than the other PR,
> it is as fast as the original find_in_batches (or faster, in case records
> are not loaded), and the yielded relations are more useful than the other
> PR's in my opinion.
>
> —
> Reply to this email directly or view it on GitHub
> <https://github.com/rails/rails/pull/20933#issuecomment-123657374>.
>
","1","2015-07-22T10:42:29Z"
"246684","18810","123709669","122436","bogdan","@dhh @siadat ok take your turn.
This is my last test concern. I promise.
@siadat is the following solved:
``` ruby
People.in_batches.each do |relation|
relation.where(age: 21).update_all('age = age + 1')
end
```
I would recommend to use this example as an idea for a test. It describes the problem we are solving more closely. I don't think that relation with `where(id: [5, 6])` can be considered as something that end user wants. End user just wants less problems like in the code example above and no matter how they are solved.
","1","2015-07-22T12:50:10Z"
"246685","18810","123767311","364548","siadat","@bogdan That's a good idea, thanks! I just pushed a new test for that.","1","2015-07-22T15:51:05Z"
"246686","18810","123809701","350807","kaspth","Well done @siadat :smile:","1","2015-07-22T18:00:21Z"
"246687","18810","123881321","364548","siadat","Thank you @kaspth! :smile: ","1","2015-07-22T22:05:59Z"
"246688","18810","124132760","364548","siadat","I forked this branch to put together an implementation of the API that @dhh suggested (https://github.com/rails/rails/pull/20933#issuecomment-122885481), and pushed the code to siadat@db55682724a6e00d68f31c8dc21bc6de93e19600.
I did it in another branch because I thought the implementation is not perfect and someone else should review it first. Please review the new [batches_delegator.rb](https://github.com/siadat/rails/blob/relations-in-batches-using-ids-and-delegator/activerecord/lib/active_record/relation/batches_delegator.rb) file and let me know if you want me to apply it in this PR, or submit it as a new PR after (and if) this one is merged.
So, current examples will still work, but these:
```ruby
People.in_batches.each { |relation| relation.update_all(should_party: true) }
People.in_batches.each { |relation| relation.delete_all }
People.in_batches(load: true).each { |relation| relation.each(&:party_all_night!) }
```
will also have the following shortcuts:
```ruby
People.in_batches.update_all(should_party: true)
People.in_batches.delete_all
People.in_batches.each_record(&:party_all_night!)
```
**NOTE** I implemented this with a new name `in_batches_delegator` to make the diff as small as possible. I will rename it to `in_batches` later.","1","2015-07-23T15:00:04Z"
"246689","18810","124135733","2741","dhh","? on the API.","1","2015-07-23T15:11:39Z"
"246690","18810","124475411","364548","siadat","I merged the delegator here. Thanks to @kaspth for reviewing the initial implementation! :smile:
Here's a short summary of the new API:
```ruby
People.in_batches { |relation| ... }
People.in_batches.each { |relation| ... }
People.in_batches.each_record { |record| ... }
People.in_batches.each_record.with_index { |record, record_index| ... }
People.in_batches.delete_all('age > 21')
People.in_batches.update_all('age = age + 1')
```","1","2015-07-24T11:03:37Z"
"246691","18810","124481475","2741","dhh","Lovely! Any blockers left before we can merge?
On Fri, Jul 24, 2015 at 1:04 PM, Sina Siadat <notifications@github.com>
wrote:
> I merged the delegator here. Thanks to @kaspth <https://github.com/kaspth>
> for reviewing the initial implementation! [image: :smile:]
>
> Here's a short summary of the new API:
>
> People.in_batches { |relation| ... }People.in_batches.each { |relation| ... }People.in_batches.each_record { |record| ... }People.in_batches.each_record.with_index { |record, record_index| ... }People.in_batches.delete_all('age > 21')People.in_batches.update_all('age = age + 1')
>
> —
> Reply to this email directly or view it on GitHub
> <https://github.com/rails/rails/pull/20933#issuecomment-124475411>.
>
","1","2015-07-24T11:17:48Z"
"246692","18810","124499857","1529387","sgrif","I would still like a chance to review this before we merge, which I will
have time today or tomorrow.
On Fri, Jul 24, 2015, 5:18 AM David Heinemeier Hansson <
notifications@github.com> wrote:
> Lovely! Any blockers left before we can merge?
>
> On Fri, Jul 24, 2015 at 1:04 PM, Sina Siadat <notifications@github.com>
> wrote:
>
> > I merged the delegator here. Thanks to @kaspth <
> https://github.com/kaspth>
> > for reviewing the initial implementation! [image: :smile:]
> >
> > Here's a short summary of the new API:
> >
> > People.in_batches { |relation| ... }People.in_batches.each { |relation|
> ... }People.in_batches.each_record { |record| ...
> }People.in_batches.each_record.with_index { |record, record_index| ...
> }People.in_batches.delete_all('age > 21')People.in_batches.update_all('age
> = age + 1')
> >
> > —
> > Reply to this email directly or view it on GitHub
> > <https://github.com/rails/rails/pull/20933#issuecomment-124475411>.
> >
>
> —
> Reply to this email directly or view it on GitHub
> <https://github.com/rails/rails/pull/20933#issuecomment-124481475>.
>
","1","2015-07-24T12:04:19Z"
"246693","18810","124542652","354185","robin850","Nice work @siadat ! This will need a changelog entry, otherwise this is looking good! :+1:","1","2015-07-24T14:34:01Z"
"246694","18810","124625188","364548","siadat","@kaspth @robin850 Thank you! :smile: ","1","2015-07-24T18:49:38Z"
"246695","18810","124830601","364548","siadat","@robin850 I added a changelog entry, squashed all the commits, and rebased the branch.","1","2015-07-25T10:09:52Z"
"246696","18810","124880502","364548","siadat","The `activerecord/CHANGELOG.md` edit is the reason for conflict. Shall I revert it to make it easy to merge?","1","2015-07-25T19:50:18Z"
"246697","18810","124881063","350807","kaspth","The easiest way I've found to solve those pesky CHANGELOG conflicts is to cut out your entry (maybe `git stash`-ing it?), amend your commit, rebase on master, and then paste it in again and amend your commit once more. Lastly you force push to your branch and it should all be peachy keen :ok_hand: ","1","2015-07-25T19:54:42Z"
"246698","18810","124890538","364548","siadat","Done. The conflict is resolved until CHANGELOG is updated again in master! :smile: ","1","2015-07-25T20:44:37Z"
"246699","18810","124951964","2741","dhh","@sgrif Did you have any comments or are we merging?","1","2015-07-26T07:04:17Z"
"246700","18810","128265664","364548","siadat","Any particular reason why this PR is abandoned?
/cc @sgrif ","1","2015-08-06T06:32:12Z"
"246701","18810","128459924","2741","dhh","Not on my end. If @sgrif or @matthewd wants to do a review, let's make that happen this week. Otherwise, we'll merge on Monday and any subsequent reviews can happen as its part of rails/master. The API is good, so any additional tuning on the implementation can happen after a merge too.","1","2015-08-06T18:01:31Z"
"246702","18810","128460584","1529387","sgrif","The PR wasn't abandoned, we just don't have unlimited time. I left a few more comments, this looks fine beyond those two things.","1","2015-08-06T18:04:45Z"
"246703","18810","128608381","364548","siadat","@dhh @sgrif Thank you for your comments! Commit updated. :smile: ","1","2015-08-07T06:10:08Z"
"246704","18810","128711379","2741","dhh","?","1","2015-08-07T14:14:35Z"
"246705","18810","128822689","364548","siadat","Thank you! :tada:","1","2015-08-07T20:11:51Z"
"246706","18810","131761697","5187816","reshadman","Great discussion and PR :dart: ","1","2015-08-17T10:01:10Z"
"246707","18811","122662478","1685896","repinel","I liked the idea of having the doc categorized by the nature of the methods (e.g. `Creation`). :smile: ","1","2015-07-19T13:43:25Z"
"246708","18811","123873746","260746","maurogeorge","@repinel thanks for the review :star2:
I updated with your suggestions","1","2015-07-22T21:35:17Z"
"246709","18811","149842570","260746","maurogeorge","Thanks for the merge :heart: ","1","2015-10-21T09:56:39Z"
"246710","18812","122587847","16556","twalpole","@sgrif Adding with_indifferent_access to AC::Parameters removed the need for checks for #permitted? and becomes one check for #with_indifferent_access ... If you still plan on refactoring the nested attributes code feel free to close this.","1","2015-07-18T19:38:00Z"
"246711","18812","122587951","1529387","sgrif","I'm not sure that I like this implementation, since Parameters already is with indifferent access, and I'd expect it to just return `self`. I'll take a closer look when I get a chance though. ","1","2015-07-18T19:40:22Z"
"246712","18812","122587953","1529387","sgrif","Whoops wrong button","1","2015-07-18T19:40:31Z"
"246713","18812","122588190","47848","rafaelfranca",":-1: to implement this method on parameter.
On Sat, Jul 18, 2015, 16:40 Sean Griffin <notifications@github.com> wrote:
> Whoops wrong button
>
> —
> Reply to this email directly or view it on GitHub
> <https://github.com/rails/rails/pull/20935#issuecomment-122587953>.
>
","1","2015-07-18T19:47:47Z"
"246714","18813","122602992","1685896","repinel","Some of the tests from #11695 didn't seem necessary, but if anyone really think it matters, I can add them in.","1","2015-07-18T22:56:19Z"
"246715","18813","125183761","1247102","d-Pixie","@repinel Thanks <3 I never got all the tests to pass locally for my branch.","1","2015-07-27T12:14:30Z"
"246716","18814","122610002","342081","aprescott","I'm not well-versed enough in the Rails codebase to be able to comment on the solution in this PR, but I wanted to point out potential overlap with #18109, just in case.
It seems worth having a test for `unscoped` in addition to `scoping`? The two aren't necessarily equivalent. I'm thinking of something like the gist mentioned in https://github.com/rails/rails/issues/13775#issuecomment-57435609.","1","2015-07-19T01:15:51Z"
"246717","18814","122614500","1529387","sgrif","Thanks, but this is an insufficient solution. Relations created in a `scoping` block but executed outside of it should respect it as well. This will require a much deeper restructuring as I've said on the various issues. ","1","2015-07-19T02:08:37Z"
"246718","18814","122617532","614945","sidot3291","Can you go into more detail? I pulled execution outside of the scoping block and it still passes the tests:
https://github.com/sidot3291/rails/commit/de95548b2edc07c9f11f88e3bdd72331b58f9094","1","2015-07-19T02:41:36Z"
"246719","18815","122660502","1685896","repinel","This will remove the link to the `DateTime` documentation :-1: ","1","2015-07-19T13:17:27Z"
"246720","18815","122688353","1186240","TheBlasfem","@repinel thanks for the observation, so i've changed the file to display correctly the link to `DateTime` in the documentation","1","2015-07-19T17:44:48Z"
"246721","18816","123537269","1196663","rafaelsales","Anything needed from my end to have feedback here?","1","2015-07-22T02:24:44Z"
"246722","18816","123864216","2394703","seuros","LGTM
cc @rafaelfranca ","1","2015-07-22T21:08:47Z"
"246723","18816","124572526","1196663","rafaelsales","ping @rafaelfranca ","1","2015-07-24T16:25:07Z"
"246724","18816","145408501","833383","arthurnn","Not sure about this honestly. the multiple `get '/',` look good to me already. I think this will add a few more bits of complexity to the code, that can already handle the use case described.
:-1: from me. ","1","2015-10-05T01:26:01Z"
"246725","18816","145409580","1196663","rafaelsales","But then routes DSL is inconsistent. You can have multiple `root` but with a ""hack"", using `get '/'`
Also, where this adds complexity to code? Instead, this makes the code consistent.
There are other inconsistencies in routes DSL, but I figured rails codebase looks like a ghost city","1","2015-10-05T01:46:41Z"
"246726","18816","147076970","1196663","rafaelsales","@rafaelfranca Removed that doc by mistake. Fixed and rebased","1","2015-10-10T11:31:46Z"
"246727","18816","147112990","1196663","rafaelsales","ty","1","2015-10-10T18:00:07Z"
"246728","18817","123543407","1196663","rafaelsales","Added specs!","1","2015-07-22T02:49:21Z"
"246729","18817","124572507","1196663","rafaelsales","ping @rafaelfranca :)","1","2015-07-24T16:25:02Z"
"246730","18817","124612622","350807","kaspth","Thanks for the pull request, but this feels exactly like the kind of code that adds a lot of lines to protect people from themselves that tiny amount of times they might hurt themselves.
To me the point of the inquirer is to get a yes or no from whatever you check it with. You're supposed to inquire it, after all :smile:
Thanks again :heart:","1","2015-07-24T18:33:28Z"
"246731","18817","124627217","1196663","rafaelsales","@kaspth I just find myself and other devs doing these kind of stuff with lots of frequency:
You have a class with a status column. The status might be ""a"", ""b"", ... ""z"". You start writing code like `object.status == :a` and the devs realize that spreading symbols all over is error prone, so it's better to get something more ""static"" so that the language helps us identifying bugs. So, some devs will write `def a?; status == :a; end` (similar for other statuses), and other devs will use `method_missing` and `respond_to` to avoid writing the same thing tons of times. Well, for me it's clear we have a pattern the StringInquirer is already on the way to solve it.
I actually would like to hear a reason which makes this **not** a good idea.
It's basically the same thing as Rails extending `String` to have `.presence?` - it's providing something that will save time and keystrokes.","1","2015-07-24T18:52:28Z"
"246732","18817","124691531","350807","kaspth","You provided this feature without a use case, as such I have to guess at what the use is, which I might not see.
After having heard from you some more, this sounds like what you're trying to solve:
```ruby
'hello'.inquiry.hello?
'hello'.inquiry.hell? # Misspelling would return always return false
```
Which is different than what I had imagined. I'll reopen, but I hope you can see my point.","1","2015-07-24T20:00:00Z"
"246733","18840","125329228","2741","dhh","?","1","2015-07-27T20:12:33Z"
"246734","18840","125554028","26328","carlosantoniodasilva","Sounds good to me.","1","2015-07-28T10:50:04Z"
"246735","18840","128486979","47848","rafaelfranca","> I've declared this method here and I don't like what I did. I think this is a bad example to show developers to repeat yourself. Maybe we can define this method in active_support to use in other places, I didn't think declaring this method inside of a file in bin folder because someone can remove it. Any advice?
It is a script so there is no problem of repeating it. Over DRy is also a problem","1","2015-08-06T20:00:05Z"
"246736","18840","128527179","1840945","meinac","@rafaelfranca I fixed the problems you've pointed, WDYT about this now?","1","2015-08-06T22:25:09Z"
"246737","18840","128552404","1840945","meinac","@matthewd Thanks for the point, I've fixed it.","1","2015-08-07T01:01:56Z"
"246738","18841","123469901","1840945","meinac","@rafaelfranca , @sgrif this will fix the status of rails.","1","2015-07-21T20:34:14Z"
"246739","18842","123537001","1196663","rafaelsales","Functions that handle really particular scenarios of input data structures tend to be harder to understand. So, I would say it's up to the user to call `hash.values.sum` or `array.flatten.sum`.
This might also break existing functionality if someone has an enumerable with `+` method overridden.","1","2015-07-22T02:23:15Z"
"246740","18842","123624130","921198","naliwajek","I didn't think about breaking the existing functionality, my bad :disappointed: (first timers' disease, I suppose ;))
I just assumed that if there's an extension for `Enumarable` module then it should return meaningful - according to its name that is - values for at least built-in classes, but yeah, that could be potentially troublesome.
Should we then do any of this?
* add example with `{ a: 1, b: 2}.sum` to doc comment so people know what to except and not get worried that that's a bug?
* near `[[1, 2], [3, 1, 5]].sum` example in doc comment, add information that it's not the same as flatten and will not work on array with multiple different dimensions, like `[1, [2, 3]]` - it might be an edge case not worth commenting on but I did run into it hence I'm asking ;)
* and since we're interested in backward compatibility: add tests for `[].sum` and `{}.sum` behaviour to ensure we have something testing that compatibility?","1","2015-07-22T08:52:29Z"
"246741","18842","123629968","350807","kaspth","I don't think we should special case `sum` like this. Maybe I could see the value in updating the documentation to say that each element must respond to `+`. Because as long as you keep that in mind, your examples make sense.","1","2015-07-22T09:03:22Z"
"246742","18842","149040387","4388676","Bartuz","IMHO `{ a: 1, b: 2}.sum` should raise an exception","1","2015-10-18T19:23:30Z"
"246743","18843","123577903","350807","kaspth","Thanks!","1","2015-07-22T06:40:07Z"
"246744","18845","145406418","833383","arthurnn","I think this make sense. However I dont have much experience with Postgres to judge.
@sgrif @senny thoughts?","1","2015-10-05T00:55:43Z"
"246745","18845","145406537","1529387","sgrif","Nice work. Thanks for helping this. More people should use native enums. ","1","2015-10-05T00:58:02Z"
"246746","18845","145454960","334030","dkoprov","Great! That's a cool feature especially for working with state machines.","1","2015-10-05T07:53:49Z"
"246747","18875","124813764","3303032","ianks","I ACK this as well, but would ACK it more if you encouraged a student to make this PR ?","1","2015-07-25T06:37:57Z"
"246748","18875","124873332","8007635","EmilyMB","As a newer developer, I agree with the comments above and :heart: @edwardloveall's friendly phrasing. All the comments throughout all of Rails seem verbose and unnecessary... If I get stuck on something, I just Google it. Between Stack Overflow and the docs, things are pretty well covered.","1","2015-07-25T19:05:58Z"
"246749","18875","124883176","2415484","jonatack","Agreed concerning ""comments throughout all of Rails"" for generated files, but not in the codebase itself. For what its worth, I'd say the first/best/most reliable places to look for information once you get into it are the Rails source code & comments (`bundle open rails` on the command line), the Rails Guides at http://guides.rubyonrails.org/, the Rails API at http://api.rubyonrails.org/, and for Ruby, http://ruby-doc.org.","1","2015-07-25T20:13:33Z"
"246750","18875","124998987","8315971","loriculberson","Great idea! A link to the guides would provide a cleaner interface. I like Jason Noble's suggestion to offer the option of minimal or full comments upon installation. Though I don't know if anyone would choose to add them. ","1","2015-07-26T14:51:18Z"
"246751","18875","130428712","6632025","marlabrizel",":+1: to this change. As a new Rails dev, I actually fear inadvertently deleting configuration code when I'm deleting large sections of comments. While this is likely less of an issue with the routes file, I can envision a scenario elsewhere in which I delete commented out code, accidentally nuke something essential to my config, and then spend lots of time debugging due to my still-limited familiarity with the framework.","1","2015-08-12T20:06:26Z"
"246752","18875","130439192","47848","rafaelfranca","Yeah, I agree with the change, but I'd like to hear @fxn and @dhh comments.","1","2015-08-12T20:34:20Z"
"246753","18875","130447733","2741","dhh","I'm fine replacing this with a link to a guide, but let's not kid ourselves thinking that the guide is somehow going to be magically more up to date than a code comment. Also, I don't agree that comments in general are bad in generated files because you can google things and maybe find something on Stack Overflow. But in this case, this isn't a comment, but literally a full guide. Don't need that.","1","2015-08-12T21:00:47Z"
"246754","18875","130506719","1529387","sgrif","Sounds like we're all on the same page. I'm going to move forward with this. ","1","2015-08-13T01:57:28Z"
"246755","18875","130562679","3387","fxn","Agree with David's arguments.
The link points to the latest stable guide, it would be better to point to the versioned one.","1","2015-08-13T07:18:55Z"
"246756","18876","126894490","5402","senny","@earksiinni can you revert the changes to `Gemfile.lock`?","1","2015-08-01T09:56:47Z"
"246757","18876","127026100","5427394","earksiinni","@senny, I updated my fork with the requested changes and pushed to my repo. Apologies for being such a n00b, is there anything else that I need to do? Do I need to issue another PR? Also, for future reference, should I not change Gemfile.lock for small patches like this? I was following the Rails guide (http://edgeguides.rubyonrails.org/contributing_to_ruby_on_rails.html#updating-the-gemfile-lock), which says under section 4.10 that one should update Gemfile.lock.","1","2015-08-02T14:01:11Z"
"246758","18876","127051741","5402","senny","@earksiinni while the guide states that it's necessary to upgrade the `Gemfile.lock` the leading sentence for this paragraph is:
> Some changes require the dependencies to be upgraded.
So basically we upgrade `Gemfile.lock` along changes that depend on some version of a dependency. For example if we have a git dependency on `arel` that should be updated when we make changes to Rails that depend on changes to `arel`. Hope that makes sense.","1","2015-08-02T18:16:19Z"
"246759","18876","127061830","5427394","earksiinni","@senny got it, thanks!","1","2015-08-02T19:51:36Z"
"246760","18876","128499743","47848","rafaelfranca","Merged in 7c23c38. Thanks","1","2015-08-06T20:35:38Z"
"246761","18876","128500361","47848","rafaelfranca","Backported in 28df487","1","2015-08-06T20:37:10Z"
"246762","18877","145408749","833383","arthurnn","Yes I agree this could be confusing. However this is the type of thing can happen allover the place. So I would say this check is kinda weak. In a sense, that we cannot do much to prevent/warn the user.
@sgrif thoughts?","1","2015-10-05T01:30:31Z"
"246763","18877","145423890","1529387","sgrif","Agreed, I'm not sure we can appropriately detect it. ","1","2015-10-05T03:54:22Z"
"246764","18878","124818003","47848","rafaelfranca","Thank you for the pull request but we avoid to add new features to active support that would not be used by the framework or by a large number of applications. ","1","2015-07-25T07:51:20Z"
"246765","18879","124853208","350807","kaspth","These assertions are already starting to feel pretty complex to me and I'm wondering if we may be shooting ourselves in the foot adding more.
We added `assert_called` and friends because the stub returning a mock was a lot of boilerplate, and maybe the boilerplate isn't as bad here.
So @ronakjangir47, can you try taking the example test you've linked to above and rewrite it to how it would look without any helper method? That way we can use a real test case to drive the design of a solution.
How does that sound to you? :smile:
Also thanks for working on this! :heart:","1","2015-07-25T15:23:59Z"
"246766","18879","124958227","1909242","ronakjangir47","We're using `any_instance` with [stubbing](https://github.com/rails/rails/blob/master/actionmailer/test/base_test.rb#L896) and [expectations](https://github.com/rails/rails/blob/master/actionmailer/test/delivery_methods_test.rb#L110) so without helper method our test suite might become less clean.
Any way here is the example
````ruby
mail = BaseMailer.welcome
BaseMailerPreview.any_instance.stubs(:welcome).returns(mail)
MyInterceptor.expects(:previewing_email).with(mail)
BaseMailerPreview.call(:welcome)
````
might be written like this (without redefining method)
````ruby
mail = BaseMailer.welcome
object = BaseMailerPreview.new
BaseMailerPreview.stub(:new, object) do
object.stub(:welcome, mail) do
assert_called_with(MyInterceptor, :previewing_email, [mail]) do
BaseMailerPreview.call(:welcome)
end
end
end
````
And with `assert_any_instance_called` helper
````ruby
mail = BaseMailer.welcome
assert_any_instance_called(BaseMailerPreview, :welcome, returns: mail) do
assert_called_with(MyInterceptor, :previewing_email, [mail]) do
BaseMailerPreview.call(:welcome)
end
end
````","1","2015-07-26T08:54:15Z"
"246767","18879","125008434","350807","kaspth","@ronakjangir47 Yeah, that's some configuration. But I do like the idea of `new` being stubbed in our own helper more than the method redefining we have currently.
Can you try changing your code to do that?
Also I think we should remove `times_called` unless there's more than one place where we're asserting that any instance is called a certain number of times.","1","2015-07-26T15:31:20Z"
"246768","18879","125009434","350807","kaspth","Thinking about this some more it might make more sense to use an `ActiveSupport::Mock` (which inherits from Minitest::Mock) that wraps the `times_called` stuff and whatever else we need - but I'm unsure how far we should take this code ¯\_(ツ)_/¯","1","2015-07-26T15:39:39Z"
"246769","18879","125105603","1909242","ronakjangir47","> Can you try changing your code to do that?
Sure will do.
> Thinking about this some more it might make more sense to use an ActiveSupport::Mock (which inherits from Minitest::Mock) that wraps the times_called stuff
I'm not sure I completely got you, can you please explain it more?","1","2015-07-27T06:49:43Z"
"246770","18879","125301531","350807","kaspth","I was just thinking if it might be better to capture some of the code in these helpers within a private domain object. It's not necessarily something you need to look into - I was just thinking out loud :smile:","1","2015-07-27T18:42:28Z"
"246771","18879","127303404","1909242","ronakjangir47","@kaspth There are some problems with stubbing `new` method.
````ruby
def stub_any_instance(klass)
object = klass.new
klass.stub(:new, object) do
yield(object)
end
end
````
* It won't work if object is initialized out side the block.
* How will we pass parameters to `new`
And also I tried to bring the method back in existing PR. but couldn't find a way to do this. Can you please help if we are going forward in this way?","1","2015-08-03T16:23:49Z"
"246772","18879","129239270","350807","kaspth","To solve your questions, can't we just add a second parameter that people can pass in? Like so:
```ruby
def stub_any_instance(klass, instance = klass.new)
klass.stub(:new, object) { yield instance }
end
```
I'd really like the final helper to use as little configuration as possible. I think it's better to cut down the bulk of the boilerplate and leave some complexity to the callers.","1","2015-08-09T20:52:54Z"
"246773","18879","129905157","1909242","ronakjangir47","@kaspth Updated PR. Please have a look","1","2015-08-11T14:28:37Z"
"246774","18879","130384327","350807","kaspth","Final comments, then I think it's ready to roll :+1:","1","2015-08-12T17:30:55Z"
"246775","18879","130514231","1909242","ronakjangir47","@kaspth Updated PR","1","2015-08-13T03:03:54Z"
"246776","18879","130568568","350807","kaspth","Alright, lets try this.","1","2015-08-13T07:56:29Z"
"246777","18879","131172067","1909242","ronakjangir47","@kaspth Thanks for review, I will try this.","1","2015-08-14T16:33:18Z"
"246778","18880","124869321","350807","kaspth","Thanks :smile:
I'm borderlining on considering this a cosmetic commit, but I stumbled on the `map` the other day too and thought of removing it myself. I can't decide ¯\_(ツ)_/¯","1","2015-07-25T18:26:27Z"
"246779","18880","124871336","6752349","antnvtkvsk","@kaspth why do you need it?","1","2015-07-25T18:40:29Z"
"246780","18880","124873045","350807","kaspth","It's ostensibly a cosmetic commit in that it *mostly* reformats the code while blowing away potentially valuable git history. It does improve the readability a tiny bit by shifting to the more idiomatic %i shortcut.
Your other change, however, is purely cosmetic and won't be accepted, so that has to go :smile:","1","2015-07-25T19:03:39Z"
"246781","18880","124874993","6752349","antnvtkvsk","I TRIED! :lollipop: ","1","2015-07-25T19:20:59Z"
"246782","18880","124875038","350807","kaspth","I'm sorry, but I don't understand what you're saying? :smile:","1","2015-07-25T19:22:05Z"
"246783","18880","124875509","350807","kaspth","@antnvtkvsk I see you've deleted your Rails fork. Is everything okay? :heart:
Though we might not have accepted this change, that doesn't mean you're a bad person or anything, so don't take any decision personally. Remember, you can always try again :heart:","1","2015-07-25T19:26:52Z"
"246784","18880","124877348","6752349","antnvtkvsk","hah, it's ok. I just decided it could be changed, why not","1","2015-07-25T19:36:58Z"
"246785","18880","124878377","350807","kaspth","That's great! If you want more help please check out our contributing guidelines: http://edgeguides.rubyonrails.org/contributing_to_ruby_on_rails.html - it's jam-packed with all the things we like to see from contributors :grin:","1","2015-07-25T19:39:47Z"
"246786","18882","1586627","9582","josevalim","/cc @drogus","1","2011-07-16T11:00:22Z"
"246787","18882","1586981","5004","drogus","@loz it makes sense for me, but please take into account that user can skip gemspec: https://github.com/rails/rails/blob/master/railties/lib/rails/generators/rails/plugin_new/plugin_new_generator.rb#L153 We should skip that line in such situation. ","1","2011-07-16T13:58:16Z"
"246788","18882","1587026","580772","loz","@drogus, I have updated the file to not add the line if --skip-gemspec is specified. Do I need to do another pull request for this, or will this one be just fine? [Edit: I see that the commit is included already so I guess that answers that ;) ]","1","2011-07-16T14:22:44Z"
"246789","18882","1587096","52642","spastorino","@loz can you squash both commits in one and push -f to your 3-1-stable branch, this will fix the pull request ;).
Also can you do another pull request for master?.
Thanks a lot!.","1","2011-07-16T14:48:45Z"
"246790","18883","124952813","350807","kaspth","Thanks!","1","2015-07-26T07:19:55Z"
"246791","18884","124963220","1943787","searover",":+1: ","1","2015-07-26T09:14:55Z"
"246792","18885","145407034","833383","arthurnn","Looking good..
thanks! :heart: ","1","2015-10-05T01:07:58Z"
"246793","18885","147488861","11101","igorkasyanchuk","Please check my https://github.com/igorkasyanchuk/benchmark_methods has some connection to profiling.","1","2015-10-12T18:46:05Z"
"246794","18886","125090839","55829","chancancode","Congrats :smile:!","1","2015-07-27T05:30:15Z"
"246795","18887","138196799","1034","matthewd","@brainopia sorry this has sat for so long.
Can't we avoid the (quite undesirable) move of `proper_table_name` etc, by just passing the migration to `connection_dispatch`?","1","2015-09-07T06:00:01Z"
"246796","18887","138203139","1034","matthewd","Looking further at how the implementation goes through `connection_dispatch` / `connection_arguments`... is there actually merit to using the separate strategy class here? It feels like it'd be simpler to understand, work with, and adapt to future needs if we had version-specific control of the Migration class itself.
Strategy works when you have a consistent API, and you want to vary its behaviour. While the `method_missing` capture attempts to approximate that, what we're really seeking to vary is the API itself.","1","2015-09-07T06:21:13Z"
"246797","18887","138436337","1034","matthewd","I think best while looking at code, so I made a thing (#21538) to sketch out what I had in mind.
It does seem more comfortable, to me, to write the argument-adaptation code. What do you think?","1","2015-09-08T05:14:27Z"
"246798","18887","165666698","1034","matthewd","Addressed by #21538; thanks so much for you work on this :heart: :heart: :heart:","1","2015-12-18T04:08:01Z"
"246799","18888","125259162","833383","arthurnn","thanks","1","2015-07-27T16:12:11Z"
"246800","18889","128498784","47848","rafaelfranca","Backported in 1f3774c5bc5f3483ff9202ed51893dbe722a03c6","1","2015-08-06T20:31:14Z"
"246801","18889","128517185","987638","y-yagi","Thanks!","1","2015-08-06T21:37:42Z"
"246802","18890","125790312","402","trevorturk","Thanks for picking this up, @repinel! I'm not sure that filtering all parameters by default makes sense. Don't you think filtering the same things as the existing incoming parameter filter has makes more sense? ","1","2015-07-29T00:28:09Z"
"246803","18890","125791402","1685896","repinel","@trevorturk Yes. IMO, I would follow the existing behavior and keep it consistent. I'll wait for people to jump into discussion before changing it. Thanks!","1","2015-07-29T00:37:01Z"
"246804","18890","145542030","1685896","repinel","r? @rafaelfranca ","1","2015-10-05T14:13:33Z"
"246805","18890","145950014","1685896","repinel","@kaspth I updated it to use `fetch_header` instead of `request.env.fetch`. Thanks","1","2015-10-06T18:10:39Z"
"246806","18890","164211998","4912","sikachu","This needs to be rebased. Would you mind rebase this against master and force push to your branch?","1","2015-12-13T02:15:13Z"
"246807","18890","164268701","1685896","repinel","@sikachu It should be good now. Thanks","1","2015-12-13T15:38:33Z"
"246808","18891","125565508","5356517","yui-knk","I want someone's review !!","1","2015-07-28T11:26:48Z"
"246809","18891","125571530","354185","robin850","Nice catch, thanks! :-)","1","2015-07-28T11:47:22Z"
"246810","18892","125573252","5356517","yui-knk","@senny will merge this!","1","2015-07-28T11:54:50Z"
"246811","18892","125573704","5402","senny","Thank you! :yellow_heart:","1","2015-07-28T11:56:05Z"
"246812","18892","125574026","5356517","yui-knk","This is my just 100 commits! :)","1","2015-07-28T11:57:04Z"
"246813","18893","125684409","26328","carlosantoniodasilva","Thanks.","1","2015-07-28T17:23:56Z"
"246814","18893","125753432","987638","y-yagi","Thanks!","1","2015-07-28T21:04:10Z"
"246815","18894","125719312","47848","rafaelfranca","Thank you for the pull request. Could you explain where it is useful? `Array.wrap` is usually called using a variable, and in that case you can have a array or a object. If you are calling `Array.wrap` like the example:
```
Array.wrap(1, 2, 3, 4)
```
You should just make it an array:
```
[1, 2, 3, 4]
```
And save the `wrap` call. ","1","2015-07-28T18:57:09Z"
"246816","18894","125732039","7417034","krishnarohitreddy","Nice point, better syntax their should be more work around to remove nil objects,
","1","2015-07-28T19:38:58Z"
"246817","18895","125745671","350807","kaspth","I'm not sure what else is missing, but I've left you some comments now :smile:
I'm definitely :+1: on getting this published.","1","2015-07-28T20:32:05Z"
"246818","18895","125745942","354185","robin850","Thank you very much for your quick review! :heart:","1","2015-07-28T20:33:25Z"
"246819","18895","125756443","354185","robin850","@kaspth : Okay thanks, updated! :-)
Some comments aren't there anymore as they were inside the commit but here are the changes:
* s/Cache Digests/ActionView::Digestor.
* s/works/work.
* Created a ""Collection caching"" part under ""Fragment caching"".
* Removed ""as mentioned above"".","1","2015-07-28T21:17:13Z"
"246820","18895","125782794","10076","claudiob","Do you think we should still include Page caching and Action caching in this guide?
They have been removed from Rails a while ago.
I think we might be better off focusing on what Rails offers right now out of the box.","1","2015-07-28T23:39:49Z"
"246821","18895","125783144","10076","claudiob","Additionally, I think the very beginning of this guide could be improved. Right now it says:
> This guide will teach you what you need to know about avoiding that expensive round-trip to your database and returning what you need to return to the web clients in the shortest time possible.
>
> After reading this guide, you will know:
> * Page and action caching (moved to separate gems as of Rails 4).
> * Fragment caching.
> * Alternative cache stores.
> * Conditional GET support.
Since this is a guide, I think we can take a wider approach and introduce what caching is and why is beneficial. For instance:
> Caching means to store the content generated by a request and to reuse it when responding to similar requests.
> Caching is arguably one of the hardest problems in computer science.
> At the same time, it is the most effective way to boost the performance of an application.
> Through caching, web sites running on a single server with a single database can sustain a load of thousands of concurrent users.
> Rails provides a set of caching methods out of the box.
> This guide will teach you the scope and purpose of each one of them.
> Master these techniques and you will be able to scale your Rails applications, serving million of views without incurring in exorbitant delays or server bills.
","1","2015-07-28T23:42:40Z"
"246822","18895","125985730","354185","robin850","> Do you think we should still include Page caching and Action caching in this guide?
I vaguely remember that I asked this on Campfire once and IIRC, we should keep it in the guide ; it's extracted from Rails core but it is still maintained. At least, we aren't going in depth — just mentioning that these strategies exist.
> I think we can take a wider approach and introduce what caching is and why is beneficial
Good call! :+1: Commit 69e97ea08f7e52c47a5fc9c4b7ef1a3bd714a5ec adds that ; I took the liberty to set you as an author.
Thank you very much for your feedback!","1","2015-07-29T15:18:10Z"
"246823","18895","126075271","350807","kaspth","Great suggestions, @claudiob :smile:
@robin850 what the latest changes this is starting to feel really good :+1:","1","2015-07-29T19:45:30Z"
"246824","18895","126399994","354185","robin850","@kaspth : Thanks, updated! :-)","1","2015-07-30T16:51:25Z"
"246825","18895","127182614","354185","robin850","@kaspth : Much better, thanks! :+1: I didn't even know the expression ""to one up""!","1","2015-08-03T10:03:29Z"
"246826","18895","127187583","350807","kaspth","Alright, this feels good to me :+1:","1","2015-08-03T10:30:13Z"
"246827","18895","127188188","354185","robin850","Yay, thanks! \o/","1","2015-08-03T10:35:14Z"
"246828","18898","126019333","47848","rafaelfranca","If you want just to run tests you can always push to rails/rails since you have commit access.","1","2015-07-29T17:02:47Z"
"246829","18898","126394831","59744","schneems","Build is green, for some reason it's not showing up on the PR https://travis-ci.org/rails/rails/builds/73305474","1","2015-07-30T16:32:22Z"
"246830","18898","126396533","199","jeremy","Nice work @schneems !","1","2015-07-30T16:38:13Z"
"246831","18898","126397386","567626","vipulnsward",":horse_racing: ","1","2015-07-30T16:41:44Z"
"246832","18898","126397964","833383","arthurnn","Squash! =)","1","2015-07-30T16:44:26Z"
"246833","18898","126397965","47848","rafaelfranca"," :shipit:","1","2015-07-30T16:44:26Z"
"246834","18898","126398025","47848","rafaelfranca","Really nice work!","1","2015-07-30T16:44:36Z"
"246835","18898","126398144","833383","arthurnn",":heart: :heart: :heart: :heart: :heart: ","1","2015-07-30T16:44:55Z"
"246836","18898","126398442","6321","pixeltrix","@schneems well done :clap: ","1","2015-07-30T16:45:38Z"
"246837","18898","126783666","3791081","JMD1986","nice!","1","2015-07-31T18:55:49Z"
"246838","18898","126834008","45299","pcreux",":+1: :heart: :green_heart: :yellow_heart: ","1","2015-07-31T23:23:35Z"
"246839","18898","128560961","3078931","jjgh","@schneems thanks for making Rails so much better, one more time! ? ? ?","1","2015-08-07T02:02:14Z"
"246840","18898","128608859","1003691","nitinstp23","Nice work @schneems :beers: ","1","2015-08-07T06:14:05Z"
"246841","18898","128625933","192247","arteezy","@schneems bravo :clap: ","1","2015-08-07T07:45:54Z"
"246842","18898","128626032","127343","marcgg",":+1: :+1: :+1: Thanks a lot for this","1","2015-08-07T07:46:21Z"
"246843","18898","128740566","593857","arun057","Nice work @schneems ","1","2015-08-07T15:43:02Z"
"246844","18898","129411774","985537","coderxin","@schneems nice work! :clap: ","1","2015-08-10T11:23:15Z"
"246845","18898","129425408","160117","kennym","@schneems this is awesome :-) :+1: ","1","2015-08-10T12:19:56Z"
"246846","18898","129431207","5091","dmitry","Still a question, why not to use constants, instead of `forzen`? Because of the readability?","1","2015-08-10T12:53:55Z"
"246847","18898","129432620","1034","matthewd","@dmitry there is no reason *to* use constants. This is how you spell an immutable string literal in ruby; we want immutable string literals, so that's what we're doing.
(Also, @schneems has already pointed out that [constants may be slower](https://github.com/rails/rails/pull/21057#discussion_r36532115).)","1","2015-08-10T12:58:28Z"
"246848","18898","129446670","5091","dmitry","@matthewd thanks for pointing out.
Interestingly on my computer (with 2.1.5 and 2.2.2 rubies) this benchmark produces almost the same results for constant/freeze strings. But readability of `freeze` is better, except the times when it's repeating many times in a code, and you would like to inspect them with IDE or grep.","1","2015-08-10T13:22:51Z"
"246849","18898","129473544","92330","garysweaver",":+1: :+1: Nice work!","1","2015-08-10T14:27:01Z"
"246850","18898","144815920","1541261","alejandrodevs","@schneems Nice work!","1","2015-10-01T18:55:08Z"
"246851","18898","164359880","86755","lucascaton","@schneems Nice one! ツ","1","2015-12-14T06:47:25Z"
"246852","18898","184552035","1291980","swapnilabnave","Is this PR available in rails 3.2.22 or 3.2.22.1 ?","1","2016-02-16T07:00:43Z"
"246853","18898","184552486","5091","dmitry","@swapnilabnave no, it's only available for v5.0.0.beta2 v5.0.0.beta1.1 v5.0.0.beta1. You can see that by checking merge commit: https://github.com/rails/rails/commit/5373bf228d1273deae0ed03370ec4a63c580422b","1","2016-02-16T07:04:08Z"
"246854","18899","126038581","621238","prathamesh-sonpatki","Asset paths before this commit - https://gist.github.com/prathamesh-sonpatki/e0a96678b7ecf54e5bf8
After this commit - https://gist.github.com/prathamesh-sonpatki/4285ae91104c148f0e87","1","2015-07-29T17:56:16Z"
"246855","18899","129706568","621238","prathamesh-sonpatki","@rafaelfranca Can you please have a look?","1","2015-08-11T04:59:53Z"
"246856","18899","131658141","47848","rafaelfranca","This may introduce a performance problem like rails/sprockets-rails#232 did. Can we try to add it using sprockets-rails?","1","2015-08-17T02:13:09Z"
"246857","18899","131674846","621238","prathamesh-sonpatki","@rafaelfranca Do you mean using latest version of sprockets-rails?","1","2015-08-17T04:12:59Z"
"246858","18899","131675104","47848","rafaelfranca","Yeas, and changing sprockets-rails to include this path in assets load path for Rails < 5 too","1","2015-08-17T04:15:22Z"
"246859","18899","131675471","621238","prathamesh-sonpatki","Thanks. I will work on sprockets-rails part first then :smile:. Should I close this issue for now?","1","2015-08-17T04:21:28Z"
"246860","18899","131675969","47848","rafaelfranca",":+1: ","1","2015-08-17T04:28:40Z"
"246861","18900","126918310","5356517","yui-knk","related https://github.com/rails/rails/blob/master/activesupport/lib/active_support/core_ext/object/to_query.rb#L40","1","2015-08-01T14:23:37Z"
"246862","18901","126893297","5402","senny","I don't think we should change this. As long as we have [`core_ext/object/to_param.rb`](https://github.com/rails/rails/blob/master/activesupport/lib/active_support/core_ext/object/to_param.rb) this is the extension that you should load when you rely on `#to_param`. Sure, currently this file is only an alias but nonetheless from a user perspective it's the relevant entry point.","1","2015-08-01T09:51:17Z"
"246863","18901","126894588","5356517","yui-knk","OK, thanks!","1","2015-08-01T09:59:49Z"
"246864","18902","126693920","5402","senny","@cmisenas thank you :yellow_heart: ","1","2015-07-31T13:38:00Z"
"246865","18902","126698597","3933148","cmisenas",":smile: :+1: ","1","2015-07-31T13:55:23Z"
"246866","18904","126531852","1840945","meinac","Hi @dmitry. I couldn't realise the real world example. Can you give a code example to show as a developer in which case I need to check the validity of an object in multiple contexts.","1","2015-07-31T00:46:06Z"
"246867","18904","126691674","5091","dmitry","@meinac hey, thank you for the critics!
For example, imagine you have a multiple steps before you could create an order. You would like to add more and more validations on each steps, so each step will validate all the previous step validations + current one.
Another example, actually what I've got recently (but we are still on rails 3.2.x, hopefully will update soon or later), when you want to validate model for almost everything, except presence of the user, in that case when user isn't logged in yet or not created his profile, which will be created through the nested attributes.
I can think of other possible cases, which can be solved a other way around, but in some cases it's really better to have this feature to make everything easier.","1","2015-07-31T13:30:25Z"
"246868","18904","131403189","235844","gaurish",":+1: This would enable to remove conditional validations. Much needed feature.","1","2015-08-15T17:31:47Z"
"246869","18904","131448772","5091","dmitry","Through it's 5x slower, it's really helpful feature.
```ruby
require 'benchmark'
a = [:a, :b]
b = :b
n = 10000000
Benchmark.bm do |x|
x.report { n.times do !(Array(a) & Array(b)).empty? end }
x.report { n.times do Array(a).include?(b) end }
end
```
```
user system total real
5.220000 0.010000 5.230000 ( 5.223742)
1.070000 0.000000 1.070000 ( 1.066095)
```","1","2015-08-15T21:17:48Z"
"246870","18904","136694241","5091","dmitry","I would be glad to rebase this PR if anyone from the core agrees to merge it into the master.","1","2015-09-01T12:22:57Z"
"246871","18904","136709108","350807","kaspth","How much does `valid?` being slowed down impact `save` (which calls `valid?`)?
I don't think this change is worth it over just doing `valid?(:context1) && valid?(:context2)`.","1","2015-09-01T12:59:06Z"
"246872","18904","136713939","5091","dmitry","@kaspth I've answered on the both questions above :)
With `valid?(:context1) && valid?(:context2)` you will get an errors of only `:context2`, because each time `valid?` resets an errors. Yes, it can be workaround with accumulator, but it's really not nice to maintain + errors state isn't inside the model record, but outside of it.
Slowdown is 5x times, but can be improved a little bit with `is_a?(String) || is_a?(Symbol)` check.","1","2015-09-01T13:09:32Z"
"246873","18904","136714931","350807","kaspth","Duh, sorry! :smile:
> Slowdown is 5x times,
Is that for `save`? I don't think we can't accept this if `save` is slowed down 5x.","1","2015-09-01T13:12:06Z"
"246874","18904","136716059","5091","dmitry","Not `save` but this code:
```ruby
x.report { n.times do !(Array(a) & Array(b)).empty? end }
x.report { n.times do Array(a).include?(b) end }
```
I believe it will slowdown `save` by 1.000001. How can I benchmark this part of the code easily, without spending too much time on it?
PS. Looks like it's much easier to close this PR, because such cases might be moved to the `if` blocks, when required, if you are really think `Array#include?` much faster than `Array#&` (in reality it changes only that).","1","2015-09-01T13:16:14Z"
"246875","18904","136942850","47848","rafaelfranca","I don't think this slowdown will change anything. This feature is something that I wanted to implement some times so I think it is worth.","1","2015-09-02T05:47:04Z"
"246876","18904","138370001","47848","rafaelfranca","It broke Active Record tests. I revert it. Could you take a look on these failures and open a new PR?","1","2015-09-07T20:18:17Z"
"246877","18904","138382813","5091","dmitry","@rafaelfranca fixed at #21535
PS. Broken because some code left when I tried to make it to work as splat params.","1","2015-09-07T21:45:17Z"
"246878","18905","126313880","350807","kaspth","Thanks!","1","2015-07-30T12:55:10Z"
"246879","18906","134578542","354185","robin850","Thanks!","1","2015-08-25T13:04:33Z"
"246880","18907","126443791","44640","byroot","I did a quick grep over the codebase, and it seems there is quite a lot of occurrences of `.any?` without a block passed.
Some of them might be legit, and most of them not in actual hotspots, but I wonder if you'd be interested in a PR to convert them.","1","2015-07-30T19:17:54Z"
"246881","18907","126444347","47848","rafaelfranca","If they are not in hotspots there is no reason to change them, but if they are please send a PR.","1","2015-07-30T19:21:00Z"
"246882","18907","126444996","59744","schneems","I agree, with @rafaelfranca. The `!empty?` is not as nice to work with, and should only be used for performance sensitive areas.
If you wanted to tackle this, take a look at my methodology on the last PR. You could get hotpots with some metaprogramming
```
class Array
HOTPOTS = Hash.new { 0 }
def any?(*args, &block)
HOTPOTS[caller.first] += 1 if block_not_given
puts HOTPOTS.inspect
super
end
end
```
Then make the changes on the highest counts. Finally benchmark with derailed benchmarks `derailed exec perf:test` run a few times against master and a few times against your patch. If the change makes a consistently better measureable performance improvement i.e. not just a better number once, then we should shoot for it.
","1","2015-07-30T19:23:51Z"
"246883","18907","128562124","653258","cmaitchison","`!empty?` differs to `any?` when the array contains only `nil` objects
```
irb(main):001:0> [nil].any?
=> false
irb(main):002:0> [nil].empty?
=> false
```
Swapping these two lines in Ruby itself should bring the performance of `empty any?` in line with `empty !empty?` without side-effect - https://github.com/ruby/ruby/blob/95c84eac49064986bfd877ccf4d7e91e9929e833/array.c#L5524-L5526
","1","2015-08-07T02:12:18Z"
"246884","18907","128562643","47848","rafaelfranca","@cmaitchison seems you found a good patch for ruby/ruby. :shipit:","1","2015-08-07T02:14:47Z"
"246885","18907","128563929","653258","cmaitchison","@rafaelfranca Yeah, there are a few more marginal gains to be had in even just that file. Just familiarising myself with the contribution process now... seems relatively heavyweight :P ","1","2015-08-07T02:19:10Z"
"246886","18907","128564382","59744","schneems","I actually tried already, when I compiled it helps but it's still slower. It looks like `empty? ` gets a further optimization here: https://github.com/ruby/ruby/blob/95c84eac49064986bfd877ccf4d7e91e9929e833/insns.def#L1964-L2000 (maybe?)
@cmaitchison let me know if you have questions with compiling or contributing. I don't know much, but happy to share what I do know.","1","2015-08-07T02:21:20Z"
"246887","18907","128738946","44640","byroot","Even if theoretically `.any?` should be as fast as `!empty?` on empty arrays, it will always be slower on non empty array since it must ensure at least one value of the array is truthy.
`any?` is intended to be the ""inverse"" of `all?` not of `empty?`.","1","2015-08-07T15:36:00Z"
"246888","18908","126507588","8597439","r11runner","Thanks for the comment, I've corrected it.
Sorry, I didn't know that lines should be wrapped at 80 chars.","1","2015-07-30T22:15:06Z"
"246889","18908","126635292","8597439","r11runner","Added the article ""the"" :)","1","2015-07-31T10:18:41Z"
"246890","18908","126635617","2415484","jonatack","That was quick :smiley: ","1","2015-07-31T10:20:12Z"
"246891","18908","126656506","8597439","r11runner","Punctuation and the missing spaces have been corrected in the last commit.
I also changed ""will create"" to ""creates"", because according to the API Documentation Guidelines we should prefer present tense.","1","2015-07-31T11:10:25Z"
"246892","18908","126943907","8597439","r11runner","In the last commit:
- removed the ellipses
- changed has_and_belongs_to_many => has_and_belongs_to_many
- added ""which"" to line 376
- moved the note about the name of the join table to the section about the :table_name option","1","2015-08-01T18:33:21Z"
"246893","18908","127020152","8597439","r11runner","Sorry, my mistake. I've corrected it in the last commit.","1","2015-08-02T12:07:36Z"
"246894","18908","127419594","8597439","r11runner","@claudiob Thanks for this remark. I agree and have deleted the line ""which creates the columns...""
I've squashed all commits into 1.
Let me know, if there is something else to do.","1","2015-08-03T22:13:36Z"
"246895","18908","127472462","10076","claudiob","Thanks! :ribbon: ","1","2015-08-04T04:17:09Z"
"246896","18909","126515798","47848","rafaelfranca","I think we already made this change and had to revert. Could you check the
old PRs?
On Thu, Jul 30, 2015, 19:27 Mehmet Emin İNAÇ <notifications@github.com>
wrote:
> I can't find any test case for current behaviour so I think this is not
> intended. If user tries to save object with validate: false option
> related associations should be saved with validate: false so user can
> save object and its invalid associations.
> Fixes #21058 <https://github.com/rails/rails/issues/21058>
> ------------------------------
> You can view, comment on, or merge this pull request online at:
>
> https://github.com/rails/rails/pull/21077
> Commit Summary
>
> - Autosave associations should respect to value of validate option
>
> File Changes
>
> - *M* activerecord/CHANGELOG.md
> <https://github.com/rails/rails/pull/21077/files#diff-0> (6)
> - *M* activerecord/lib/active_record/autosave_association.rb
> <https://github.com/rails/rails/pull/21077/files#diff-1> (10)
> - *M* activerecord/test/cases/autosave_association_test.rb
> <https://github.com/rails/rails/pull/21077/files#diff-2> (32)
>
> Patch Links:
>
> - https://github.com/rails/rails/pull/21077.patch
> - https://github.com/rails/rails/pull/21077.diff
>
> —
> Reply to this email directly or view it on GitHub
> <https://github.com/rails/rails/pull/21077>.
>
","1","2015-07-30T23:05:32Z"
"246897","18909","126526009","1840945","meinac","@rafaelfranca sorry but I've looked at the history of the `autosave_association.rb` and couldn't find any change about this. It's possible for me to miss something in the history :confused: Can you please send me the link of the pr in your free time if you can find? If is there a good reason to keep this behaviour at least we have to create test cases to show this is intended behaviour.","1","2015-07-31T00:09:11Z"
"246898","18909","126527326","47848","rafaelfranca","I think it was about validation context, not skiping validations
On Thu, Jul 30, 2015, 21:09 Mehmet Emin İNAÇ <notifications@github.com>
wrote:
> @rafaelfranca <https://github.com/rafaelfranca> sorry but I've looked at
> the history of the autosave_association.rb and couldn't find any change
> about this. It's possible for me to miss something in the history [image:
> :confused:] Can you please send me the link of the pr in your free time
> if you can find? If is there a good reason to keep this behaviour at least
> we have to create test cases to show this is intended behaviour.
>
> —
> Reply to this email directly or view it on GitHub
> <https://github.com/rails/rails/pull/21077#issuecomment-126526009>.
>
","1","2015-07-31T00:15:53Z"
"246899","18909","127085656","1840945","meinac","@rafaelfranca I think you are pointing [this](https://github.com/rails/rails/commit/5f8274efe128ffeec8fa3179460f5167a078f007) pull request. But this change is not about this.
Normally if you don't pass `validate: false` option to save method then it will check validations about child relation but if you pass `validate: false` option to save method then it will bypass the validations and tries to save child relation with validations this is why I've created this pull request. The point is, it bypasses validations and tries to save relation with `validate: true`. If it bypasses validations it should save relation with `validation: false`.","1","2015-08-03T00:00:56Z"
"246900","18909","128541240","1840945","meinac","@rafaelfranca I fixed the problems you've mentioned. Also I've created a method for passing validation option through associations. By this method we will know if we need to validate while saving associated object or not.","1","2015-08-06T23:51:24Z"
"246901","18909","128561087","47848","rafaelfranca","I'm not sure if this is fixing anything. [These callbacks](https://github.com/vngrs/rails/blob/autosave_association_respect_to_validate/activerecord/lib/active_record/autosave_association.rb#L208) will still run and validate the associated validated.","1","2015-08-07T02:03:34Z"
"246902","18909","128575142","1840945","meinac","@rafaelfranca [This](https://github.com/vngrs/rails/blob/autosave_association_respect_to_validate/activerecord/lib/active_record/autosave_association.rb#L208) is just a method for defining validation callbacks so if you give `validate: false` option to save method these validations won't work like the others.
For example:
```ruby
class Foo < ActiveRecord::Base
belongs_to :bar, validate: true # in this line the validation callback will be created and registered with 'autosave_associated_records_for_bar' name
end
class Bar < ActiveRecord::Base
has_one :foo
end
foo = Foo.new
foo.build_bar
foo.save(validate: false) #this will bypass all validation methods for foo object so 'autosave_associated_records_for_bar' method will be bypassed too.
```
As you can see these methods will not work if you pass `validate: false`.","1","2015-08-07T03:05:47Z"
"246903","18911","126831512","1840945","meinac","@bukue could you please add documentation about it?","1","2015-07-31T23:04:59Z"
"246904","18911","126834466","1486951","bukue","@meinac done!","1","2015-07-31T23:28:44Z"
"246905","18911","127401519","1486951","bukue","@meinac @kaspth I just submitted the changes that you guys asked. This is ready for another review.","1","2015-08-03T20:42:31Z"
"246906","18911","127406172","350807","kaspth","@bukue doing great. Now we just need you to squash your commits down to one :grin:","1","2015-08-03T21:05:09Z"
"246907","18911","127424905","1486951","bukue","@kaspth done!","1","2015-08-03T22:42:52Z"
"246908","18911","127425968","1034","matthewd","I'm a bit dubious as to whether we actually want this... but that notwithstanding, shouldn't the `split` change too?","1","2015-08-03T22:50:59Z"
"246909","18911","127427790","1486951","bukue","@matthewd Why are you dubious?
The main reason to split with ""\n"" is to split by lines. I see how it would be useful to split it by ""\r\n"" or any other sequence that helps defining a line. Unless somebody else considers it not useful, I will gladly implement it. ","1","2015-08-03T23:04:32Z"
"246910","18911","127437043","1486951","bukue","@matthewd added the changes you suggested","1","2015-08-03T23:58:42Z"
"246911","18911","127445288","1034","matthewd","Why would your `line_splitter` and `break_sequence` differ? My concern was that you'd seemingly-arbitrarily chosen to replace *some* of the instances of `""\n""` in the method with a parameter -- not that we hadn't added enough parameters.
What does this offer over `word_wrap(...).gsub(""\n"", ""\r\n"")` ?
If I use a `break_sequence` of `""...\nand then, ""`, how does that interact with the line width? I can obviously see the answer... but is that going to be what callers would expect, and/or find most useful?
""Great!, this is just what I need... I'll wrap on `""<br>\n"".html_safe`""","1","2015-08-04T01:07:29Z"
"246912","18911","127446398","1486951","bukue","Yeah, you can totally have the same result doing word_wrap(...).gsub(""\n"", ""\r\n""). Actually, this PR started because we were doing the exact same thing at work because we needed the end of lines to be indicated with ""\r\n"".
I see your point, although I feel this changes give you more legibility and flexibility. Let's see what the other guys think. ","1","2015-08-04T01:19:21Z"
"246913","18911","128539903","1486951","bukue","@kaspth @meinac what do you guys think?","1","2015-08-06T23:39:06Z"
"246914","18911","129011626","350807","kaspth","This feels like way too much code for me for something that can be done with `gsub` ¯\_(ツ)_/¯","1","2015-08-08T16:50:13Z"
"246915","18911","129014134","1840945","meinac","I agree with @kaspth. If you are doing this many times in your application then I recommend you to create a method which does what do you want for your application. ","1","2015-08-08T17:19:32Z"
"246916","18911","129051096","1486951","bukue","This approach is cheaper since you don't have to transverse your string twice like you would do using gsub. Also, all I am doing is parametrizing things that otherwise would be hardcoded.
This would be my first commit to the rails repository so I might be going to far with my changes. So if you guys believe this change is too much I am happy to roll it back to just parametrizing the line break.
What do you guys think?","1","2015-08-08T21:51:45Z"
"246917","18911","130081596","1486951","bukue","@kaspth All done!","1","2015-08-11T21:21:09Z"
"246918","18911","130083939","350807","kaspth","Thanks","1","2015-08-11T21:30:22Z"
"246919","18912","127291529","1840945","meinac","@kaspth I've changed the pr. Anything else?","1","2015-08-03T16:09:36Z"
"246920","18912","127292361","350807","kaspth","Great, thanks :heart:","1","2015-08-03T16:10:53Z"
"246921","18913","126922536","59744","schneems","Thanks :heart:","1","2015-08-01T14:42:23Z"
"246922","18913","126922597","5356517","yui-knk","thanks merge!","1","2015-08-01T14:43:51Z"
"246923","18915","134161755","5402","senny","@y-yagi thank you :yellow_heart: ","1","2015-08-24T11:34:42Z"
"246924","18915","134201030","987638","y-yagi","@senny Thanks for reviewing! ","1","2015-08-24T13:30:10Z"
"246925","18917","127060277","1840945","meinac","@senny actually it does not make any change encapsulating only first argument or both of them but I've changed it according to your suggestion.","1","2015-08-02T19:42:13Z"
"246926","18917","127066101","350807","kaspth","While it would still work, @senny's feels a bit easier to understand :)
Thanks!","1","2015-08-02T20:16:07Z"
"246927","18919","127161445","1955930","aditya-kapoor","@senny reverted the definition... :smiley: ","1","2015-08-03T08:19:16Z"
"246928","18920","127012786","3948","arunagw","thanks :-)","1","2015-08-02T10:32:40Z"
"246929","18920","127015587","987638","y-yagi",":)","1","2015-08-02T11:03:50Z"
"246930","18921","127045305","59744","schneems",":rocket: thanks","1","2015-08-02T17:08:15Z"
"246931","18922","852441","412101","dre3k","Going to make new pull request.","1","2011-03-09T17:12:11Z"
"246932","18923","127048885","59744","schneems","I ran this local and my test app does hit this optimization. Doing some math we save 4.3108037795403217e-07 seconds per iteration and I hit this 1776 times per request. So this PR would buy me 1776 * 4.3108037795403217e-07 # => 0.0007655987512463612 seconds per request or 0.7655987512463611 miliseconds per request. So over the course of 1000 requests we would save `765.5` miliseconds. Great work.","1","2015-08-02T17:42:54Z"
"246933","18923","127051128","22333","bquorning","Thanks!
> So over the course of 1000 requests we would save 765.5 miliseconds.
It all adds up.","1","2015-08-02T18:04:54Z"
"246934","18923","127055648","59744","schneems","Totally. Two of these patches would be 1.5 ms per request and 1.5 seconds over 1000 requests. 20 of them would save us 15 seconds over 1000 requests. :clap:","1","2015-08-02T19:04:30Z"
"246935","19064","132637735","2741","dhh","?","1","2015-08-19T15:25:27Z"
"246936","19064","132656017","509611","strand",":heart: ","1","2015-08-19T16:04:08Z"
"246937","19064","132688872","24634","Ovid","As an aside, could it be called a Standard of Conduct instead? I get tired of juvenile ""CoC"" jokes at conferences.","1","2015-08-19T16:38:45Z"
"246938","19064","132781887","322663","tzs","That's a pretty good CoC, except for one big unclear section: ""This code of conduct applies both within project spaces and in public spaces when an individual is representing the project or its community"".
What does ""representing the project or its community mean""? For example, suppose X has their resume on their website and lists there that they are a contributor to the project. Suppose also on their website they have copies of their erotic Harry Potter fan fiction, which contains sexualized language.
OK, or violation?
I think you'll save yourself a lot of drama in the future if you add a sentence clarifying this. Personally, I'd recommend saying that merely listing your contributions to or membership in the project as part of biographical information (such as a resume, a LinkedIn profile, a personal Facebook or Twitter or similar profile, etc.) is not representing the project, but if you want to go the other way and make all those count, fine. The important thing is to make it clear which it is.
","1","2015-08-19T20:59:44Z"
"246939","19064","132785027","2741","dhh","That would not be representing the project in my definition of the term.
Representing the project would be speaking at a conference, hosting a user
group, managing a mailing list, mentoring students, or any such involvement
that's connected to the project.
If you want to write erotic Harry Potter fan fiction in addition to your
Rails contributions, knock yourself out.
It's all on a sliding scale, though. If you want to be a raging neo nazi
who's also chairing a sub-reddit on the topic of hate, well, then that
might be your hobby, but I don't think it's compatible with being in polite
company of Rails contributors.
Now, the world is rarely that black and white. Shades of grey will be
interpreted by the Rails core group, as the designated project maintainers,
in the spirit of this CoC.
On Wed, Aug 19, 2015 at 4:00 PM, Tim Smith <notifications@github.com> wrote:
> That's a pretty good CoC, except for one big unclear section: ""This code
> of conduct applies both within project spaces and in public spaces when an
> individual is representing the project or its community"".
>
> What does ""representing the project or its community mean""? For example,
> suppose X has their resume on their website and lists there that they are a
> contributor to the project. Suppose also on their website they have copies
> of their erotic Harry Potter fan fiction, which contains sexualized
> language.
>
> OK, or violation?
>
> I think you'll save yourself a lot of drama in the future if you add a
> sentence clarifying this. Personally, I'd recommend saying that merely
> listing your contributions to or membership in the project as part of
> biographical information (such as a resume, a LinkedIn profile, a personal
> Facebook or Twitter or similar profile, etc.) is not representing the
> project, but if you want to go the other way and make all those count,
> fine. The important thing is to make it clear which it is.
>
> —
> Reply to this email directly or view it on GitHub
> <https://github.com/rails/rails/pull/21292#issuecomment-132781887>.
>
","1","2015-08-19T21:08:19Z"
"246940","19175","136147827","350807","kaspth","Great and thanks for the link in the description. That made it way easy to merge ?","1","2015-08-30T14:23:31Z"
"246941","19175","136194280","987638","y-yagi","Thanks :)","1","2015-08-30T21:14:19Z"
"246942","19176","136234264","7468109","rails-bot","Thanks for the pull request, and welcome! The Rails team is excited to review your changes, and you should hear from @senny (or someone else) soon.
If any changes to this PR are deemed necessary, please add them as extra commits. This ensures that the reviewer can see what has changed since they last reviewed the code. Due to the way GitHub handles out-of-date commits, this should also make it reasonably obvious what issues have or haven't been addressed. Large or tricky changes may require several passes of review and changes.
Please see [the contribution instructions](http://edgeguides.rubyonrails.org/contributing_to_ruby_on_rails.html) for more information.
","1","2015-08-31T02:07:46Z"
"246943","19176","136242228","1529387","sgrif","Can you please give context about why this change is needed in your commit message?","1","2015-08-31T03:26:56Z"
"246944","19176","136242291","1529387","sgrif","This also caused some test failures that look legitimate.","1","2015-08-31T03:27:40Z"
"246945","19176","137173995","47848","rafaelfranca","You need to run `bin/generate_tables` at activesupport folder and commit the generated file too.","1","2015-09-02T17:09:10Z"
"246946","19176","137365861","4547169","optimisticanshul","@sgrif everything is green now.
@rafaelfranca :+1:
","1","2015-09-03T07:46:40Z"
"246947","19176","137525710","26328","carlosantoniodasilva","@justanshulsharma can you add a changelog entry as well? In case it causes any issue to anyone using the framework, that's probably the first place people will look at. Please amend your commit to include that, thanks!","1","2015-09-03T17:47:10Z"
"246948","19176","137529343","4547169","optimisticanshul","@carlosantoniodasilva Done :+1: ","1","2015-09-03T18:00:59Z"
"246949","19176","137545632","26328","carlosantoniodasilva","Thanks!","1","2015-09-03T19:13:41Z"
"246950","19177","136288087","7468109","rails-bot","r? @chancancode
(rails_highfive has picked a reviewer for you, use r? to override)","1","2015-08-31T07:34:37Z"
"246951","19177","136288816","10076","claudiob","And see https://travis-ci.org/rails/rails/jobs/78001204 for the Travis log of this pull request (without any more deprecation warnings).","1","2015-08-31T07:39:05Z"
"246952","19178","136370136","7468109","rails-bot","Thanks for the pull request, and welcome! The Rails team is excited to review your changes, and you should hear from @eileencodes (or someone else) soon.
If any changes to this PR are deemed necessary, please add them as extra commits. This ensures that the reviewer can see what has changed since they last reviewed the code. Due to the way GitHub handles out-of-date commits, this should also make it reasonably obvious what issues have or haven't been addressed. Large or tricky changes may require several passes of review and changes.
Please see [the contribution instructions](http://edgeguides.rubyonrails.org/contributing_to_ruby_on_rails.html) for more information.
","1","2015-08-31T13:25:48Z"
"246953","19178","136414264","1080678","eileencodes","Hi @EugZol! Thanks for the PR. I'm at a conference right now and will look at this when I get back. I'll need to also discuss with others if this is a feature we want to add to ActiveRecord. ","1","2015-08-31T15:56:41Z"
"246954","19178","136421115","835","EugZol","Hi @eileencodes! Thanks for your attention. This feature just feels so natural, and many SO questions from Rails developers which I referred in my message above (there are much more) prove that it's not only my personal opinion. Anyway, looking forward to your review.","1","2015-08-31T16:27:51Z"
"246955","19178","136597050","235844","gaurish","How is this different then [exists method](http://api.rubyonrails.org/classes/ActiveRecord/FinderMethods.html#method-i-exists-3F)?","1","2015-09-01T06:18:42Z"
"246956","19178","136612432","8417720","benoittgt","@gaurish it seems that *exists method* only returns boolean value rather than returning items of the request.","1","2015-09-01T07:25:52Z"
"246957","19178","136633672","835","EugZol","@benoittgt that is correct
@gaurish `exists?` method answers the question ""Whether a record with given parameters exists?"". `where_exists` (no question mark at the end for a reason) issues a command ""Select all records, for which *some other (associated) record* with given parameters exists"".
Actually it might make sense to chain them.
For example, let's say you need to know if there is a user which belongs to group named ""Admin group"":
User.where_exists(:group, name: ""Admin group"").exists?
# or
Group.where(name: ""Admin group"").where_exists(:users).exists?","1","2015-09-01T08:21:02Z"
"246958","19178","136676052","835","EugZol","I've added gist with benchmark:
https://gist.github.com/EugZol/756a5992f11502a2c6ab
Excerpt:
Benchmark.ips do |x|
x.report(""Exists: Using joins"") do
ActiveRecord::Base.uncached do
Group.joins(:developers).where.not(""developers.id"" => nil).pluck(:id)
end
end
x.report(""Exists: Using where_exists"") do
ActiveRecord::Base.uncached do
Group.where_exists(:developers).pluck(:id)
end
end
x.report(""Not Exists: Using joins"") do
ActiveRecord::Base.uncached do
Group.
joins(""LEFT JOIN developers ON developers.group_id = groups.id"").
where(""developers.id"" => nil).pluck(:id)
end
end
x.report(""Not Exists: Using where_not_exists"") do
ActiveRecord::Base.uncached do
Group.where_not_exists(:developers).pluck(:id)
end
end
x.compare!
end
Results I got: https://gist.github.com/EugZol/454941a492e5de06d52b
Perhaps I didn't come up with the best test cases, so if somebody's willing to suggest some way of rewriting the benchmark I'll be glad to do that.
The conclusion is: suggested `where_exists` and `where_not_exists` methods are performing with similar speed as their `.joins(...).where(...)` counterparts. The only exception is `has_many :through` association with MySQL – with it even Ruby processing is faster than both JOIN and EXISTS, and EXISTS itself is extremely slow. Probably that's because something is wrong with my MySQL configuration. With PostgreSQL the results are sane.","1","2015-09-01T11:07:23Z"
"246959","19178","136933739","1529387","sgrif","I'm strongly against this feature. There are several other missing bits for where clauses that we have chosen not to implement that I think we would before this feature. We allow SQL strings for this kind of thing, and combined with `Relation#to_sql`, handles this case sufficiently. ","1","2015-09-02T04:18:55Z"
"246960","19178","136959437","835","EugZol","@sgrif Could I ask you to elaborate on that? Are you saying, that some other features are blocking that one in some way from being implemented? If I understood correctly, which ones are those?","1","2015-09-02T07:17:18Z"
"246961","19178","137061798","1529387","sgrif","No, what I mean are, there are other features that would be accepted before
this one, which we have rejected as well.
On Wed, Sep 2, 2015, 1:17 AM Eugene Zolotarev <notifications@github.com>
wrote:
> Could I ask you to elaborate on that? Are you saying, that some other
> features are blocking that one in some way from being implemented? If I
> understood correctly, which ones are those?
>
> —
> Reply to this email directly or view it on GitHub
> <https://github.com/rails/rails/pull/21438#issuecomment-136959437>.
>
","1","2015-09-02T12:42:20Z"
"246962","19179","136686097","11460","pwnall","I just ran into this too and filed #21446. My PR also fixes the broken tests.","1","2015-09-01T11:51:00Z"
"246963","19180","136650292","7468109","rails-bot","Thanks for the pull request, and welcome! The Rails team is excited to review your changes, and you should hear from @chancancode (or someone else) soon.
If any changes to this PR are deemed necessary, please add them as extra commits. This ensures that the reviewer can see what has changed since they last reviewed the code. Due to the way GitHub handles out-of-date commits, this should also make it reasonably obvious what issues have or haven't been addressed. Large or tricky changes may require several passes of review and changes.
Please see [the contribution instructions](http://edgeguides.rubyonrails.org/contributing_to_ruby_on_rails.html) for more information.
","1","2015-09-01T09:36:26Z"
"246964","19180","136705258","350807","kaspth","Thanks and welcome to Rails! Remember to add `[ci skip]` to your commit message for documentation changes. That way, Travis, our CI server won't run :grin:","1","2015-09-01T12:50:52Z"
"246965","19181","136684765","7468109","rails-bot","r? @schneems
(@rails-bot has picked a reviewer for you, use r? to override)","1","2015-09-01T11:42:26Z"
"246966","19181","136684826","11460","pwnall","r? @rafaelfranca @schneems ","1","2015-09-01T11:42:51Z"
"246967","19181","136686519","11460","pwnall","The CI breakage in `guides` references the wrong commit. My commit SHA1 is 1c4679b063fff6d6b73b3cdc7cccc5f29057fd29. Perhaps `guides` uses master instead of the new commit?","1","2015-09-01T11:53:43Z"
"246968","19181","136687003","26328","carlosantoniodasilva","Sorry, I've just merged #21443 and committed the same fix for the tests on 8ce0fdb5c412a5083dff3ecb863e86c1853651d7 before seeing your PR, otherwise I'd have merged yours. Thanks for your contribution.","1","2015-09-01T11:56:28Z"
"246969","19181","136687354","11460","pwnall","As long as things are fixed, everything is good! Any chance of prodding the broken PR's author to actually write tests for it?","1","2015-09-01T11:57:19Z"
"246970","19181","136689166","26328","carlosantoniodasilva","We could/should yeah, but if you want to try and add a test, that'd be cool too :).","1","2015-09-01T12:06:42Z"
"246971","19181","136702141","11460","pwnall","Done in #21449 :)","1","2015-09-01T12:41:42Z"
"246972","19182","136689222","7468109","rails-bot","r? @eileencodes
(@rails-bot has picked a reviewer for you, use r? to override)","1","2015-09-01T12:07:09Z"
"246973","19182","136706130","1955930","aditya-kapoor","Since @eileencodes is away so r? @kaspth can you pls review my PR?","1","2015-09-01T12:52:59Z"
"246974","19182","136710283","350807","kaspth","Thanks :grin:","1","2015-09-01T13:01:37Z"
"246975","19182","136710947","1955930","aditya-kapoor","thanks for merging...:beers: ","1","2015-09-01T13:02:33Z"
"246976","19183","136703977","1955930","aditya-kapoor","Duplicate of #21447","1","2015-09-01T12:46:16Z"
"246977","19183","136710202","350807","kaspth","Closing as a duplicate. Thanks!","1","2015-09-01T13:01:27Z"
"246978","19184","136714865","1284716","Gaurav2728","Cosmetic change :zzz:","1","2015-09-01T13:11:58Z"
"246979","19184","136715481","350807","kaspth","Thanks!
@Gaurav2728 we treat grammar changes a bit differently. If it had been a typo fix in a variable, then yes, I wouldn't have merged :)","1","2015-09-01T13:13:24Z"
"246980","19184","136715687","1284716","Gaurav2728","@kaspth :yellow_heart: ","1","2015-09-01T13:14:20Z"
"246981","19185","136750623","7468109","rails-bot","Thanks for the pull request, and welcome! The Rails team is excited to review your changes, and you should hear from @schneems (or someone else) soon.
If any changes to this PR are deemed necessary, please add them as extra commits. This ensures that the reviewer can see what has changed since they last reviewed the code. Due to the way GitHub handles out-of-date commits, this should also make it reasonably obvious what issues have or haven't been addressed. Large or tricky changes may require several passes of review and changes.
Please see [the contribution instructions](http://edgeguides.rubyonrails.org/contributing_to_ruby_on_rails.html) for more information.
","1","2015-09-01T14:54:31Z"
"246982","19185","136873154","59744","schneems","Thanks for the pull request! :heart: can you squash these two changes together, and we can get this merged in. The http://edgeguides.rubyonrails.org/contributing_to_ruby_on_rails.html has a section on how to squash. Let me know if you have any questions.
","1","2015-09-01T21:47:59Z"
"246983","19185","136928844","894678","kishore-mohan","@schneems squash the two commit into one. kindly check :+1: ","1","2015-09-02T03:53:04Z"
"246984","19186","136781157","7468109","rails-bot","r? @schneems
(@rails-bot has picked a reviewer for you, use r? to override)","1","2015-09-01T16:24:16Z"
"246985","19186","136781845","59744","schneems","r? @sikachu :wink: ","1","2015-09-01T16:27:16Z"
"246986","19186","136782365","4912","sikachu","Travis didn't like it.
> What is your opinion about the require 'action_controller/railtie' I had to add?
Can we require only `action_controller/metal/strong_parameters`? ","1","2015-09-01T16:29:22Z"
"246987","19186","136814299","10076","claudiob","@egilburg @sikachu See my latest commit for the comment part.
Also that change should be included in the Rails 5 release notes, so I'm referencing https://github.com/rails/rails/issues/20612 here :ribbon: ","1","2015-09-01T18:06:08Z"
"246988","19186","161494275","10076","claudiob","Now that #17169 has been merged into master, the core commit of this PR does not need to be anymore.
However, the other two commits that change documentation, test and require still make sense, so I'm extracting them into separate PRs.","1","2015-12-03T02:07:53Z"
"246989","19187","136782614","7468109","rails-bot","r? @eileencodes
(@rails-bot has picked a reviewer for you, use r? to override)","1","2015-09-01T16:30:24Z"
"246990","19187","136783716","350807","kaspth","Thanks @claudiob :heart:","1","2015-09-01T16:35:35Z"
"246991","19188","136795781","7468109","rails-bot","r? @carlosantoniodasilva
(@rails-bot has picked a reviewer for you, use r? to override)","1","2015-09-01T17:01:11Z"
"246992","19189","136817933","7468109","rails-bot","Thanks for the pull request, and welcome! The Rails team is excited to review your changes, and you should hear from @arthurnn (or someone else) soon.
If any changes to this PR are deemed necessary, please add them as extra commits. This ensures that the reviewer can see what has changed since they last reviewed the code. Due to the way GitHub handles out-of-date commits, this should also make it reasonably obvious what issues have or haven't been addressed. Large or tricky changes may require several passes of review and changes.
Please see [the contribution instructions](http://edgeguides.rubyonrails.org/contributing_to_ruby_on_rails.html) for more information.
","1","2015-09-01T18:19:51Z"
"246993","19189","136818779","47848","rafaelfranca","Thank you @bkeepers :beers: ","1","2015-09-01T18:21:14Z"
"246994","19189","137142341","173","bkeepers",":+1: Thanks. You're quick!","1","2015-09-02T15:55:05Z"
"246995","19190","136822654","7468109","rails-bot","r? @senny
(@rails-bot has picked a reviewer for you, use r? to override)","1","2015-09-01T18:37:13Z"
"246996","19192","1605935","9347","dmathieu","I'll backport this to 3-1 (tests are failing because of this) after this is approved in master.","1","2011-07-19T10:25:46Z"
"246997","19192","1606976","8701","joshk","@fxn review time :)","1","2011-07-19T13:41:54Z"
"246998","19192","1610491","3387","fxn","I'll have a look at it, we have a thread elsewhere also about this.
Thing is, in 1.9 the character class [[:space:]] is Unicode-aware. So, in my view the ideal blank? implementation for 1.9 would delegate to the regexp engine and should be a simple !~ /[^[:space:]]/. Anything deviating from that should be very well justified in my view. Solution for 1.8.7, I don't know, perhaps none in core.
","1","2011-07-19T20:46:21Z"
"246999","19192","1613880","9347","dmathieu","I have changed my commit to use [:space:] on 1.9 and the previous regex on 1.8.","1","2011-07-20T08:44:58Z"
"247000","19192","1614118","3387","fxn","Excellent, I think this one will have expected behavior in 1.9.
I don't really know what to think about the regexp for 1.8. If we want to emulate 1.9 then we should test for the rest of the whitespace characters. But then in 1.8 the regexp engines knows nothing about the encoding and looks like a blind guess to me to hard-code that.
Anyway, that may be subject of a later revision, I think this particular PR is good to go.","1","2011-07-20T09:38:15Z"
"247001","19193","136938119","47848","rafaelfranca","r? @fxn ","1","2015-09-02T05:10:09Z"
"247002","19193","136939410","8219340","sambostock","Not sure what caused the failure. It seems (?) unrelated. I ran the ActiveSupport tests without issue on my machine. I don't think my changes should affect anything outside that, as things should behave normally when the `ignore_dashes` option isn't provided.
Perhaps someone with more experience can weigh in?
Last couple lines of the failed Travis test log:
```
Finished in 0.514553s, 15.5475 runs/s, 5.8303 assertions/s.
8 runs, 3 assertions, 0 failures, 0 errors, 6 skips
You have skipped tests. Run with --verbose for details.
/home/travis/.rvm/rubies/ruby-2.2.3/bin/ruby -I""lib:test"" -I""/home/travis/.rvm/rubies/ruby-2.2.3/lib/ruby/2.2.0"" ""/home/travis/.rvm/rubies/ruby-2.2.3/lib/ruby/2.2.0/rake/rake_test_loader.rb"" ""test/integration/queuing_test.rb""
*** rake aj:integration:backburner ***
Cannot run integration tests for backburner. To be able to run integration tests for backburner you need to install and start beanstalkd.
Errors running test:integration:sidekiq
Rails build FAILED
Failed components: activejob
The command ""ci/travis.rb"" exited with 1.
cache.2
store build cache
$ bundle clean
Resolving dependencies...
8.27s/home/travis/build/rails/rails/vendor/bundle/ruby/2.2.0/bundler/gems/sprockets-7b913165d54b/test/fixtures/errors/symlink: No such file or directory
change detected:
/home/travis/build/rails/rails/vendor/bundle/ruby/2.2.0/bundler/gems/arel-64d897844c5b/.git/index
/home/travis/build/rails/rails/vendor/bundle/ruby/2.2.0/bundler/gems/arel-64d897844c5b/.git/index
/home/travis/build/rails/rails/vendor/bundle/ruby/2.2.0/bundler/gems/globalid-8178ff2dc898/.git/index
/home/travis/build/rails/rails/vendor/bundle/ruby/2.2.0/bundler/gems/globalid-8178ff2dc898/.git/index
/home/travis/build/rails/rails/vendor/bundle/ruby/2.2.0/bundler/gems/jquery-rails-9cb0e2df2d27/.git/index
/home/travis/build/rails/rails/vendor/bundle/ruby/2.2.0/bundler/gems/jquery-rails-9cb0e2df2d27/.git/index
/home/travis/build/rails/rails/vendor/bundle/ruby/2.2.0/bundler/gems/mail-64ef1a12efcd/.git/index
/home/travis/build/rails/rails/vendor/bundle/ruby/2.2.0/bundler/gems/mail-64ef1a12efcd/.git/index
/home/travis/build/rails/rails/vendor/bundle/ruby/2.2.0/bundler/gems/qu-d098e2657c92/.git/index
/home/travis/build/rails/rails/vendor/bundle/ruby/2.2.0/bundler/gems/qu-d098e2657c92/.git/index
/
...
changes detected, packing new archive
.
uploading archive
Done. Your build exited with 1.
```","1","2015-09-02T05:18:16Z"
"247003","19194","136956941","7468109","rails-bot","Thanks for the pull request, and welcome! The Rails team is excited to review your changes, and you should hear from @senny (or someone else) soon.
If any changes to this PR are deemed necessary, please add them as extra commits. This ensures that the reviewer can see what has changed since they last reviewed the code. Due to the way GitHub handles out-of-date commits, this should also make it reasonably obvious what issues have or haven't been addressed. Large or tricky changes may require several passes of review and changes.
Please see [the contribution instructions](http://edgeguides.rubyonrails.org/contributing_to_ruby_on_rails.html) for more information.
","1","2015-09-02T07:04:57Z"
"247004","19194","144703267","1034","matthewd","We'll need some tests, too.","1","2015-10-01T11:36:27Z"
"247005","19194","147589809","244988","icambron","IMO, it's a bit odd to support non-ascii without also supporting quoted strings for ascii-but-reserved characters (also part of 5987/6266). It creates a weird, non-working middle ground between vanilla file names that always worked and non-ascii chars that will now work. ""Your file download isn't parsing correctly? Just add a non-ascii char to the name and it work!""","1","2015-10-13T03:54:25Z"
"247006","19196","137034697","7468109","rails-bot","Thanks for the pull request, and welcome! The Rails team is excited to review your changes, and you should hear from @pixeltrix (or someone else) soon.
If any changes to this PR are deemed necessary, please add them as extra commits. This ensures that the reviewer can see what has changed since they last reviewed the code. Due to the way GitHub handles out-of-date commits, this should also make it reasonably obvious what issues have or haven't been addressed. Large or tricky changes may require several passes of review and changes.
Please see [the contribution instructions](http://edgeguides.rubyonrails.org/contributing_to_ruby_on_rails.html) for more information.
","1","2015-09-02T11:14:07Z"
"247007","19196","137040196","988558","manish-shrivastava","I am sorry. I was not aware of after word apostrophe use. This PR should be discarded. ","1","2015-09-02T11:36:31Z"
"247008","19196","137042513","2394703","seuros","Thank you for your contribution.","1","2015-09-02T11:40:53Z"
"247009","19197","137045530","7468109","rails-bot","Thanks for the pull request, and welcome! The Rails team is excited to review your changes, and you should hear from @pixeltrix (or someone else) soon.
If any changes to this PR are deemed necessary, please add them as extra commits. This ensures that the reviewer can see what has changed since they last reviewed the code. Due to the way GitHub handles out-of-date commits, this should also make it reasonably obvious what issues have or haven't been addressed. Large or tricky changes may require several passes of review and changes.
Please see [the contribution instructions](http://edgeguides.rubyonrails.org/contributing_to_ruby_on_rails.html) for more information.
","1","2015-09-02T11:51:11Z"
"247010","19197","137076425","1191","al2o3cr","Does this happen when chaining against scopes that aren't `none`? I'm wondering if it's an issue with how that's implemented...","1","2015-09-02T13:22:16Z"
"247011","19197","137077747","667726","ignatiusreza","Yes, it happen with any scope.. I choose `none` here simply because it is the easiest to explain..","1","2015-09-02T13:24:48Z"
"247012","19197","137080995","667726","ignatiusreza","Checking into the object, inside a `scope`, `self` is actually not `ActiveRecord::Relation` .. So code like `Post.none.tagged_only(false).to_sql` will fail with a no method error.. hence, a proper fix is probably to make sure that `self` is `ActiveRecord::Relation`.. thoughts?","1","2015-09-02T13:33:09Z"
"247013","19292","139424560","5074763","lachlanjc","And for the quick review! ???","1","2015-09-11T01:22:17Z"
"247014","19293","140048594","1080678","eileencodes","Hey @bogdan can you update the commit message to be more clear why you're changing this. I think it can better describe the reason why you made the change. Thanks! ","1","2015-09-14T11:56:40Z"
"247015","19293","140078206","122436","bogdan","@eileencodes improved commit message. Does it look ok now?","1","2015-09-14T13:38:45Z"
"247016","19294","139523924","7468109","rails-bot","r? @sgrif
(@rails-bot has picked a reviewer for you, use r? to override)","1","2015-09-11T11:44:25Z"
"247017","19296","139551282","7468109","rails-bot","r? @rafaelfranca
(@rails-bot has picked a reviewer for you, use r? to override)","1","2015-09-11T13:46:31Z"
"247018","19296","139621512","199","jeremy","+1. There are a handful of other spots where we refer to characters, also.","1","2015-09-11T18:32:16Z"
"247019","19296","139846285","47848","rafaelfranca","@kamipo could you take a look in the other spots?","1","2015-09-13T06:02:09Z"
"247020","19296","139847199","12642","kamipo","It looks like not found the other spots.
```
% git grep -n character lib/active_record/connection_adapters
lib/active_record/connection_adapters/abstract/quoting.rb:78: # characters.
lib/active_record/connection_adapters/abstract/schema_definitions.rb:239: # Requests a maximum column length. This is number of characters for <tt>:string</tt> and
lib/active_record/connection_adapters/abstract/schema_statements.rb:731: # +identifier+ is a 10 character long string which is deterministically generated from the
lib/active_record/connection_adapters/abstract/schema_statements.rb:979: raise ArgumentError, ""Index name '#{index_name}' on table '#{table_name}' is too long; the limit is #{max_index_length} characters""
lib/active_record/connection_adapters/abstract/schema_statements.rb:1078: raise ArgumentError, ""Index name '#{new_name}' on table '#{table_name}' is too long; the limit is #{allowed_index_name_length} characters""
lib/active_record/connection_adapters/abstract_mysql_adapter.rb:513: # Returns the database character set.
lib/active_record/connection_adapters/abstract_mysql_adapter.rb:515: show_variable 'character_set_database'
lib/active_record/connection_adapters/mysql_adapter.rb:226: ""select @@character_set_client"",
lib/active_record/connection_adapters/postgresql/schema_statements.rb:426: # cast the default to the columns type, which leaves us with a default like ""default NULL::character varying"".
lib/active_record/connection_adapters/postgresql_adapter.rb:80: string: { name: ""character varying"" },
lib/active_record/connection_adapters/postgresql_adapter.rb:665: # connected server's characteristics.
lib/active_record/connection_adapters/sqlite3_adapter.rb:155: # characters. The rest is used by rails internally to perform
```
`git grep -n character lib/active_record/` and `git grep -n character test/` are also.","1","2015-09-13T06:46:02Z"
"247021","19296","139847241","47848","rafaelfranca",":+1:","1","2015-09-13T06:47:51Z"
"247022","19296","139972211","199","jeremy","These in particular:
```
lib/active_record/connection_adapters/abstract/schema_statements.rb
974: raise ArgumentError, ""Index name '#{index_name}' on table '#{table_name}' is too long; the limit is #{max_index_length} characters""
1073: raise ArgumentError, ""Index name '#{new_name}' on table '#{table_name}' is too long; the limit is #{allowed_index_name_length} characters""
lib/active_record/connection_adapters/abstract/schema_definitions.rb
239: # Requests a maximum column length. This is number of characters for <tt>:string</tt> and
```
They aren't MySQL-specific, but they are incorrect for MySQL.","1","2015-09-14T06:11:30Z"
"247023","19296","139981603","12642","kamipo","Indeed, the doc of the limit option in `abstract/schema_definitions.rb` is incorrect for MySQL.
* <tt>:limit</tt> -
Requests a maximum column length. This is number of characters for <tt>:string</tt> and
<tt>:text</tt> columns and number of bytes for <tt>:binary</tt> and <tt>:integer</tt> columns.
But the error messages of the index name length in `abstract/schema_statements.rb` is correct.
```ruby
if index_name.length > max_index_length
raise ArgumentError, ""Index name '#{index_name}' on table '#{table_name}' is too long; the limit is #{max_index_length} characters""
end
```
```ruby
if new_name.length > allowed_index_name_length
raise ArgumentError, ""Index name '#{new_name}' on table '#{table_name}' is too long; the limit is #{allowed_index_name_length} characters""
end
```","1","2015-09-14T07:13:27Z"
"247024","19297","139580167","7468109","rails-bot","Thanks for the pull request, and welcome! The Rails team is excited to review your changes, and you should hear from @carlosantoniodasilva (or someone else) soon.
If any changes to this PR are deemed necessary, please add them as extra commits. This ensures that the reviewer can see what has changed since they last reviewed the code. Due to the way GitHub handles out-of-date commits, this should also make it reasonably obvious what issues have or haven't been addressed. Large or tricky changes may require several passes of review and changes.
Please see [the contribution instructions](http://edgeguides.rubyonrails.org/contributing_to_ruby_on_rails.html) for more information.
","1","2015-09-11T15:41:05Z"
"247025","19297","139580169","7468109","rails-bot","<img src=""http://www.joshmatthews.net/warning.svg"" alt=""warning"" height=20> **Warning** <img src=""http://www.joshmatthews.net/warning.svg"" alt=""warning"" height=20>
* Pull requests are usually filed against the master branch for this repo, but this one is against 4-2-stable. Please double check that you specified the right target!","1","2015-09-11T15:41:06Z"
"247026","19297","139580697","1497438","bernabas",":+1: ","1","2015-09-11T15:43:21Z"
"247027","19297","139580811","541665","andreibondarev","Should probably open against `master`","1","2015-09-11T15:43:50Z"
"247028","19297","139581824","5035724","mgwidmann","Closing in favor of #21593 ","1","2015-09-11T15:48:36Z"
"247029","19298","139581771","7468109","rails-bot","Thanks for the pull request, and welcome! The Rails team is excited to review your changes, and you should hear from @kaspth (or someone else) soon.
If any changes to this PR are deemed necessary, please add them as extra commits. This ensures that the reviewer can see what has changed since they last reviewed the code. Due to the way GitHub handles out-of-date commits, this should also make it reasonably obvious what issues have or haven't been addressed. Large or tricky changes may require several passes of review and changes.
Please see [the contribution instructions](http://edgeguides.rubyonrails.org/contributing_to_ruby_on_rails.html) for more information.
","1","2015-09-11T15:48:14Z"
"247030","19298","139582930","1497438","bernabas",":+1: ","1","2015-09-11T15:53:46Z"
"247031","19298","139583037","119823","americos","+1","1","2015-09-11T15:54:12Z"
"247032","19298","139586738","7101910","richessler",":+1:","1","2015-09-11T16:06:01Z"
"247033","19298","139606589","2065666","prosanelli",":+1: ","1","2015-09-11T17:25:28Z"
"247034","19298","139607466","47848","rafaelfranca","I think this solution will not work. Rails application.assets is not
present at production environment when you disable the assets compilation
(that is the default)
On Fri, Sep 11, 2015, 14:25 Peter Rosanelli <notifications@github.com>
wrote:
> [image: :+1:]
>
> —
> Reply to this email directly or view it on GitHub
> <https://github.com/rails/rails/pull/21593#issuecomment-139606589>.
>
","1","2015-09-11T17:29:50Z"
"247035","19298","139610492","5035724","mgwidmann","@rafaelfranca would it work to replace it with the equivalent `""#{Rails.env}-#{Rails.application.config.assets.version}-#{Sprockets::VERSION}""` even though I don't like the idea...","1","2015-09-11T17:43:42Z"
"247036","19298","139615663","5035724","mgwidmann","Ah I see, if I use `--skip-sprockets` to generate a new app and `RAILS_ENV=production rails c` it is nil like you say.
Previously before I submitted this I had something like this instead:
```
asset_version = Rails.application.assets.try(:version) || ""#{Rails.env}-#{Rails.application.config.assets.version}""
```","1","2015-09-11T18:07:59Z"
"247037","19298","139616563","5035724","mgwidmann","rebased and pushed...","1","2015-09-11T18:12:19Z"
"247038","19298","139620221","199","jeremy","This would blow fragment caches every time your assets change – no good. Even if it's opt-in config.
It'd be great if we could track asset digests as part of template digesting. It'd only work for static references like `image_path 'foo'` where we could look up the digest for that logical path.
Also, we're missing a simple way to add your own cross-cutting keys to all frag cache keys. Then Rails could, by default, include things like Sprockets version, and you could add your own sub-keys.
Here's a workaround path to doing that today. In your controller, inject a global template dependency:
```ruby
# Tell the template digestor that this template is a global dependency.
# When it changes, all template digests change, and hence all fragment cache keys change.
view_cache_dependency { 'shared/cache_dependencies' }
```
And in `app/views/shared/cache_dependencies.text.erb`:
```text
Global fragment cache dependencies
WARNING: Changing this file in any way will expire all fragment caches!
Assets version: v1
Sprockets version: 4.0
…
```
Then all your template digests, and hence your frag cache keys, will change when this one template changes.","1","2015-09-11T18:27:53Z"
"247039","19298","139626354","5035724","mgwidmann","@jeremy It wouldn't blow all fragments, only the ones marked with `assets: true`, which is the desired behavior since they *should* contain asset URLs within them. Cache blocks without `asset: true` would not contain the appended key and so therefore would remain cached. I don't see the harm in that since the thumbprints will have changed so you would want the cache to stay sync'd with it.","1","2015-09-11T18:50:43Z"
"247040","19298","139632629","199","jeremy","@mgwidmann Right, but ultimately that's the majority of your fragment caches. You lose any granularity.
Plus, marking specific caches with a special flag means you'll end up missing caches with asset urls within them, e.g. from a helper method you didn't notice.
We have two routes here. We can take either or both, depending on the root problem you're solving:
1. Track asset references in template and include the assets' digests in the template digest. Updating an asset will update the digest of any template that directly references it and hence expire its frag caches.
2. Inject global cache keys so we can declare global expiry rules, like Sprockets upgrades, and bake some sensible defaults in to sprockets-rails.
I think 2. is the appropriate solution for the problem you encountered: needing to expire fragment caches globally due to a Sprockets version change.","1","2015-09-11T19:05:00Z"
"247041","19298","139637716","5035724","mgwidmann","Just wanted to point out that it may or may not be a majority of the fragment caches depending upon your application since CSS images are unaffected by this. Since JavaScript and CSS would likely be in the head (and likely uncached) we are mostly talking about image tags which are use less and less frequently every day in favor of CSS. Icons for example would not be affected by this.
Just expiring caches when sprockets changes won't fully solve the problem. If `config.assets.version` is bumped, I need a way to target and expire my fragments which use assets (such as shown in the example) in an atomic manner so that no user receives a 404 image.
The only case where this approach is heavy handed is when for example I modified **one** image asset which the URL is included in **one** fragment. Ideally, we'd like to expire just that fragment. Perhaps rather than accepting just a boolean, `true` or a list of asset names could be supplied to the option to add in the thumbprint of that asset to the key, expiring just the caches that need to be expired.","1","2015-09-11T19:22:04Z"
"247042","19298","139662187","47848","rafaelfranca","r? @jeremy you have more background to take a decision here so I'm assigning to you.","1","2015-09-11T21:10:55Z"
"247043","19298","139927022","5035724","mgwidmann","@jeremy If you want to do number 2, could you point me at a few places where you think you'd start? This is a bit larger of a change than I was anticipating...
","1","2015-09-13T22:56:41Z"
"247044","19299","139737775","3387","fxn","Excellent.
This patch is not equivalent, it is stronger.
The original implementation computes the length of the indent in the least indented line, and removes those much whitespace characters (space or tab in this case) from the rest of lines.
This alternative looks at the shorter indent and replaces it as a string. Thus, assumes all lines are indented in the same way.
The approaches defer when the indentation mixes spaces and tabs, this alternative assumes the indentation is uniform. But I think this assumption is correct, this helper is thought for the use case in which the indentation is uniform, the behavior when it is mixed... doesn't matter. I mean, any choice is valid.
I am :+1: on this patch, but would like to ask for an stylistic tweak. In Rails we use single quotes unless double quotes are needed, would you mind changing the quotes?","1","2015-09-12T07:12:01Z"
"247045","19299","139740167","1000669","JuanitoFatas","@fxn Thanks for the detailed sum up! :blush:
> I am on this patch, but would like to ask for an stylistic tweak. In Rails we use single quotes unless double quotes are needed, would you mind changing the quotes?
Changed to single quote. :dolphin:","1","2015-09-12T08:27:59Z"
"247046","19299","139740668","3387","fxn",":rocket: :heart: ","1","2015-09-12T08:45:14Z"
"247047","19300","139732682","7468109","rails-bot","r? @kaspth
(@rails-bot has picked a reviewer for you, use r? to override)","1","2015-09-12T06:30:24Z"
"247048","19300","139809119","47848","rafaelfranca","Thank you for the pull request but as we already pointed in a lot of PRs to the guides they don't need to cover all the possible usages of the methods, that is what the documentation is for. So given that I don't see this feature to be used a lot like a single context I don't think we need to cover in the guides.","1","2015-09-12T18:44:07Z"
"247049","19301","139809014","47848","rafaelfranca","Thank you for the pull request but `check_box_tag` is a low level helper and in my opinion it should not do a lot of magic like handling multiple checkboxes. If you want that to be handled correctly automatically you can use the `collection_check_boxes` helper.","1","2015-09-12T18:41:38Z"
"247050","19302","861575","2741","dhh","Rails plugins are meant to be shared, Rails applications generally aren't. I'm not interested in changing the opinionated default of including the MIT-LICENSE, but please do fix the bug. You can reopen a new pull request with just that fix and I'll apply that.","1","2011-03-11T19:04:52Z"
"247051","19381","141841926","199","jeremy","Thanks @joshuapinter !
Note: you can use `[ci skip]` in your docs commit message to skip Travis builds ?","1","2015-09-20T22:32:52Z"
"247052","19381","141843482","180819","joshuapinter",":+1: Beauty! I'll do that next time!","1","2015-09-20T23:00:20Z"
"247053","19382","141827404","7468109","rails-bot","Thanks for the pull request, and welcome! The Rails team is excited to review your changes, and you should hear from @sgrif (or someone else) soon.
If any changes to this PR are deemed necessary, please add them as extra commits. This ensures that the reviewer can see what has changed since they last reviewed the code. Due to the way GitHub handles out-of-date commits, this should also make it reasonably obvious what issues have or haven't been addressed. Large or tricky changes may require several passes of review and changes.
Please see [the contribution instructions](http://edgeguides.rubyonrails.org/contributing_to_ruby_on_rails.html) for more information.
","1","2015-09-20T19:55:15Z"
"247054","19382","141827714","199","jeremy","Thanks @harrykiselev !
(Note: when no code changes are made, you can add `[ci skip]` to your commit message to skip the CI run, saving time and resources.)","1","2015-09-20T19:59:54Z"
"247055","19382","141829272","3241812","harrykiselev","Thanks for your note, @jeremy .
I will be more accurate next time.","1","2015-09-20T20:11:20Z"
"247056","19383","141944844","6321","pixeltrix","Consensus in the office here is definitely not a scope with a special name. Of the other two options maybe we could support both? You would use the class attribute for the simple case where it's just a single column but also allow overriding of the method if a more complicated relation is required, e.g:
``` ruby
class Product < ActiveRecord::Base
self.natural_order = { name: :asc }
# Default implementation
def self.natural_ordering
if natural_order
order(natural_order)
elsif primary_key
order(arel_table[primary_key].asc)
else
raise <<-MSG.strip_heredoc
No natural ordering on #{name} since it has no primary key.
To specify one use the `natural_order` attribute, e.g:
class #{name} < ActiveRecord::Base
self.natural_order = { #{column_names.first}: :asc }
end
If you need a more complicated natural ordering you can
override the `natural_ordering` class method to return
an instance of `ActiveRecord::Relation`.
MSG
end
end
# Override for complicated scopes
def self.natural_ordering
joins(:category).order(Category.arel_table[:name].asc, arel_table[:name].asc)
end
end
```
","1","2015-09-21T11:17:19Z"
"247057","19383","142005400","1529387","sgrif","I'd also be in favor of having users just define `self.natural_ordering` if they want to override it.","1","2015-09-21T14:51:22Z"
"247058","19383","142049572","199","jeremy","I like that, @pixeltrix. Covers the common case nicely (order by `created_at`) yet makes uncommon cases possible.","1","2015-09-21T17:27:14Z"
"247059","19383","144898793","47848","rafaelfranca","I like the simplicity of expecting users to just define their own `natural_ordering` if they need to override but it is hard right to make explicit what are methods that we expect users to override and what are not. Because of that I prefer @pixeltrix's solution.
:+1: for the feature.","1","2015-10-02T02:08:06Z"
"247060","19384","141881264","7468109","rails-bot","Thanks for the pull request, and welcome! The Rails team is excited to review your changes, and you should hear from @senny (or someone else) soon.
If any changes to this PR are deemed necessary, please add them as extra commits. This ensures that the reviewer can see what has changed since they last reviewed the code. Due to the way GitHub handles out-of-date commits, this should also make it reasonably obvious what issues have or haven't been addressed. Large or tricky changes may require several passes of review and changes.
Please see [the contribution instructions](http://edgeguides.rubyonrails.org/contributing_to_ruby_on_rails.html) for more information.
","1","2015-09-21T05:39:58Z"
"247061","19384","142507025","4891","gdeglin","For extra clarity on this bug and fix, here's a very simple failing testcase: https://gist.github.com/gdeglin/a32541807ba366d57c57
The stack trace of the failure is:
```
# Running:
D, [2015-09-22T23:18:52.424245 #65833] DEBUG -- : (0.1ms) BEGIN
D, [2015-09-22T23:18:52.428852 #65833] DEBUG -- : SQL (0.4ms) INSERT INTO ""users"" DEFAULT VALUES
D, [2015-09-22T23:18:52.430462 #65833] DEBUG -- : SQL (0.2ms) SELECT currval('_id_seq')
D, [2015-09-22T23:18:52.430666 #65833] DEBUG -- : (0.1ms) ROLLBACK
E
Finished in 0.017891s, 55.8932 runs/s, 0.0000 assertions/s.
1) Error:
BugTest#test_association:
ActiveRecord::StatementInvalid: PG::InFailedSqlTransaction: ERROR: current transaction is aborted, commands ignored until end of transaction block
: SELECT currval('_id_seq')
/Users/George/.rbenv/versions/2.2.2/lib/ruby/gems/2.2.0/bundler/gems/rails-ef7791ca1460/activerecord/lib/active_record/connection_adapters/postgresql_adapter.rb:611:in `async_exec'
/Users/George/.rbenv/versions/2.2.2/lib/ruby/gems/2.2.0/bundler/gems/rails-ef7791ca1460/activerecord/lib/active_record/connection_adapters/postgresql_adapter.rb:611:in `block in exec_no_cache'
/Users/George/.rbenv/versions/2.2.2/lib/ruby/gems/2.2.0/bundler/gems/rails-ef7791ca1460/activerecord/lib/active_record/connection_adapters/abstract_adapter.rb:514:in `block in log'
/Users/George/.rbenv/versions/2.2.2/lib/ruby/gems/2.2.0/bundler/gems/rails-ef7791ca1460/activesupport/lib/active_support/notifications/instrumenter.rb:20:in `instrument'
/Users/George/.rbenv/versions/2.2.2/lib/ruby/gems/2.2.0/bundler/gems/rails-ef7791ca1460/activerecord/lib/active_record/connection_adapters/abstract_adapter.rb:508:in `log'
/Users/George/.rbenv/versions/2.2.2/lib/ruby/gems/2.2.0/bundler/gems/rails-ef7791ca1460/activerecord/lib/active_record/connection_adapters/postgresql_adapter.rb:611:in `exec_no_cache'
/Users/George/.rbenv/versions/2.2.2/lib/ruby/gems/2.2.0/bundler/gems/rails-ef7791ca1460/activerecord/lib/active_record/connection_adapters/postgresql_adapter.rb:603:in `execute_and_clear'
/Users/George/.rbenv/versions/2.2.2/lib/ruby/gems/2.2.0/bundler/gems/rails-ef7791ca1460/activerecord/lib/active_record/connection_adapters/postgresql/database_statements.rb:160:in `exec_query'
/Users/George/.rbenv/versions/2.2.2/lib/ruby/gems/2.2.0/bundler/gems/rails-ef7791ca1460/activerecord/lib/active_record/connection_adapters/postgresql_adapter.rb:728:in `last_insert_id_result'
/Users/George/.rbenv/versions/2.2.2/lib/ruby/gems/2.2.0/bundler/gems/rails-ef7791ca1460/activerecord/lib/active_record/connection_adapters/postgresql/database_statements.rb:199:in `exec_insert'
/Users/George/.rbenv/versions/2.2.2/lib/ruby/gems/2.2.0/bundler/gems/rails-ef7791ca1460/activerecord/lib/active_record/connection_adapters/abstract/database_statements.rb:109:in `insert'
/Users/George/.rbenv/versions/2.2.2/lib/ruby/gems/2.2.0/bundler/gems/rails-ef7791ca1460/activerecord/lib/active_record/connection_adapters/abstract/query_cache.rb:14:in `insert'
/Users/George/.rbenv/versions/2.2.2/lib/ruby/gems/2.2.0/bundler/gems/rails-ef7791ca1460/activerecord/lib/active_record/relation.rb:65:in `insert'
/Users/George/.rbenv/versions/2.2.2/lib/ruby/gems/2.2.0/bundler/gems/rails-ef7791ca1460/activerecord/lib/active_record/persistence.rb:541:in `_create_record'
/Users/George/.rbenv/versions/2.2.2/lib/ruby/gems/2.2.0/bundler/gems/rails-ef7791ca1460/activerecord/lib/active_record/counter_cache.rb:128:in `_create_record'
/Users/George/.rbenv/versions/2.2.2/lib/ruby/gems/2.2.0/bundler/gems/rails-ef7791ca1460/activerecord/lib/active_record/locking/optimistic.rb:75:in `_create_record'
/Users/George/.rbenv/versions/2.2.2/lib/ruby/gems/2.2.0/bundler/gems/rails-ef7791ca1460/activerecord/lib/active_record/attribute_methods/dirty.rb:132:in `_create_record'
/Users/George/.rbenv/versions/2.2.2/lib/ruby/gems/2.2.0/bundler/gems/rails-ef7791ca1460/activerecord/lib/active_record/callbacks.rb:310:in `block in _create_record'
/Users/George/.rbenv/versions/2.2.2/lib/ruby/gems/2.2.0/bundler/gems/rails-ef7791ca1460/activesupport/lib/active_support/callbacks.rb:119:in `call'
/Users/George/.rbenv/versions/2.2.2/lib/ruby/gems/2.2.0/bundler/gems/rails-ef7791ca1460/activesupport/lib/active_support/callbacks.rb:119:in `call'
/Users/George/.rbenv/versions/2.2.2/lib/ruby/gems/2.2.0/bundler/gems/rails-ef7791ca1460/activesupport/lib/active_support/callbacks.rb:498:in `block (2 levels) in compile'
/Users/George/.rbenv/versions/2.2.2/lib/ruby/gems/2.2.0/bundler/gems/rails-ef7791ca1460/activesupport/lib/active_support/callbacks.rb:441:in `call'
/Users/George/.rbenv/versions/2.2.2/lib/ruby/gems/2.2.0/bundler/gems/rails-ef7791ca1460/activesupport/lib/active_support/callbacks.rb:441:in `call'
/Users/George/.rbenv/versions/2.2.2/lib/ruby/gems/2.2.0/bundler/gems/rails-ef7791ca1460/activesupport/lib/active_support/callbacks.rb:94:in `__run_callbacks__'
/Users/George/.rbenv/versions/2.2.2/lib/ruby/gems/2.2.0/bundler/gems/rails-ef7791ca1460/activesupport/lib/active_support/callbacks.rb:752:in `_run_create_callbacks'
/Users/George/.rbenv/versions/2.2.2/lib/ruby/gems/2.2.0/bundler/gems/rails-ef7791ca1460/activerecord/lib/active_record/callbacks.rb:310:in `_create_record'
/Users/George/.rbenv/versions/2.2.2/lib/ruby/gems/2.2.0/bundler/gems/rails-ef7791ca1460/activerecord/lib/active_record/timestamp.rb:64:in `_create_record'
/Users/George/.rbenv/versions/2.2.2/lib/ruby/gems/2.2.0/bundler/gems/rails-ef7791ca1460/activerecord/lib/active_record/persistence.rb:521:in `create_or_update'
/Users/George/.rbenv/versions/2.2.2/lib/ruby/gems/2.2.0/bundler/gems/rails-ef7791ca1460/activerecord/lib/active_record/callbacks.rb:306:in `block in create_or_update'
/Users/George/.rbenv/versions/2.2.2/lib/ruby/gems/2.2.0/bundler/gems/rails-ef7791ca1460/activesupport/lib/active_support/callbacks.rb:119:in `call'
/Users/George/.rbenv/versions/2.2.2/lib/ruby/gems/2.2.0/bundler/gems/rails-ef7791ca1460/activesupport/lib/active_support/callbacks.rb:119:in `call'
/Users/George/.rbenv/versions/2.2.2/lib/ruby/gems/2.2.0/bundler/gems/rails-ef7791ca1460/activesupport/lib/active_support/callbacks.rb:498:in `block (2 levels) in compile'
/Users/George/.rbenv/versions/2.2.2/lib/ruby/gems/2.2.0/bundler/gems/rails-ef7791ca1460/activesupport/lib/active_support/callbacks.rb:441:in `call'
/Users/George/.rbenv/versions/2.2.2/lib/ruby/gems/2.2.0/bundler/gems/rails-ef7791ca1460/activesupport/lib/active_support/callbacks.rb:441:in `call'
/Users/George/.rbenv/versions/2.2.2/lib/ruby/gems/2.2.0/bundler/gems/rails-ef7791ca1460/activesupport/lib/active_support/callbacks.rb:94:in `__run_callbacks__'
/Users/George/.rbenv/versions/2.2.2/lib/ruby/gems/2.2.0/bundler/gems/rails-ef7791ca1460/activesupport/lib/active_support/callbacks.rb:752:in `_run_save_callbacks'
/Users/George/.rbenv/versions/2.2.2/lib/ruby/gems/2.2.0/bundler/gems/rails-ef7791ca1460/activerecord/lib/active_record/callbacks.rb:306:in `create_or_update'
/Users/George/.rbenv/versions/2.2.2/lib/ruby/gems/2.2.0/bundler/gems/rails-ef7791ca1460/activerecord/lib/active_record/suppressor.rb:41:in `create_or_update'
/Users/George/.rbenv/versions/2.2.2/lib/ruby/gems/2.2.0/bundler/gems/rails-ef7791ca1460/activerecord/lib/active_record/persistence.rb:125:in `save'
/Users/George/.rbenv/versions/2.2.2/lib/ruby/gems/2.2.0/bundler/gems/rails-ef7791ca1460/activerecord/lib/active_record/validations.rb:43:in `save'
/Users/George/.rbenv/versions/2.2.2/lib/ruby/gems/2.2.0/bundler/gems/rails-ef7791ca1460/activerecord/lib/active_record/attribute_methods/dirty.rb:21:in `save'
/Users/George/.rbenv/versions/2.2.2/lib/ruby/gems/2.2.0/bundler/gems/rails-ef7791ca1460/activerecord/lib/active_record/transactions.rb:297:in `block (2 levels) in save'
/Users/George/.rbenv/versions/2.2.2/lib/ruby/gems/2.2.0/bundler/gems/rails-ef7791ca1460/activerecord/lib/active_record/transactions.rb:373:in `block in with_transaction_returning_status'
/Users/George/.rbenv/versions/2.2.2/lib/ruby/gems/2.2.0/bundler/gems/rails-ef7791ca1460/activerecord/lib/active_record/connection_adapters/abstract/database_statements.rb:212:in `block in transaction'
/Users/George/.rbenv/versions/2.2.2/lib/ruby/gems/2.2.0/bundler/gems/rails-ef7791ca1460/activerecord/lib/active_record/connection_adapters/abstract/transaction.rb:183:in `within_new_transaction'
/Users/George/.rbenv/versions/2.2.2/lib/ruby/gems/2.2.0/bundler/gems/rails-ef7791ca1460/activerecord/lib/active_record/connection_adapters/abstract/database_statements.rb:212:in `transaction'
/Users/George/.rbenv/versions/2.2.2/lib/ruby/gems/2.2.0/bundler/gems/rails-ef7791ca1460/activerecord/lib/active_record/transactions.rb:209:in `transaction'
/Users/George/.rbenv/versions/2.2.2/lib/ruby/gems/2.2.0/bundler/gems/rails-ef7791ca1460/activerecord/lib/active_record/transactions.rb:370:in `with_transaction_returning_status'
/Users/George/.rbenv/versions/2.2.2/lib/ruby/gems/2.2.0/bundler/gems/rails-ef7791ca1460/activerecord/lib/active_record/transactions.rb:297:in `block in save'
/Users/George/.rbenv/versions/2.2.2/lib/ruby/gems/2.2.0/bundler/gems/rails-ef7791ca1460/activerecord/lib/active_record/transactions.rb:312:in `rollback_active_record_state!'
/Users/George/.rbenv/versions/2.2.2/lib/ruby/gems/2.2.0/bundler/gems/rails-ef7791ca1460/activerecord/lib/active_record/transactions.rb:296:in `save'
/Users/George/.rbenv/versions/2.2.2/lib/ruby/gems/2.2.0/bundler/gems/rails-ef7791ca1460/activerecord/lib/active_record/persistence.rb:34:in `create'
insert_returning_bug.rb:53:in `test_association'
```
You can see that Rails attempted to query a non-existent sequence. This is because it fails to fetch the table name correctly. This patch corrects a regular expression so that it does correctly fetch the table name in this case, and then queries the correct sequence.","1","2015-09-23T06:23:40Z"
"247062","19385","141959814","7468109","rails-bot","Thanks for the pull request, and welcome! The Rails team is excited to review your changes, and you should hear from @schneems (or someone else) soon.
If any changes to this PR are deemed necessary, please add them as extra commits. This ensures that the reviewer can see what has changed since they last reviewed the code. Due to the way GitHub handles out-of-date commits, this should also make it reasonably obvious what issues have or haven't been addressed. Large or tricky changes may require several passes of review and changes.
Please see [the contribution instructions](http://edgeguides.rubyonrails.org/contributing_to_ruby_on_rails.html) for more information.
","1","2015-09-21T12:35:44Z"
"247063","19386","861688","2741","dhh","This has been committed. Thanks!","1","2011-03-11T19:37:57Z"
"247064","19387","1621016","760352","brentkirby","a `--bundle` flag seems to make more sense to me, and makes more sense. It would also be the inverse of --skip-bundle if you wanna get technical :)","1","2011-07-21T03:19:24Z"
"247065","19387","1621698","38746","kimptoc","Great - thanks for doing this.
On the tests, I'd have thought there would be a test to check bundler is run when the flag is true.
As for the option name, run_bundler seems very explicit, I like it.","1","2011-07-21T06:43:47Z"
"247066","19387","1622784","9582","josevalim","Tks for the pull request but skip_* follows the same pattern as the other options. So imho we need a stronger reason to change it to run_bundler besides having true as default.","1","2011-07-21T10:49:36Z"
"247067","19387","1625269","131246","sespindola","Thanks for your input guys.
So, which one do you prefer: --bundle with default false or --skip_bundle with default true? Can we take a vote?
I'll make the necessary modifications once we reach some consensus.
","1","2011-07-21T17:31:00Z"
"247068","19387","1625324","760352","brentkirby","Id agree with @josevalim that --skip-bundle would follow the existing pattern, I just think its weird since it would default to true, you'd basically set --skip-bundler false each time :) Choosing your javascript etc uses -j (unless something changed) so I'd think --bundle makes more sense since your explicitly saying you want to do something.
An even better solution would be to remove it completely IMO, if you want to run bundler automatically create an application template. Ignoring the RVM aspect of the initial issue post.... 99% of the time your going to be adding additional gems to your gemfile (sometimes even changing rails to use edge etc) after creating a new app, which means you will have to re-bundle anyway, which means another request to rubygems.org (which even yesterday kept failing to respond for me for an hour or so :) ).
I'm guessing the point of adding it to begin with was to ease the setup / get started for new users? I don't see any other purpose of it really. I haven't checked to see how it effects using an app template on a new project.","1","2011-07-21T17:40:41Z"
"247069","19387","1628652","131246","sespindola","@brentkirby, I agree with you that most of us will be heavily customizing the gemfile after generating a new app. But,
from the perspective of less experienced users, I think that this option is a nice thing to have.
I've renamed --run_bundler to --bundle.
Also added the ""-I"" alias for the --bundle option.
Let me know what you guys think.
","1","2011-07-22T00:40:30Z"
"247070","19388","142031290","7468109","rails-bot","Thanks for the pull request, and welcome! The Rails team is excited to review your changes, and you should hear from @rafaelfranca (or someone else) soon.
If any changes to this PR are deemed necessary, please add them as extra commits. This ensures that the reviewer can see what has changed since they last reviewed the code. Due to the way GitHub handles out-of-date commits, this should also make it reasonably obvious what issues have or haven't been addressed. Large or tricky changes may require several passes of review and changes.
Please see [the contribution instructions](http://edgeguides.rubyonrails.org/contributing_to_ruby_on_rails.html) for more information.
","1","2015-09-21T16:14:49Z"
"247071","19388","142031291","7468109","rails-bot","<img src=""http://www.joshmatthews.net/warning.svg"" alt=""warning"" height=20> **Warning** <img src=""http://www.joshmatthews.net/warning.svg"" alt=""warning"" height=20>
* Pull requests are usually filed against the master branch for this repo, but this one is against 4-2-stable. Please double check that you specified the right target!","1","2015-09-21T16:14:50Z"
"247072","19388","142061401","6321","pixeltrix","I think if we were going to do anything we'd add a `params` to the preview instance that was available inside the method and not passed in. I like to think of previews as similar to controllers so each method is equivalent to an action. e.g:
``` ruby
class OrderMailerPreview < ActionMailer::Preview
def receipt
OrderMailer.receipt(Order.find(params[:id]))
end
end
```
I think anything else is straying too far into application level concerns.","1","2015-09-21T17:58:23Z"
"247073","19388","143393452","47848","rafaelfranca","Could you please open the pull request with @pixeltrix's suggestion against the master branch? Thanks","1","2015-09-26T02:59:23Z"
"247074","19389","142148008","199","jeremy","Agreed! Thank you @ronakjangir47 ","1","2015-09-22T00:44:16Z"
"247075","19390","142046523","7468109","rails-bot","r? @pixeltrix
(@rails-bot has picked a reviewer for you, use r? to override)","1","2015-09-21T17:15:49Z"
"247076","19390","142065812","6321","pixeltrix","@ronakjangir47 thanks for spotting that!","1","2015-09-21T18:17:31Z"
"247077","19390","142066446","1909242","ronakjangir47","@pixeltrix Thanks for review ","1","2015-09-21T18:20:19Z"
"247078","19391","142049482","7468109","rails-bot","r? @carlosantoniodasilva
(@rails-bot has picked a reviewer for you, use r? to override)","1","2015-09-21T17:26:53Z"
"247079","19391","142130128","10076","claudiob","r? @fxn ","1","2015-09-21T22:45:17Z"
"247080","19391","142135026","199","jeremy","These indicate ""API visibility""—whether it's ok to safely use or override these methods, despite being public in Ruby.","1","2015-09-21T23:15:17Z"
"247081","19392","142077326","7468109","rails-bot","Thanks for the pull request, and welcome! The Rails team is excited to review your changes, and you should hear from @eileencodes (or someone else) soon.
If any changes to this PR are deemed necessary, please add them as extra commits. This ensures that the reviewer can see what has changed since they last reviewed the code. Due to the way GitHub handles out-of-date commits, this should also make it reasonably obvious what issues have or haven't been addressed. Large or tricky changes may require several passes of review and changes.
Please see [the contribution instructions](http://edgeguides.rubyonrails.org/contributing_to_ruby_on_rails.html) for more information.
","1","2015-09-21T18:59:37Z"
"247082","19392","145249639","1080678","eileencodes","Looking at the history of the test you mentioned, the change was added to prevent writing timestamps when the table has no timestamp columns. You can read more about it in this PR #8813
It also looks like as @egilburg said this doesn't return what you want it to? Travis has some failing tests for this because it's returning true and not the attribute. Additionally can you write a test that demonstrates the behavior you want this to support?
","1","2015-10-03T13:40:59Z"
"247083","19392","146618445","1695630","mooreniemi","Thanks for getting back to me @eileencodes!
> Looking at the history of the test you mentioned, the change was added to prevent writing timestamps when the table has no timestamp columns. You can read more about it in this PR #8813
My use case is ultimately for caching, because `cache_key` as implemented relies on these timestamps. But what if a table has a relation to another table, and thus the model is actually ""updated"" by composition of more than one table?
Let's say a `cars` table and a `car_washings` table. A `car`'s `update_at` can be incremented when a change happens on the `car_washings` table. (In other words, the domain model of ""car"" should be served up as `clean` rather than `dirty`, because a _related_ table that captures that status is the authority.) But in Rails as is, `car` won't see an incremented `updated_at` unless I do:
class Car < ActiveRecord::Base
def [](attr)
if attr == :updated_at
car_washings.updated_at #imagine this is also checking on car first
else
super
end
end
end
I know in this example it seems kind of wonky, but I hope you can imagine there are legit cases to having multiple tables be relevant to the status of a model? (If no, I will try again! :grin:)
> It also looks like as @egilburg said this doesn't return what you want it to? Travis has some failing tests for this because it's returning true and not the attribute. Additionally can you write a test that demonstrates the behavior you want this to support?
@egilburg is right, and that can be changed, for sure. But the test as written explicitly is opposite to what I want. Via #8813 I see that we _don't_ want to write to a column that doesn't exist on that specific model, but the assumption there is the column _must be on that model's direct table_, not a related table. This is one of those places where I feel Rails wants me to have a 1:1 model:table thing, and for this app, it just isn't possible.
Is a related table update something Rails wants to support or no? If so, I will try to write a test for it. If not, I will just stick with my `attr` hack to insert relations into the top level of a model's attributes.","1","2015-10-08T16:47:56Z"
"247084","19392","146621956","1695630","mooreniemi","Perhaps another, clearer, way of putting this is simply:
While we may not want to allow _writing_ timestamps that don't exist on the model's direct table, for caching at least we may want to allow _reading_ timestamps that don't exist on a model's direct table -- either by allowing methods, or by searching relation timestamps. (I would think methods would be simpler.)
(See current commit for what I mean.)","1","2015-10-08T16:56:44Z"
"247085","19392","152598862","1695630","mooreniemi","bump.","1","2015-10-30T17:44:34Z"
"247086","19403","142960408","199","jeremy","@byroot The behavior of the model and characteristics of its attributes are `AR::Base` concerns for sure ? I think this is a great immediate change that exposes a long-running feeling that we have a missing link between the model and the db conn: a table definition.
`AR::Base` handles automatic schema introspection and mapping, but doesn't expose an abstraction for the table definition itself or allow it to be altered. Perhaps columns/schema introspection should be at arms' length from `AR::Base`: delegate the job to a `TableDefinition` that we can provide ourselves, introspect from the db conn, and alter.
Another approach would be to push the responsibility to Arel. Make the table's base relation a projection that doesn't include the defunct column.
In either case, we're pushing up against a missing capability to control schema introspection ourselves.","1","2015-09-24T15:19:25Z"
"247087","19404","142424640","350807","kaspth","@ronakjangir47 seems like there were some copy and paste scuffs. Even though these removals are pretty routine, please think about what you call variables and such. Thanks! :smile:","1","2015-09-22T21:13:38Z"
"247088","19404","142641270","1909242","ronakjangir47","@kaspth Thanks for your feedback and Sorry for naming conventions :wink:
Updated PR, please have a look again.","1","2015-09-23T15:34:55Z"
"247089","19404","142715124","350807","kaspth","Thanks!","1","2015-09-23T20:10:56Z"
"247090","19405","142426969","5402","senny","@ronakjangir47 thank you.","1","2015-09-22T21:23:03Z"
"247091","19406","142467229","7468109","rails-bot","r? @carlosantoniodasilva
(@rails-bot has picked a reviewer for you, use r? to override)","1","2015-09-23T01:16:00Z"
"247092","19406","142487308","6321","pixeltrix","@y-yagi thanks!","1","2015-09-23T04:31:49Z"
"247093","19406","142497986","987638","y-yagi","@pixeltrix Thank you for your confirmation!","1","2015-09-23T05:27:36Z"
"247094","19407","142468162","7468109","rails-bot","r? @senny
(@rails-bot has picked a reviewer for you, use r? to override)","1","2015-09-23T01:27:55Z"
"247095","19407","142482166","47848","rafaelfranca","Thank you for the pull request. As you can see in the top of this file inflections are frozen and we don't accept pull requests to change it https://github.com/rails/rails/blob/master/activesupport/lib/active_support/inflections.rb#L4","1","2015-09-23T03:45:08Z"
"247096","19407","142573350","79619","iamvery","Oh my, I am so sorry! Thank you for the gentle reminder. Apologies for overlooking that note!","1","2015-09-23T11:31:38Z"
"247097","19408","142469447","7468109","rails-bot","r? @kaspth
(@rails-bot has picked a reviewer for you, use r? to override)","1","2015-09-23T01:40:12Z"
"247098","19409","142471365","7468109","rails-bot","r? @sgrif
(@rails-bot has picked a reviewer for you, use r? to override)","1","2015-09-23T01:59:08Z"
"247099","19410","142474885","7468109","rails-bot","r? @schneems
(@rails-bot has picked a reviewer for you, use r? to override)","1","2015-09-23T02:42:58Z"
"247100","19410","142474899","5356517","yui-knk","r? @sgrif ","1","2015-09-23T02:43:17Z"
"247101","19410","142474964","5356517","yui-knk","`sanitize_sql_for_conditions` is protected method but also Public API, should we deprecate it first?","1","2015-09-23T02:44:21Z"
"247102","19410","142474967","1529387","sgrif","Thanks for the context in the commit message. ","1","2015-09-23T02:44:26Z"
"247103","19410","142475066","1529387","sgrif","I don't think we need to deprecate an option which has no affect. ","1","2015-09-23T02:45:36Z"
"247104","19410","142475217","5356517","yui-knk","OK, thanks!","1","2015-09-23T02:47:47Z"
"247105","19411","142485987","7468109","rails-bot","r? @sgrif
(@rails-bot has picked a reviewer for you, use r? to override)","1","2015-09-23T04:12:38Z"
"247106","19412","142506254","7468109","rails-bot","r? @eileencodes
(@rails-bot has picked a reviewer for you, use r? to override)","1","2015-09-23T06:20:51Z"
"247107","19412","142516646","350807","kaspth"," Thanks! ","1","2015-09-23T07:07:34Z"
"247108","19412","142516794","5356517","yui-knk","@y-yagi Thanks!!","1","2015-09-23T07:09:13Z"
"247109","19412","142563194","987638","y-yagi","Thanks guys!","1","2015-09-23T10:44:19Z"
"247110","19413","1622025","30642","aratak","That's great, that you let backward compatibility. And much better, than #898","1","2011-07-21T08:07:43Z"
"247111","19413","1700903","199887","alder","+1","1","2011-08-01T14:57:00Z"
"247112","19413","1751926","92907","MitinPavel","""Flag Argument"" (http://martinfowler.com/bliki/FlagArgument.html) is a smell. So the pull request improves the quality of the Rails codebase. +1","1","2011-08-08T06:30:15Z"
"247113","19413","1922533","124430","dmitriy-kiriyenko","Any news on that?","1","2011-08-28T03:47:22Z"
"247114","19413","2237924","124430","dmitriy-kiriyenko","Ok, you beat me.
Anyway I want this api change, so here is the rework _without_ `*args` and _without_ breaking the existing api.","1","2011-09-29T13:54:54Z"
"247115","19413","2318787","124430","dmitriy-kiriyenko","Any news?","1","2011-10-07T07:29:59Z"
"247116","19413","3232623","124430","dmitriy-kiriyenko","Anyone here?","1","2011-12-21T11:31:31Z"
"247117","19413","3367036","124430","dmitriy-kiriyenko","Come on, guys, do you believe giving no response is a good practice in open sourcing?","1","2012-01-05T08:43:58Z"
"247118","19413","5400419","47848","rafaelfranca","hey @dmitriy-kiriyenko sorry about the delay of the response. I agree with your pull request.
Right now this pull request cannot be automatically merged. So, please rebase it against the master. I'll be glad to ask someone from the Core Team to review it and merge.
We need to change the action_view_overview guide too.
Ping me when you are done.
Thanks.","1","2012-04-28T21:29:15Z"
"247119","19413","5405966","124430","dmitriy-kiriyenko","Wow, thanks. Will do it tomorrow morning.","1","2012-04-29T15:52:17Z"
"247120","19413","5412838","124430","dmitriy-kiriyenko","Have no idea why these two commits are here. Will redo a PR.","1","2012-04-30T07:16:51Z"
"247121","19413","5412854","124430","dmitriy-kiriyenko","Remade in #6077.","1","2012-04-30T07:18:58Z"
"247122","19414","142516713","7468109","rails-bot","Thanks for the pull request, and welcome! The Rails team is excited to review your changes, and you should hear from @arthurnn (or someone else) soon.
If any changes to this PR are deemed necessary, please add them as extra commits. This ensures that the reviewer can see what has changed since they last reviewed the code. Due to the way GitHub handles out-of-date commits, this should also make it reasonably obvious what issues have or haven't been addressed. Large or tricky changes may require several passes of review and changes.
Please see [the contribution instructions](http://edgeguides.rubyonrails.org/contributing_to_ruby_on_rails.html) for more information.
","1","2015-09-23T07:08:21Z"
"247123","19414","142942451","1529387","sgrif","I don't think this is a common enough use case to warrant this change (which would need documentation and tests if it were to be accepted). Overall, the goal has been to simplify the validators, and prune out edge cases. This use case can be easily accomplished by just using a method instead.","1","2015-09-24T14:13:44Z"
"247124","19414","142945230","1817625","jhsbeat","@sgrif Thanks for your feedback.","1","2015-09-24T14:25:28Z"
"247125","19415","142536226","7468109","rails-bot","r? @sgrif
(@rails-bot has picked a reviewer for you, use r? to override)","1","2015-09-23T09:09:23Z"
"247126","19416","142591329","7468109","rails-bot","r? @pixeltrix
(@rails-bot has picked a reviewer for you, use r? to override)","1","2015-09-23T12:59:09Z"
"247127","19416","142643713","6321","pixeltrix","Hmm, don't know about this one - what if one key is an integer and the other is a uuid? I think expecting developers to drop back to `create_table` if they need to customise it is probably okay. However I'm not dead set against it so I'll leave it open for the moment.","1","2015-09-23T15:43:51Z"
"247128","19416","142649640","47848","rafaelfranca","When I added this method my idea was to give a helper to create join table but if users need complex things they should use `create_table` instead. That said I prefer to not add more complexity in this method. Thank you for the pull request.","1","2015-09-23T16:07:01Z"
"247129","19416","142746871","987638","y-yagi","OK. Thank you for explanation!","1","2015-09-23T22:18:07Z"
"247130","19417","142664083","7468109","rails-bot","r? @senny
(@rails-bot has picked a reviewer for you, use r? to override)","1","2015-09-23T17:03:13Z"
"247131","19417","142715937","350807","kaspth","Thanks!","1","2015-09-23T20:14:48Z"
"247132","19418","142690265","7468109","rails-bot","r? @eileencodes
(@rails-bot has picked a reviewer for you, use r? to override)","1","2015-09-23T18:31:35Z"
"247133","19418","142749949","1080678","eileencodes","Thanks! :+1: ","1","2015-09-23T22:37:37Z"
"247134","19419","142691210","7468109","rails-bot","r? @eileencodes
(@rails-bot has picked a reviewer for you, use r? to override)","1","2015-09-23T18:34:54Z"
"247135","19419","142691693","1080678","eileencodes","Thanks for the PR! :smile:
While perhaps it's out of scope of engines I still think this is useful information for beginners. I don't agree with removing it. Why do you think it should be removed?","1","2015-09-23T18:37:04Z"
"247136","19419","142696008","632942","cllns","It's definitely useful information, and I agree it should be in the guides.
Engines aren't trivial, so I don't think they're a place for extraneous information.
I feel like if you're looking into Engines, you likely already know this.
If a beginner is wondering why they're getting something like `#<User:0x00000100ccb3b0>`, they might look in documentation for views instead.
Maybe the bottom of section `3.1.1` of the Action View Guide might be a better place for this, as a `TIP`?
http://edgeguides.rubyonrails.org/action_view_overview.html#templates
What do you think of that?","1","2015-09-23T18:54:42Z"
"247137","19419","142749449","1080678","eileencodes","Yea that looks like it could be a good place. :+1: ","1","2015-09-23T22:34:17Z"
"247138","19419","142766711","632942","cllns","What about my most recent push?
I would've copied the whole text, but I feel like reducing it to a TIP is better, considering the section it's in.","1","2015-09-24T00:16:58Z"
"247139","19419","142954999","1080678","eileencodes","I'm sorry I didn't read it closely. I agree that's a weird thing to say - to override the to_s in the engine. I've been immersed in sprockets and I think it's making my brain mushy.
Can you remove the tip? I know I asked you to add it but I wasn't thinking. Your change was good originally.","1","2015-09-24T15:00:33Z"
"247140","19419","142976704","632942","cllns","No problem! All set.","1","2015-09-24T16:16:38Z"
"247141","19420","142694209","7468109","rails-bot","r? @arthurnn
(@rails-bot has picked a reviewer for you, use r? to override)","1","2015-09-23T18:47:41Z"
"247142","19420","142698202","47848","rafaelfranca","r? @sgrif ","1","2015-09-23T19:00:28Z"
"247143","19420","142698528","1529387","sgrif","This test is invalid if subsecond precision isn't supported. As such, we should use `skip` here, to indicate that, rather than having it pass.","1","2015-09-23T19:01:48Z"
"247144","19420","142699974","1909242","ronakjangir47","@sgrif Thanks for your feedback. Updated PR.","1","2015-09-23T19:07:55Z"
"247145","19421","142716453","7468109","rails-bot","r? @senny
(@rails-bot has picked a reviewer for you, use r? to override)","1","2015-09-23T20:17:10Z"
"247146","19421","142827541","5402","senny","@cllns thank you :yellow_heart: The addition goes well with what we have on `Builder` already. Length and depth are fine. Readers looking for details should consult the `Jbuilder` docs.","1","2015-09-24T06:36:21Z"
"247147","19421","142827857","5402","senny","@cllns I changed the `a` tags to markdown markup in the merge commit (8516d76)","1","2015-09-24T06:39:29Z"
"247148","19421","142977812","632942","cllns","Awesome. thanks!","1","2015-09-24T16:21:33Z"
"247149","19422","142736886","7468109","rails-bot","r? @sgrif
(@rails-bot has picked a reviewer for you, use r? to override)","1","2015-09-23T21:34:35Z"
"247150","19423","142748755","7468109","rails-bot","Thanks for the pull request, and welcome! The Rails team is excited to review your changes, and you should hear from @arthurnn (or someone else) soon.
If any changes to this PR are deemed necessary, please add them as extra commits. This ensures that the reviewer can see what has changed since they last reviewed the code. Due to the way GitHub handles out-of-date commits, this should also make it reasonably obvious what issues have or haven't been addressed. Large or tricky changes may require several passes of review and changes.
Please see [the contribution instructions](http://edgeguides.rubyonrails.org/contributing_to_ruby_on_rails.html) for more information.
","1","2015-09-23T22:29:51Z"
"247151","19423","142748756","7468109","rails-bot","<img src=""http://www.joshmatthews.net/warning.svg"" alt=""warning"" height=20> **Warning** <img src=""http://www.joshmatthews.net/warning.svg"" alt=""warning"" height=20>
* Pull requests are usually filed against the master branch for this repo, but this one is against 4-2-stable. Please double check that you specified the right target!","1","2015-09-23T22:29:51Z"
"247152","19423","143786470","833383","arthurnn","#18775 was merged into master, is this a problem there too?","1","2015-09-28T15:53:49Z"
"247153","19423","143848509","3860146","merhard","@arthurnn
Good call. It is a problem there as well. Verified against the [testapp](https://github.com/merhard/rails-regression-testapp) and the test in this pull request.
I was so focused on the v4.2 regression I forgot to check on master. Should I open a new pull request against master?","1","2015-09-28T19:18:37Z"
"247154","19423","143878934","47848","rafaelfranca","> Should I open a new pull request against master?
Yes please. And we will backport the fix to 4-2-stable if we think it is applicable ","1","2015-09-28T21:25:59Z"
"247155","19424","142787797","7468109","rails-bot","r? @arthurnn
(@rails-bot has picked a reviewer for you, use r? to override)","1","2015-09-24T02:47:50Z"
"247156","19425","142819729","7468109","rails-bot","Thanks for the pull request, and welcome! The Rails team is excited to review your changes, and you should hear from @carlosantoniodasilva (or someone else) soon.
If any changes to this PR are deemed necessary, please add them as extra commits. This ensures that the reviewer can see what has changed since they last reviewed the code. Due to the way GitHub handles out-of-date commits, this should also make it reasonably obvious what issues have or haven't been addressed. Large or tricky changes may require several passes of review and changes.
Please see [the contribution instructions](http://edgeguides.rubyonrails.org/contributing_to_ruby_on_rails.html) for more information.
","1","2015-09-24T06:05:27Z"
"247157","19425","142826105","5402","senny","@brandoncc thank you. :yellow_heart:
For further documentation patches, please include `[ci skip]` in the commit message. This will keep our CI from running needlessly.","1","2015-09-24T06:28:08Z"
"247158","19486","144646413","350807","kaspth","Thanks ?","1","2015-10-01T07:49:06Z"
"247159","19487","144636737","7468109","rails-bot","r? @pixeltrix
(@rails-bot has picked a reviewer for you, use r? to override)","1","2015-10-01T06:50:46Z"
"247160","19487","144895974","47848","rafaelfranca","Thank you for the pull request but I think that both changes are unnecessary. The test is not duplicated and the other test that was added is being tested through another tests. ","1","2015-10-02T01:36:16Z"
"247161","19488","144640695","7468109","rails-bot","r? @rafaelfranca
(@rails-bot has picked a reviewer for you, use r? to override)","1","2015-10-01T07:12:47Z"
"247162","19488","144640735","1928523","akshay-vishnoi","r? @rafaelfranca ","1","2015-10-01T07:13:00Z"
"247163","19488","144895684","47848","rafaelfranca","Yes, this is by design. Sometimes you want the open tag but not the closing tag. When you so this you use the form without the block.","1","2015-10-02T01:33:05Z"
"247164","19488","145242036","1928523","akshay-vishnoi","@rafaelfranca -
I think if we want to use open form tag then we can pass option in form tag as:
```ruby
form_tag('/posts', open: true, enforce_utf8: false)
# => <form action=""/posts"" accept-charset=""UTF-8"" method=""post"">
# and,
form_tag('/posts', enforce_utf8: false)
# => <form action=""/posts"" accept-charset=""UTF-8"" method=""post""></form>
```
Hence if we don't want to add any content in the form then I don't need to add a block with form_tag.","1","2015-10-03T11:37:49Z"
"247165","19488","146519379","1928523","akshay-vishnoi","Hi @rafaelfranca -
This PR is closed already, so you might not have seen my comment. Just wanted to be sure - Is my above comment make sense or should I leave it?","1","2015-10-08T12:14:33Z"
"247166","19488","146619358","47848","rafaelfranca","Sorry, I don't see any reason to change this behavior.","1","2015-10-08T16:50:36Z"
"247167","19489","144644687","7468109","rails-bot","r? @sgrif
(@rails-bot has picked a reviewer for you, use r? to override)","1","2015-10-01T07:39:23Z"
"247168","19490","144719463","7468109","rails-bot","Thanks for the pull request, and welcome! The Rails team is excited to review your changes, and you should hear from @matthewd (or someone else) soon.
If any changes to this PR are deemed necessary, please add them as extra commits. This ensures that the reviewer can see what has changed since they last reviewed the code. Due to the way GitHub handles out-of-date commits, this should also make it reasonably obvious what issues have or haven't been addressed. Large or tricky changes may require several passes of review and changes.
Please see [the contribution instructions](http://edgeguides.rubyonrails.org/contributing_to_ruby_on_rails.html) for more information.
","1","2015-10-01T12:57:50Z"
"247169","19490","144722387","1131536","Eric-Guo","r? @jeremy @tenderlove","1","2015-10-01T13:12:30Z"
"247170","19490","144753543","3124","tenderlove","We should probably not be assigning the header if it's nil, I think.","1","2015-10-01T14:58:39Z"
"247171","19490","144763765","1131536","Eric-Guo","Agree, except I can not perfectly resolve it. :cry: ","1","2015-10-01T15:32:21Z"
"247172","19490","144778325","3124","tenderlove","Sorry, I'm confused. Does this not work?
```ruby
hv = make_set_cookie_header headers[HTTP_HEADER]
headers[HTTP_HEADER] = hv if hv
```","1","2015-10-01T16:23:07Z"
"247173","19490","144898135","47848","rafaelfranca","Fixed by https://github.com/rails/rails/pull/21836","1","2015-10-02T02:00:15Z"
"247174","19491","1632229","52642","spastorino","@Karunakar is this same thing present in 3-1-stable and master?","1","2011-07-22T14:53:53Z"
"247175","19491","1633924","16808","Karunakar","@spastorino in 3-1-stable its not duplicated.","1","2011-07-22T18:15:23Z"
"247176","19491","1636604","3948","arunagw","And not in master also :-)","1","2011-07-23T06:02:46Z"
"247177","19492","144799110","7468109","rails-bot","r? @schneems
(@rails-bot has picked a reviewer for you, use r? to override)","1","2015-10-01T17:49:36Z"
"247178","19492","144812604","47848","rafaelfranca","Could we freeze all string we use in instrumentation across the framework? I'm sure we have a lot of allocations because of that.","1","2015-10-01T18:41:00Z"
"247179","19549","146504073","5551587","swaathi","Alright. Got it. ??","1","2015-10-08T10:56:55Z"
"247180","19549","146697056","5551587","swaathi","I've added the deprecation warning and updated the docs. It would be great if you can have a look over it! ","1","2015-10-08T21:55:36Z"
"247181","19549","146772367","5402","senny","?r @chancancode ","1","2015-10-09T06:54:44Z"
"247182","19549","147946047","55829","chancancode","Sorry for the delay, the PR is looking good! other than the few things I commented, here is a few more minor things:
1. The PR no longer merges cleanly, can you rebase against master?
2. Can you squash your commits?
3. Can you add an entry about this change to the top of the Active Support CHANGELOG?
4. Can you run the test suite locally (or you can look at the travis run if you prefer) and see if we have been calling this method with the old signature anywhere else in the codebase? If so, can you fix all of them in a second commit?
The contributors guide has some information on how to do these (http://edgeguides.rubyonrails.org/contributing_to_ruby_on_rails.html). @eileencodes also did a workshop on that topic if you prefer watching a video (http://confreaks.tv/videos/railsconf2015-breaking-down-the-barrier-demystifying-contributing-to-rails).
Thanks again for working on this :grin: ","1","2015-10-14T06:05:54Z"
"247183","19549","147948169","5551587","swaathi","Thanks for the great feedback! I'll get these things done soon and raise a final pull. And no problem, the pleasure was mine! ?","1","2015-10-14T06:16:05Z"
"247184","19549","149130305","5551587","swaathi","I've rebased, squashed and cleared up the CI. Let me know if I missed anything. ?","1","2015-10-19T07:49:43Z"
"247185","19549","153309773","5551587","swaathi","Sorry to bother, but when will this be merged? Excited! :)","1","2015-11-03T10:30:01Z"
"247186","19549","153310404","350807","kaspth","@swaathi it's not ready to merge, there's a bunch of feedback that hasn't been addressed, it's not in one commit and there's merge conflicts. When those things are taken care of, we can merge. Thanks for your work! :smile:","1","2015-11-03T10:33:46Z"
"247187","19549","153320606","5551587","swaathi","@kaspth Alright thank you! The things @chancancode mentioned has been taken care of. Let me take care of the new issues that creeped in. Thanks for your time! ?","1","2015-11-03T11:18:00Z"
"247188","19549","153337992","350807","kaspth","Sweet! Ping me when you got it ?","1","2015-11-03T12:30:29Z"
"247189","19549","154060398","5551587","swaathi","@kaspth It would be great if you could review this again! I think I've addressed everything. Please let me know if I missed out anything.?","1","2015-11-05T13:36:55Z"
"247190","19549","154095816","350807","kaspth","Found some final nicks. Please remember to squash your commits down to one too :heart:","1","2015-11-05T15:36:43Z"
"247191","19549","154312069","5551587","swaathi","@kaspth I hope I got everything this time around. Please have a look. ? ","1","2015-11-06T06:02:52Z"
"247192","19549","154692386","5551587","swaathi","@kaspth Is this my lucky round? ? Please have a look!","1","2015-11-07T11:31:13Z"
"247193","19549","154744879","350807","kaspth","@swaathi you got it! — thanks so much :heart:","1","2015-11-07T20:21:17Z"
"247194","19549","154769346","5551587","swaathi","Oh wow. This feels great. ? Thanks so much @kaspth and @chancancode. ?","1","2015-11-08T01:30:55Z"
"247195","19550","146210891","7468109","rails-bot","Thanks for the pull request, and welcome! The Rails team is excited to review your changes, and you should hear from @rafaelfranca (or someone else) soon.
If any changes to this PR are deemed necessary, please add them as extra commits. This ensures that the reviewer can see what has changed since they last reviewed the code. Due to the way GitHub handles out-of-date commits, this should also make it reasonably obvious what issues have or haven't been addressed. Large or tricky changes may require several passes of review and changes.
Please see [the contribution instructions](http://edgeguides.rubyonrails.org/contributing_to_ruby_on_rails.html) for more information.
","1","2015-10-07T14:28:18Z"
"247196","19550","146218901","47848","rafaelfranca","r? @schneems since you are native speaker.","1","2015-10-07T14:51:21Z"
"247197","19550","146224226","59744","schneems","Dropping the ""in"" makes more sense. Thanks for the PR :heart:","1","2015-10-07T15:08:36Z"
"247198","19551","1064152","2741","dhh","@josevalim, can you look at this?","1","2011-04-27T13:21:55Z"
"247199","19551","1068672","9582","josevalim","Merged.","1","2011-04-28T07:43:23Z"
"247200","19552","146211804","7468109","rails-bot","Thanks for the pull request, and welcome! The Rails team is excited to review your changes, and you should hear from @senny (or someone else) soon.
If any changes to this PR are deemed necessary, please add them as extra commits. This ensures that the reviewer can see what has changed since they last reviewed the code. Due to the way GitHub handles out-of-date commits, this should also make it reasonably obvious what issues have or haven't been addressed. Large or tricky changes may require several passes of review and changes.
Please see [the contribution instructions](http://edgeguides.rubyonrails.org/contributing_to_ruby_on_rails.html) for more information.
","1","2015-10-07T14:31:47Z"
"247201","19553","146242402","7468109","rails-bot","Thanks for the pull request, and welcome! The Rails team is excited to review your changes, and you should hear from @carlosantoniodasilva (or someone else) soon.
If any changes to this PR are deemed necessary, please add them as extra commits. This ensures that the reviewer can see what has changed since they last reviewed the code. Due to the way GitHub handles out-of-date commits, this should also make it reasonably obvious what issues have or haven't been addressed. Large or tricky changes may require several passes of review and changes.
Please see [the contribution instructions](http://edgeguides.rubyonrails.org/contributing_to_ruby_on_rails.html) for more information.
","1","2015-10-07T15:55:05Z"
"247202","19554","146258314","350807","kaspth","Thanks, but I'd rather keep the git history in the tests.","1","2015-10-07T16:44:21Z"
"247203","19555","146279928","7468109","rails-bot","r? @schneems
(@rails-bot has picked a reviewer for you, use r? to override)","1","2015-10-07T18:04:19Z"
"247204","19555","146307160","59744","schneems","@seuros looks like you've touched this method before. Thoughts?","1","2015-10-07T19:42:43Z"
"247205","19555","146314282","2394703","seuros","@schneems This change looks good to me.","1","2015-10-07T20:10:19Z"
"247206","19555","146318694","59744","schneems","Thanks :heart:","1","2015-10-07T20:29:34Z"
"247207","19556","146325209","7468109","rails-bot","Thanks for the pull request, and welcome! The Rails team is excited to review your changes, and you should hear from @carlosantoniodasilva (or someone else) soon.
If any changes to this PR are deemed necessary, please add them as extra commits. This ensures that the reviewer can see what has changed since they last reviewed the code. Due to the way GitHub handles out-of-date commits, this should also make it reasonably obvious what issues have or haven't been addressed. Large or tricky changes may require several passes of review and changes.
Please see [the contribution instructions](http://edgeguides.rubyonrails.org/contributing_to_ruby_on_rails.html) for more information.
","1","2015-10-07T20:55:31Z"
"247208","19556","146392639","10076","claudiob","@scottgonzalez Thanks for your contribution. If you agree with the fixes above, just add them (and squash into a single commit) and this PR is :+1: for me.
Additionally, remember to write `[ci skip]` in the commit message next time you create a commit that only affects the documentation, so tests are not run by Travis CI (no need for that if the actual code does not change). Thanks!","1","2015-10-08T01:59:51Z"
"247209","19556","146529153","141167","scottgonzalez","I've added those changes.
Also, the commit already had `[ci skip]`, I just dropped it from the PR title :-)","1","2015-10-08T12:50:10Z"
"247210","19557","146332628","7468109","rails-bot","Thanks for the pull request, and welcome! The Rails team is excited to review your changes, and you should hear from @arthurnn (or someone else) soon.
If any changes to this PR are deemed necessary, please add them as extra commits. This ensures that the reviewer can see what has changed since they last reviewed the code. Due to the way GitHub handles out-of-date commits, this should also make it reasonably obvious what issues have or haven't been addressed. Large or tricky changes may require several passes of review and changes.
Please see [the contribution instructions](http://edgeguides.rubyonrails.org/contributing_to_ruby_on_rails.html) for more information.
","1","2015-10-07T21:18:53Z"
"247211","19557","148781217","833383","arthurnn","Can you add a regression test for the fix?
thanks for the PR","1","2015-10-16T17:38:45Z"
"247212","19557","149064636","1527631","madej","Test added.","1","2015-10-18T23:37:06Z"
"247213","19557","152778165","1527631","madej","@arthurnn , is there a problem with this pr? I see new rc is released, but without this patch cleanup in file_store will not work and generate exceptions in new version as well.","1","2015-10-31T22:24:51Z"
"247214","19557","160156517","833383","arthurnn","My concern here is that we are changing the keys schema. So once someone update to a Rails version that includes this fix, it will invalidate the file cache as now the keys are different.
cc @jeremy ","1","2015-11-27T15:05:35Z"
"247215","19557","160164822","1527631","madej","No, we don't. This change only fixes 'recreating' a key from a path. We don't change anything in generating keys.","1","2015-11-27T15:50:33Z"
"247216","19558","146380153","7468109","rails-bot","Thanks for the pull request, and welcome! The Rails team is excited to review your changes, and you should hear from @eileencodes (or someone else) soon.
If any changes to this PR are deemed necessary, please add them as extra commits. This ensures that the reviewer can see what has changed since they last reviewed the code. Due to the way GitHub handles out-of-date commits, this should also make it reasonably obvious what issues have or haven't been addressed. Large or tricky changes may require several passes of review and changes.
Please see [the contribution instructions](http://edgeguides.rubyonrails.org/contributing_to_ruby_on_rails.html) for more information.
","1","2015-10-08T00:36:50Z"
"247217","19558","149023131","1080678","eileencodes","Hi @brauliobo sorry for not getting around to this sooner. Can you explain more indepth why you need this? Was this broken in a certain version of Rails or is this a new bug in ActiveRecord that has existed in all versions? ","1","2015-10-18T14:52:34Z"
"247218","19558","149064180","41740","brauliobo","Hi @eileencodes! in some rails apps, you can have a model defined in some place and then extended with freedom patches elsewhere. this is the case of engines with dependencies, which is the case of my app (we call it plugins and they extend the core models).
In this situation, the sti models descendants simply won't get these new associations.
this patch fixes this.","1","2015-10-18T23:26:46Z"
"247219","19559","146451515","7468109","rails-bot","Thanks for the pull request, and welcome! The Rails team is excited to review your changes, and you should hear from @carlosantoniodasilva (or someone else) soon.
If any changes to this PR are deemed necessary, please add them as extra commits. This ensures that the reviewer can see what has changed since they last reviewed the code. Due to the way GitHub handles out-of-date commits, this should also make it reasonably obvious what issues have or haven't been addressed. Large or tricky changes may require several passes of review and changes.
Please see [the contribution instructions](http://edgeguides.rubyonrails.org/contributing_to_ruby_on_rails.html) for more information.
","1","2015-10-08T08:09:58Z"
"247220","19559","146451517","7468109","rails-bot","<img src=""http://www.joshmatthews.net/warning.svg"" alt=""warning"" height=20> **Warning** <img src=""http://www.joshmatthews.net/warning.svg"" alt=""warning"" height=20>
* Pull requests are usually filed against the master branch for this repo, but this one is against 3-2-stable. Please double check that you specified the right target!","1","2015-10-08T08:09:58Z"
"247221","19559","146626701","47848","rafaelfranca","Thank you for the pull request but Rails 3 is not supported anymore.","1","2015-10-08T17:11:24Z"
"247222","19559","146660920","621861","tkrajcar","This is really rack-cache's issue, not Rails - see https://github.com/rtomayko/rack-cache/issues/124. Hopefully it will get addressed. Right now it's impossible to install Rails 3 on Ruby 1.8 or 1.9 or JRuby. :(","1","2015-10-08T19:18:21Z"
"247223","19559","146662657","11367","grosser","1.3.1 has ruby 1.9 support, if you are on 1.8 then `gem 'rack-cacke', '~> 1.2.0'`","1","2015-10-08T19:26:42Z"
"247224","19560","146458991","7468109","rails-bot","Thanks for the pull request, and welcome! The Rails team is excited to review your changes, and you should hear from @eileencodes (or someone else) soon.
If any changes to this PR are deemed necessary, please add them as extra commits. This ensures that the reviewer can see what has changed since they last reviewed the code. Due to the way GitHub handles out-of-date commits, this should also make it reasonably obvious what issues have or haven't been addressed. Large or tricky changes may require several passes of review and changes.
Please see [the contribution instructions](http://edgeguides.rubyonrails.org/contributing_to_ruby_on_rails.html) for more information.
","1","2015-10-08T08:37:30Z"
"247225","19561","146463514","7468109","rails-bot","r? @kaspth
(@rails-bot has picked a reviewer for you, use r? to override)","1","2015-10-08T09:00:10Z"
"247226","19561","146549894","350807","kaspth","Should promote it to the public namespace too (remember to remove [ci skip] from your commit then) :grin:","1","2015-10-08T13:44:49Z"
"247227","19561","146618193","47848","rafaelfranca","It don't need to be public namespace. Only add `# :doc:` to it","1","2015-10-08T16:47:21Z"
"247228","19561","146709376","987638","y-yagi","`# :doc:` is necessary for only private method and thinks that it is unnecessary because `prepare_destination` is protected method.
I tried to generate the doc without setting the `# :doc:`, it seems to be displayed.
","1","2015-10-08T22:46:31Z"
"247229","19561","146720388","1529387","sgrif","Yeah, I believe you're right. This should be fine.","1","2015-10-09T00:03:22Z"
"247230","19561","146729546","987638","y-yagi","Thanks!","1","2015-10-09T01:09:03Z"
"247231","19562","146468783","7468109","rails-bot","r? @matthewd
(@rails-bot has picked a reviewer for you, use r? to override)","1","2015-10-08T09:21:36Z"
"247232","19563","146469431","7468109","rails-bot","Thanks for the pull request, and welcome! The Rails team is excited to review your changes, and you should hear from @matthewd (or someone else) soon.
If any changes to this PR are deemed necessary, please add them as extra commits. This ensures that the reviewer can see what has changed since they last reviewed the code. Due to the way GitHub handles out-of-date commits, this should also make it reasonably obvious what issues have or haven't been addressed. Large or tricky changes may require several passes of review and changes.
Please see [the contribution instructions](http://edgeguides.rubyonrails.org/contributing_to_ruby_on_rails.html) for more information.
","1","2015-10-08T09:23:20Z"
"247233","19563","146565337","10076","claudiob","Hello @zachalewel – I believe `accept` is correct since it refers to two different subjects.
At that point, simply adding an `a` article to the CHANGELOG file might fall into the category of ""cosmetic changes"" that [do not add anything substantial to the stability, functionality, or testability of Rails will generally not be accepted](http://edgeguides.rubyonrails.org/contributing_to_ruby_on_rails.html#write-your-code).
I invite you to keep contributing to Rails in the future. If you need a place to start, you might look at [methods that need documentation](http://www.docsdoctor.org/rails/rails) or [list of open issues](http://www.codetriage.com/rails/rails).
Thanks! :ribbon:
","1","2015-10-08T14:36:22Z"
"247234","19563","146663526","1080678","eileencodes","Grammatically, ""accepts a"" is correct and since this is a grammar correction it's ok. In the future, please add `[ci skip]` so travis doesn't run on changes like this.","1","2015-10-08T19:30:56Z"
"247235","19563","146725105","1034","matthewd","@eileencodes shouldn't this be ""accept a""? ","1","2015-10-09T00:28:15Z"
"247236","19563","146727794","1080678","eileencodes","It doesn't read right to me as 'accept a' but I don't know. I don't think the original is correct though
> On Oct 8, 2015, at 8:28 PM, Matthew Draper <notifications@github.com> wrote:
>
> @eileencodes shouldn't this be ""accept a""?
>
> —
> Reply to this email directly or view it on GitHub.
>
","1","2015-10-09T00:54:20Z"
"247237","19563","146922428","52120","Fryguy","I think the plural of accept is ""accept"". So, I think ""accept a"" is correct
Oddly the 3rd person singular form is ""accepts""
```
Singular Plural
I accept We accept
You accept You accept
He/she/it accepts They accept
```
[Source](http://www.writingenglish.com/cverbs/accept.htm)","1","2015-10-09T16:30:57Z"
"247238","19563","146977972","1080678","eileencodes","Yea I think I was reading it as ""a accepts y"" and ""b accepts y"" so together ""a and be accepts y"" but then when I read it with literally any other sentence ""you and i accept"" I realize it's wrong. I had a long week :grin:","1","2015-10-09T20:23:17Z"
"247239","19564","146476132","7468109","rails-bot","Thanks for the pull request, and welcome! The Rails team is excited to review your changes, and you should hear from @pixeltrix (or someone else) soon.
If any changes to this PR are deemed necessary, please add them as extra commits. This ensures that the reviewer can see what has changed since they last reviewed the code. Due to the way GitHub handles out-of-date commits, this should also make it reasonably obvious what issues have or haven't been addressed. Large or tricky changes may require several passes of review and changes.
Please see [the contribution instructions](http://edgeguides.rubyonrails.org/contributing_to_ruby_on_rails.html) for more information.
","1","2015-10-08T09:46:36Z"
"247240","19564","146516657","6321","pixeltrix","@zachalewel thanks for the PR but I think in this case I prefer the original text","1","2015-10-08T11:59:01Z"
"247241","19564","146626504","47848","rafaelfranca",":+1: for original text. Thanks","1","2015-10-08T17:10:28Z"
"247242","19565","146519441","7468109","rails-bot","r? @matthewd
(@rails-bot has picked a reviewer for you, use r? to override)","1","2015-10-08T12:14:54Z"
"247243","19566","146536561","7468109","rails-bot","r? @kaspth
(@rails-bot has picked a reviewer for you, use r? to override)","1","2015-10-08T13:04:28Z"
"247244","19566","146553384","350807","kaspth","Gonna leave this up to someone else. @eileencodes @sgrif do one of you want this? :smile:","1","2015-10-08T13:56:38Z"
"247245","19566","146555815","1529387","sgrif","I'd prefer to see a benchmark that shows that actually preloading records improves if we're going to merge this from a performance point of view. That said, I do like this structure better than what was there before. However, the performance difference here is going to be trivial I think.","1","2015-10-08T14:03:35Z"
"247246","19566","150205460","122436","bogdan","@sgrif here it is (surprisingly it still shows ~5% change):
https://gist.github.com/74ac22af36e62c3040de
```
user system total real
---------------------1 iterations 1 associated for 10 given
After patch: 0.000000 0.000000 0.000000 ( 0.002354)
Before patch: 0.000000 0.000000 0.000000 ( 0.002398)
Improvement: 2%
--------------------1 iterations 10 associated for 10 given
After patch: 0.000000 0.000000 0.000000 ( 0.003126)
Before patch: 0.000000 0.000000 0.000000 ( 0.003319)
Improvement: 6%
-------------------1 iterations 100 associated for 10 given
After patch: 0.020000 0.000000 0.020000 ( 0.026294)
Before patch: 0.030000 0.010000 0.040000 ( 0.030489)
Improvement: 14%
--------------------1 iterations 1 associated for 100 given
After patch: 0.000000 0.000000 0.000000 ( 0.005105)
Before patch: 0.000000 0.000000 0.000000 ( 0.004928)
Improvement: -4%
-------------------1 iterations 10 associated for 100 given
After patch: 0.020000 0.000000 0.020000 ( 0.026311)
Before patch: 0.030000 0.000000 0.030000 ( 0.027560)
Improvement: 5%
------------------1 iterations 100 associated for 100 given
After patch: 0.240000 0.010000 0.250000 ( 0.250245)
Before patch: 0.260000 0.000000 0.260000 ( 0.266468)
Improvement: 6%
","1","2015-10-22T12:28:29Z"
"247247","19617","150579181","350807","kaspth","Can you rebase on master? ?","1","2015-10-23T13:54:03Z"
"247248","19617","150579825","1144873","greysteil","Done!","1","2015-10-23T13:57:06Z"
"247249","19617","150681470","350807","kaspth","Thanks!","1","2015-10-23T20:28:23Z"
"247250","19618","149048273","7468109","rails-bot","Thanks for the pull request, and welcome! The Rails team is excited to review your changes, and you should hear from @kaspth (or someone else) soon.
If any changes to this PR are deemed necessary, please add them as extra commits. This ensures that the reviewer can see what has changed since they last reviewed the code. Due to the way GitHub handles out-of-date commits, this should also make it reasonably obvious what issues have or haven't been addressed. Large or tricky changes may require several passes of review and changes.
Please see [the contribution instructions](http://edgeguides.rubyonrails.org/contributing_to_ruby_on_rails.html) for more information.
","1","2015-10-18T21:20:24Z"
"247251","19619","149153849","7468109","rails-bot","Thanks for the pull request, and welcome! The Rails team is excited to review your changes, and you should hear from @carlosantoniodasilva (or someone else) soon.
If any changes to this PR are deemed necessary, please add them as extra commits. This ensures that the reviewer can see what has changed since they last reviewed the code. Due to the way GitHub handles out-of-date commits, this should also make it reasonably obvious what issues have or haven't been addressed. Large or tricky changes may require several passes of review and changes.
Please see [the contribution instructions](http://edgeguides.rubyonrails.org/contributing_to_ruby_on_rails.html) for more information.
","1","2015-10-19T09:13:40Z"
"247252","19619","149155315","182","mtodd","Hmm, would like to see https://github.com/mtodd/rails/commit/b780f9581c76ef1176409036b2fdcc2a84acfbf3 built and fail as expected.","1","2015-10-19T09:20:41Z"
"247253","19619","151343512","833383","arthurnn","thanks , merged via 60c9701269f5b412849f1a507df61ba4735914d7","1","2015-10-27T02:06:13Z"
"247254","19619","151359161","47848","rafaelfranca","That broke the build so I reverted it.","1","2015-10-27T03:11:37Z"
"247255","19619","151382824","182","mtodd","For the record: the failing build referenced includes https://travis-ci.org/rails/rails/jobs/87585808#L1309-L1309
@rafaelfranca @arthurnn looks like `Company`'s `accounts` association was removed in @rafaelsales' commit https://github.com/rafaelsales/rails/commit/4f21d42faaf12955fa0116306966d4ef09e62462 (merged in https://github.com/rails/rails/commit/4f21d42faaf12955fa0116306966d4ef09e62462) very recently because it was missing an ID in the schema. So that would be the simple answer why it started failing (though reading through the history I'm surprised my branch didn't have that change).
@rafaelfranca @arthurnn who would know best about the current implementation of scope inheritance and this test in particular? @sikachu backported @Ben-M's patch for this test a while back, though I'm not sure how much the implementation has changed or whether the test was failing correctly in the first place (before the fix was applied), if the association in `Company.of_first_firm` is supposed to be plural or singular, or what...
In fact, I'm noticing that the [`Company.of_first_firm`](https://github.com/rails/rails/blob/190c69ece3a94dbd92f84833491d1b7b1bad06ea/activerecord/test/models/company.rb#L16) definition provides a `where('firms.id' => 1)` but there's no `firms` table since `Firm` is an STI class of Company. Does it matter for the test? Clearly not, since we're just testing that the scope is inherited, not whether the scope is correct.
Following that line of reasoning, it would seem that it doesn't matter if the association actually exists at all, just that both `Company`, the class that defines `of_first_firm`, and `Client`, the class that inherits `of_first_firm`, both respond to that method without exploding. This means that the test is fine as is, we don't need to actually materialize the SQL validating the associations in the scope, just that the subclass responds to the method.
Am I understanding the situation correctly? Is this kind of test or test environment acceptable?
If this is the case, I don't mind adding a comment in to explain as much for anybody who stumbles upon the test and wonders what the intent was, and offers a warning that the actual scope itself doesn't work.
","1","2015-10-27T05:54:07Z"
"247256","19619","151384501","182","mtodd","Opened https://github.com/rails/rails/pull/22084 with a simple documentation change, assuming I'm understanding the nature of the test correctly.","1","2015-10-27T06:09:27Z"
"247257","19620","149155575","7468109","rails-bot","Thanks for the pull request, and welcome! The Rails team is excited to review your changes, and you should hear from @pixeltrix (or someone else) soon.
If any changes to this PR are deemed necessary, please add them as extra commits. This ensures that the reviewer can see what has changed since they last reviewed the code. Due to the way GitHub handles out-of-date commits, this should also make it reasonably obvious what issues have or haven't been addressed. Large or tricky changes may require several passes of review and changes.
Please see [the contribution instructions](http://edgeguides.rubyonrails.org/contributing_to_ruby_on_rails.html) for more information.
","1","2015-10-19T09:21:52Z"
"247258","19620","149173547","6321","pixeltrix","@tak1n thanks for your PR - I just need to you to adjust for Rails 5 and then I'll merge it.","1","2015-10-19T10:08:52Z"
"247259","19620","149185422","675705","tak1n","Forgot to commit with [skip ci] sry ","1","2015-10-19T11:03:03Z"
"247260","19626","20373545","394835","grantovich","It definitely sounds like you're talking about a different problem than the one under discussion here. If the approach I suggested isn't working for you and you think there's a bug with Rails, I would open a separate issue.","1","2013-07-02T20:27:58Z"
"247261","19626","31334045","28369","saurabhnanda","I'm investigating this issue yet again, and it just doesn't make sense to me why as_json / to_json / serializable_hash is not called on associations that one explicitly `include`s in the call to `as_json`. What was the rationale for defining the API in this way?","1","2013-12-30T05:30:47Z"
"247262","19626","77569612","1943540","Ch4s3","I have to agree with @saurabhnanda I really don't get why `as_json` isn't called on included associations. It would be light-weight compared to RABL and active_model_serializers. Is there any interest in reopening this discussion with an eye toward new functionality?","1","2015-03-06T14:46:39Z"
"247263","19626","78883215","3498786","TangMonk","same issue in rails 4.2.0","1","2015-03-13T09:20:58Z"
"247264","19626","79059143","394835","grantovich","@TangMonk This has been closed as a non-issue, please see https://github.com/rails/rails/pull/2200#issuecomment-11008662 and https://github.com/rails/rails/pull/2200#issuecomment-14134738. Any further discussion would be on the subject of ""should overriding `as_json` become a supported use case"", which would be a separate feature request. (I wouldn't expect it to gain much traction though, since there are numerous workable alternatives, including overriding `serializable_hash` for those who cannot move to AMS or another solution – though that is similarly unsupported)","1","2015-03-13T15:42:54Z"
"247265","19688","160158262","833383","arthurnn","? ","1","2015-11-27T15:17:19Z"
"247266","19689","151675201","7468109","rails-bot","r? @arthurnn
(@rails-bot has picked a reviewer for you, use r? to override)","1","2015-10-27T23:33:43Z"
"247267","19690","151686027","7468109","rails-bot","Thanks for the pull request, and welcome! The Rails team is excited to review your changes, and you should hear from @arthurnn (or someone else) soon.
If any changes to this PR are deemed necessary, please add them as extra commits. This ensures that the reviewer can see what has changed since they last reviewed the code. Due to the way GitHub handles out-of-date commits, this should also make it reasonably obvious what issues have or haven't been addressed. Large or tricky changes may require several passes of review and changes.
Please see [the contribution instructions](http://edgeguides.rubyonrails.org/contributing_to_ruby_on_rails.html) for more information.
","1","2015-10-28T00:51:09Z"
"247268","19690","151689355","47848","rafaelfranca","After reviewing this PR I'm not sure if this improve something. The methods are shorten, sure but the code now is harder to follow, there are a lot of jumps over methods and order dependencies between them. Also, most of the changes are cosmetics and don't follow the Rails style guidelines like the early returns and the `fail` over `raise`. Thank said, we appreciate the effort but I think we will not apply this PR.","1","2015-10-28T01:14:37Z"
"247269","19690","151770058","781760","hnatt","@rafaelfranca Thanks for your attention! I'm still eager to contribute! Can you point me to a document where it says what techniques are preferred in Rails code? The section [Follow the coding conventions](http://edgeguides.rubyonrails.org/contributing_to_ruby_on_rails.html#follow-the-coding-conventions) in the contributing guidelines says very little. Except for ""Follow the conventions in the source you see used already"", but it can be understood as ""no refactoring ever, the code you see is perfect"".","1","2015-10-28T08:55:11Z"
"247270","19690","151817094","350807","kaspth","@hnatt thanks for the interest! :heart:
Try watching how other's got their refactoring pull requests merged in to Rails. That should give you a feel for what we think is worth it to merge, and why, while we appreciate your effort, don't think these changes overall, add up to much improvement. Thanks again!","1","2015-10-28T11:47:43Z"
"247271","19690","151855092","47848","rafaelfranca","There are still refactoring in your pr that are still good. I'll point
those so you can open a new pr just with these things.
On Wed, Oct 28, 2015, 09:47 Kasper Timm Hansen <notifications@github.com>
wrote:
> @hnatt <https://github.com/hnatt> thanks for the interest! [image:
> :heart:]
>
> Try watching how other's got their refactoring pull requests merged in to
> Rails. That should give you a feel for what we think is worth it to merge,
> and why, while we appreciate your effort, don't think these changes
> overall, add up to much improvement. Thanks again!
>
> —
> Reply to this email directly or view it on GitHub
> <https://github.com/rails/rails/pull/22094#issuecomment-151817094>.
>
","1","2015-10-28T14:02:42Z"
"247272","19690","151901728","47848","rafaelfranca","I'm pretty sure there are some methods in the `mail` method that can be extracted also, but it is better to do this kind of refactoring slowly. I recommend you to do a commit per refactoring so I can review them individually and we can chose what make sense and what doesn't. Pay attention to not go too far and lose the clarity of the method, also prefer to pass all the arguments to the methods instead of relying in the instance attributes.","1","2015-10-28T16:31:21Z"
"247273","19690","152139137","781760","hnatt","@rafaelfranca great, thanks! Will do another PR soon!","1","2015-10-29T10:32:10Z"
"247274","19690","152302204","781760","hnatt","@rafaelfranca did a PR #22120 with the two changes you pointed out were good. Also separated some chunks from `#mail` which appeared not very painful.","1","2015-10-29T20:00:05Z"
"247275","19691","151688679","7468109","rails-bot","Thanks for the pull request, and welcome! The Rails team is excited to review your changes, and you should hear from @kaspth (or someone else) soon.
If any changes to this PR are deemed necessary, please add them as extra commits. This ensures that the reviewer can see what has changed since they last reviewed the code. Due to the way GitHub handles out-of-date commits, this should also make it reasonably obvious what issues have or haven't been addressed. Large or tricky changes may require several passes of review and changes.
Please see [the contribution instructions](http://edgeguides.rubyonrails.org/contributing_to_ruby_on_rails.html) for more information.
","1","2015-10-28T01:08:44Z"
"247276","19692","151755303","7468109","rails-bot","r? @schneems
(@rails-bot has picked a reviewer for you, use r? to override)","1","2015-10-28T07:51:08Z"
"247277","19692","151866945","59744","schneems","Seems good, thanks","1","2015-10-28T14:39:49Z"
"247278","19693","151868812","7468109","rails-bot","r? @carlosantoniodasilva
(@rails-bot has picked a reviewer for you, use r? to override)","1","2015-10-28T14:46:37Z"
"247279","19693","151868892","5356517","yui-knk","Is this explanation enough?","1","2015-10-28T14:46:53Z"
"247280","19693","151893072","833383","arthurnn","thanks
","1","2015-10-28T16:02:22Z"
"247281","19693","151893160","833383","arthurnn",">Is this explanation enough?
I think so","1","2015-10-28T16:02:42Z"
"247282","19693","151894756","5356517","yui-knk",":smile: :yellow_heart: ","1","2015-10-28T16:07:40Z"
"247283","19694","863574","3387","fxn","Applied, thanks!","1","2011-03-12T13:31:25Z"
"247284","19695","1638234","672377","diedthreetimes","Shouldn't this just be the single b1b850d commit?","1","2011-07-23T18:22:35Z"
"247285","19703","152036443","199","jeremy","Batteries included. We needn't host all adapters in-tree, and queue/job libraries are free to adopt responsibility for their AJ adapter, but AJ itself is the nursery for them as they mature.
(Not to mention that removing them wholesale with zero recourse or guidance is particularly user-hostile ?)","1","2015-10-29T00:06:02Z"
"247286","19704","152050220","7468109","rails-bot","Thanks for the pull request, and welcome! The Rails team is excited to review your changes, and you should hear from @schneems (or someone else) soon.
If any changes to this PR are deemed necessary, please add them as extra commits. This ensures that the reviewer can see what has changed since they last reviewed the code. Due to the way GitHub handles out-of-date commits, this should also make it reasonably obvious what issues have or haven't been addressed. Large or tricky changes may require several passes of review and changes.
Please see [the contribution instructions](http://edgeguides.rubyonrails.org/contributing_to_ruby_on_rails.html) for more information.
","1","2015-10-29T01:55:59Z"
"247287","19704","152057052","59744","schneems","Thanks for the PR unfortunately the inflector is on lock down.","1","2015-10-29T02:52:55Z"
"247288","19705","152097640","7468109","rails-bot","Thanks for the pull request, and welcome! The Rails team is excited to review your changes, and you should hear from @sgrif (or someone else) soon.
If any changes to this PR are deemed necessary, please add them as extra commits. This ensures that the reviewer can see what has changed since they last reviewed the code. Due to the way GitHub handles out-of-date commits, this should also make it reasonably obvious what issues have or haven't been addressed. Large or tricky changes may require several passes of review and changes.
Please see [the contribution instructions](http://edgeguides.rubyonrails.org/contributing_to_ruby_on_rails.html) for more information.
","1","2015-10-29T06:52:38Z"
"247289","19705","152208008","1529387","sgrif","Thanks, but I don't think this is an improvement. I find the wording you've added confusing, and I'm not entirely sure what it's recommending. Are you implying that the defaults do not work?","1","2015-10-29T15:05:36Z"
"247290","19705","152228442","13164030","sachinvinsol","yes the default do not work.it only works for virtual attribute.
On Thu, Oct 29, 2015 at 8:36 PM, Sean Griffin <notifications@github.com>
wrote:
> Closed #22111 <https://github.com/rails/rails/pull/22111>.
>
> —
> Reply to this email directly or view it on GitHub
> <https://github.com/rails/rails/pull/22111#event-449317452>.
>
","1","2015-10-29T16:08:44Z"
"247291","19705","152265782","1529387","sgrif","Why would you have a database column for this, when there's a validation that says the record cannot be saved unless it has exactly one value? There's no point in persisting that.","1","2015-10-29T17:55:55Z"
"247292","19705","152432543","13164030","sachinvinsol","Yes, you are right. We should not support this validation for database column.
I think that we should remove this [line](https://github.com/rails/rails/blob/master/activemodel/lib/active_model/validations/acceptance.rb#L95) as the docs are inconsistent and really confuse the reader.","1","2015-10-30T05:52:09Z"
"247293","19705","166504968","13164030","sachinvinsol","@sgrif - Any update here? Should I update [this line](https://github.com/rails/rails/blob/master/activemodel/lib/active_model/validations/acceptance.rb#L95).","1","2015-12-22T04:57:12Z"
"247294","19706","152107060","7468109","rails-bot","Thanks for the pull request, and welcome! The Rails team is excited to review your changes, and you should hear from @rafaelfranca (or someone else) soon.
If any changes to this PR are deemed necessary, please add them as extra commits. This ensures that the reviewer can see what has changed since they last reviewed the code. Due to the way GitHub handles out-of-date commits, this should also make it reasonably obvious what issues have or haven't been addressed. Large or tricky changes may require several passes of review and changes.
Please see [the contribution instructions](http://edgeguides.rubyonrails.org/contributing_to_ruby_on_rails.html) for more information.
","1","2015-10-29T08:01:18Z"
"247295","19706","152123250","350807","kaspth","r? @fxn","1","2015-10-29T09:16:17Z"
"247296","19706","152853027","6321","pixeltrix","@claudix the problem is that Ruby finds the `ApplicationController` constant via the `Object` ancestor and doesn't trigger `const_missing` which is how Rails implements autoloading - I don't think the warning you've written explains this properly since it places the blame on how Rails loads the controllers which isn't the correct reason. I suggest something along these lines may be better:
NOTE: Because of the way that Ruby does constant lookup you may run into a situation
where your engine controller is inheriting from the main application controller and
not your engine's application controller. Ruby will look in the ancestor chain for
constants and every class has `Object` as an ancestor, meaning that if the global
`ApplicationController` is loaded Ruby will return that and not call `const_missing`
and trigger the Rails autoloading mechanism. The best way to prevent this from
happening is to use `require_dependency` to ensure that the engine's application
controller is loaded. For example:
``` ruby
# app/controllers/blorgh/articles_controller.rb:
require_dependency ""blorgh/application_controller""
module Blorgh
class ArticlesController < ApplicationController
...
end
end
```
WARNING: Don't use `require` because it will break the automatic reloading of classes
in the development environment - using `require_dependency` ensures that classes are
loaded and unloaded in the correct manner.
","1","2015-11-01T19:18:39Z"
"247297","19706","152853475","15111489","Michaelbrich","This is so true and I will create dependency injection by withholding methods of
Supplement
Michael
-----Original Message-----
From: ""Andrew White"" <notifications@github.com>
Sent: 11/1/2015 2:19 PM
To: ""rails/rails"" <rails@noreply.github.com>
Subject: Re: [rails] Added warning on coding engine controllers (#22112)
@claudix the problem is that Ruby finds the ApplicationController constant via the Object ancestor and doesn't trigger const_missing which is how Rails implements autoloading - I don't think the warning you've written explains this properly since it places the blame on how Rails loads the controllers which isn't the correct reason. I suggest something along these lines may be better:
NOTE: Because of the way that Ruby does constant lookup you may run into a situation
where your engine controller is inheriting from the main application controller and
not your engine's application controller. Ruby will look in the ancestor chain for
constants and every class has `Object` as an ancestor, meaning that if the global
`ApplicationController` is loaded Ruby will return that and not call `const_missing`
and trigger the Rails autoloading mechanism. The best way to prevent this from
happening is to use `require_dependency` to ensure that the engine's application
controller is loaded. For example:
``` ruby
# app/controllers/blorgh/articles_controller.rb:
require_dependency ""blorgh/application_controller""
module Blorgh
class ArticlesController < ApplicationController
...
end
end
```
WARNING: Don't use `require` because it will break the automatic reloading of classes
in the development environment - using `require_dependency` ensures that classes are
loaded and unloaded in the correct manner.
—
Reply to this email directly or view it on GitHub.","1","2015-11-01T19:26:13Z"
"247298","19706","152856373","5880835","claudix","@pixeltrix, thank you very much for your reply. I'm not an expert on how Ruby internals work and I was actually looking for a better explanation of what I faced with. If you don't mind I'll take your words as-is to update this branch.","1","2015-11-01T19:47:03Z"
"247299","19706","152864272","3387","fxn","I am on my mobile, what about a shorter warning that links to this gotcha in the autoloading guide?","1","2015-11-01T21:11:20Z"
"247300","19706","156321544","3387","fxn","The patch looks good to me. Only one remark:
> Ruby will look in the ancestor chain for constants and every class has `Object` as an ancestor, meaning that if the global `ApplicationController` is loaded Ruby will return that and not call `const_missing` and trigger the Rails autoloading mechanism.
On one hand it is not the case that every class has `Object` as an ancestor, because a Ruby class may inherit from `BasicObject` without inheriting from `Object`. And some do, indeed. The autoloading guide [has a section](http://guides.rubyonrails.org/autoloading_and_reloading_constants.html#autoloading-in-basicobject) about it.
Also, in that spot `ApplicationController` is not looked up in the ancestor chain of the engine controller, precisely at that point the ancestor chain is being defined. Rather, the nesting to look up that constant is `[Blorgh]`. Since `ApplicationController` is a relative constant, the module is checked, it does not exist there (hypothesis), and Ruby then tries `Object` by hand even if it does not belong to its ancestor chain because [modules have that special rule](http://guides.rubyonrails.org/autoloading_and_reloading_constants.html#resolution-algorithms).
You can test this for example this way:
```ruby
class BasicObject
class D < Object
end
end
```
In that example `BasicObject::D` is a regular class, it does *not* inherit from `BasicObject`, but Ruby raises ""uninitialized constant BasicObject::Object (NameError)"" because it tries to resolve `Object` with nesting `[BasicObject]` regardless of the nature of `D`.
I think this would work:
> Ruby is able to resolve the `ApplicationController` constant, and therefore the autoloading mechanism is not triggered. See the section [When Constants Aren't Missed](http://guides.rubyonrails.org/autoloading_and_reloading_constants.html#when-constants-aren-t-missed) of the [Autoloading and Reloading Constants](http://guides.rubyonrails.org/autoloading_and_reloading_constants.html) guide for further details.
","1","2015-11-13T04:57:38Z"
"247301","19706","156360115","5880835","claudix","Thanks @fxn for your assessment!","1","2015-11-13T08:21:52Z"
"247302","19706","156571278","3387","fxn","Thanks!","1","2015-11-13T22:00:33Z"
"247303","19707","152166479","7468109","rails-bot","Thanks for the pull request, and welcome! The Rails team is excited to review your changes, and you should hear from @kaspth (or someone else) soon.
If any changes to this PR are deemed necessary, please add them as extra commits. This ensures that the reviewer can see what has changed since they last reviewed the code. Due to the way GitHub handles out-of-date commits, this should also make it reasonably obvious what issues have or haven't been addressed. Large or tricky changes may require several passes of review and changes.
Please see [the contribution instructions](http://edgeguides.rubyonrails.org/contributing_to_ruby_on_rails.html) for more information.
","1","2015-10-29T12:40:11Z"
"247304","19707","152167999","277819","zzak","LGTM /cc @senny ","1","2015-10-29T12:47:37Z"
"247305","19707","152172724","5402","senny",":+1: ","1","2015-10-29T12:58:22Z"
"247306","19708","152197326","7468109","rails-bot","r? @rafaelfranca
(@rails-bot has picked a reviewer for you, use r? to override)","1","2015-10-29T14:29:35Z"
"247307","19708","152197699","122436","bogdan","r? @sgrif ","1","2015-10-29T14:30:55Z"
"247308","19709","152198528","7468109","rails-bot","r? @matthewd
(@rails-bot has picked a reviewer for you, use r? to override)","1","2015-10-29T14:34:12Z"
"247309","19709","152213029","5402","senny","@gsamokovarov :+1: ","1","2015-10-29T15:22:51Z"
"247310","19710","152227545","7468109","rails-bot","r? @eileencodes
(@rails-bot has picked a reviewer for you, use r? to override)","1","2015-10-29T16:06:45Z"
"247311","19711","152266595","7468109","rails-bot","Thanks for the pull request, and welcome! The Rails team is excited to review your changes, and you should hear from @rafaelfranca (or someone else) soon.
If any changes to this PR are deemed necessary, please add them as extra commits. This ensures that the reviewer can see what has changed since they last reviewed the code. Due to the way GitHub handles out-of-date commits, this should also make it reasonably obvious what issues have or haven't been addressed. Large or tricky changes may require several passes of review and changes.
Please see [the contribution instructions](http://edgeguides.rubyonrails.org/contributing_to_ruby_on_rails.html) for more information.
","1","2015-10-29T17:58:48Z"
"247312","19711","152307047","6321","pixeltrix","@philr thanks for the PR! When providing documentation only updates please can you append `[ci skip]` to the commit message to spare our poor overworked CI servers :smile: - thanks again.","1","2015-10-29T20:20:26Z"
"247313","19712","152297095","7468109","rails-bot","Thanks for the pull request, and welcome! The Rails team is excited to review your changes, and you should hear from @rafaelfranca (or someone else) soon.
If any changes to this PR are deemed necessary, please add them as extra commits. This ensures that the reviewer can see what has changed since they last reviewed the code. Due to the way GitHub handles out-of-date commits, this should also make it reasonably obvious what issues have or haven't been addressed. Large or tricky changes may require several passes of review and changes.
Please see [the contribution instructions](http://edgeguides.rubyonrails.org/contributing_to_ruby_on_rails.html) for more information.
","1","2015-10-29T19:38:09Z"
"247314","19712","159136773","47848","rafaelfranca"," :heart: :green_heart: :blue_heart: :yellow_heart: :purple_heart:","1","2015-11-24T02:55:06Z"
"247315","19712","159136844","47848","rafaelfranca","Thank you so much. I merged this PR and made some more modifications.","1","2015-11-24T02:55:50Z"
"247316","19712","160183516","833383","arthurnn","❤️ ? (awesome avatar)","1","2015-11-27T18:01:47Z"
"247317","19713","152303621","7468109","rails-bot","Thanks for the pull request, and welcome! The Rails team is excited to review your changes, and you should hear from @rafaelfranca (or someone else) soon.
If any changes to this PR are deemed necessary, please add them as extra commits. This ensures that the reviewer can see what has changed since they last reviewed the code. Due to the way GitHub handles out-of-date commits, this should also make it reasonably obvious what issues have or haven't been addressed. Large or tricky changes may require several passes of review and changes.
Please see [the contribution instructions](http://edgeguides.rubyonrails.org/contributing_to_ruby_on_rails.html) for more information.
","1","2015-10-29T20:06:24Z"
"247318","19713","152307673","110275","hmarr","@pixeltrix I also just removed now-outdated comments about the availability of the setting","1","2015-10-29T20:23:13Z"
"247319","19713","152307904","6321","pixeltrix","@hmarr thanks - want to amend the CHANGELOG entry as well?","1","2015-10-29T20:24:20Z"
"247320","19713","152308231","6321","pixeltrix","@hmarr oh, can you squash the commits as well so I can backport them easily - thanks.","1","2015-10-29T20:25:36Z"
"247321","19713","152309781","110275","hmarr","@pixeltrix updated the changelog & squashed","1","2015-10-29T20:32:04Z"
"247322","19713","152314818","6321","pixeltrix","@hmarr thanks - will merge and backport when the build is green","1","2015-10-29T20:44:03Z"
"247323","19713","152326936","6321","pixeltrix","Backported in c76b074 - thanks for fixing so quickly @hmarr","1","2015-10-29T21:06:38Z"
"247324","19713","152333310","110275","hmarr","@pixeltrix no worries - thanks for your help","1","2015-10-29T21:27:47Z"
"247325","19713","155730137","142624","ivanovv","any chance of this being backported to 4.1 branch?","1","2015-11-11T10:35:18Z"
"247326","19713","155738020","6321","pixeltrix","@ivanovv having just checked which versions of the pg gem we support on 4.1 (which is pg 0.11), PostgreSQL 7.4 and later are compatible so we'd possibly be breaking someone's application. Given that I think it's too risky to backport, sorry.","1","2015-11-11T11:09:57Z"
"247327","19714","152334598","7468109","rails-bot","Thanks for the pull request, and welcome! The Rails team is excited to review your changes, and you should hear from @schneems (or someone else) soon.
If any changes to this PR are deemed necessary, please add them as extra commits. This ensures that the reviewer can see what has changed since they last reviewed the code. Due to the way GitHub handles out-of-date commits, this should also make it reasonably obvious what issues have or haven't been addressed. Large or tricky changes may require several passes of review and changes.
Please see [the contribution instructions](http://edgeguides.rubyonrails.org/contributing_to_ruby_on_rails.html) for more information.
","1","2015-10-29T21:33:41Z"
"247328","19714","152335610","4147639","samphilipd","Improves on this previous implementation https://github.com/rails/rails/pull/22103","1","2015-10-29T21:38:17Z"
"247329","19714","152336213","59744","schneems","Interesting idea. Is this a pain point that you've run into before? Are we protected a little by default by the databases already? For example I would have assumed postgres would use a locking structure to prevent duplicate changes to the same table.","1","2015-10-29T21:39:47Z"
"247330","19714","152336372","59744","schneems","r? @sgrif or @matthewd ","1","2015-10-29T21:40:39Z"
"247331","19714","152338622","1529387","sgrif","Can we add a test case for this?","1","2015-10-29T21:51:35Z"
"247332","19714","152338944","4147639","samphilipd","@schneems
> Interesting idea. Is this a pain point that you've run into before?
Yup, see the issue referenced in the commit message.
> Are we protected a little by default by the databases already? For example I would have assumed postgres would use a locking structure to prevent duplicate changes to the same table.
Postgres will throw an exception if you try to simultanously add a new column with the same name twice for example, but other than that there is no protection. See issue #22092 for examples of what can go wrong here.","1","2015-10-29T21:53:03Z"
"247333","19714","152349822","1529387","sgrif","This looks fine, other than the remaining comments and adding a test for this.","1","2015-10-29T22:52:10Z"
"247334","19714","152526742","4147639","samphilipd","@sgrif thanks for the feedback, I addressed all your comments and added tests. Let me know when you have reviewed and if everything is good I will clean up the commit history.","1","2015-10-30T13:30:39Z"
"247335","19714","152548183","1529387","sgrif","Good to squash & rebase","1","2015-10-30T14:58:49Z"
"247336","19715","152499936","7468109","rails-bot","r? @carlosantoniodasilva
(@rails-bot has picked a reviewer for you, use r? to override)","1","2015-10-30T11:26:03Z"
"247337","19760","153950474","199","jeremy","?","1","2015-11-05T04:11:16Z"
"247338","19761","153990278","7468109","rails-bot","r? @matthewd
(@rails-bot has picked a reviewer for you, use r? to override)","1","2015-11-05T08:42:01Z"
"247339","19761","154169718","6321","pixeltrix","@kamipo thanks","1","2015-11-05T19:44:57Z"
"247340","19762","153999358","7468109","rails-bot","r? @kaspth
(@rails-bot has picked a reviewer for you, use r? to override)","1","2015-11-05T09:12:49Z"
"247341","19762","154025982","350807","kaspth","Don't think I'm the best reviewer for this ?
R+ @rails-bot","1","2015-11-05T10:42:09Z"
"247342","19762","154025984","7468109","rails-bot","r+ @eileencodes. This pull request was approved by one of the reviewers and it is waiting your decision","1","2015-11-05T10:42:09Z"
"247343","19762","154170010","5402","senny","@kamipo what is not working as long as this entry is missing? Can we specify that in a test-case?","1","2015-11-05T19:46:08Z"
"247344","19762","154170318","350807","kaspth","Be sure to clarify that in your commit message as well :grin:","1","2015-11-05T19:47:14Z"
"247345","19762","154727249","12642","kamipo","This PR is nitpick.
`NATIVE_DATABASE_TYPES` is used in `type_to_sql` for look up to native database type.
```ruby
def type_to_sql(type, limit = nil, precision = nil, scale = nil) #:nodoc:
if native = native_database_types[type.to_sym]
column_type_sql = (native.is_a?(Hash) ? native[:name] : native).dup
```
https://github.com/kamipo/rails/blob/add_missing_serial_in_native_database_types/activerecord/lib/active_record/connection_adapters/abstract/schema_statements.rb#L999
In most case, not have any problem though forgot the additions to the `NATIVE_DATABASE_TYPES`.
It is because if missing in the `NATIVE_DATABASE_TYPES`, `type_to_sql` will `to_s` the `type` simply.
https://github.com/kamipo/rails/blob/add_missing_serial_in_native_database_types/activerecord/lib/active_record/connection_adapters/abstract/schema_statements.rb#L1027","1","2015-11-07T17:32:34Z"
"247346","19762","154728391","5402","senny","@kamipo but shouldn't the default behavior `to_s` be equivalent to adding all those entries? Does this change any actual behavior?","1","2015-11-07T17:35:41Z"
"247347","19762","154738645","12642","kamipo","Ideally, the supported types should be added to the `NATIVE_DATABASE_TYPES`. It is because a column type is checked by `valid_type?` in `SchemaDumper`.
```ruby
# then dump all non-primary key columns
column_specs = columns.map do |column|
raise StandardError, ""Unknown type '#{column.sql_type}' for column '#{column.name}'"" unless @connection.valid_type?(column.type)
next if column.name == pk
@connection.column_spec(column)
end.compact
```
https://github.com/kamipo/rails/blob/add_missing_serial_in_native_database_types/activerecord/lib/active_record/schema_dumper.rb#L148
`valid_type?`:
```ruby
def valid_type?(type)
!native_database_types[type].nil?
end
```
https://github.com/kamipo/rails/blob/add_missing_serial_in_native_database_types/activerecord/lib/active_record/connection_adapters/postgresql_adapter.rb#L373-L375","1","2015-11-07T18:53:13Z"
"247348","19762","160463593","12642","kamipo","Closed in favor of #22302 and #22304. Thanks!","1","2015-11-29T20:16:31Z"
"247349","19763","154001672","7468109","rails-bot","r? @senny
(@rails-bot has picked a reviewer for you, use r? to override)","1","2015-11-05T09:22:12Z"
"247350","19763","154086386","5402","senny","@kamipo thank you :yellow_heart: ","1","2015-11-05T15:05:21Z"
"247351","19764","1638711","52642","spastorino","@kommen Can you provide the same fix for master? thanks","1","2011-07-23T20:51:08Z"
"247352","19764","1638730","52642","spastorino","@kommen also we need a backport for 3-0-stable too in order to close [2080](https://github.com/rails/rails/pull/2080)","1","2011-07-23T20:55:33Z"
"247353","19764","2399802","199","jeremy","This was applied to 3-1-stable, but not master.
","1","2011-10-13T20:34:29Z"
"247354","19764","2399928","258","kommen","@jeremy, that's right. I opend pull request #2224 back then, but as of now it's still open and nobody gave feedback.","1","2011-10-13T20:45:55Z"
"247355","19765","154022690","7468109","rails-bot","Thanks for the pull request, and welcome! The Rails team is excited to review your changes, and you should hear from @matthewd (or someone else) soon.
If any changes to this PR are deemed necessary, please add them as extra commits. This ensures that the reviewer can see what has changed since they last reviewed the code. Due to the way GitHub handles out-of-date commits, this should also make it reasonably obvious what issues have or haven't been addressed. Large or tricky changes may require several passes of review and changes.
Please see [the contribution instructions](http://edgeguides.rubyonrails.org/contributing_to_ruby_on_rails.html) for more information.
","1","2015-11-05T10:33:38Z"
"247356","19765","154168937","6321","pixeltrix","@1st8 nice catch! If you could add a CHANGELOG entry and squash the commits that'd be great.","1","2015-11-05T19:41:42Z"
"247357","19765","154341598","646693","1st8","Thanks for your feedback, it's done.","1","2015-11-06T08:16:19Z"
"247358","19765","155411566","6321","pixeltrix","@1st8 sorry, for the delay in merging - I just tweaked the commit message and changelog entry and then merged it in 320b79f. I've also backported it to 4-1-stable (4696e0d) and 4-2-stable (8f6ee25).","1","2015-11-10T12:47:59Z"
"247359","19765","155411698","6321","pixeltrix","@1st8 sorry, forgot to say thanks for you fix :smile:","1","2015-11-10T12:48:27Z"
"247360","19765","155412345","646693","1st8","Very nice, thank you. I am happy to contribute! :beers: ","1","2015-11-10T12:52:12Z"
"247361","19766","154034105","7468109","rails-bot","r? @chancancode
(@rails-bot has picked a reviewer for you, use r? to override)","1","2015-11-05T11:18:04Z"
"247362","19766","154051612","350807","kaspth","?","1","2015-11-05T12:56:55Z"
"247363","19766","154055650","2415484","jonatack","Thanks @kaspth :deciduous_tree: ","1","2015-11-05T13:09:09Z"
"247364","19767","154149853","7468109","rails-bot","Thanks for the pull request, and welcome! The Rails team is excited to review your changes, and you should hear from @sgrif (or someone else) soon.
If any changes to this PR are deemed necessary, please add them as extra commits. This ensures that the reviewer can see what has changed since they last reviewed the code. Due to the way GitHub handles out-of-date commits, this should also make it reasonably obvious what issues have or haven't been addressed. Large or tricky changes may require several passes of review and changes.
Please see [the contribution instructions](http://edgeguides.rubyonrails.org/contributing_to_ruby_on_rails.html) for more information.
","1","2015-11-05T18:46:24Z"
"247365","19767","154167844","6321","pixeltrix","Checking the content type isn't anymore secure since that could be sent by the client as well. You'd only disable CSRF protection like this if you have some form of authentication in place, so the example in the docs is a bit contrived. I definitely think we should improve the example but just changing it to content type isn't correct,","1","2015-11-05T19:37:28Z"
"247366","19767","154201783","1191","al2o3cr","`Content-Type` describes the way the incoming data (in a `POST`, for instance) should be interpreted. `GET` requests won't have one at all, generally.
`format` and the `Accept` header describe the way the data returned in the response should be formatted.
Requests with a JSON payload format (`Content-Type` of JSON) usually expect a JSON response (via `.json` at the end of the URL, or via an `Accept` header). But this is NOT true for all cases, so swapping `format` for `content_type` does not accomplish the same thing.
Not certain *which* behavior is correct or desirable, but they are different.","1","2015-11-05T21:40:46Z"
"247367","19767","154213370","6321","pixeltrix","> Not certain which behavior is correct or desirable, but they are different
Yes, they are different but neither are safe from client modification which is why we changed the behaviour for XHR POST requests to require CSRF by default some time ago. We used to think that the same origin policy was protection but it turned out that browser plugins could circumvent that.
","1","2015-11-05T22:20:04Z"
"247368","19768","154258144","7468109","rails-bot","Thanks for the pull request, and welcome! The Rails team is excited to review your changes, and you should hear from @eileencodes (or someone else) soon.
If any changes to this PR are deemed necessary, please add them as extra commits. This ensures that the reviewer can see what has changed since they last reviewed the code. Due to the way GitHub handles out-of-date commits, this should also make it reasonably obvious what issues have or haven't been addressed. Large or tricky changes may require several passes of review and changes.
Please see [the contribution instructions](http://edgeguides.rubyonrails.org/contributing_to_ruby_on_rails.html) for more information.
","1","2015-11-06T01:36:27Z"
"247369","19768","154276766","11367","grosser","rebased :)","1","2015-11-06T03:44:20Z"
"247370","19768","154412600","1080678","eileencodes","Hi @grosser - thanks for the PR! Can you update your commit message to explain a little more indepth how/when it was getting called 3 times. Obviously calling something once is better than 3 times, but commit messages should better explain the what and the why of our changes that way we don't need to come back to github to learn more about a change :smile: ","1","2015-11-06T13:42:33Z"
"247371","19768","154420172","11367","grosser","better ?","1","2015-11-06T14:20:14Z"
"247372","19768","154527150","1080678","eileencodes","I restarted this job to see if the AJ test passes. Tests after aren't failing and I haven't had time to investigate why they just barf out uninitialized constant on my machine. Can you just check that your change didn't cause the failure in AJ?","1","2015-11-06T20:43:48Z"
"247373","19768","154531105","11367","grosser","green now ... so I don't think my change causes the failures","1","2015-11-06T20:54:41Z"
"247374","19768","154532091","1080678","eileencodes","Ah yes good, I thought I reran it before and it was still red. Didn't think it was related but wanted to double check.
Thanks!","1","2015-11-06T20:55:57Z"
"247375","19769","154259464","7468109","rails-bot","Thanks for the pull request, and welcome! The Rails team is excited to review your changes, and you should hear from @sgrif (or someone else) soon.
If any changes to this PR are deemed necessary, please add them as extra commits. This ensures that the reviewer can see what has changed since they last reviewed the code. Due to the way GitHub handles out-of-date commits, this should also make it reasonably obvious what issues have or haven't been addressed. Large or tricky changes may require several passes of review and changes.
Please see [the contribution instructions](http://edgeguides.rubyonrails.org/contributing_to_ruby_on_rails.html) for more information.
","1","2015-11-06T01:44:22Z"
"247376","19769","154274142","11367","grosser","thx! :D ","1","2015-11-06T03:27:37Z"
"247377","19771","154536694","350807","kaspth","@grosser you already pinged Sean in the description, curious why you're pinging so soon again? ?","1","2015-11-06T21:01:25Z"
"247378","19771","154542085","11367","grosser","don't want anyone to see / deal with the brokenness that got merged in the last PR :D ","1","2015-11-06T21:10:23Z"
"247379","19771","154562022","350807","kaspth","Think the patch looks good, but can you elaborate your change in the commit message? :)","1","2015-11-06T22:28:16Z"
"247380","19771","154576753","11367","grosser","the `def fetch` was merged in https://github.com/rails/rails/pull/22194 at which point I was not aware that I'm overwriting the actual fetch method, which should not return entries but actual values -> fix that bug + add a test to make sure it does not happen again","1","2015-11-06T23:32:29Z"
"247381","19771","154721975","11367","grosser","NoMethodError: protected method `fetch_entry' called for #<ActiveSupport::Cache::Strategy::LocalCache::LocalStore:0","1","2015-11-07T16:37:56Z"
"247382","19771","154721995","11367","grosser","so public or I can use send ...","1","2015-11-07T16:38:13Z"
"247383","19771","154724954","350807","kaspth","Damn it, missed entirely that the method was in another scope :smile:
Thanks!","1","2015-11-07T17:17:06Z"
"247384","19772","154348409","7468109","rails-bot","r? @rafaelfranca
(@rails-bot has picked a reviewer for you, use r? to override)","1","2015-11-06T08:58:12Z"
"247385","19772","159144445","47848","rafaelfranca","I don't like the idea of adding that defensive code in Action View for cases that don't seem to happen a lot. Even the case in the router where action is an empty string I don't see happening.","1","2015-11-24T04:05:09Z"
"247386","19772","161228806","987638","y-yagi","Thank you for your comment.
I agree with your point out. In certainly frequently occurring problem I think that it is not.
I close this PR.
","1","2015-12-02T09:11:29Z"
"247387","19773","863980","9582","josevalim","Great patch, applied as well.","1","2011-03-12T17:35:52Z"
"247388","19774","154419723","7468109","rails-bot","Thanks for the pull request, and welcome! The Rails team is excited to review your changes, and you should hear from @arthurnn (or someone else) soon.
If any changes to this PR are deemed necessary, please add them as extra commits. This ensures that the reviewer can see what has changed since they last reviewed the code. Due to the way GitHub handles out-of-date commits, this should also make it reasonably obvious what issues have or haven't been addressed. Large or tricky changes may require several passes of review and changes.
Please see [the contribution instructions](http://edgeguides.rubyonrails.org/contributing_to_ruby_on_rails.html) for more information.
","1","2015-11-06T14:18:00Z"
"247389","19774","154500973","11367","grosser","ok, should be green now ... had some random error ...","1","2015-11-06T18:56:50Z"
"247390","19774","154513464","350807","kaspth","Please add some more details to your commit message. Why can we safely replace the extend in initialize in with `prepend`, for instance?","1","2015-11-06T19:45:39Z"
"247391","19774","154521092","11367","grosser","better ?","1","2015-11-06T20:18:10Z"
"247392","19774","154529859","350807","kaspth","Way better, thanks ?","1","2015-11-06T20:52:47Z"
"247393","19775","154469065","7468109","rails-bot","Thanks for the pull request, and welcome! The Rails team is excited to review your changes, and you should hear from @arthurnn (or someone else) soon.
If any changes to this PR are deemed necessary, please add them as extra commits. This ensures that the reviewer can see what has changed since they last reviewed the code. Due to the way GitHub handles out-of-date commits, this should also make it reasonably obvious what issues have or haven't been addressed. Large or tricky changes may require several passes of review and changes.
Please see [the contribution instructions](http://edgeguides.rubyonrails.org/contributing_to_ruby_on_rails.html) for more information.
","1","2015-11-06T16:50:55Z"
"247394","19775","154485797","833383","arthurnn","see that if there is an error on the memcache backend we will return false https://github.com/grosser/rails/blob/9011e27a3cd2187a65900b00e058f22c2f1c2377/activesupport/lib/active_support/cache/mem_cache_store.rb#L152
I guess in that scenario we dont wanna write to the local cache, to not have inconsistent data.","1","2015-11-06T17:56:45Z"
"247395","19775","154529903","11367","grosser","original implementation does not care https://github.com/rails/rails/blob/master/activesupport/lib/active_support/cache/strategy/local_cache.rb#L116-L119
and all other methods do not care, for example a read that fails will cache nil a delete that fails still deletes from local cache etc ... so I think this behavior is more consistent ...
also since that user is writing the value it is the 'truth' and getting back and old value would also be bad (just calculated a new result -> read it from cache -> old result)","1","2015-11-06T20:52:51Z"
"247396","19775","154581502","11367","grosser","/fyi @kaspth @jeremy in case you got a opinion on expected behavior here ...","1","2015-11-07T00:01:31Z"
"247397","19775","154690859","350807","kaspth","Sorry, don't have any input here.","1","2015-11-07T10:46:46Z"
"247398","19775","160515782","11367","grosser","@arthurnn fixed the duplicate write too now :D
","1","2015-11-30T04:55:08Z"
"247399","19775","160515903","11367","grosser","I can haz merge now ? :)","1","2015-11-30T04:56:52Z"
"247400","19775","162238648","11367","grosser","@arthurnn looking good ?
","1","2015-12-05T19:15:48Z"
"247401","19775","162245238","833383","arthurnn","thanks @grosser !","1","2015-12-05T20:57:28Z"
"247402","19776","154507090","7468109","rails-bot","r? @eileencodes
(@rails-bot has picked a reviewer for you, use r? to override)","1","2015-11-06T19:20:24Z"
"247403","19776","154540519","1080678","eileencodes","Hey @cllns thanks for the PR! I think the anchor is incorrect, I think it should be going to #the-has-many-association. Can you check on that? ","1","2015-11-06T21:07:10Z"
"247404","19776","154549349","632942","cllns","I think it's correct! Since the code specifically refers to a helper method, I think it makes more sense to link down to the list of helper methods. I could switch it to `#methods-added-by-has-many`, but they're basically the same (since it's only a few lines below what `#has-many-association-reference`) and pointing to `#has-many-association-reference` provides some useful context.
For reference:
- [#has-many-association-reference](http://guides.rubyonrails.org/association_basics.html#has-many-association-reference)
- [#the-has-many-association](http://guides.rubyonrails.org/association_basics.html#the-has-many-association)
- [#methods-added-by-has-many](http://guides.rubyonrails.org/association_basics.html#methods-added-by-has-many)","1","2015-11-06T21:37:54Z"
"247405","19776","154549859","1080678","eileencodes","Thanks I couldn't find it, wasn't sure where it was pointing too. ","1","2015-11-06T21:40:13Z"
"247406","19777","154612058","7468109","rails-bot","Thanks for the pull request, and welcome! The Rails team is excited to review your changes, and you should hear from @senny (or someone else) soon.
If any changes to this PR are deemed necessary, please add them as extra commits. This ensures that the reviewer can see what has changed since they last reviewed the code. Due to the way GitHub handles out-of-date commits, this should also make it reasonably obvious what issues have or haven't been addressed. Large or tricky changes may require several passes of review and changes.
Please see [the contribution instructions](http://edgeguides.rubyonrails.org/contributing_to_ruby_on_rails.html) for more information.
","1","2015-11-07T03:29:12Z"
"247407","19777","157162658","11367","grosser","@rafaelfranca rebased this on the normalize_key PR to make it cleaner, looks good ?","1","2015-11-16T20:39:36Z"
"247408","19777","157170526","5402","senny","?r @rafaelfranca ","1","2015-11-16T21:08:10Z"
"247409","19777","157413337","11367","grosser","@rafaelfranca can you take a look ?","1","2015-11-17T16:00:05Z"
"247410","19777","157812477","11367","grosser","@rafaelfranca ping :)","1","2015-11-18T18:31:56Z"
"247411","19777","157829811","47848","rafaelfranca","I'll take a look, but before that @jeremy explained me what is the API breakage at https://github.com/rails/rails/pull/22215. The changes in the FileStore cache will make its subclasses to not work because `namespaced_key` returns the key now, the same with MemCacheStore subclasses that now have `namespaced_key` to return unescaped keys. That said we will need to revert that change.
Is possible to apply the changes in this PRs without relying on that change?","1","2015-11-18T19:22:45Z"
"247412","19777","157834280","11367","grosser","could be possible but then I have to rebase it and it will be uglier ...
I think the normalize_key is a great step forward ... makes things dry and clean ... it might break when someone extends FileStore or MemcachedStore ... but how many people do that ... blocking any change on perfect backwards compatibility is pretty limiting :(","1","2015-11-18T19:31:47Z"
"247413","19777","157834581","11367","grosser","also should be obvious since it will blow up when undefined method escape_key / file_to_path ...","1","2015-11-18T19:32:57Z"
"247414","19777","157834916","47848","rafaelfranca","Yes. I have to agree with that. I'll give it a second thought.","1","2015-11-18T19:34:21Z"
"247415","19777","157835028","11367","grosser","basically: children of FileStore / Memcached would need to use `escape_key(namespaced_key(xxx))` and that will blow up now ... ","1","2015-11-18T19:34:45Z"
"247416","19777","158468193","47848","rafaelfranca","Could you rebase it please?","1","2015-11-20T17:34:55Z"
"247417","19777","158489355","11367","grosser","rebased
downside of this PR will be that classes (not only Cache subclasses) that do not use increment_entry/decrement_entry lose local caching for increment+decrement since increment_entry + decrement_entry will never be called ... I'll add a deprecation for that (included hook to check if methods are defined) ... could lead to bugs like read+increment+read = stale value ... so we should get this into dalli_store / libmemcached_store to cover the most common ones ...","1","2015-11-20T18:46:45Z"
"247418","19777","158574464","11367","grosser","idk how to deprectace increment/decrement ... I cannot do it at inclusion since the module might be the first thing that is included -> methods are not defined ... and I cannot do it on initialize since the methods are then always defined because of the LocalCache inclusion ... smart idea welcome ...","1","2015-11-21T01:54:59Z"
"247419","19778","154612811","7468109","rails-bot","Thanks for the pull request, and welcome! The Rails team is excited to review your changes, and you should hear from @rafaelfranca (or someone else) soon.
If any changes to this PR are deemed necessary, please add them as extra commits. This ensures that the reviewer can see what has changed since they last reviewed the code. Due to the way GitHub handles out-of-date commits, this should also make it reasonably obvious what issues have or haven't been addressed. Large or tricky changes may require several passes of review and changes.
Please see [the contribution instructions](http://edgeguides.rubyonrails.org/contributing_to_ruby_on_rails.html) for more information.
","1","2015-11-07T03:33:22Z"
"247420","19778","154722057","1529387","sgrif","Can you rebase as well? Master should be green now.","1","2015-11-07T16:39:41Z"
"247421","19778","154722851","11367","grosser","fixed and rebased","1","2015-11-07T16:48:06Z"
"247422","19779","154661394","7468109","rails-bot","r? @arthurnn
(@rails-bot has picked a reviewer for you, use r? to override)","1","2015-11-07T09:00:26Z"
"247423","19779","154689556","350807","kaspth","Thanks!","1","2015-11-07T10:30:55Z"
"247424","19779","154689611","5356517","yui-knk",":)","1","2015-11-07T10:32:36Z"
"247425","19780","154686891","7468109","rails-bot","r? @eileencodes
(@rails-bot has picked a reviewer for you, use r? to override)","1","2015-11-07T10:00:11Z"
"247426","19780","154910480","5356517","yui-knk","@sgrif Thanks I agree we do not need to care about `mb_chars`! I will remove it.
`mb_chars` appeared by [this commit](https://github.com/rails/rails/commit/1585a7ed0228c2d4688e986c24fc221a4a9e5104) and never be removed to today :cry: .
BTW I think we can remove `mb_chars` from other tests in sanitize_test.rb (ex: test_sanitize_sql_array_handles_string_interpolation), I will send another PR!","1","2015-11-09T03:36:46Z"
"247427","19780","154910952","1529387","sgrif","Thanks. Can we have the test case also test using more than one variable, and using a variable with the same name more than once?","1","2015-11-09T03:42:49Z"
"247428","19780","154913516","5356517","yui-knk","Do you mean?
> test using more than one variable
```ruby
Binary.send(:sanitize_sql_array, [""name=:name AND group_id=:group_id"", name: ""Bambi"", group_id: 1])
```
> using a variable with the same name more than once
```ruby
Binary.send(:sanitize_sql_array, [""name=:name"", name: ""Bambi"", name: ""Bambi\nand\nThumper""])
```
If so, I want to change `Binary` to `Author`, because `Author` has `name` and `organization_id` (in this test real SQL is not generated but I do not like to pass invalid sql to `sanitize_sql_array`)
```ruby
create_table :authors, force: true do |t|
t.string :name, null: false
t.integer :author_address_id
t.integer :author_address_extra_id
t.string :organization_id
t.string :owned_essay_id
end
```","1","2015-11-09T04:05:51Z"
"247429","19780","154919811","5356517","yui-knk","ref #22229","1","2015-11-09T04:44:22Z"
"247430","19780","155051563","1080678","eileencodes","r? @sgrif ","1","2015-11-09T12:31:31Z"
"247431","19780","155051578","5356517","yui-knk","@sgrif Updated!","1","2015-11-09T12:31:37Z"
"247432","19782","154690683","7468109","rails-bot","Thanks for the pull request, and welcome! The Rails team is excited to review your changes, and you should hear from @eileencodes (or someone else) soon.
If any changes to this PR are deemed necessary, please add them as extra commits. This ensures that the reviewer can see what has changed since they last reviewed the code. Due to the way GitHub handles out-of-date commits, this should also make it reasonably obvious what issues have or haven't been addressed. Large or tricky changes may require several passes of review and changes.
Please see [the contribution instructions](http://edgeguides.rubyonrails.org/contributing_to_ruby_on_rails.html) for more information.
","1","2015-11-07T10:41:45Z"
"247433","19782","154690741","350807","kaspth","Thanks! In future *documentation* changes add `[ci skip]` to the start of your commit message, that way our CI won't run needlessly :smile:","1","2015-11-07T10:43:24Z"
"247434","19782","154690819","13537588","atul-shimpi","ok.","1","2015-11-07T10:45:38Z"
"247435","19783","154695657","7468109","rails-bot","Thanks for the pull request, and welcome! The Rails team is excited to review your changes, and you should hear from @rafaelfranca (or someone else) soon.
If any changes to this PR are deemed necessary, please add them as extra commits. This ensures that the reviewer can see what has changed since they last reviewed the code. Due to the way GitHub handles out-of-date commits, this should also make it reasonably obvious what issues have or haven't been addressed. Large or tricky changes may require several passes of review and changes.
Please see [the contribution instructions](http://edgeguides.rubyonrails.org/contributing_to_ruby_on_rails.html) for more information.
","1","2015-11-07T12:16:40Z"
"247436","19784","154704961","7468109","rails-bot","r? @schneems
(@rails-bot has picked a reviewer for you, use r? to override)","1","2015-11-07T13:35:15Z"
"247437","19784","154709634","59744","schneems","Thanks!","1","2015-11-07T14:20:59Z"
"247438","19784","154757058","987638","y-yagi","Thanks!","1","2015-11-07T22:01:15Z"
"247439","19785","154733516","7468109","rails-bot","r? @arthurnn
(@rails-bot has picked a reviewer for you, use r? to override)","1","2015-11-07T18:18:23Z"
"247440","19785","154733764","12642","kamipo","[type_to_sql](https://github.com/kamipo/rails/blob/not_passing_native_database_types_to_table_definition/activerecord/lib/active_record/connection_adapters/abstract/schema_statements.rb#L998-L1029):
```ruby
def type_to_sql(type, limit = nil, precision = nil, scale = nil) #:nodoc:
if native = native_database_types[type.to_sym]
column_type_sql = (native.is_a?(Hash) ? native[:name] : native).dup
if type == :decimal # ignore limit, use precision and scale
scale ||= native[:scale]
if precision ||= native[:precision]
if scale
column_type_sql << ""(#{precision},#{scale})""
else
column_type_sql << ""(#{precision})""
end
elsif scale
raise ArgumentError, ""Error adding decimal column: precision cannot be empty if scale is specified""
end
elsif [:datetime, :time].include?(type) && precision ||= native[:precision]
if (0..6) === precision
column_type_sql << ""(#{precision})""
else
raise(ActiveRecordError, ""No #{native[:name]} type has precision of #{precision}. The allowed range of precision is from 0 to 6"")
end
elsif (type != :primary_key) && (limit ||= native.is_a?(Hash) && native[:limit])
column_type_sql << ""(#{limit})""
end
column_type_sql
else
type.to_s
end
end
```","1","2015-11-07T18:21:13Z"
"247441","19785","159145327","12642","kamipo","r? @senny","1","2015-11-24T04:14:24Z"
"247442","19786","155273304","11367","grosser","@kaspth another one ... this did not get assigned to anyone ...","1","2015-11-10T03:25:45Z"
"247443","19786","155276467","199","jeremy","API changes break any non-core cache store subclasses that override or call these methods.","1","2015-11-10T03:54:38Z"
"247444","19786","155277710","11367","grosser","so leave the method as namespaced_key so nobody that calls super gets hurt ?","1","2015-11-10T04:02:56Z"
"247445","19786","155287150","199","jeremy","And the callers of any of the methods that now require a namespaced/normalized key argument.","1","2015-11-10T04:50:08Z"
"247446","19786","155291334","11367","grosser","Only private methods were changes, so this would only affect
users that do Rails.cache.send(:read_entry) ...
On Mon, Nov 9, 2015 at 8:51 PM, Jeremy Daer <notifications@github.com>
wrote:
> And the callers of any of the methods that now require a
> namespaced/normalized key argument.
>
> —
> Reply to this email directly or view it on GitHub
> <https://github.com/rails/rails/pull/22215#issuecomment-155287150>.
>
","1","2015-11-10T05:01:14Z"
"247447","19786","155300591","199","jeremy","The consumers of these API are other cache store subclasses. They call or super() to these boilerplate methods.","1","2015-11-10T05:44:17Z"
"247448","19786","155340905","11367","grosser","so they would still work fine when renamed to normalize_parameters, right ?","1","2015-11-10T07:19:49Z"
"247449","19786","155492180","11367","grosser","I added an alias for the old method, so there should be no fallout ... good to go ?","1","2015-11-10T17:14:27Z"
"247450","19786","155669073","11367","grosser","rebased
@jeremy looking good ?","1","2015-11-11T05:14:31Z"
"247451","19786","156253453","11367","grosser","@rafaelfranca got 2 cents on that ?","1","2015-11-12T22:17:26Z"
"247452","19786","157105967","11367","grosser","@jeremy / @kaspth / @rafaelfranca ok to merge this ?","1","2015-11-16T17:20:54Z"
"247453","19786","157156152","47848","rafaelfranca","The API is being maintained by the alias so I think it is good. Thanks","1","2015-11-16T20:12:17Z"
"247454","19786","157843050","350807","kaspth","Missed the conversation going on in https://github.com/rails/rails/pull/22205#issuecomment-157834280. Backing off :metal: ","1","2015-11-18T19:53:01Z"
"247455","19787","154748381","7468109","rails-bot","Thanks for the pull request, and welcome! The Rails team is excited to review your changes, and you should hear from @arthurnn (or someone else) soon.
If any changes to this PR are deemed necessary, please add them as extra commits. This ensures that the reviewer can see what has changed since they last reviewed the code. Due to the way GitHub handles out-of-date commits, this should also make it reasonably obvious what issues have or haven't been addressed. Large or tricky changes may require several passes of review and changes.
Please see [the contribution instructions](http://edgeguides.rubyonrails.org/contributing_to_ruby_on_rails.html) for more information.
","1","2015-11-07T20:35:38Z"
"247456","19787","155273035","11367","grosser","@kaspth can you take a look at this PR too ? :)","1","2015-11-10T03:23:05Z"
"247457","19787","155492772","11367","grosser","good to go ?","1","2015-11-10T17:15:17Z"
"247458","19787","155496688","11367","grosser","a wild @rafaelfranca appears :D
thx!","1","2015-11-10T17:22:03Z"
"247459","19787","155515043","47848","rafaelfranca",":smile: weekend was crazy with Rails rumble, but I'm back","1","2015-11-10T18:01:30Z"
"247460","19787","155515600","11367","grosser","that's what I imagined you do on weekends ;)","1","2015-11-10T18:03:49Z"
"247461","19788","154753146","7468109","rails-bot","Thanks for the pull request, and welcome! The Rails team is excited to review your changes, and you should hear from @matthewd (or someone else) soon.
If any changes to this PR are deemed necessary, please add them as extra commits. This ensures that the reviewer can see what has changed since they last reviewed the code. Due to the way GitHub handles out-of-date commits, this should also make it reasonably obvious what issues have or haven't been addressed. Large or tricky changes may require several passes of review and changes.
Please see [the contribution instructions](http://edgeguides.rubyonrails.org/contributing_to_ruby_on_rails.html) for more information.
","1","2015-11-07T21:27:58Z"
"247462","19788","154891645","52642","spastorino","But then on each execution of the block you will be calling reflection.name","1","2015-11-09T00:37:43Z"
"247463","19788","154995195","5087644","EhsanYousefi","I don't get it, How ruby understands that should not call `name` on `self` inside block? Also block will be execute later, So `name` variable how can be call later? I mean in runtime `name` variable is out of scope.","1","2015-11-09T08:24:55Z"
"247464","19788","156335676","42360","timbreitkreutz","It's a closure -- here's a starting point: https://ahsansblog.herokuapp.com/closures-in-ruby-blocks-procs-and-lambdas/ :)","1","2015-11-13T06:10:58Z"
"247465","19789","154753162","7468109","rails-bot","Thanks for the pull request, and welcome! The Rails team is excited to review your changes, and you should hear from @schneems (or someone else) soon.
If any changes to this PR are deemed necessary, please add them as extra commits. This ensures that the reviewer can see what has changed since they last reviewed the code. Due to the way GitHub handles out-of-date commits, this should also make it reasonably obvious what issues have or haven't been addressed. Large or tricky changes may require several passes of review and changes.
Please see [the contribution instructions](http://edgeguides.rubyonrails.org/contributing_to_ruby_on_rails.html) for more information.
","1","2015-11-07T21:28:21Z"
"247466","19789","154754004","59744","schneems","Thanks for the commit!
Not sure here. Looks like the original code was written that way to not go past 80 lines. It's not a coding style we enforce, but some people do. We generally don't take refactoring commits since the havoc it plays with git blame is way worse than dealing with slightly messy code. Here we're introducing a new reference which is a small speed decrease. Given the combination, and low impact. I'm in favor of merging. I'll bring it in once the tests pass.
","1","2015-11-07T21:44:16Z"
"247467","19789","154754106","59744","schneems","thanks :rocket: ","1","2015-11-07T21:46:10Z"
"247468","19789","154789293","5087644","EhsanYousefi","Welcome. I trying to learn how active record works, I found some coding style issues that effects on performance. I'll fix those too. ","1","2015-11-08T08:29:54Z"
"247469","19790","154762064","7468109","rails-bot","Thanks for the pull request, and welcome! The Rails team is excited to review your changes, and you should hear from @chancancode (or someone else) soon.
If any changes to this PR are deemed necessary, please add them as extra commits. This ensures that the reviewer can see what has changed since they last reviewed the code. Due to the way GitHub handles out-of-date commits, this should also make it reasonably obvious what issues have or haven't been addressed. Large or tricky changes may require several passes of review and changes.
Please see [the contribution instructions](http://edgeguides.rubyonrails.org/contributing_to_ruby_on_rails.html) for more information.
","1","2015-11-07T23:12:10Z"
"247470","19790","154768002","59744","schneems","Core extensions are on lockdown. The only way to get something added is to have an overwhelmingly compelling reason for how much better it would be if applied to the existing codebase ","1","2015-11-08T00:45:26Z"
"247471","19804","155213525","350807","kaspth","Thanks and what @gsamokovarov said ?","1","2015-11-09T22:04:24Z"
"247472","19805","155211409","7468109","rails-bot","r? @eileencodes
(@rails-bot has picked a reviewer for you, use r? to override)","1","2015-11-09T21:56:58Z"
"247473","19805","155220180","12642","kamipo","Sorry it seems that current definition is correct...","1","2015-11-09T22:33:15Z"
"247474","19805","155413196","1080678","eileencodes","Hi @kamipo thanks for the PR! Yea, some of the relationships don't make sense until you ""fix"" them and then a bunch of stuff breaks :smile:
This particular `:foreign_key` case is needed to test setting foreign keys and their behavior.","1","2015-11-10T12:57:36Z"
"247475","19806","155264803","7468109","rails-bot","Thanks for the pull request, and welcome! The Rails team is excited to review your changes, and you should hear from @schneems (or someone else) soon.
If any changes to this PR are deemed necessary, please add them as extra commits. This ensures that the reviewer can see what has changed since they last reviewed the code. Due to the way GitHub handles out-of-date commits, this should also make it reasonably obvious what issues have or haven't been addressed. Large or tricky changes may require several passes of review and changes.
Please see [the contribution instructions](http://edgeguides.rubyonrails.org/contributing_to_ruby_on_rails.html) for more information.
","1","2015-11-10T02:36:20Z"
"247476","19806","155271921","42360","timbreitkreutz","I think I need to work a bit more on this, sorry! I noticed that only the case without a primary key is fixed... back soon!","1","2015-11-10T03:19:41Z"
"247477","19808","155274689","7468109","rails-bot","Thanks for the pull request, and welcome! The Rails team is excited to review your changes, and you should hear from @matthewd (or someone else) soon.
If any changes to this PR are deemed necessary, please add them as extra commits. This ensures that the reviewer can see what has changed since they last reviewed the code. Due to the way GitHub handles out-of-date commits, this should also make it reasonably obvious what issues have or haven't been addressed. Large or tricky changes may require several passes of review and changes.
Please see [the contribution instructions](http://edgeguides.rubyonrails.org/contributing_to_ruby_on_rails.html) for more information.
","1","2015-11-10T03:40:22Z"
"247478","19808","162247649","833383","arthurnn","thanks for the PR @resource11 . I like the text change, and indeed think we should change the link. Our official docs are on http://api.rubyonrails.org/ . The AR::Base class docs are in http://api.rubyonrails.org/classes/ActiveRecord/Base.html , However as far as I can tell, there is no list of methods there. So I am not sure where else we can find that list.
@rafaelfranca thoughts?","1","2015-12-05T21:10:27Z"
"247479","19809","155316069","7468109","rails-bot","r? @senny
(@rails-bot has picked a reviewer for you, use r? to override)","1","2015-11-10T06:27:30Z"
"247480","19809","155404369","5356517","yui-knk","I think it is better to add test cases for `columns_for_distinct ` like [postgresql](https://github.com/rails/rails/blob/master/activerecord/test/cases/adapters/postgresql/postgresql_adapter_test.rb).","1","2015-11-10T12:10:55Z"
"247481","19809","155807389","12642","kamipo","Added test cases for `columns_for_distinct`, thanks!","1","2015-11-11T15:08:54Z"
"247482","19809","164414490","116996","joker1007",":+1: ","1","2015-12-14T11:26:41Z"
"247483","19809","166290867","12642","kamipo","The default SQL mode in MySQL 5.7 includes these modes: `ONLY_FULL_GROUP_BY`, `STRICT_TRANS_TABLES`, `NO_ZERO_IN_DATE`, `NO_ZERO_DATE`, `ERROR_FOR_DIVISION_BY_ZERO`, `NO_AUTO_CREATE_USER`, and `NO_ENGINE_SUBSTITUTION`.
http://dev.mysql.com/doc/refman/5.7/en/sql-mode.html#sql-mode-setting
And in MySQL 5.7.5 and up, `ONLY_FULL_GROUP_BY` affects handling of queries that use `DISTINCT` and `ORDER BY`. It requires the `ORDER BY` columns in the select list for distinct queries, and requires that the `ORDER BY` include the distinct column.
https://dev.mysql.com/doc/refman/5.7/en/group-by-handling.html
This means that Rails doesn't work on MySQL 5.7 with default sql_mode. We need to fix this issue and should backport to 4-2-stable.
`test/config.example.yml`:
```diff
diff --git a/activerecord/test/config.example.yml b/activerecord/test/config.example.yml
index 58e2d45..8168b29 100644
--- a/activerecord/test/config.example.yml
+++ b/activerecord/test/config.example.yml
@@ -53,6 +53,7 @@ connections:
mysql2:
arunit:
+ strict: :default
username: rails
encoding: utf8
collation: utf8_unicode_ci
```
Result:
```
% rake test_mysql2 --verbose
/Users/kamipo/.rbenv/versions/2.2.3/bin/ruby -w -I""lib:test"" -I""/Users/kamipo/.rbenv/versions/2.2.3/lib/ruby/2.2.0"" ""/Users/kamipo/.rbenv/versions/2.2.3/lib/ruby/2.2.0/rake/rake_test_loader.rb"" ""test/cases/adapter_test.rb"" ""test/cases/aggregations_test.rb"" ""test/cases/ar_schema_test.rb"" ""test/cases/associations/association_scope_test.rb"" ""test/cases/associations/belongs_to_associations_test.rb"" ""test/cases/associations/bidirectional_destroy_dependencies_test.rb"" ""test/cases/associations/callbacks_test.rb"" ""test/cases/associations/cascaded_eager_loading_test.rb"" ""test/cases/associations/eager_load_includes_full_sti_class_test.rb"" ""test/cases/associations/eager_load_nested_include_test.rb"" ""test/cases/associations/eager_singularization_test.rb"" ""test/cases/associations/eager_test.rb"" ""test/cases/associations/extension_test.rb"" ""test/cases/associations/has_and_belongs_to_many_associations_test.rb"" ""test/cases/associations/has_many_associations_test.rb"" ""test/cases/associations/has_many_through_associations_test.rb"" ""test/cases/associations/has_one_associations_test.rb"" ""test/cases/associations/has_one_through_associations_test.rb"" ""test/cases/associations/inner_join_association_test.rb"" ""test/cases/associations/inverse_associations_test.rb"" ""test/cases/associations/join_model_test.rb"" ""test/cases/associations/left_outer_join_association_test.rb"" ""test/cases/associations/nested_through_associations_test.rb"" ""test/cases/associations/required_test.rb"" ""test/cases/associations_test.rb"" ""test/cases/attribute_decorators_test.rb"" ""test/cases/attribute_methods/read_test.rb"" ""test/cases/attribute_methods_test.rb"" ""test/cases/attribute_set_test.rb"" ""test/cases/attribute_test.rb"" ""test/cases/attributes_test.rb"" ""test/cases/autosave_association_test.rb"" ""test/cases/base_test.rb"" ""test/cases/batches_test.rb"" ""test/cases/binary_test.rb"" ""test/cases/bind_parameter_test.rb"" ""test/cases/cache_key_test.rb"" ""test/cases/calculations_test.rb"" ""test/cases/callbacks_test.rb"" ""test/cases/clone_test.rb"" ""test/cases/coders/yaml_column_test.rb"" ""test/cases/collection_cache_key_test.rb"" ""test/cases/column_alias_test.rb"" ""test/cases/column_definition_test.rb"" ""test/cases/connection_adapters/adapter_leasing_test.rb"" ""test/cases/connection_adapters/connection_handler_test.rb"" ""test/cases/connection_adapters/connection_specification_test.rb"" ""test/cases/connection_adapters/merge_and_resolve_default_url_config_test.rb"" ""test/cases/connection_adapters/mysql_type_lookup_test.rb"" ""test/cases/connection_adapters/quoting_test.rb"" ""test/cases/connection_adapters/schema_cache_test.rb"" ""test/cases/connection_adapters/type_lookup_test.rb"" ""test/cases/connection_management_test.rb"" ""test/cases/connection_pool_test.rb"" ""test/cases/connection_specification/resolver_test.rb"" ""test/cases/core_test.rb"" ""test/cases/counter_cache_test.rb"" ""test/cases/custom_locking_test.rb"" ""test/cases/database_statements_test.rb"" ""test/cases/date_time_precision_test.rb"" ""test/cases/date_time_test.rb"" ""test/cases/defaults_test.rb"" ""test/cases/dirty_test.rb"" ""test/cases/disconnected_test.rb"" ""test/cases/dup_test.rb"" ""test/cases/enum_test.rb"" ""test/cases/errors_test.rb"" ""test/cases/explain_subscriber_test.rb"" ""test/cases/explain_test.rb"" ""test/cases/finder_respond_to_test.rb"" ""test/cases/finder_test.rb"" ""test/cases/fixture_set/file_test.rb"" ""test/cases/fixtures_test.rb"" ""test/cases/forbidden_attributes_protection_test.rb"" ""test/cases/habtm_destroy_order_test.rb"" ""test/cases/hot_compatibility_test.rb"" ""test/cases/i18n_test.rb"" ""test/cases/inheritance_test.rb"" ""test/cases/integration_test.rb"" ""test/cases/invalid_connection_test.rb"" ""test/cases/invalid_date_test.rb"" ""test/cases/invertible_migration_test.rb"" ""test/cases/json_serialization_test.rb"" ""test/cases/locking_test.rb"" ""test/cases/log_subscriber_test.rb"" ""test/cases/migration/change_schema_test.rb"" ""test/cases/migration/change_table_test.rb"" ""test/cases/migration/column_attributes_test.rb"" ""test/cases/migration/column_positioning_test.rb"" ""test/cases/migration/columns_test.rb"" ""test/cases/migration/command_recorder_test.rb"" ""test/cases/migration/create_join_table_test.rb"" ""test/cases/migration/foreign_key_test.rb"" ""test/cases/migration/index_test.rb"" ""test/cases/migration/logger_test.rb"" ""test/cases/migration/pending_migrations_test.rb"" ""test/cases/migration/references_foreign_key_test.rb"" ""test/cases/migration/references_index_test.rb"" ""test/cases/migration/references_statements_test.rb"" ""test/cases/migration/rename_table_test.rb"" ""test/cases/migration/table_and_index_test.rb"" ""test/cases/migration_test.rb"" ""test/cases/migrator_test.rb"" ""test/cases/mixin_test.rb"" ""test/cases/modules_test.rb"" ""test/cases/multiparameter_attributes_test.rb"" ""test/cases/multiple_db_test.rb"" ""test/cases/nested_attributes_test.rb"" ""test/cases/nested_attributes_with_callbacks_test.rb"" ""test/cases/persistence_test.rb"" ""test/cases/pooled_connections_test.rb"" ""test/cases/primary_keys_test.rb"" ""test/cases/query_cache_test.rb"" ""test/cases/quoting_test.rb"" ""test/cases/readonly_test.rb"" ""test/cases/reaper_test.rb"" ""test/cases/reflection_test.rb"" ""test/cases/relation/delegation_test.rb"" ""test/cases/relation/merging_test.rb"" ""test/cases/relation/mutation_test.rb"" ""test/cases/relation/or_test.rb"" ""test/cases/relation/predicate_builder_test.rb"" ""test/cases/relation/record_fetch_warning_test.rb"" ""test/cases/relation/where_chain_test.rb"" ""test/cases/relation/where_clause_test.rb"" ""test/cases/relation/where_test.rb"" ""test/cases/relation_test.rb"" ""test/cases/relations_test.rb"" ""test/cases/reload_models_test.rb"" ""test/cases/result_test.rb"" ""test/cases/sanitize_test.rb"" ""test/cases/schema_dumper_test.rb"" ""test/cases/scoping/default_scoping_test.rb"" ""test/cases/scoping/named_scoping_test.rb"" ""test/cases/scoping/relation_scoping_test.rb"" ""test/cases/secure_token_test.rb"" ""test/cases/serialization_test.rb"" ""test/cases/serialized_attribute_test.rb"" ""test/cases/statement_cache_test.rb"" ""test/cases/store_test.rb"" ""test/cases/suppressor_test.rb"" ""test/cases/tasks/database_tasks_test.rb"" ""test/cases/tasks/mysql_rake_test.rb"" ""test/cases/tasks/postgresql_rake_test.rb"" ""test/cases/tasks/sqlite_rake_test.rb"" ""test/cases/test_fixtures_test.rb"" ""test/cases/time_precision_test.rb"" ""test/cases/timestamp_test.rb"" ""test/cases/touch_later_test.rb"" ""test/cases/transaction_callbacks_test.rb"" ""test/cases/transaction_isolation_test.rb"" ""test/cases/transactions_test.rb"" ""test/cases/type/adapter_specific_registry_test.rb"" ""test/cases/type/date_time_test.rb"" ""test/cases/type/integer_test.rb"" ""test/cases/type/string_test.rb"" ""test/cases/type/type_map_test.rb"" ""test/cases/type_test.rb"" ""test/cases/types_test.rb"" ""test/cases/unconnected_test.rb"" ""test/cases/validations/absence_validation_test.rb"" ""test/cases/validations/association_validation_test.rb"" ""test/cases/validations/i18n_generate_message_validation_test.rb"" ""test/cases/validations/i18n_validation_test.rb"" ""test/cases/validations/length_validation_test.rb"" ""test/cases/validations/presence_validation_test.rb"" ""test/cases/validations/uniqueness_validation_test.rb"" ""test/cases/validations_test.rb"" ""test/cases/view_test.rb"" ""test/cases/yaml_serialization_test.rb"" ""test/cases/adapters/mysql2/active_schema_test.rb"" ""test/cases/adapters/mysql2/bind_parameter_test.rb"" ""test/cases/adapters/mysql2/boolean_test.rb"" ""test/cases/adapters/mysql2/case_sensitivity_test.rb"" ""test/cases/adapters/mysql2/charset_collation_test.rb"" ""test/cases/adapters/mysql2/connection_test.rb"" ""test/cases/adapters/mysql2/enum_test.rb"" ""test/cases/adapters/mysql2/explain_test.rb"" ""test/cases/adapters/mysql2/json_test.rb"" ""test/cases/adapters/mysql2/quoting_test.rb"" ""test/cases/adapters/mysql2/reserved_word_test.rb"" ""test/cases/adapters/mysql2/schema_migrations_test.rb"" ""test/cases/adapters/mysql2/schema_test.rb"" ""test/cases/adapters/mysql2/sp_test.rb"" ""test/cases/adapters/mysql2/sql_types_test.rb"" ""test/cases/adapters/mysql2/table_options_test.rb"" ""test/cases/adapters/mysql2/unsigned_type_test.rb""
Using mysql2
Run options: --seed 1014
# Running:
....................................................................................................................................................................................E...............................................E........E.................................E..............E.............E..............................................E..............E..........................................................................................E...................E................................................................................................................................................................................................................................................................................E..................................................................................................................................................................................................................................................................E..............................E..............................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................S..............................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................E...............................................................................E................................................................................................................................................................................................................................................................................................................................................S.....................................S..........................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................S.............................................................................................................................................................................................................E..........................................E............E...............................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................F................................................................
Finished in 132.519118s, 35.6401 runs/s, 99.2008 assertions/s.
1) Error:
CascadedEagerLoadingTest#test_eager_association_loading_with_multiple_stis_and_order:
ActiveRecord::StatementInvalid: Mysql2::Error: Expression #1 of ORDER BY clause is not in SELECT list, references column 'activerecord_unittest.authors.name' which is not in SELECT list; this is incompatible with DISTINCT: SELECT DISTINCT `authors`.`id` FROM `authors` LEFT OUTER JOIN `posts` ON `posts`.`author_id` = `authors`.`id` LEFT OUTER JOIN `comments` ON `comments`.`post_id` = `posts`.`id` AND `comments`.`type` IN ('SpecialComment', 'SubSpecialComment') LEFT OUTER JOIN `comments` `very_special_comments_posts` ON `very_special_comments_posts`.`post_id` = `posts`.`id` AND `very_special_comments_posts`.`type` IN ('VerySpecialComment') WHERE (posts.id = 4) ORDER BY authors.name, comments.body, very_special_comments_posts.body LIMIT 1
/Users/kamipo/src/github.com/rails/rails/vendor/bundle/ruby/2.2.0/gems/mysql2-0.4.2/lib/mysql2/client.rb:107:in `_query'
/Users/kamipo/src/github.com/rails/rails/vendor/bundle/ruby/2.2.0/gems/mysql2-0.4.2/lib/mysql2/client.rb:107:in `block in query'
/Users/kamipo/src/github.com/rails/rails/vendor/bundle/ruby/2.2.0/gems/mysql2-0.4.2/lib/mysql2/client.rb:106:in `handle_interrupt'
/Users/kamipo/src/github.com/rails/rails/vendor/bundle/ruby/2.2.0/gems/mysql2-0.4.2/lib/mysql2/client.rb:106:in `query'
/Users/kamipo/src/github.com/rails/rails/activerecord/lib/active_record/connection_adapters/abstract_mysql_adapter.rb:400:in `block in execute'
/Users/kamipo/src/github.com/rails/rails/activerecord/lib/active_record/connection_adapters/abstract_adapter.rb:535:in `block in log'
/Users/kamipo/src/github.com/rails/rails/activesupport/lib/active_support/notifications/instrumenter.rb:21:in `instrument'
/Users/kamipo/src/github.com/rails/rails/activerecord/lib/active_record/connection_adapters/abstract_adapter.rb:529:in `log'
/Users/kamipo/src/github.com/rails/rails/activerecord/lib/active_record/connection_adapters/abstract_mysql_adapter.rb:400:in `execute'
/Users/kamipo/src/github.com/rails/rails/activerecord/lib/active_record/connection_adapters/mysql2_adapter.rb:141:in `execute'
/Users/kamipo/src/github.com/rails/rails/activerecord/lib/active_record/connection_adapters/mysql2_adapter.rb:145:in `exec_query'
/Users/kamipo/src/github.com/rails/rails/activerecord/lib/active_record/connection_adapters/abstract/database_statements.rb:371:in `select'
/Users/kamipo/src/github.com/rails/rails/activerecord/lib/active_record/connection_adapters/abstract/database_statements.rb:41:in `select_all'
/Users/kamipo/src/github.com/rails/rails/activerecord/lib/active_record/connection_adapters/abstract/query_cache.rb:70:in `select_all'
/Users/kamipo/src/github.com/rails/rails/activerecord/lib/active_record/relation/finder_methods.rb:396:in `limited_ids_for'
/Users/kamipo/src/github.com/rails/rails/activerecord/lib/active_record/relation/finder_methods.rb:382:in `apply_join_dependency'
/Users/kamipo/src/github.com/rails/rails/activerecord/lib/active_record/relation/finder_methods.rb:342:in `find_with_associations'
/Users/kamipo/src/github.com/rails/rails/activerecord/lib/active_record/relation.rb:691:in `exec_queries'
/Users/kamipo/src/github.com/rails/rails/activerecord/lib/active_record/relation.rb:572:in `load'
/Users/kamipo/src/github.com/rails/rails/activerecord/lib/active_record/relation.rb:252:in `to_a'
/Users/kamipo/src/github.com/rails/rails/activerecord/lib/active_record/relation/finder_methods.rb:495:in `find_nth_with_limit'
/Users/kamipo/src/github.com/rails/rails/activerecord/lib/active_record/relation/finder_methods.rb:479:in `find_nth'
/Users/kamipo/src/github.com/rails/rails/activerecord/lib/active_record/relation/finder_methods.rb:122:in `first'
/Users/kamipo/src/github.com/rails/rails/activerecord/test/cases/associations/cascaded_eager_loading_test.rb:143:in `test_eager_association_loading_with_multiple_stis_and_order'
2) Error:
EagerAssociationTest#test_limited_eager_with_multiple_order_columns:
ActiveRecord::StatementInvalid: Mysql2::Error: Expression #1 of ORDER BY clause is not in SELECT list, references column 'activerecord_unittest.posts.title' which is not in SELECT list; this is incompatible with DISTINCT: SELECT DISTINCT `posts`.`id` FROM `posts` LEFT OUTER JOIN `authors` ON `authors`.`id` = `posts`.`author_id` LEFT OUTER JOIN `comments` ON `comments`.`post_id` = `posts`.`id` WHERE `authors`.`name` = 'David' ORDER BY UPPER(posts.title), posts.id LIMIT 2 OFFSET 1
/Users/kamipo/src/github.com/rails/rails/vendor/bundle/ruby/2.2.0/gems/mysql2-0.4.2/lib/mysql2/client.rb:107:in `_query'
/Users/kamipo/src/github.com/rails/rails/vendor/bundle/ruby/2.2.0/gems/mysql2-0.4.2/lib/mysql2/client.rb:107:in `block in query'
/Users/kamipo/src/github.com/rails/rails/vendor/bundle/ruby/2.2.0/gems/mysql2-0.4.2/lib/mysql2/client.rb:106:in `handle_interrupt'
/Users/kamipo/src/github.com/rails/rails/vendor/bundle/ruby/2.2.0/gems/mysql2-0.4.2/lib/mysql2/client.rb:106:in `query'
/Users/kamipo/src/github.com/rails/rails/activerecord/lib/active_record/connection_adapters/abstract_mysql_adapter.rb:400:in `block in execute'
/Users/kamipo/src/github.com/rails/rails/activerecord/lib/active_record/connection_adapters/abstract_adapter.rb:535:in `block in log'
/Users/kamipo/src/github.com/rails/rails/activesupport/lib/active_support/notifications/instrumenter.rb:21:in `instrument'
/Users/kamipo/src/github.com/rails/rails/activerecord/lib/active_record/connection_adapters/abstract_adapter.rb:529:in `log'
/Users/kamipo/src/github.com/rails/rails/activerecord/lib/active_record/connection_adapters/abstract_mysql_adapter.rb:400:in `execute'
/Users/kamipo/src/github.com/rails/rails/activerecord/lib/active_record/connection_adapters/mysql2_adapter.rb:141:in `execute'
/Users/kamipo/src/github.com/rails/rails/activerecord/lib/active_record/connection_adapters/mysql2_adapter.rb:145:in `exec_query'
/Users/kamipo/src/github.com/rails/rails/activerecord/lib/active_record/connection_adapters/abstract/database_statements.rb:371:in `select'
/Users/kamipo/src/github.com/rails/rails/activerecord/lib/active_record/connection_adapters/abstract/database_statements.rb:41:in `select_all'
/Users/kamipo/src/github.com/rails/rails/activerecord/lib/active_record/connection_adapters/abstract/query_cache.rb:70:in `select_all'
/Users/kamipo/src/github.com/rails/rails/activerecord/lib/active_record/relation/finder_methods.rb:396:in `limited_ids_for'
/Users/kamipo/src/github.com/rails/rails/activerecord/lib/active_record/relation/finder_methods.rb:382:in `apply_join_dependency'
/Users/kamipo/src/github.com/rails/rails/activerecord/lib/active_record/relation/finder_methods.rb:342:in `find_with_associations'
/Users/kamipo/src/github.com/rails/rails/activerecord/lib/active_record/relation.rb:691:in `exec_queries'
/Users/kamipo/src/github.com/rails/rails/activerecord/lib/active_record/relation.rb:572:in `load'
/Users/kamipo/src/github.com/rails/rails/activerecord/lib/active_record/relation.rb:252:in `to_a'
/Users/kamipo/src/github.com/rails/rails/activerecord/test/cases/associations/eager_test.rb:838:in `test_limited_eager_with_multiple_order_columns'
3) Error:
EagerAssociationTest#test_include_has_many_using_primary_key:
ActiveRecord::StatementInvalid: Mysql2::Error: Expression #1 of ORDER BY clause is not in SELECT list, references column 'activerecord_unittest.clients_using_primary_keys_companies.name' which is not in SELECT list; this is incompatible with DISTINCT: SELECT DISTINCT `companies`.`id` FROM `companies` LEFT OUTER JOIN `companies` `clients_using_primary_keys_companies` ON `clients_using_primary_keys_companies`.`firm_name` = `companies`.`name` AND `clients_using_primary_keys_companies`.`type` IN ('Client', 'SpecialClient', 'VerySpecialClient') WHERE `companies`.`type` IN ('Firm') AND `companies`.`id` = 1 ORDER BY clients_using_primary_keys_companies.name LIMIT 1
/Users/kamipo/src/github.com/rails/rails/vendor/bundle/ruby/2.2.0/gems/mysql2-0.4.2/lib/mysql2/client.rb:107:in `_query'
/Users/kamipo/src/github.com/rails/rails/vendor/bundle/ruby/2.2.0/gems/mysql2-0.4.2/lib/mysql2/client.rb:107:in `block in query'
/Users/kamipo/src/github.com/rails/rails/vendor/bundle/ruby/2.2.0/gems/mysql2-0.4.2/lib/mysql2/client.rb:106:in `handle_interrupt'
/Users/kamipo/src/github.com/rails/rails/vendor/bundle/ruby/2.2.0/gems/mysql2-0.4.2/lib/mysql2/client.rb:106:in `query'
/Users/kamipo/src/github.com/rails/rails/activerecord/lib/active_record/connection_adapters/abstract_mysql_adapter.rb:400:in `block in execute'
/Users/kamipo/src/github.com/rails/rails/activerecord/lib/active_record/connection_adapters/abstract_adapter.rb:535:in `block in log'
/Users/kamipo/src/github.com/rails/rails/activesupport/lib/active_support/notifications/instrumenter.rb:21:in `instrument'
/Users/kamipo/src/github.com/rails/rails/activerecord/lib/active_record/connection_adapters/abstract_adapter.rb:529:in `log'
/Users/kamipo/src/github.com/rails/rails/activerecord/lib/active_record/connection_adapters/abstract_mysql_adapter.rb:400:in `execute'
/Users/kamipo/src/github.com/rails/rails/activerecord/lib/active_record/connection_adapters/mysql2_adapter.rb:141:in `execute'
/Users/kamipo/src/github.com/rails/rails/activerecord/lib/active_record/connection_adapters/mysql2_adapter.rb:145:in `exec_query'
/Users/kamipo/src/github.com/rails/rails/activerecord/lib/active_record/connection_adapters/abstract/database_statements.rb:371:in `select'
/Users/kamipo/src/github.com/rails/rails/activerecord/lib/active_record/connection_adapters/abstract/database_statements.rb:41:in `select_all'
/Users/kamipo/src/github.com/rails/rails/activerecord/lib/active_record/connection_adapters/abstract/query_cache.rb:70:in `select_all'
/Users/kamipo/src/github.com/rails/rails/activerecord/lib/active_record/relation/finder_methods.rb:396:in `limited_ids_for'
/Users/kamipo/src/github.com/rails/rails/activerecord/lib/active_record/relation/finder_methods.rb:382:in `apply_join_dependency'
/Users/kamipo/src/github.com/rails/rails/activerecord/lib/active_record/relation/finder_methods.rb:342:in `find_with_associations'
/Users/kamipo/src/github.com/rails/rails/activerecord/lib/active_record/relation.rb:691:in `exec_queries'
/Users/kamipo/src/github.com/rails/rails/activerecord/lib/active_record/relation.rb:572:in `load'
/Users/kamipo/src/github.com/rails/rails/activerecord/lib/active_record/relation.rb:252:in `to_a'
/Users/kamipo/src/github.com/rails/rails/activerecord/lib/active_record/relation/finder_methods.rb:470:in `find_take'
/Users/kamipo/src/github.com/rails/rails/activerecord/lib/active_record/relation/finder_methods.rb:100:in `take'
/Users/kamipo/src/github.com/rails/rails/activerecord/lib/active_record/relation/finder_methods.rb:437:in `find_one'
/Users/kamipo/src/github.com/rails/rails/activerecord/lib/active_record/relation/finder_methods.rb:418:in `find_with_ids'
/Users/kamipo/src/github.com/rails/rails/activerecord/lib/active_record/relation/finder_methods.rb:66:in `find'
/Users/kamipo/src/github.com/rails/rails/activerecord/test/cases/associations/eager_test.rb:1132:in `test_include_has_many_using_primary_key'
4) Error:
EagerAssociationTest#test_limited_eager_with_order:
ActiveRecord::StatementInvalid: Mysql2::Error: Expression #1 of ORDER BY clause is not in SELECT list, references column 'activerecord_unittest.posts.title' which is not in SELECT list; this is incompatible with DISTINCT: SELECT DISTINCT `posts`.`id` FROM `posts` LEFT OUTER JOIN `authors` ON `authors`.`id` = `posts`.`author_id` LEFT OUTER JOIN `comments` ON `comments`.`post_id` = `posts`.`id` WHERE `authors`.`name` = 'David' ORDER BY UPPER(posts.title) LIMIT 2 OFFSET 1
/Users/kamipo/src/github.com/rails/rails/vendor/bundle/ruby/2.2.0/gems/mysql2-0.4.2/lib/mysql2/client.rb:107:in `_query'
/Users/kamipo/src/github.com/rails/rails/vendor/bundle/ruby/2.2.0/gems/mysql2-0.4.2/lib/mysql2/client.rb:107:in `block in query'
/Users/kamipo/src/github.com/rails/rails/vendor/bundle/ruby/2.2.0/gems/mysql2-0.4.2/lib/mysql2/client.rb:106:in `handle_interrupt'
/Users/kamipo/src/github.com/rails/rails/vendor/bundle/ruby/2.2.0/gems/mysql2-0.4.2/lib/mysql2/client.rb:106:in `query'
/Users/kamipo/src/github.com/rails/rails/activerecord/lib/active_record/connection_adapters/abstract_mysql_adapter.rb:400:in `block in execute'
/Users/kamipo/src/github.com/rails/rails/activerecord/lib/active_record/connection_adapters/abstract_adapter.rb:535:in `block in log'
/Users/kamipo/src/github.com/rails/rails/activesupport/lib/active_support/notifications/instrumenter.rb:21:in `instrument'
/Users/kamipo/src/github.com/rails/rails/activerecord/lib/active_record/connection_adapters/abstract_adapter.rb:529:in `log'
/Users/kamipo/src/github.com/rails/rails/activerecord/lib/active_record/connection_adapters/abstract_mysql_adapter.rb:400:in `execute'
/Users/kamipo/src/github.com/rails/rails/activerecord/lib/active_record/connection_adapters/mysql2_adapter.rb:141:in `execute'
/Users/kamipo/src/github.com/rails/rails/activerecord/lib/active_record/connection_adapters/mysql2_adapter.rb:145:in `exec_query'
/Users/kamipo/src/github.com/rails/rails/activerecord/lib/active_record/connection_adapters/abstract/database_statements.rb:371:in `select'
/Users/kamipo/src/github.com/rails/rails/activerecord/lib/active_record/connection_adapters/abstract/database_statements.rb:41:in `select_all'
/Users/kamipo/src/github.com/rails/rails/activerecord/lib/active_record/connection_adapters/abstract/query_cache.rb:70:in `select_all'
/Users/kamipo/src/github.com/rails/rails/activerecord/lib/active_record/relation/finder_methods.rb:396:in `limited_ids_for'
/Users/kamipo/src/github.com/rails/rails/activerecord/lib/active_record/relation/finder_methods.rb:382:in `apply_join_dependency'
/Users/kamipo/src/github.com/rails/rails/activerecord/lib/active_record/relation/finder_methods.rb:342:in `find_with_associations'
/Users/kamipo/src/github.com/rails/rails/activerecord/lib/active_record/relation.rb:691:in `exec_queries'
/Users/kamipo/src/github.com/rails/rails/activerecord/lib/active_record/relation.rb:572:in `load'
/Users/kamipo/src/github.com/rails/rails/activerecord/lib/active_record/relation.rb:252:in `to_a'
/Users/kamipo/src/github.com/rails/rails/activerecord/test/cases/associations/eager_test.rb:821:in `test_limited_eager_with_order'
5) Error:
EagerAssociationTest#test_works_in_combination_with_order(:symbol)_and_reorder(:symbol):
ActiveRecord::StatementInvalid: Mysql2::Error: Expression #1 of ORDER BY clause is not in SELECT list, references column 'activerecord_unittest.authors.name' which is not in SELECT list; this is incompatible with DISTINCT: SELECT DISTINCT `authors`.`id` FROM `authors` LEFT OUTER JOIN `posts` ON `posts`.`author_id` = `authors`.`id` WHERE (posts.title IS NOT NULL) ORDER BY `authors`.`name` ASC LIMIT 1
/Users/kamipo/src/github.com/rails/rails/vendor/bundle/ruby/2.2.0/gems/mysql2-0.4.2/lib/mysql2/client.rb:107:in `_query'
/Users/kamipo/src/github.com/rails/rails/vendor/bundle/ruby/2.2.0/gems/mysql2-0.4.2/lib/mysql2/client.rb:107:in `block in query'
/Users/kamipo/src/github.com/rails/rails/vendor/bundle/ruby/2.2.0/gems/mysql2-0.4.2/lib/mysql2/client.rb:106:in `handle_interrupt'
/Users/kamipo/src/github.com/rails/rails/vendor/bundle/ruby/2.2.0/gems/mysql2-0.4.2/lib/mysql2/client.rb:106:in `query'
/Users/kamipo/src/github.com/rails/rails/activerecord/lib/active_record/connection_adapters/abstract_mysql_adapter.rb:400:in `block in execute'
/Users/kamipo/src/github.com/rails/rails/activerecord/lib/active_record/connection_adapters/abstract_adapter.rb:535:in `block in log'
/Users/kamipo/src/github.com/rails/rails/activesupport/lib/active_support/notifications/instrumenter.rb:21:in `instrument'
/Users/kamipo/src/github.com/rails/rails/activerecord/lib/active_record/connection_adapters/abstract_adapter.rb:529:in `log'
/Users/kamipo/src/github.com/rails/rails/activerecord/lib/active_record/connection_adapters/abstract_mysql_adapter.rb:400:in `execute'
/Users/kamipo/src/github.com/rails/rails/activerecord/lib/active_record/connection_adapters/mysql2_adapter.rb:141:in `execute'
/Users/kamipo/src/github.com/rails/rails/activerecord/lib/active_record/connection_adapters/mysql2_adapter.rb:145:in `exec_query'
/Users/kamipo/src/github.com/rails/rails/activerecord/lib/active_record/connection_adapters/abstract/database_statements.rb:371:in `select'
/Users/kamipo/src/github.com/rails/rails/activerecord/lib/active_record/connection_adapters/abstract/database_statements.rb:41:in `select_all'
/Users/kamipo/src/github.com/rails/rails/activerecord/lib/active_record/connection_adapters/abstract/query_cache.rb:70:in `select_all'
/Users/kamipo/src/github.com/rails/rails/activerecord/lib/active_record/relation/finder_methods.rb:396:in `limited_ids_for'
/Users/kamipo/src/github.com/rails/rails/activerecord/lib/active_record/relation/finder_methods.rb:382:in `apply_join_dependency'
/Users/kamipo/src/github.com/rails/rails/activerecord/lib/active_record/relation/finder_methods.rb:342:in `find_with_associations'
/Users/kamipo/src/github.com/rails/rails/activerecord/lib/active_record/relation.rb:691:in `exec_queries'
/Users/kamipo/src/github.com/rails/rails/activerecord/lib/active_record/relation.rb:572:in `load'
/Users/kamipo/src/github.com/rails/rails/activerecord/lib/active_record/relation.rb:252:in `to_a'
/Users/kamipo/src/github.com/rails/rails/activerecord/lib/active_record/relation/finder_methods.rb:470:in `find_take'
/Users/kamipo/src/github.com/rails/rails/activerecord/lib/active_record/relation/finder_methods.rb:100:in `take'
/Users/kamipo/src/github.com/rails/rails/activerecord/lib/active_record/relation/finder_methods.rb:78:in `find_by'
/Users/kamipo/src/github.com/rails/rails/activerecord/test/cases/associations/eager_test.rb:1283:in `block in <class:EagerAssociationTest>'
6) Error:
EagerAssociationTest#test_order_on_join_table_with_include_and_limit:
ActiveRecord::StatementInvalid: Mysql2::Error: Expression #1 of ORDER BY clause is not in SELECT list, references column 'activerecord_unittest.developers_projects.joined_on' which is not in SELECT list; this is incompatible with DISTINCT: SELECT DISTINCT `developers`.`id` FROM `developers` LEFT OUTER JOIN `developers_projects` ON `developers_projects`.`developer_id` = `developers`.`id` LEFT OUTER JOIN `projects` ON `projects`.`id` = `developers_projects`.`project_id` ORDER BY developers_projects.joined_on DESC LIMIT 5
/Users/kamipo/src/github.com/rails/rails/vendor/bundle/ruby/2.2.0/gems/mysql2-0.4.2/lib/mysql2/client.rb:107:in `_query'
/Users/kamipo/src/github.com/rails/rails/vendor/bundle/ruby/2.2.0/gems/mysql2-0.4.2/lib/mysql2/client.rb:107:in `block in query'
/Users/kamipo/src/github.com/rails/rails/vendor/bundle/ruby/2.2.0/gems/mysql2-0.4.2/lib/mysql2/client.rb:106:in `handle_interrupt'
/Users/kamipo/src/github.com/rails/rails/vendor/bundle/ruby/2.2.0/gems/mysql2-0.4.2/lib/mysql2/client.rb:106:in `query'
/Users/kamipo/src/github.com/rails/rails/activerecord/lib/active_record/connection_adapters/abstract_mysql_adapter.rb:400:in `block in execute'
/Users/kamipo/src/github.com/rails/rails/activerecord/lib/active_record/connection_adapters/abstract_adapter.rb:535:in `block in log'
/Users/kamipo/src/github.com/rails/rails/activesupport/lib/active_support/notifications/instrumenter.rb:21:in `instrument'
/Users/kamipo/src/github.com/rails/rails/activerecord/lib/active_record/connection_adapters/abstract_adapter.rb:529:in `log'
/Users/kamipo/src/github.com/rails/rails/activerecord/lib/active_record/connection_adapters/abstract_mysql_adapter.rb:400:in `execute'
/Users/kamipo/src/github.com/rails/rails/activerecord/lib/active_record/connection_adapters/mysql2_adapter.rb:141:in `execute'
/Users/kamipo/src/github.com/rails/rails/activerecord/lib/active_record/connection_adapters/mysql2_adapter.rb:145:in `exec_query'
/Users/kamipo/src/github.com/rails/rails/activerecord/lib/active_record/connection_adapters/abstract/database_statements.rb:371:in `select'
/Users/kamipo/src/github.com/rails/rails/activerecord/lib/active_record/connection_adapters/abstract/database_statements.rb:41:in `select_all'
/Users/kamipo/src/github.com/rails/rails/activerecord/lib/active_record/connection_adapters/abstract/query_cache.rb:70:in `select_all'
/Users/kamipo/src/github.com/rails/rails/activerecord/lib/active_record/relation/finder_methods.rb:396:in `limited_ids_for'
/Users/kamipo/src/github.com/rails/rails/activerecord/lib/active_record/relation/finder_methods.rb:382:in `apply_join_dependency'
/Users/kamipo/src/github.com/rails/rails/activerecord/lib/active_record/relation/finder_methods.rb:342:in `find_with_associations'
/Users/kamipo/src/github.com/rails/rails/activerecord/lib/active_record/relation.rb:691:in `exec_queries'
/Users/kamipo/src/github.com/rails/rails/activerecord/lib/active_record/relation.rb:572:in `load'
/Users/kamipo/src/github.com/rails/rails/activerecord/lib/active_record/relation.rb:252:in `to_a'
/Users/kamipo/src/github.com/rails/rails/activerecord/test/cases/associations/eager_test.rb:1025:in `test_order_on_join_table_with_include_and_limit'
7) Error:
EagerAssociationTest#test_nested_loading_through_has_one_association_with_order_on_nested_association:
ActiveRecord::StatementInvalid: Mysql2::Error: Expression #1 of ORDER BY clause is not in SELECT list, references column 'activerecord_unittest.posts.id' which is not in SELECT list; this is incompatible with DISTINCT: SELECT DISTINCT `author_addresses`.`id` FROM `author_addresses` LEFT OUTER JOIN `authors` ON `authors`.`author_address_id` = `author_addresses`.`id` LEFT OUTER JOIN `posts` ON `posts`.`author_id` = `authors`.`id` WHERE `author_addresses`.`id` = 1 ORDER BY posts.id LIMIT 1
/Users/kamipo/src/github.com/rails/rails/vendor/bundle/ruby/2.2.0/gems/mysql2-0.4.2/lib/mysql2/client.rb:107:in `_query'
/Users/kamipo/src/github.com/rails/rails/vendor/bundle/ruby/2.2.0/gems/mysql2-0.4.2/lib/mysql2/client.rb:107:in `block in query'
/Users/kamipo/src/github.com/rails/rails/vendor/bundle/ruby/2.2.0/gems/mysql2-0.4.2/lib/mysql2/client.rb:106:in `handle_interrupt'
/Users/kamipo/src/github.com/rails/rails/vendor/bundle/ruby/2.2.0/gems/mysql2-0.4.2/lib/mysql2/client.rb:106:in `query'
/Users/kamipo/src/github.com/rails/rails/activerecord/lib/active_record/connection_adapters/abstract_mysql_adapter.rb:400:in `block in execute'
/Users/kamipo/src/github.com/rails/rails/activerecord/lib/active_record/connection_adapters/abstract_adapter.rb:535:in `block in log'
/Users/kamipo/src/github.com/rails/rails/activesupport/lib/active_support/notifications/instrumenter.rb:21:in `instrument'
/Users/kamipo/src/github.com/rails/rails/activerecord/lib/active_record/connection_adapters/abstract_adapter.rb:529:in `log'
/Users/kamipo/src/github.com/rails/rails/activerecord/lib/active_record/connection_adapters/abstract_mysql_adapter.rb:400:in `execute'
/Users/kamipo/src/github.com/rails/rails/activerecord/lib/active_record/connection_adapters/mysql2_adapter.rb:141:in `execute'
/Users/kamipo/src/github.com/rails/rails/activerecord/lib/active_record/connection_adapters/mysql2_adapter.rb:145:in `exec_query'
/Users/kamipo/src/github.com/rails/rails/activerecord/lib/active_record/connection_adapters/abstract/database_statements.rb:371:in `select'
/Users/kamipo/src/github.com/rails/rails/activerecord/lib/active_record/connection_adapters/abstract/database_statements.rb:41:in `select_all'
/Users/kamipo/src/github.com/rails/rails/activerecord/lib/active_record/connection_adapters/abstract/query_cache.rb:70:in `select_all'
/Users/kamipo/src/github.com/rails/rails/activerecord/lib/active_record/relation/finder_methods.rb:396:in `limited_ids_for'
/Users/kamipo/src/github.com/rails/rails/activerecord/lib/active_record/relation/finder_methods.rb:382:in `apply_join_dependency'
/Users/kamipo/src/github.com/rails/rails/activerecord/lib/active_record/relation/finder_methods.rb:342:in `find_with_associations'
/Users/kamipo/src/github.com/rails/rails/activerecord/lib/active_record/relation.rb:691:in `exec_queries'
/Users/kamipo/src/github.com/rails/rails/activerecord/lib/active_record/relation.rb:572:in `load'
/Users/kamipo/src/github.com/rails/rails/activerecord/lib/active_record/relation.rb:252:in `to_a'
/Users/kamipo/src/github.com/rails/rails/activerecord/lib/active_record/relation/finder_methods.rb:470:in `find_take'
/Users/kamipo/src/github.com/rails/rails/activerecord/lib/active_record/relation/finder_methods.rb:100:in `take'
/Users/kamipo/src/github.com/rails/rails/activerecord/lib/active_record/relation/finder_methods.rb:437:in `find_one'
/Users/kamipo/src/github.com/rails/rails/activerecord/lib/active_record/relation/finder_methods.rb:418:in `find_with_ids'
/Users/kamipo/src/github.com/rails/rails/activerecord/lib/active_record/relation/finder_methods.rb:66:in `find'
/Users/kamipo/src/github.com/rails/rails/activerecord/test/cases/associations/eager_test.rb:311:in `test_nested_loading_through_has_one_association_with_order_on_nested_association'
8) Error:
EagerAssociationTest#test_nested_loading_through_has_one_association_with_order_on_association:
ActiveRecord::StatementInvalid: Mysql2::Error: Expression #1 of ORDER BY clause is not in SELECT list, references column 'activerecord_unittest.authors.id' which is not in SELECT list; this is incompatible with DISTINCT: SELECT DISTINCT `author_addresses`.`id` FROM `author_addresses` LEFT OUTER JOIN `authors` ON `authors`.`author_address_id` = `author_addresses`.`id` LEFT OUTER JOIN `posts` ON `posts`.`author_id` = `authors`.`id` WHERE `author_addresses`.`id` = 1 ORDER BY authors.id LIMIT 1
/Users/kamipo/src/github.com/rails/rails/vendor/bundle/ruby/2.2.0/gems/mysql2-0.4.2/lib/mysql2/client.rb:107:in `_query'
/Users/kamipo/src/github.com/rails/rails/vendor/bundle/ruby/2.2.0/gems/mysql2-0.4.2/lib/mysql2/client.rb:107:in `block in query'
/Users/kamipo/src/github.com/rails/rails/vendor/bundle/ruby/2.2.0/gems/mysql2-0.4.2/lib/mysql2/client.rb:106:in `handle_interrupt'
/Users/kamipo/src/github.com/rails/rails/vendor/bundle/ruby/2.2.0/gems/mysql2-0.4.2/lib/mysql2/client.rb:106:in `query'
/Users/kamipo/src/github.com/rails/rails/activerecord/lib/active_record/connection_adapters/abstract_mysql_adapter.rb:400:in `block in execute'
/Users/kamipo/src/github.com/rails/rails/activerecord/lib/active_record/connection_adapters/abstract_adapter.rb:535:in `block in log'
/Users/kamipo/src/github.com/rails/rails/activesupport/lib/active_support/notifications/instrumenter.rb:21:in `instrument'
/Users/kamipo/src/github.com/rails/rails/activerecord/lib/active_record/connection_adapters/abstract_adapter.rb:529:in `log'
/Users/kamipo/src/github.com/rails/rails/activerecord/lib/active_record/connection_adapters/abstract_mysql_adapter.rb:400:in `execute'
/Users/kamipo/src/github.com/rails/rails/activerecord/lib/active_record/connection_adapters/mysql2_adapter.rb:141:in `execute'
/Users/kamipo/src/github.com/rails/rails/activerecord/lib/active_record/connection_adapters/mysql2_adapter.rb:145:in `exec_query'
/Users/kamipo/src/github.com/rails/rails/activerecord/lib/active_record/connection_adapters/abstract/database_statements.rb:371:in `select'
/Users/kamipo/src/github.com/rails/rails/activerecord/lib/active_record/connection_adapters/abstract/database_statements.rb:41:in `select_all'
/Users/kamipo/src/github.com/rails/rails/activerecord/lib/active_record/connection_adapters/abstract/query_cache.rb:70:in `select_all'
/Users/kamipo/src/github.com/rails/rails/activerecord/lib/active_record/relation/finder_methods.rb:396:in `limited_ids_for'
/Users/kamipo/src/github.com/rails/rails/activerecord/lib/active_record/relation/finder_methods.rb:382:in `apply_join_dependency'
/Users/kamipo/src/github.com/rails/rails/activerecord/lib/active_record/relation/finder_methods.rb:342:in `find_with_associations'
/Users/kamipo/src/github.com/rails/rails/activerecord/lib/active_record/relation.rb:691:in `exec_queries'
/Users/kamipo/src/github.com/rails/rails/activerecord/lib/active_record/relation.rb:572:in `load'
/Users/kamipo/src/github.com/rails/rails/activerecord/lib/active_record/relation.rb:252:in `to_a'
/Users/kamipo/src/github.com/rails/rails/activerecord/lib/active_record/relation/finder_methods.rb:470:in `find_take'
/Users/kamipo/src/github.com/rails/rails/activerecord/lib/active_record/relation/finder_methods.rb:100:in `take'
/Users/kamipo/src/github.com/rails/rails/activerecord/lib/active_record/relation/finder_methods.rb:437:in `find_one'
/Users/kamipo/src/github.com/rails/rails/activerecord/lib/active_record/relation/finder_methods.rb:418:in `find_with_ids'
/Users/kamipo/src/github.com/rails/rails/activerecord/lib/active_record/relation/finder_methods.rb:66:in `find'
/Users/kamipo/src/github.com/rails/rails/activerecord/test/cases/associations/eager_test.rb:306:in `test_nested_loading_through_has_one_association_with_order_on_association'
9) Error:
HasAndBelongsToManyAssociationsTest#test_dynamic_find_should_respect_association_include:
ActiveRecord::StatementInvalid: Mysql2::Error: Expression #1 of ORDER BY clause is not in SELECT list, references column 'activerecord_unittest.authors.id' which is not in SELECT list; this is incompatible with DISTINCT: SELECT DISTINCT `posts`.`id` FROM `posts` LEFT OUTER JOIN `categorizations` ON `categorizations`.`category_id` = `posts`.`id` LEFT OUTER JOIN `authors` ON `authors`.`id` = `categorizations`.`author_id` INNER JOIN `categories_posts` ON `posts`.`id` = `categories_posts`.`post_id` WHERE `categories_posts`.`category_id` = 1 AND `posts`.`title` = 'Welcome to the weblog' ORDER BY authors.id LIMIT 1
/Users/kamipo/src/github.com/rails/rails/vendor/bundle/ruby/2.2.0/gems/mysql2-0.4.2/lib/mysql2/client.rb:107:in `_query'
/Users/kamipo/src/github.com/rails/rails/vendor/bundle/ruby/2.2.0/gems/mysql2-0.4.2/lib/mysql2/client.rb:107:in `block in query'
/Users/kamipo/src/github.com/rails/rails/vendor/bundle/ruby/2.2.0/gems/mysql2-0.4.2/lib/mysql2/client.rb:106:in `handle_interrupt'
/Users/kamipo/src/github.com/rails/rails/vendor/bundle/ruby/2.2.0/gems/mysql2-0.4.2/lib/mysql2/client.rb:106:in `query'
/Users/kamipo/src/github.com/rails/rails/activerecord/lib/active_record/connection_adapters/abstract_mysql_adapter.rb:400:in `block in execute'
/Users/kamipo/src/github.com/rails/rails/activerecord/lib/active_record/connection_adapters/abstract_adapter.rb:535:in `block in log'
/Users/kamipo/src/github.com/rails/rails/activesupport/lib/active_support/notifications/instrumenter.rb:21:in `instrument'
/Users/kamipo/src/github.com/rails/rails/activerecord/lib/active_record/connection_adapters/abstract_adapter.rb:529:in `log'
/Users/kamipo/src/github.com/rails/rails/activerecord/lib/active_record/connection_adapters/abstract_mysql_adapter.rb:400:in `execute'
/Users/kamipo/src/github.com/rails/rails/activerecord/lib/active_record/connection_adapters/mysql2_adapter.rb:141:in `execute'
/Users/kamipo/src/github.com/rails/rails/activerecord/lib/active_record/connection_adapters/mysql2_adapter.rb:145:in `exec_query'
/Users/kamipo/src/github.com/rails/rails/activerecord/lib/active_record/connection_adapters/abstract/database_statements.rb:371:in `select'
/Users/kamipo/src/github.com/rails/rails/activerecord/lib/active_record/connection_adapters/abstract/database_statements.rb:41:in `select_all'
/Users/kamipo/src/github.com/rails/rails/activerecord/lib/active_record/connection_adapters/abstract/query_cache.rb:70:in `select_all'
/Users/kamipo/src/github.com/rails/rails/activerecord/lib/active_record/relation/finder_methods.rb:396:in `limited_ids_for'
/Users/kamipo/src/github.com/rails/rails/activerecord/lib/active_record/relation/finder_methods.rb:382:in `apply_join_dependency'
/Users/kamipo/src/github.com/rails/rails/activerecord/lib/active_record/relation/finder_methods.rb:342:in `find_with_associations'
/Users/kamipo/src/github.com/rails/rails/activerecord/lib/active_record/relation.rb:691:in `exec_queries'
/Users/kamipo/src/github.com/rails/rails/activerecord/lib/active_record/association_relation.rb:32:in `exec_queries'
/Users/kamipo/src/github.com/rails/rails/activerecord/lib/active_record/relation.rb:572:in `load'
/Users/kamipo/src/github.com/rails/rails/activerecord/lib/active_record/relation.rb:252:in `to_a'
/Users/kamipo/src/github.com/rails/rails/activerecord/lib/active_record/relation/finder_methods.rb:470:in `find_take'
/Users/kamipo/src/github.com/rails/rails/activerecord/lib/active_record/relation/finder_methods.rb:100:in `take'
/Users/kamipo/src/github.com/rails/rails/activerecord/lib/active_record/relation/finder_methods.rb:78:in `find_by'
/Users/kamipo/src/github.com/rails/rails/activerecord/lib/active_record/querying.rb:7:in `find_by'
/Users/kamipo/src/github.com/rails/rails/activerecord/lib/active_record/core.rb:175:in `find_by'
/Users/kamipo/src/github.com/rails/rails/activerecord/lib/active_record/dynamic_matchers.rb:65:in `find_by_title'
/Users/kamipo/src/github.com/rails/rails/activerecord/lib/active_record/dynamic_matchers.rb:19:in `method_missing'
/Users/kamipo/src/github.com/rails/rails/activerecord/lib/active_record/relation/delegation.rb:88:in `public_send'
/Users/kamipo/src/github.com/rails/rails/activerecord/lib/active_record/relation/delegation.rb:88:in `block in method_missing'
/Users/kamipo/src/github.com/rails/rails/activerecord/lib/active_record/associations/collection_proxy.rb:897:in `block in scoping'
/Users/kamipo/src/github.com/rails/rails/activerecord/lib/active_record/relation.rb:343:in `scoping'
/Users/kamipo/src/github.com/rails/rails/activerecord/lib/active_record/associations/collection_proxy.rb:897:in `scoping'
/Users/kamipo/src/github.com/rails/rails/activerecord/lib/active_record/relation/delegation.rb:88:in `method_missing'
/Users/kamipo/src/github.com/rails/rails/activerecord/test/cases/associations/has_and_belongs_to_many_associations_test.rb:799:in `test_dynamic_find_should_respect_association_include'
10) Error:
HasManyAssociationsTestForReorderWithJoinDependency#test_should_generate_valid_sql:
ActiveRecord::StatementInvalid: Mysql2::Error: Expression #1 of ORDER BY clause is not in SELECT list, references column 'activerecord_unittest.posts.comments_count' which is not in SELECT list; this is incompatible with DISTINCT: SELECT DISTINCT `posts`.`id` FROM `posts` LEFT OUTER JOIN `comments` ON `comments`.`post_id` = `posts`.`id` WHERE `posts`.`author_id` = 1 AND (comments.id > 0) ORDER BY posts.comments_count ASC, posts.tags_count ASC LIMIT 1
/Users/kamipo/src/github.com/rails/rails/vendor/bundle/ruby/2.2.0/gems/mysql2-0.4.2/lib/mysql2/client.rb:107:in `_query'
/Users/kamipo/src/github.com/rails/rails/vendor/bundle/ruby/2.2.0/gems/mysql2-0.4.2/lib/mysql2/client.rb:107:in `block in query'
/Users/kamipo/src/github.com/rails/rails/vendor/bundle/ruby/2.2.0/gems/mysql2-0.4.2/lib/mysql2/client.rb:106:in `handle_interrupt'
/Users/kamipo/src/github.com/rails/rails/vendor/bundle/ruby/2.2.0/gems/mysql2-0.4.2/lib/mysql2/client.rb:106:in `query'
/Users/kamipo/src/github.com/rails/rails/activerecord/lib/active_record/connection_adapters/abstract_mysql_adapter.rb:400:in `block in execute'
/Users/kamipo/src/github.com/rails/rails/activerecord/lib/active_record/connection_adapters/abstract_adapter.rb:535:in `block in log'
/Users/kamipo/src/github.com/rails/rails/activesupport/lib/active_support/notifications/instrumenter.rb:21:in `instrument'
/Users/kamipo/src/github.com/rails/rails/activerecord/lib/active_record/connection_adapters/abstract_adapter.rb:529:in `log'
/Users/kamipo/src/github.com/rails/rails/activerecord/lib/active_record/connection_adapters/abstract_mysql_adapter.rb:400:in `execute'
/Users/kamipo/src/github.com/rails/rails/activerecord/lib/active_record/connection_adapters/mysql2_adapter.rb:141:in `execute'
/Users/kamipo/src/github.com/rails/rails/activerecord/lib/active_record/connection_adapters/mysql2_adapter.rb:145:in `exec_query'
/Users/kamipo/src/github.com/rails/rails/activerecord/lib/active_record/connection_adapters/abstract/database_statements.rb:371:in `select'
/Users/kamipo/src/github.com/rails/rails/activerecord/lib/active_record/connection_adapters/abstract/database_statements.rb:41:in `select_all'
/Users/kamipo/src/github.com/rails/rails/activerecord/lib/active_record/connection_adapters/abstract/query_cache.rb:70:in `select_all'
/Users/kamipo/src/github.com/rails/rails/activerecord/lib/active_record/relation/finder_methods.rb:396:in `limited_ids_for'
/Users/kamipo/src/github.com/rails/rails/activerecord/lib/active_record/relation/finder_methods.rb:382:in `apply_join_dependency'
/Users/kamipo/src/github.com/rails/rails/activerecord/lib/active_record/relation/finder_methods.rb:342:in `find_with_associations'
/Users/kamipo/src/github.com/rails/rails/activerecord/lib/active_record/relation.rb:691:in `exec_queries'
/Users/kamipo/src/github.com/rails/rails/activerecord/lib/active_record/association_relation.rb:32:in `exec_queries'
/Users/kamipo/src/github.com/rails/rails/activerecord/lib/active_record/relation.rb:572:in `load'
/Users/kamipo/src/github.com/rails/rails/activerecord/lib/active_record/relation.rb:252:in `to_a'
/Users/kamipo/src/github.com/rails/rails/activerecord/lib/active_record/relation/finder_methods.rb:506:in `find_last'
/Users/kamipo/src/github.com/rails/rails/activerecord/lib/active_record/relation/finder_methods.rb:155:in `last'
/Users/kamipo/src/github.com/rails/rails/activerecord/test/cases/associations/has_many_associations_test.rb:49:in `test_should_generate_valid_sql'
11) Error:
HasManyThroughAssociationsTest#test_dynamic_find_should_respect_association_include:
ActiveRecord::StatementInvalid: Mysql2::Error: Expression #1 of ORDER BY clause is not in SELECT list, references column 'activerecord_unittest.comments.id' which is not in SELECT list; this is incompatible with DISTINCT: SELECT DISTINCT `posts`.`id` FROM `posts` LEFT OUTER JOIN `comments` ON `comments`.`post_id` = `posts`.`id` INNER JOIN `readers` ON `posts`.`id` = `readers`.`post_id` WHERE `readers`.`person_id` = 1 AND `posts`.`title` = 'Welcome to the weblog' ORDER BY comments.id LIMIT 1
/Users/kamipo/src/github.com/rails/rails/vendor/bundle/ruby/2.2.0/gems/mysql2-0.4.2/lib/mysql2/client.rb:107:in `_query'
/Users/kamipo/src/github.com/rails/rails/vendor/bundle/ruby/2.2.0/gems/mysql2-0.4.2/lib/mysql2/client.rb:107:in `block in query'
/Users/kamipo/src/github.com/rails/rails/vendor/bundle/ruby/2.2.0/gems/mysql2-0.4.2/lib/mysql2/client.rb:106:in `handle_interrupt'
/Users/kamipo/src/github.com/rails/rails/vendor/bundle/ruby/2.2.0/gems/mysql2-0.4.2/lib/mysql2/client.rb:106:in `query'
/Users/kamipo/src/github.com/rails/rails/activerecord/lib/active_record/connection_adapters/abstract_mysql_adapter.rb:400:in `block in execute'
/Users/kamipo/src/github.com/rails/rails/activerecord/lib/active_record/connection_adapters/abstract_adapter.rb:535:in `block in log'
/Users/kamipo/src/github.com/rails/rails/activesupport/lib/active_support/notifications/instrumenter.rb:21:in `instrument'
/Users/kamipo/src/github.com/rails/rails/activerecord/lib/active_record/connection_adapters/abstract_adapter.rb:529:in `log'
/Users/kamipo/src/github.com/rails/rails/activerecord/lib/active_record/connection_adapters/abstract_mysql_adapter.rb:400:in `execute'
/Users/kamipo/src/github.com/rails/rails/activerecord/lib/active_record/connection_adapters/mysql2_adapter.rb:141:in `execute'
/Users/kamipo/src/github.com/rails/rails/activerecord/lib/active_record/connection_adapters/mysql2_adapter.rb:145:in `exec_query'
/Users/kamipo/src/github.com/rails/rails/activerecord/lib/active_record/connection_adapters/abstract/database_statements.rb:371:in `select'
/Users/kamipo/src/github.com/rails/rails/activerecord/lib/active_record/connection_adapters/abstract/database_statements.rb:41:in `select_all'
/Users/kamipo/src/github.com/rails/rails/activerecord/lib/active_record/connection_adapters/abstract/query_cache.rb:70:in `select_all'
/Users/kamipo/src/github.com/rails/rails/activerecord/lib/active_record/relation/finder_methods.rb:396:in `limited_ids_for'
/Users/kamipo/src/github.com/rails/rails/activerecord/lib/active_record/relation/finder_methods.rb:382:in `apply_join_dependency'
/Users/kamipo/src/github.com/rails/rails/activerecord/lib/active_record/relation/finder_methods.rb:342:in `find_with_associations'
/Users/kamipo/src/github.com/rails/rails/activerecord/lib/active_record/relation.rb:691:in `exec_queries'
/Users/kamipo/src/github.com/rails/rails/activerecord/lib/active_record/association_relation.rb:32:in `exec_queries'
/Users/kamipo/src/github.com/rails/rails/activerecord/lib/active_record/relation.rb:572:in `load'
/Users/kamipo/src/github.com/rails/rails/activerecord/lib/active_record/relation.rb:252:in `to_a'
/Users/kamipo/src/github.com/rails/rails/activerecord/lib/active_record/relation/finder_methods.rb:470:in `find_take'
/Users/kamipo/src/github.com/rails/rails/activerecord/lib/active_record/relation/finder_methods.rb:100:in `take'
/Users/kamipo/src/github.com/rails/rails/activerecord/lib/active_record/relation/finder_methods.rb:78:in `find_by'
/Users/kamipo/src/github.com/rails/rails/activerecord/lib/active_record/querying.rb:7:in `find_by'
/Users/kamipo/src/github.com/rails/rails/activerecord/lib/active_record/core.rb:175:in `find_by'
/Users/kamipo/src/github.com/rails/rails/activerecord/lib/active_record/dynamic_matchers.rb:65:in `find_by_title'
/Users/kamipo/src/github.com/rails/rails/activerecord/lib/active_record/relation/delegation.rb:64:in `block in find_by_title'
/Users/kamipo/src/github.com/rails/rails/activerecord/lib/active_record/associations/collection_proxy.rb:897:in `block in scoping'
/Users/kamipo/src/github.com/rails/rails/activerecord/lib/active_record/relation.rb:343:in `scoping'
/Users/kamipo/src/github.com/rails/rails/activerecord/lib/active_record/associations/collection_proxy.rb:897:in `scoping'
/Users/kamipo/src/github.com/rails/rails/activerecord/lib/active_record/relation/delegation.rb:64:in `find_by_title'
/Users/kamipo/src/github.com/rails/rails/activerecord/test/cases/associations/has_many_through_associations_test.rb:730:in `test_dynamic_find_should_respect_association_include'
12) Error:
InverseHasManyTests#test_parent_instance_should_be_shared_with_eager_loaded_children:
ActiveRecord::StatementInvalid: Mysql2::Error: Expression #1 of ORDER BY clause is not in SELECT list, references column 'activerecord_unittest.interests.id' which is not in SELECT list; this is incompatible with DISTINCT: SELECT DISTINCT `men`.`id` FROM `men` LEFT OUTER JOIN `interests` ON `interests`.`man_id` = `men`.`id` WHERE `men`.`name` = 'Gordon' ORDER BY interests.id LIMIT 1
/Users/kamipo/src/github.com/rails/rails/vendor/bundle/ruby/2.2.0/gems/mysql2-0.4.2/lib/mysql2/client.rb:107:in `_query'
/Users/kamipo/src/github.com/rails/rails/vendor/bundle/ruby/2.2.0/gems/mysql2-0.4.2/lib/mysql2/client.rb:107:in `block in query'
/Users/kamipo/src/github.com/rails/rails/vendor/bundle/ruby/2.2.0/gems/mysql2-0.4.2/lib/mysql2/client.rb:106:in `handle_interrupt'
/Users/kamipo/src/github.com/rails/rails/vendor/bundle/ruby/2.2.0/gems/mysql2-0.4.2/lib/mysql2/client.rb:106:in `query'
/Users/kamipo/src/github.com/rails/rails/activerecord/lib/active_record/connection_adapters/abstract_mysql_adapter.rb:400:in `block in execute'
/Users/kamipo/src/github.com/rails/rails/activerecord/lib/active_record/connection_adapters/abstract_adapter.rb:535:in `block in log'
/Users/kamipo/src/github.com/rails/rails/activesupport/lib/active_support/notifications/instrumenter.rb:21:in `instrument'
/Users/kamipo/src/github.com/rails/rails/activerecord/lib/active_record/connection_adapters/abstract_adapter.rb:529:in `log'
/Users/kamipo/src/github.com/rails/rails/activerecord/lib/active_record/connection_adapters/abstract_mysql_adapter.rb:400:in `execute'
/Users/kamipo/src/github.com/rails/rails/activerecord/lib/active_record/connection_adapters/mysql2_adapter.rb:141:in `execute'
/Users/kamipo/src/github.com/rails/rails/activerecord/lib/active_record/connection_adapters/mysql2_adapter.rb:145:in `exec_query'
/Users/kamipo/src/github.com/rails/rails/activerecord/lib/active_record/connection_adapters/abstract/database_statements.rb:371:in `select'
/Users/kamipo/src/github.com/rails/rails/activerecord/lib/active_record/connection_adapters/abstract/database_statements.rb:41:in `select_all'
/Users/kamipo/src/github.com/rails/rails/activerecord/lib/active_record/connection_adapters/abstract/query_cache.rb:70:in `select_all'
/Users/kamipo/src/github.com/rails/rails/activerecord/lib/active_record/relation/finder_methods.rb:396:in `limited_ids_for'
/Users/kamipo/src/github.com/rails/rails/activerecord/lib/active_record/relation/finder_methods.rb:382:in `apply_join_dependency'
/Users/kamipo/src/github.com/rails/rails/activerecord/lib/active_record/relation/finder_methods.rb:342:in `find_with_associations'
/Users/kamipo/src/github.com/rails/rails/activerecord/lib/active_record/relation.rb:691:in `exec_queries'
/Users/kamipo/src/github.com/rails/rails/activerecord/lib/active_record/relation.rb:572:in `load'
/Users/kamipo/src/github.com/rails/rails/activerecord/lib/active_record/relation.rb:252:in `to_a'
/Users/kamipo/src/github.com/rails/rails/activerecord/lib/active_record/relation/finder_methods.rb:495:in `find_nth_with_limit'
/Users/kamipo/src/github.com/rails/rails/activerecord/lib/active_record/relation/finder_methods.rb:479:in `find_nth'
/Users/kamipo/src/github.com/rails/rails/activerecord/lib/active_record/relation/finder_methods.rb:122:in `first'
/Users/kamipo/src/github.com/rails/rails/activerecord/test/cases/associations/inverse_associations_test.rb:324:in `test_parent_instance_should_be_shared_with_eager_loaded_children'
13) Error:
AssociationsJoinModelTest#test_eager_load_has_many_through_has_many:
ActiveRecord::StatementInvalid: Mysql2::Error: Expression #1 of ORDER BY clause is not in SELECT list, references column 'activerecord_unittest.comments.id' which is not in SELECT list; this is incompatible with DISTINCT: SELECT DISTINCT `authors`.`id` FROM `authors` LEFT OUTER JOIN `posts` ON `posts`.`author_id` = `authors`.`id` LEFT OUTER JOIN `comments` ON `comments`.`post_id` = `posts`.`id` WHERE (name = 'David') ORDER BY comments.id LIMIT 1
/Users/kamipo/src/github.com/rails/rails/vendor/bundle/ruby/2.2.0/gems/mysql2-0.4.2/lib/mysql2/client.rb:107:in `_query'
/Users/kamipo/src/github.com/rails/rails/vendor/bundle/ruby/2.2.0/gems/mysql2-0.4.2/lib/mysql2/client.rb:107:in `block in query'
/Users/kamipo/src/github.com/rails/rails/vendor/bundle/ruby/2.2.0/gems/mysql2-0.4.2/lib/mysql2/client.rb:106:in `handle_interrupt'
/Users/kamipo/src/github.com/rails/rails/vendor/bundle/ruby/2.2.0/gems/mysql2-0.4.2/lib/mysql2/client.rb:106:in `query'
/Users/kamipo/src/github.com/rails/rails/activerecord/lib/active_record/connection_adapters/abstract_mysql_adapter.rb:400:in `block in execute'
/Users/kamipo/src/github.com/rails/rails/activerecord/lib/active_record/connection_adapters/abstract_adapter.rb:535:in `block in log'
/Users/kamipo/src/github.com/rails/rails/activesupport/lib/active_support/notifications/instrumenter.rb:21:in `instrument'
/Users/kamipo/src/github.com/rails/rails/activerecord/lib/active_record/connection_adapters/abstract_adapter.rb:529:in `log'
/Users/kamipo/src/github.com/rails/rails/activerecord/lib/active_record/connection_adapters/abstract_mysql_adapter.rb:400:in `execute'
/Users/kamipo/src/github.com/rails/rails/activerecord/lib/active_record/connection_adapters/mysql2_adapter.rb:141:in `execute'
/Users/kamipo/src/github.com/rails/rails/activerecord/lib/active_record/connection_adapters/mysql2_adapter.rb:145:in `exec_query'
/Users/kamipo/src/github.com/rails/rails/activerecord/lib/active_record/connection_adapters/abstract/database_statements.rb:371:in `select'
/Users/kamipo/src/github.com/rails/rails/activerecord/lib/active_record/connection_adapters/abstract/database_statements.rb:41:in `select_all'
/Users/kamipo/src/github.com/rails/rails/activerecord/lib/active_record/connection_adapters/abstract/query_cache.rb:70:in `select_all'
/Users/kamipo/src/github.com/rails/rails/activerecord/lib/active_record/relation/finder_methods.rb:396:in `limited_ids_for'
/Users/kamipo/src/github.com/rails/rails/activerecord/lib/active_record/relation/finder_methods.rb:382:in `apply_join_dependency'
/Users/kamipo/src/github.com/rails/rails/activerecord/lib/active_record/relation/finder_methods.rb:342:in `find_with_associations'
/Users/kamipo/src/github.com/rails/rails/activerecord/lib/active_record/relation.rb:691:in `exec_queries'
/Users/kamipo/src/github.com/rails/rails/activerecord/lib/active_record/relation.rb:572:in `load'
/Users/kamipo/src/github.com/rails/rails/activerecord/lib/active_record/relation.rb:252:in `to_a'
/Users/kamipo/src/github.com/rails/rails/activerecord/lib/active_record/relation/finder_methods.rb:495:in `find_nth_with_limit'
/Users/kamipo/src/github.com/rails/rails/activerecord/lib/active_record/relation/finder_methods.rb:479:in `find_nth'
/Users/kamipo/src/github.com/rails/rails/activerecord/lib/active_record/relation/finder_methods.rb:122:in `first'
/Users/kamipo/src/github.com/rails/rails/activerecord/test/cases/associations/join_model_test.rb:414:in `test_eager_load_has_many_through_has_many'
14) Error:
FinderTest#test_find_with_order_on_included_associations_with_construct_finder_sql_for_association_limiting_and_is_distinct:
ActiveRecord::StatementInvalid: Mysql2::Error: Expression #1 of ORDER BY clause is not in SELECT list, references column 'activerecord_unittest.author_addresses.id' which is not in SELECT list; this is incompatible with DISTINCT: SELECT DISTINCT `posts`.`id` FROM `posts` LEFT OUTER JOIN `categorizations` ON `catego","1","2015-12-21T12:18:51Z"
"247484","19809","166291690","12642","kamipo","@rafaelfranca What do you think about this issue?","1","2015-12-21T12:21:30Z"
"247485","19810","155359854","7468109","rails-bot","Thanks for the pull request, and welcome! The Rails team is excited to review your changes, and you should hear from @kaspth (or someone else) soon.
If any changes to this PR are deemed necessary, please add them as extra commits. This ensures that the reviewer can see what has changed since they last reviewed the code. Due to the way GitHub handles out-of-date commits, this should also make it reasonably obvious what issues have or haven't been addressed. Large or tricky changes may require several passes of review and changes.
Please see [the contribution instructions](http://edgeguides.rubyonrails.org/contributing_to_ruby_on_rails.html) for more information.
","1","2015-11-10T08:47:19Z"
"247486","19810","155361942","350807","kaspth","Gonna hand this off, to @pixeltrix :smile:
r? @pixeltrix ","1","2015-11-10T08:59:18Z"
"247487","19810","159119044","399968","kv109","Anything I can do to help with closing/merging this?","1","2015-11-24T01:08:39Z"
"247488","19811","155368906","7468109","rails-bot","Thanks for the pull request, and welcome! The Rails team is excited to review your changes, and you should hear from @matthewd (or someone else) soon.
If any changes to this PR are deemed necessary, please add them as extra commits. This ensures that the reviewer can see what has changed since they last reviewed the code. Due to the way GitHub handles out-of-date commits, this should also make it reasonably obvious what issues have or haven't been addressed. Large or tricky changes may require several passes of review and changes.
Please see [the contribution instructions](http://edgeguides.rubyonrails.org/contributing_to_ruby_on_rails.html) for more information.
","1","2015-11-10T09:33:01Z"
"247489","19811","155442992","6321","pixeltrix","@pacso can you add a CHANGELOG entry please - thanks","1","2015-11-10T15:00:53Z"
"247490","19811","155447449","125296","pacso","@pixeltrix - Have added an entry to the activesupport CHANGELOG now.
Cheers,
Jon","1","2015-11-10T15:13:34Z"
"247491","19811","155467522","6321","pixeltrix","@pacso sorry to be a pain, but could you please squash them into a single commit - thanks","1","2015-11-10T16:10:40Z"
"247492","19811","155470387","125296","pacso","@pixeltrix no problem at all. Should already be done.","1","2015-11-10T16:18:21Z"
"247493","19811","155491669","6321","pixeltrix","@pacso thanks for your contribution!","1","2015-11-10T17:13:26Z"
"247494","19812","155387955","7468109","rails-bot","Thanks for the pull request, and welcome! The Rails team is excited to review your changes, and you should hear from @carlosantoniodasilva (or someone else) soon.
If any changes to this PR are deemed necessary, please add them as extra commits. This ensures that the reviewer can see what has changed since they last reviewed the code. Due to the way GitHub handles out-of-date commits, this should also make it reasonably obvious what issues have or haven't been addressed. Large or tricky changes may require several passes of review and changes.
Please see [the contribution instructions](http://edgeguides.rubyonrails.org/contributing_to_ruby_on_rails.html) for more information.
","1","2015-11-10T10:54:03Z"
"247495","19812","156948323","105565","amiryal","@carlosantoniodasilva seems like I'm done with rewriting the patch now, CI build passes.
In this latest rewrite, we pay the penalty of one extra `SELECT COUNT(*)` query in certain cases, in order to save a lot of resources in some other cases. I believe the trade-off is well worth it.
Thanks,
Amir","1","2015-11-16T07:47:30Z"
"247496","19813","155397914","7468109","rails-bot","Thanks for the pull request, and welcome! The Rails team is excited to review your changes, and you should hear from @pixeltrix (or someone else) soon.
If any changes to this PR are deemed necessary, please add them as extra commits. This ensures that the reviewer can see what has changed since they last reviewed the code. Due to the way GitHub handles out-of-date commits, this should also make it reasonably obvious what issues have or haven't been addressed. Large or tricky changes may require several passes of review and changes.
Please see [the contribution instructions](http://edgeguides.rubyonrails.org/contributing_to_ruby_on_rails.html) for more information.
","1","2015-11-10T11:44:03Z"
"247497","19813","155397915","7468109","rails-bot","<img src=""http://www.joshmatthews.net/warning.svg"" alt=""warning"" height=20> **Warning** <img src=""http://www.joshmatthews.net/warning.svg"" alt=""warning"" height=20>
* Pull requests are usually filed against the master branch for this repo, but this one is against 4-2-5. Please double check that you specified the right target!","1","2015-11-10T11:44:03Z"
"247498","19814","155401335","7468109","rails-bot","Thanks for the pull request, and welcome! The Rails team is excited to review your changes, and you should hear from @arthurnn (or someone else) soon.
If any changes to this PR are deemed necessary, please add them as extra commits. This ensures that the reviewer can see what has changed since they last reviewed the code. Due to the way GitHub handles out-of-date commits, this should also make it reasonably obvious what issues have or haven't been addressed. Large or tricky changes may require several passes of review and changes.
Please see [the contribution instructions](http://edgeguides.rubyonrails.org/contributing_to_ruby_on_rails.html) for more information.
","1","2015-11-10T11:56:33Z"
"247499","19814","155610889","10076","claudiob","Hello @donvaughn and thanks for your contribution.
Could you clarify what is the issue that this change fixes? Thanks.","1","2015-11-11T00:21:55Z"
"247500","19814","155915720","51815","donvaughn","My apologies, false alarm, this only fixes a bug in our own app when a third party gem is installed. I vote we shut this PR down.","1","2015-11-11T21:29:15Z"
"247501","19815","155416264","7468109","rails-bot","Thanks for the pull request, and welcome! The Rails team is excited to review your changes, and you should hear from @eileencodes (or someone else) soon.
If any changes to this PR are deemed necessary, please add them as extra commits. This ensures that the reviewer can see what has changed since they last reviewed the code. Due to the way GitHub handles out-of-date commits, this should also make it reasonably obvious what issues have or haven't been addressed. Large or tricky changes may require several passes of review and changes.
Please see [the contribution instructions](http://edgeguides.rubyonrails.org/contributing_to_ruby_on_rails.html) for more information.
","1","2015-11-10T13:15:44Z"
"247502","19815","155417648","1080678","eileencodes","Hi @arekf thanks for the PR. Can you explain better in your commit message and the changelog what fix means. Ex: explain what was the broken behavior and what the new behavior achieves. I see the linked issue but people reading the changelog/commit later may not be able to access it to find out what the reason for this change is. Thanks!","1","2015-11-10T13:22:54Z"
"247503","19815","155436273","367484","arekf","Hello @eileencodes,
thank you for reviewing my changes. I've amended my commit, hope this makes more sense now. Let me know if I can make it any better.
Thanks,
Arek","1","2015-11-10T14:34:59Z"
"247504","19815","162024509","1529387","sgrif","@arekf Can you rebase?","1","2015-12-04T17:12:35Z"
"247505","19815","162036208","367484","arekf","@sgrif Done!","1","2015-12-04T18:01:16Z"
"247506","19815","162039398","367484","arekf","@sgrif There we go!","1","2015-12-04T18:16:35Z"
"247507","19815","162040598","1529387","sgrif","Just glancing over these changes, doesn't this cause issues if you try to run more than one task in a command? e.g. `rake test:units test:functionals`. Should we only `exit` if the result is non-zero?","1","2015-12-04T18:21:43Z"
"247508","19815","162249530","833383","arthurnn","Yeah, as far as I remember we didnt add those exit exactly because of what @sgrif said.
cc @senny @kaspth ","1","2015-12-05T21:33:28Z"
"247509","19815","162466767","5402","senny","I think the `Rake::TestTask` we were using previous to the new runner also exited with a non-zero status. See https://github.com/ruby/rake/blob/master/lib/rake/testtask.rb#L109
@sgrif is right tough. We should not exit for `0` status codes. Otherwise chaining tasks won't work anymore.
","1","2015-12-07T09:51:24Z"
"247510","19815","162509808","367484","arekf","@sgrif @arthurnn @senny Sorry, you're right it would've broken chaining tasks.
Please let me know if I can amend this to `exit` only when status code is non-zero (and break tasks chain). Should there be any additional message provided when it's exiting?","1","2015-12-07T12:21:06Z"
"247511","19815","162510118","5402","senny","@arekf please feel free to amend.","1","2015-12-07T12:22:57Z"
"247512","19815","162526797","367484","arekf","Can someone have a look at my amendments?","1","2015-12-07T13:38:56Z"
"247513","19815","162690856","350807","kaspth","Thanks!","1","2015-12-07T22:36:30Z"
"247514","19816","1639538","160941","guilleiguaran","@mochaleaf can you set a more descriptive message to the commit? :D","1","2011-07-24T02:16:12Z"
"247515","19816","1639636","863132","Mochaleaf","Ah, I think most of the dialogue was covered inside of the linked issue: https://github.com/rails/rails/issues/759","1","2011-07-24T03:00:49Z"
"247516","19816","1693450","577301","scoz","Rails newbie here, this really needs to go through.
Took me way too long to figure out why Date.today and Date.yesterday were returning the same day.","1","2011-07-31T00:27:46Z"
"247517","19816","1694047","124430","dmitriy-kiriyenko","+1.","1","2011-07-31T05:42:45Z"
"247518","19816","1723472","863132","Mochaleaf","Anything else I need to do here to get this pulled?","1","2011-08-04T01:05:57Z"
"247519","19816","1724026","124430","dmitriy-kiriyenko","I believe you should remove merge commits. If you wish to update the pull request to the current code, you should `rebase` and then `push origin pull_request_branch --force`.
Perhaps it might be better to squash the 2 actual commits.","1","2011-08-04T03:03:54Z"
"247520","19817","155588925","7468109","rails-bot","Thanks for the pull request, and welcome! The Rails team is excited to review your changes, and you should hear from @chancancode (or someone else) soon.
If any changes to this PR are deemed necessary, please add them as extra commits. This ensures that the reviewer can see what has changed since they last reviewed the code. Due to the way GitHub handles out-of-date commits, this should also make it reasonably obvious what issues have or haven't been addressed. Large or tricky changes may require several passes of review and changes.
Please see [the contribution instructions](http://edgeguides.rubyonrails.org/contributing_to_ruby_on_rails.html) for more information.
","1","2015-11-10T22:32:08Z"
"247521","19823","157340658","350807","kaspth","@yui-knk we like to do the backports if needed, so don't bother with a PR ?","1","2015-11-17T11:16:36Z"
"247522","19823","157343470","5356517","yui-knk","Sure thanks!","1","2015-11-17T11:32:19Z"
"247523","19823","157407816","6321","pixeltrix","I had to tweak the order of the conditionals slightly in 5d1d5f2 because invalid arguments that are truthy leak through into `merge!` from `merge`. I didn't backport the raising on falsey arguments from b71e08f as that would be a change in behaviour but this change should just raise sooner which is preferable to raising deep inside of the merger internals.
Backported to 4-2-stable in 4be8e5d and 4-1-stable in 32ca78a","1","2015-11-17T15:41:13Z"
"247524","19823","157409914","5356517","yui-knk","@pixeltrix Thanks !! BTW I think 4-1-stable has diff with 4-1-14 branch [so change log is still Rails 4.1.14.rc1](https://github.com/rails/rails/blob/4-1-stable/activerecord/CHANGELOG.md) :)","1","2015-11-17T15:48:18Z"
"247525","19823","157436566","6321","pixeltrix","> BTW I think 4-1-stable has diff with 4-1-14 branch so change log is still Rails 4.1.14.rc1
Maybe @rafaelfranca didn't merge it back? I'll check it out thanks.","1","2015-11-17T17:07:53Z"
"247526","19824","155707452","7468109","rails-bot","Thanks for the pull request, and welcome! The Rails team is excited to review your changes, and you should hear from @sgrif (or someone else) soon.
If any changes to this PR are deemed necessary, please add them as extra commits. This ensures that the reviewer can see what has changed since they last reviewed the code. Due to the way GitHub handles out-of-date commits, this should also make it reasonably obvious what issues have or haven't been addressed. Large or tricky changes may require several passes of review and changes.
Please see [the contribution instructions](http://edgeguides.rubyonrails.org/contributing_to_ruby_on_rails.html) for more information.
","1","2015-11-11T08:52:28Z"
"247527","19824","155714772","3948","arunagw","Typo in commit message :)","1","2015-11-11T09:32:30Z"
"247528","19824","155718718","1168","rymai","lol, sorry I'll fix that! ^^","1","2015-11-11T09:50:57Z"
"247529","19824","155719491","543859","sevenseacat","lol the irony","1","2015-11-11T09:55:05Z"
"247530","19825","155766570","7468109","rails-bot","Thanks for the pull request, and welcome! The Rails team is excited to review your changes, and you should hear from @carlosantoniodasilva (or someone else) soon.
If any changes to this PR are deemed necessary, please add them as extra commits. This ensures that the reviewer can see what has changed since they last reviewed the code. Due to the way GitHub handles out-of-date commits, this should also make it reasonably obvious what issues have or haven't been addressed. Large or tricky changes may require several passes of review and changes.
Please see [the contribution instructions](http://edgeguides.rubyonrails.org/contributing_to_ruby_on_rails.html) for more information.
","1","2015-11-11T12:42:23Z"
"247531","19825","156153301","5402","senny","@daisuko thank you :yellow_heart: ","1","2015-11-12T16:18:18Z"
"247532","19826","1640430","9582","josevalim","A test case asserting something was added to tmp/cache/assets would be cool. Thanks for the patch, I was bitten by it as well!","1","2011-07-24T10:53:34Z"
"247533","19826","1641754","9347","dmathieu","@josevalim I've never seen any tests for rake tasks. Where should I put that one ?","1","2011-07-24T18:49:10Z"
"247534","19826","1642852","9582","josevalim","@dmathieu, assets ones are here:
https://github.com/rails/rails/blob/master/railties/test/application/assets_test.rb
General ones are here:
https://github.com/rails/rails/blob/master/railties/test/application/rake_test.rb","1","2011-07-25T00:28:24Z"
"247535","19827","155837102","7468109","rails-bot","Thanks for the pull request, and welcome! The Rails team is excited to review your changes, and you should hear from @kaspth (or someone else) soon.
If any changes to this PR are deemed necessary, please add them as extra commits. This ensures that the reviewer can see what has changed since they last reviewed the code. Due to the way GitHub handles out-of-date commits, this should also make it reasonably obvious what issues have or haven't been addressed. Large or tricky changes may require several passes of review and changes.
Please see [the contribution instructions](http://edgeguides.rubyonrails.org/contributing_to_ruby_on_rails.html) for more information.
","1","2015-11-11T16:35:08Z"
"247536","19827","155884147","47848","rafaelfranca","Review @rails/security ","1","2015-11-11T19:21:25Z"
"247537","19827","155941276","1144197","mastahyeti","I wrote a little Sinatra app to help test the Origin header behavior in different browsers:
```ruby
require ""sinatra""
require ""useragent""
require ""json""
get ""*"" do
<<HERE
<html>
<head>
<script>
window.addEventListener('load', function(){
document.querySelector('form').submit()
})
</script>
</head>
<body>
<form action=""/"" method=""post"">
</form>
</body>
</html>
HERE
end
post ""*"" do
JSON.dump(
:browser => UserAgent.parse(request.env['HTTP_USER_AGENT']).browser,
:origin => request.env['HTTP_ORIGIN'],
:base_url => request.base_url
)
end
```
Here's my results for port 80 and port 4567:
<img width=""620"" alt=""screen shot 2015-11-11 at 6 15 23 pm"" src=""https://cloud.githubusercontent.com/assets/1144197/11106054/11ea71ea-88a1-11e5-9b64-89fbea283864.png"">
<img width=""599"" alt=""screen shot 2015-11-11 at 6 16 08 pm"" src=""https://cloud.githubusercontent.com/assets/1144197/11106057/11ece89e-88a1-11e5-95b5-7698be4703bf.png"">
<img width=""578"" alt=""screen shot 2015-11-11 at 6 16 27 pm"" src=""https://cloud.githubusercontent.com/assets/1144197/11106052/11e89370-88a1-11e5-90d2-6be691898fc3.png"">
<img width=""614"" alt=""screen shot 2015-11-11 at 6 16 51 pm"" src=""https://cloud.githubusercontent.com/assets/1144197/11106056/11eb417e-88a1-11e5-9064-44b9ad39d555.png"">
<img width=""482"" alt=""screen shot 2015-11-11 at 6 17 00 pm"" src=""https://cloud.githubusercontent.com/assets/1144197/11106053/11e94ca2-88a1-11e5-9dfe-f3498a33f59e.png"">
<img width=""485"" alt=""screen shot 2015-11-11 at 6 17 11 pm"" src=""https://cloud.githubusercontent.com/assets/1144197/11106055/11eacf00-88a1-11e5-8d9d-5ae54bc12a25.png"">
I haven't tested this with IE or over HTTPS.","1","2015-11-11T23:22:37Z"
"247538","19827","159276222","1144197","mastahyeti","@jeremy How is this looking? Anything else you'd like to see here before this merges?","1","2015-11-24T14:02:30Z"
"247539","19827","159306889","1144197","mastahyeti","The CI is failing because of a timeout in unrelated code. Not sure how to re-run CI.","1","2015-11-24T15:37:39Z"
"247540","19827","159314569","833383","arthurnn","@mastahyeti i just retried that CI build","1","2015-11-24T16:04:07Z"
"247541","19827","159318673","1144197","mastahyeti","Thanks.","1","2015-11-24T16:15:57Z"
"247542","19827","159379148","199","jeremy","This is looking great to me. Got a couple tidbits of feedback, but +1 to merge master once someone else reviews as well.","1","2015-11-24T19:22:31Z"
"247543","19827","159655394","1144197","mastahyeti","I managed to test this with IE too:
<img width=""623"" alt=""screen shot 2015-11-25 at 9 00 07 am"" src=""https://cloud.githubusercontent.com/assets/1144197/11402108/60fb2aec-9353-11e5-8bc9-81942820af49.png"">
<img width=""633"" alt=""screen shot 2015-11-25 at 9 00 21 am"" src=""https://cloud.githubusercontent.com/assets/1144197/11402109/60fc6254-9353-11e5-8f55-7255d8ec63fb.png"">
<img width=""659"" alt=""screen shot 2015-11-25 at 9 02 21 am"" src=""https://cloud.githubusercontent.com/assets/1144197/11402110/60fc86ee-9353-11e5-8ed4-616092aade8e.png"">
<img width=""622"" alt=""screen shot 2015-11-25 at 9 02 32 am"" src=""https://cloud.githubusercontent.com/assets/1144197/11402111/60fcb1d2-9353-11e5-98ea-2cae4d7f68a5.png"">
","1","2015-11-25T16:03:38Z"
"247544","19827","159730683","47848","rafaelfranca","Awesome. Could you squash your commits? I'm going to merge it.","1","2015-11-25T21:01:39Z"
"247545","19827","159734948","199","jeremy","Great work on this! ?","1","2015-11-25T21:26:41Z"
"247546","19827","159742905","1144197","mastahyeti","> Could you squash your commits?
I have a habit of merging master into my feature branches all the time. This makes squashing commits really difficult. I reverted all my merge commits, reset back to cb67c819338d75c07a591dc23759747c740a5088 and re-committed the changes. I hope that's good enough.","1","2015-11-25T22:10:13Z"
"247547","19827","159953097","47848","rafaelfranca"," :heart: :green_heart: :blue_heart: :yellow_heart: :purple_heart:","1","2015-11-26T16:23:58Z"
"247548","19827","160346119","1144197","mastahyeti",":boom:
On Thursday, November 26, 2015, Rafael França <notifications@github.com>
wrote:
> [image: :heart:] [image: :green_heart:] [image: :blue_heart:] [image:
> :yellow_heart:] [image: :purple_heart:]
>
> —
> Reply to this email directly or view it on GitHub
> <https://github.com/rails/rails/pull/22263#issuecomment-159953097>.
>
--
-Ben Toews
","1","2015-11-28T23:47:02Z"
"247549","19829","155925237","7468109","rails-bot","Thanks for the pull request, and welcome! The Rails team is excited to review your changes, and you should hear from @eileencodes (or someone else) soon.
If any changes to this PR are deemed necessary, please add them as extra commits. This ensures that the reviewer can see what has changed since they last reviewed the code. Due to the way GitHub handles out-of-date commits, this should also make it reasonably obvious what issues have or haven't been addressed. Large or tricky changes may require several passes of review and changes.
Please see [the contribution instructions](http://edgeguides.rubyonrails.org/contributing_to_ruby_on_rails.html) for more information.
","1","2015-11-11T22:09:06Z"
"247550","19830","1639540","160941","guilleiguaran","@skippy can you set a more descriptive message to the commit? :D","1","2011-07-24T02:16:57Z"
"247551","19830","1639804","3746","skippy","haha... yes","1","2011-07-24T04:27:23Z"
"247552","19830","1648761","15175","pritchie","@skippy that works, but will the query cache now be off for the life of the Rails process?
Feels like we should be able to set the query cache flag even if the database isn't currently available.","1","2011-07-25T20:15:25Z"
"247553","19830","1648895","3746","skippy","@pritchie, addressing the 3 points in order:
* the query cache will not be turned on IF the original connection fails; otherwise it will be there.
* The querycache was baked into the connection, it seems, to just keep things clean, and now to pull it out seems messy. I made the change that I did to try and keep it small and focused rather than a (much) larger patch to decouple it completely from the connection. But I also think that is the right approach rather than having dependencies on the middleware (or some helper class). The other way to look at this is to not have ActiveRecord::Base.connection actually trigger a db call until used, but again, I think that is a thornier change outside of the scope
* I looked at that, but the reason I kept it general is that the exceptions that are thrown are direct from the driver and are quite varied in type. I'm not sure you can make the expectation that they all stem from StandardError","1","2011-07-25T20:32:08Z"
"247554","19830","1657284","15175","pritchie","I think it's reasonable to expect driver errors to inherit from StandardError. See:
http://rubydoc.info/gems/mysql2/0.3.6/Mysql2/Error
http://rubydoc.info/gems/pg/0.11.0/PGError
","1","2011-07-26T19:47:21Z"
"247555","19830","1657572","15175","pritchie","Not turning on the query cache if the original connection feels like a bug. Perhaps a smaller bug than failing to start up at all, but a bug all the same.
Lazy load feels like the right option, but from looking at /connection_adapters/abstract/connection_pool.rb that's going to be adapter specific... given that some form of middleware or helper class might be cleaner.","1","2011-07-26T20:26:52Z"
"247556","19830","1660357","3746","skippy","hey @pritchie,
all your points sound valid, so I would say go for it and submit a patch with your thoughts in code. ","1","2011-07-27T00:31:53Z"
"247557","19830","3207142","3948","arunagw","What's happening to this PR guys?? ","1","2011-12-19T18:20:09Z"
"247558","19830","3207247","3746","skippy","@pritchie was correct in that it was not the cleanest; I was trying to minimize changes, but to do it 'properly' should probably convert some of the QueryCache class into using thread-local variables wrapped in class-scoped methods.","1","2011-12-19T18:26:34Z"
"247559","19830","3207272","3948","arunagw","Can we close this PR. And you can submit the new one. What you say?","1","2011-12-19T18:28:21Z"
"247560","19830","3207304","3746","skippy","you bet, but I would look to @pritchie to submit what he thinks is appropriate; I picked this up during the rails bug squash and I don't see time coming up to rework this... sorry!","1","2011-12-19T18:30:18Z"
"247561","19830","3207335","3948","arunagw","No Probs @skippy . Thanks for your all hard work :-)","1","2011-12-19T18:32:25Z"
"247562","19831","155932888","7468109","rails-bot","Thanks for the pull request, and welcome! The Rails team is excited to review your changes, and you should hear from @senny (or someone else) soon.
If any changes to this PR are deemed necessary, please add them as extra commits. This ensures that the reviewer can see what has changed since they last reviewed the code. Due to the way GitHub handles out-of-date commits, this should also make it reasonably obvious what issues have or haven't been addressed. Large or tricky changes may require several passes of review and changes.
Please see [the contribution instructions](http://edgeguides.rubyonrails.org/contributing_to_ruby_on_rails.html) for more information.
","1","2015-11-11T22:43:50Z"
"247563","19832","157391850","350807","kaspth","?","1","2015-11-17T14:53:33Z"
"247564","19833","156038101","7468109","rails-bot","r? @eileencodes
(@rails-bot has picked a reviewer for you, use r? to override)","1","2015-11-12T09:01:16Z"
"247565","19833","156047097","1000669","JuanitoFatas","The reason behind this Pull Request can be found here: https://github.com/bundler/bundler/pull/3207","1","2015-11-12T09:31:56Z"
"247566","19833","159107060","1080678","eileencodes","Hey @y-yagi, thanks for the PR! I'm not convinced this should be removed, but maybe I'm missing the point. Why would most users not want the test files to be generated? Are we saving space in Rails or for users? I think Rails defaults should, in general, at least for generators, be geared towards new users not advanced users. Removing this may be confusing for beginners. I can reopen and merge once I have a better understanding. Thanks for your work! :smile: ","1","2015-11-23T23:51:47Z"
"247567","19833","159107977","47848","rafaelfranca","@eileencodes I believe RubyGems deprecated `test_files` option https://github.com/rubygems/guides/issues/90","1","2015-11-23T23:56:23Z"
"247568","19833","159108721","1080678","eileencodes","Ah ok I was missing some context. Thanks @rafaelfranca ","1","2015-11-24T00:00:52Z"
"247569","19833","159110864","987638","y-yagi","Thanks!","1","2015-11-24T00:12:59Z"
"247570","19834","156050151","7468109","rails-bot","r? @chancancode
(@rails-bot has picked a reviewer for you, use r? to override)","1","2015-11-12T09:42:32Z"
"247571","19834","156111344","350807","kaspth","Thanks!","1","2015-11-12T14:10:41Z"
"247572","19835","156139104","7468109","rails-bot","Thanks for the pull request, and welcome! The Rails team is excited to review your changes, and you should hear from @rafaelfranca (or someone else) soon.
If any changes to this PR are deemed necessary, please add them as extra commits. This ensures that the reviewer can see what has changed since they last reviewed the code. Due to the way GitHub handles out-of-date commits, this should also make it reasonably obvious what issues have or haven't been addressed. Large or tricky changes may require several passes of review and changes.
Please see [the contribution instructions](http://edgeguides.rubyonrails.org/contributing_to_ruby_on_rails.html) for more information.
","1","2015-11-12T15:31:31Z"
"247573","19835","156147546","47848","rafaelfranca","cc @rails/security ","1","2015-11-12T15:57:48Z"
"247574","19835","156155369","199","jeremy","Nice—definitely worth upstreaming! Preserving compatibility is a priority, though. Perhaps checking `form_authenticity_token` arity is enough?","1","2015-11-12T16:25:38Z"
"247575","19835","156158381","1144197","mastahyeti","> Nice—definitely worth upstreaming! Preserving compatibility is a priority, though. Perhaps checking form_authenticity_token arity is enough?
Okay. I pushed up my initial spike at per-form tokens (https://github.com/rails/rails/commit/61506e4a8bc26200c9d71e02a3ab5fdde00ffafc). It feels pretty hacky adding it with the current APIs. I was kind of hoping you didn't care about backwards compatibility :wink:.
I'll work on cleaning this up and adding tests over the next couple days.","1","2015-11-12T16:34:26Z"
"247576","19835","159488871","1144197","mastahyeti","After significant debugging (resulting in https://github.com/rails/rails/pull/22402), I got some simple tests written for this feature. I'll work on testing edge cases tomorrow.","1","2015-11-25T04:28:41Z"
"247577","19835","159584036","6321","pixeltrix","@mastahyeti @jeremy in #21948 we discussed using a permanent cookie for CSRF tokens - this PR will obviously complicate things if we wanted to go down that route.","1","2015-11-25T11:48:02Z"
"247578","19835","159644686","1144197","mastahyeti","@pixeltrix This PR shouldn't be complicated by using a permanent cookie for storing the CSRF token. That change would probably just be to [`#real_csrf_token`](https://github.com/rails/rails/blob/c2ad6dae14959a8e891a51389d6f8e43c392443a/actionpack/lib/action_controller/metal/request_forgery_protection.rb#L321-L324), changing it to grab the raw token value from a different place.","1","2015-11-25T15:42:09Z"
"247579","19835","161006271","1144197","mastahyeti","@jeremy I've written a number of tests and am feeling good about this branch. I'd love a set of :eyes: when you have a chance. ","1","2015-12-01T15:46:24Z"
"247580","19836","156150236","7468109","rails-bot","Thanks for the pull request, and welcome! The Rails team is excited to review your changes, and you should hear from @carlosantoniodasilva (or someone else) soon.
If any changes to this PR are deemed necessary, please add them as extra commits. This ensures that the reviewer can see what has changed since they last reviewed the code. Due to the way GitHub handles out-of-date commits, this should also make it reasonably obvious what issues have or haven't been addressed. Large or tricky changes may require several passes of review and changes.
Please see [the contribution instructions](http://edgeguides.rubyonrails.org/contributing_to_ruby_on_rails.html) for more information.
","1","2015-11-12T16:07:40Z"
"247581","19837","156261551","7468109","rails-bot","Thanks for the pull request, and welcome! The Rails team is excited to review your changes, and you should hear from @chancancode (or someone else) soon.
If any changes to this PR are deemed necessary, please add them as extra commits. This ensures that the reviewer can see what has changed since they last reviewed the code. Due to the way GitHub handles out-of-date commits, this should also make it reasonably obvious what issues have or haven't been addressed. Large or tricky changes may require several passes of review and changes.
Please see [the contribution instructions](http://edgeguides.rubyonrails.org/contributing_to_ruby_on_rails.html) for more information.
","1","2015-11-12T22:47:53Z"
"247582","19837","162249709","833383","arthurnn","what is the main use case for this?","1","2015-12-05T21:37:30Z"
"247583","19838","156310084","7468109","rails-bot","r? @schneems
(@rails-bot has picked a reviewer for you, use r? to override)","1","2015-11-13T03:07:12Z"
"247584","19838","156310191","5356517","yui-knk","Can we backport this or is there anything I can do to backport this?","1","2015-11-13T03:08:12Z"
"247585","19838","156310902","5356517","yui-knk","Sorry I will add CHANGELOG.md after CI end.","1","2015-11-13T03:14:58Z"
"247586","19838","156311034","59744","schneems","Awesome! Thanks. I'm not sure about backporting to 4.2 I would think it would be fine. cc/@rafaelfranca
Btw how did you find that issue? There's no activity on it for the last 2 days.
","1","2015-11-13T03:16:18Z"
"247587","19838","156312437","5356517","yui-knk","Add CHANGELOG and fix fixture :yum:
I found that issue by simply looking over new issues. Title of this issue is interesting, so I read issue :)","1","2015-11-13T03:30:38Z"
"247588","19838","156315340","59744","schneems","Thanks for the help :heart: ","1","2015-11-13T03:49:05Z"
"247589","19838","156315360","5356517","yui-knk","No problem :ghost: ","1","2015-11-13T03:49:22Z"
"247590","19838","156315500","5356517","yui-knk","Can I something to not forget we are discussing whether backporting is needed or not?","1","2015-11-13T03:51:03Z"
"247591","19838","156317659","59744","schneems","If you submit a pull request to the 4.x branch, that's probably the easiest way. We can talk about it there.","1","2015-11-13T04:14:05Z"
"247592","19838","156317874","5356517","yui-knk",":+1: :smile: ","1","2015-11-13T04:16:35Z"
"247593","19838","162250240","833383","arthurnn","backported this to 4-2-stable 00f8e7357b16ea28103f82431c6e31205565a1f0","1","2015-12-05T21:48:45Z"
"247594","19839","1639380","5470","Empact","/cc @josh","1","2011-07-24T00:49:25Z"
"247595","19840","156314915","7468109","rails-bot","r? @carlosantoniodasilva
(@rails-bot has picked a reviewer for you, use r? to override)","1","2015-11-13T03:44:46Z"
"247596","19840","156315294","59744","schneems","Thanks!","1","2015-11-13T03:48:30Z"
"247597","19841","156319588","7468109","rails-bot","r? @senny
(@rails-bot has picked a reviewer for you, use r? to override)","1","2015-11-13T04:37:37Z"
"247598","19841","156319589","7468109","rails-bot","<img src=""http://www.joshmatthews.net/warning.svg"" alt=""warning"" height=20> **Warning** <img src=""http://www.joshmatthews.net/warning.svg"" alt=""warning"" height=20>
* Pull requests are usually filed against the master branch for this repo, but this one is against 4-2-stable. Please double check that you specified the right target!","1","2015-11-13T04:37:37Z"
"247599","19841","158917616","179706","dabroz","Would love to see it in 4.2.","1","2015-11-23T12:18:16Z"
"247600","19841","160550676","5402","senny","I'm not sure we should change this in a patch release. I saw a lot of `if defined?(var)` code in templates. This could certainly mess with that.
I'm assigning @schneems as he merged the original PR maybe he has thoughts about a possible backport.","1","2015-11-30T08:05:45Z"
"247601","19841","160550693","5402","senny","r? @schneems ","1","2015-11-30T08:05:52Z"
"247602","19841","160681800","59744","schneems","Going to phone a friend on this one. I always get lost on backports cc/ @rafaelfranca ","1","2015-11-30T16:36:28Z"
"247603","19841","162264237","5356517","yui-knk","This was merged by [this commit](https://github.com/rails/rails/commit/00f8e7357b16ea28103f82431c6e31205565a1f0) to 4-2-stable.","1","2015-12-06T02:20:18Z"
"247604","19842","156320473","7468109","rails-bot","r? @rafaelfranca
(@rails-bot has picked a reviewer for you, use r? to override)","1","2015-11-13T04:45:05Z"
"247605","19842","156320474","7468109","rails-bot","<img src=""http://www.joshmatthews.net/warning.svg"" alt=""warning"" height=20> **Warning** <img src=""http://www.joshmatthews.net/warning.svg"" alt=""warning"" height=20>
* Pull requests are usually filed against the master branch for this repo, but this one is against 4-1-stable. Please double check that you specified the right target!","1","2015-11-13T04:45:05Z"
"247606","19842","162250241","833383","arthurnn","i dont think we are backporting fixes to 4.1 anymore. however I will indeed backport this to 4-2-stable.
Thanks
cc @schneems ","1","2015-12-05T21:48:49Z"
"247607","19843","156351252","7468109","rails-bot","Thanks for the pull request, and welcome! The Rails team is excited to review your changes, and you should hear from @carlosantoniodasilva (or someone else) soon.
If any changes to this PR are deemed necessary, please add them as extra commits. This ensures that the reviewer can see what has changed since they last reviewed the code. Due to the way GitHub handles out-of-date commits, this should also make it reasonably obvious what issues have or haven't been addressed. Large or tricky changes may require several passes of review and changes.
Please see [the contribution instructions](http://edgeguides.rubyonrails.org/contributing_to_ruby_on_rails.html) for more information.
","1","2015-11-13T07:18:29Z"
"247608","19843","160324077","833383","arthurnn","thanks
","1","2015-11-28T17:47:20Z"
"247609","19844","156380915","7468109","rails-bot","Thanks for the pull request, and welcome! The Rails team is excited to review your changes, and you should hear from @matthewd (or someone else) soon.
If any changes to this PR are deemed necessary, please add them as extra commits. This ensures that the reviewer can see what has changed since they last reviewed the code. Due to the way GitHub handles out-of-date commits, this should also make it reasonably obvious what issues have or haven't been addressed. Large or tricky changes may require several passes of review and changes.
Please see [the contribution instructions](http://edgeguides.rubyonrails.org/contributing_to_ruby_on_rails.html) for more information.
","1","2015-11-13T09:53:11Z"
"247610","19845","156574032","7468109","rails-bot","Thanks for the pull request, and welcome! The Rails team is excited to review your changes, and you should hear from @rafaelfranca (or someone else) soon.
If any changes to this PR are deemed necessary, please add them as extra commits. This ensures that the reviewer can see what has changed since they last reviewed the code. Due to the way GitHub handles out-of-date commits, this should also make it reasonably obvious what issues have or haven't been addressed. Large or tricky changes may require several passes of review and changes.
Please see [the contribution instructions](http://edgeguides.rubyonrails.org/contributing_to_ruby_on_rails.html) for more information.
","1","2015-11-13T22:14:48Z"
"247611","19846","156603067","7468109","rails-bot","Thanks for the pull request, and welcome! The Rails team is excited to review your changes, and you should hear from @pixeltrix (or someone else) soon.
If any changes to this PR are deemed necessary, please add them as extra commits. This ensures that the reviewer can see what has changed since they last reviewed the code. Due to the way GitHub handles out-of-date commits, this should also make it reasonably obvious what issues have or haven't been addressed. Large or tricky changes may require several passes of review and changes.
Please see [the contribution instructions](http://edgeguides.rubyonrails.org/contributing_to_ruby_on_rails.html) for more information.
","1","2015-11-14T01:13:25Z"
"247612","19846","156607987","42360","timbreitkreutz","@dharamgollapudi Did you happen to notice all the discussion in https://github.com/rails/rails/pull/21254 ? I was looking at doing something for #18878 also but got overwhelmed by the discussion there.","1","2015-11-14T02:01:24Z"
"247613","19846","156617335","737325","dharamgollapudi","@timbreitkreutz yes I did. My understanding per #18878 as well as follow up comments by @dhh and others in #21012, is that we needed a thin layer that proxies rake tasks, as we are not going to deprecate or move over all the existing tasks as they have dependencies. That is exactly what this pull request addresses, which handles all the rake tasks through rails cli.
Also the implementation in #21254 probably may have some performance penalties as it seems to define methods that call the underlying rake tasks. As rails cli is not a service, this will happen on every run.","1","2015-11-14T03:12:45Z"
"247614","19846","158757880","350807","kaspth","This isn't exactly what we're going for. In addition to funneling tasks through Rails, we want to deprecate running tasks with Rake (regardless of whether we use Rake to run tasks internally).
What we've been trying to do in #21254 is create a lightweight command structure to give us easier parameter parsing in the future. It's been taking longer than I've wanted, so I'm open to also move things along here. Thanks :+1: ","1","2015-11-22T12:48:03Z"
"247615","19846","163392679","350807","kaspth","@dharamgollapudi hey, since writing the above message I've changed my opinion and think your change is good. Let me know if you still want to work on this and I'll review it more in depth. Thanks! :heart:","1","2015-12-09T21:10:19Z"
"247616","19846","163447231","737325","dharamgollapudi","@kaspth I am a bit confused now.
Upon reviewing/following #22457, I thought that we are going in that direction.
I am more that happy to work on this, given a proper direction and input. ","1","2015-12-10T00:31:39Z"
"247617","19846","163537650","350807","kaspth","Sure, I can understand. We are generally going in that direction, but I don't think we will be there in time for Rails 5*. As such I think this is a great cover that gives leverage to work on the underpinnings without a deadline. I'll go through the PR now, ?.
* Partly because the command API doesn't hold its own yet, and I don't think it's worth it to just force all the tasks and existing commands over.","1","2015-12-10T08:58:48Z"
"247618","19846","163798285","737325","dharamgollapudi","@kaspth Implemented the changes per the feedback.
Let me know of any further changes.","1","2015-12-11T00:50:04Z"
"247619","19846","163798694","737325","dharamgollapudi","By running any of the following commands within the newly generated rails app:
`rails`
`rails -h`
`rails --help`
`rails help`
following is the output:
```
Usage: rails COMMAND [ARGS]
The most common rails commands are:
generate Generate new code (short-cut alias: ""g"")
console Start the Rails console (short-cut alias: ""c"")
server Start the Rails server (short-cut alias: ""s"")
test Run tests (short-cut alias: ""t"")
dbconsole Start a console for the database specified in config/database.yml
(short-cut alias: ""db"")
new Create a new Rails application. ""rails new my_app"" creates a
new application called MyApp in ""./my_app""
In addition to those, there are:
destroy Undo code generated with ""generate"" (short-cut alias: ""d"")
plugin new Generates skeleton for developing a Rails plugin
runner Run a piece of code in the application environment (short-cut alias: ""r"")
All commands can be run with -h (or --help) for more information.
In addition to those, you can run the rake tasks as rails commands:
rails about # List versions of all Rails frameworks and the environment
rails assets:clean[keep] # Remove old compiled assets
rails assets:clobber # Remove compiled assets
rails assets:environment # Load asset compile environment
rails assets:precompile # Compile all the assets named in config.assets.precompile
rails cache_digests:dependencies # Lookup first-level dependencies for TEMPLATE (like messages/show or comments/_comment.html)
rails cache_digests:nested_dependencies # Lookup nested dependencies for TEMPLATE (like messages/show or comments/_comment.html)
rails db:create # Creates the database from DATABASE_URL or config/database.yml for the current RAILS_ENV (use db:create:all to create all databases in the config)
rails db:drop # Drops the database from DATABASE_URL or config/database.yml for the current RAILS_ENV (use db:drop:all to drop all databases in the config)
rails db:fixtures:load # Loads fixtures into the current environment's database
rails db:migrate # Migrate the database (options: VERSION=x, VERBOSE=false, SCOPE=blog)
rails db:migrate:status # Display status of migrations
rails db:rollback # Rolls the schema back to the previous version (specify steps w/ STEP=n)
rails db:schema:cache:clear # Clears a db/schema_cache.dump file
rails db:schema:cache:dump # Creates a db/schema_cache.dump file
rails db:schema:dump # Creates a db/schema.rb file that is portable against any DB supported by Active Record
rails db:schema:load # Loads a schema.rb file into the database
rails db:seed # Loads the seed data from db/seeds.rb
rails db:setup # Creates the database, loads the schema, and initializes with the seed data (use db:reset to also drop the database first)
rails db:structure:dump # Dumps the database structure to db/structure.sql
rails db:structure:load # Recreates the databases from the structure.sql file
rails db:version # Retrieves the current schema version number
rails initializers # Print out all defined initializers in the order they are invoked by Rails
rails log:clear # Truncates all *.log files in log/ to zero bytes (specify which logs with LOGS=test,development)
rails middleware # Prints out your Rack middleware stack
rails notes # Enumerate all annotations (use notes:optimize, :fixme, :todo for focus)
rails notes:custom # Enumerate a custom annotation, specify with ANNOTATION=CUSTOM
rails rails:template # Applies the template supplied by LOCATION=(/path/to/template) or URL
rails rails:update # Update configs and some other initially generated files (or use just update:configs or update:bin)
rails restart # Restart app by touching tmp/restart.txt
rails riak:restart # Restart riak locally
rails riak:start # Start riak locally
rails riak:stop # Stop riak locally
rails routes # Print out all defined routes in match order, with names
rails secret # Generate a cryptographically secure secret key (this is typically used to generate a secret for cookie sessions)
rails stats # Report code statistics (KLOCs, etc) from the application or engine
rails test # Runs all tests in test folder
rails test:db # Run tests quickly, but also reset db
rails time:zones:all # Displays all time zones, also available: time:zones:us, time:zones:local -- filter with OFFSET parameter, e.g., OFFSET=-6
rails tmp:clear # Clear cache and socket files from tmp/ (narrow w/ tmp:cache:clear, tmp:sockets:clear)
rails tmp:create # Creates tmp directories for cache, sockets, and pids
```","1","2015-12-11T00:53:00Z"
"247620","19846","163941040","350807","kaspth","It seems we should just make the rake tasks flow straight with:
```
In addition to those, there are:
destroy Undo code generated with ""generate"" (short-cut alias: ""d"")
plugin new Generates skeleton for developing a Rails plugin
runner Run a piece of code in the application environment (short-cut alias: ""r"")
about List versions of all Rails frameworks and the environment
# Rest of the tasks...
All commands can be run with -h (or --help) for more information.
```
So a one space delimiter and then 3 spaces minimum. Note: this means we have to make the `HELP_MESSAGE` more dynamic.
","1","2015-12-11T13:53:15Z"
"247621","19846","164296649","350807","kaspth","@dharamgollapudi thanks so much for the work! We needed this in sooner, so I addressed my comment in the merge commit here: https://github.com/rails/rails/commit/3e65c3d3886336e9145438cdeacaf4ebec6a48b8.
Thanks again :heart:","1","2015-12-13T20:47:04Z"
"247622","19847","156635203","7468109","rails-bot","r? @rafaelfranca
(@rails-bot has picked a reviewer for you, use r? to override)","1","2015-11-14T05:17:25Z"
"247623","19847","156719703","10076","claudiob","Hello @Gaurav2728 and thanks for your support.
The new message you suggest is a little confusing to me, since both `test_assert_select_email` and test_assert_select_email_multipart` make assertions on the body of an e-mail.
Given the nature of the file you are editing, maybe the existing description is good enough?
Let me know what you think and if you can clarify what your intent is with this commit. Thanks!","1","2015-11-14T16:59:39Z"
"247624","19847","156723678","1284716","Gaurav2728","@claudiob `test_assert_select_email`, `test_assert_select_email_multipart` both do the same - make assertions on the body of an e-mail but in previous msg we need to look around the code/test what is intent !! New msg clearfy that both method testing `assertions on the body of an e-mail`
for more details any one can go through the edgeguide, you can check below -
","1","2015-11-14T17:39:44Z"
"247625","19847","156723794","350807","kaspth","Thanks, but it's a comment that divvies up the test file, not documentation. Therefore it's fine as is. :heart:","1","2015-11-14T17:41:01Z"
"247626","19849","156663670","7468109","rails-bot","r? @eileencodes
(@rails-bot has picked a reviewer for you, use r? to override)","1","2015-11-14T07:42:23Z"
"247627","19849","157894333","1080678","eileencodes","Hey @y-yagi thanks for the PR. Your commit says ""like the other generator"" - which other generator are you referencing?","1","2015-11-18T23:09:33Z"
"247628","19849","158351596","987638","y-yagi","Hi, @eileencodes.
`controller`, `helper`, `integration`, `mailer`, `model`, `scaffold`, and `view` has so as not to show.
https://github.com/rails/rails/blob/master/railties/lib/rails/generators.rb#L204..L210","1","2015-11-20T10:34:12Z"
"247629","19851","156748868","7468109","rails-bot","Thanks for the pull request, and welcome! The Rails team is excited to review your changes, and you should hear from @arthurnn (or someone else) soon.
If any changes to this PR are deemed necessary, please add them as extra commits. This ensures that the reviewer can see what has changed since they last reviewed the code. Due to the way GitHub handles out-of-date commits, this should also make it reasonably obvious what issues have or haven't been addressed. Large or tricky changes may require several passes of review and changes.
Please see [the contribution instructions](http://edgeguides.rubyonrails.org/contributing_to_ruby_on_rails.html) for more information.
","1","2015-11-14T22:00:09Z"
"247630","19851","156758672","1034","matthewd","I don't think this deprecation is right. We have existing precedent to prefer the capital over the tzdata-selected major city: see `""Brasilia"" => ""America/Sao_Paulo""`, for example.","1","2015-11-14T23:48:46Z"
"247631","19851","156856985","399968","kv109","@matthewd
- I've got PR with fix but without deprecation [here](https://github.com/rails/rails/compare/master...kv109:22233_without_deprecation?expand=1), if you decide that is the way to go.
- Maybe this is a good opportunity to do some cleanup and deprecate all non-standard timezone names? I'd be happy to check the list and create a proper PR.","1","2015-11-15T21:45:16Z"
"247632","19851","159319085","399968","kv109","PR without deprecation warning is already merged, so this one can be also closed probably - unless you want me to do this cleanup. If so, I'll close it and create a new PR.","1","2015-11-24T16:17:31Z"
"247633","19851","159375012","47848","rafaelfranca","Thanks","1","2015-11-24T19:07:20Z"
"247634","19852","156800630","7468109","rails-bot","r? @eileencodes
(@rails-bot has picked a reviewer for you, use r? to override)","1","2015-11-15T10:32:23Z"
"247635","19852","156816808","350807","kaspth","If it hasn't been in a public release we don't need a deprecation cycle. ?","1","2015-11-15T15:08:15Z"
"247636","19852","157029413","350807","kaspth","Thanks :smile:","1","2015-11-16T13:40:52Z"
"247637","19852","157031880","386234","yuki24","@kaspth Thanks!","1","2015-11-16T13:50:31Z"
"247638","19854","863973","9582","josevalim","Looks good to me.","1","2011-03-12T17:32:29Z"
"247639","19854","863977","9582","josevalim","Applied.","1","2011-03-12T17:33:50Z"
"247640","19855","4450184","6321","pixeltrix","Fixed by this [commit][1] to Journey
[1]: https://github.com/rails/journey/commit/b96ea6fb121ab63dc08c3b32c806f21dd6cb2258","1","2012-03-12T11:49:43Z"
"247641","19856","156816912","5356517","yui-knk","I am not sure:
* interface of `initialize_attributes`
Is it better to change second args of `initialize_attributes` to array of strings and remove`attributes.keys.map(&:to_s)` to `build_record`?
* test cases
I write a minimal test case, are there any test cases we should add too?
* backports is needed?","1","2015-11-15T15:10:22Z"
"247642","19856","156816963","5356517","yui-knk","r? @sgrif
because he is a assignee of #21893.","1","2015-11-15T15:11:40Z"
"247643","19856","156819495","1529387","sgrif","Can we put the huge comment in the commit message rather than a code comment?","1","2015-11-15T15:35:18Z"
"247644","19856","156819896","5356517","yui-knk","I wrote same contents for commit message and code comment, so I can remove code comment in `initialize_attributes` :)","1","2015-11-15T15:38:03Z"
"247645","19856","157055260","5356517","yui-knk","@sgrif updated!","1","2015-11-16T14:46:42Z"
"247646","19856","157414056","6321","pixeltrix","I'm not sure it is right to change this behaviour - for example the case given in #21893 is as follows:
``` ruby
class Post < ActiveRecord::Base
has_many :comments, -> { where(flag: true) }
end
```
``` irb
>> Post.create.comments.build(flag: false).flag
=> true
```
By changing it so that it can be overridden from build you can effectively add an object to the association in memory that wouldn't be there after reload - this is likely to lead to lots of head scratching.
@rafaelfranca @matthewd wdyt?
","1","2015-11-17T16:02:39Z"
"247647","19856","157560253","5356517","yui-knk","@pixeltrix even before this commit, there was [a test case](https://github.com/yui-knk/rails/blob/69f72223e82a4a4f16f16ad7abb36ebfd162a366/activerecord/test/cases/associations/has_many_associations_test.rb#L207) where default scope is overridden by arguments of `build`. I think this commit is not inconsistent with the test case.","1","2015-11-18T00:46:09Z"
"247648","19880","158626564","3241812","harrykiselev","@senny ? yep, sorry) thanks!","1","2015-11-21T10:48:06Z"
"247649","19881","158021154","350807","kaspth","Nice! Can you amend your commit to add the benchmark to the commit message? That way we don't lose that context later, or have to go to GitHub for it :smile:","1","2015-11-19T10:51:43Z"
"247650","19881","158102992","308724","tjschuck","@kaspth Done!","1","2015-11-19T16:10:00Z"
"247651","19881","158110586","350807","kaspth","Unrelated failure. Thanks! :+1: ","1","2015-11-19T16:33:19Z"
"247652","19882","157937153","7468109","rails-bot","Thanks for the pull request, and welcome! The Rails team is excited to review your changes, and you should hear from @pixeltrix (or someone else) soon.
If any changes to this PR are deemed necessary, please add them as extra commits. This ensures that the reviewer can see what has changed since they last reviewed the code. Due to the way GitHub handles out-of-date commits, this should also make it reasonably obvious what issues have or haven't been addressed. Large or tricky changes may require several passes of review and changes.
Please see [the contribution instructions](http://edgeguides.rubyonrails.org/contributing_to_ruby_on_rails.html) for more information.
","1","2015-11-19T03:26:00Z"
"247653","19883","1639973","108369","franckverrot","+1","1","2011-07-24T06:21:23Z"
"247654","19883","1640972","13026","titanous",":+1:","1","2011-07-24T14:51:08Z"
"247655","19883","1647314","13121","smasry","Closing pull request. Going to push to master instead of 3-1-stable.","1","2011-07-25T17:08:33Z"
"247656","19883","11873955","896502","joxxoxo","What if we have function with more than 2 operands? Like GREATEST(34.0,3.0,5.0,767.0), COALESCE(2, 4, 5). I think we need to improve this solution","1","2013-01-04T06:44:41Z"
"247657","19883","11883423","26328","carlosantoniodasilva","@joxxoxo We have a possible solution in #8225, please take a look there.","1","2013-01-04T13:56:45Z"
"247658","19883","11886984","896502","joxxoxo","@carlosantoniodasilva Also i've made #8741 for this.","1","2013-01-04T15:39:04Z"
"247659","19884","158048093","7468109","rails-bot","Thanks for the pull request, and welcome! The Rails team is excited to review your changes, and you should hear from @senny (or someone else) soon.
If any changes to this PR are deemed necessary, please add them as extra commits. This ensures that the reviewer can see what has changed since they last reviewed the code. Due to the way GitHub handles out-of-date commits, this should also make it reasonably obvious what issues have or haven't been addressed. Large or tricky changes may require several passes of review and changes.
Please see [the contribution instructions](http://edgeguides.rubyonrails.org/contributing_to_ruby_on_rails.html) for more information.
","1","2015-11-19T12:52:27Z"
"247660","19884","158058326","5402","senny","@rbr thank you :yellow_heart: ","1","2015-11-19T13:35:33Z"
"247661","19885","158052329","7468109","rails-bot","Thanks for the pull request, and welcome! The Rails team is excited to review your changes, and you should hear from @senny (or someone else) soon.
If any changes to this PR are deemed necessary, please add them as extra commits. This ensures that the reviewer can see what has changed since they last reviewed the code. Due to the way GitHub handles out-of-date commits, this should also make it reasonably obvious what issues have or haven't been addressed. Large or tricky changes may require several passes of review and changes.
Please see [the contribution instructions](http://edgeguides.rubyonrails.org/contributing_to_ruby_on_rails.html) for more information.
","1","2015-11-19T13:06:06Z"
"247662","19886","158062310","7468109","rails-bot","Thanks for the pull request, and welcome! The Rails team is excited to review your changes, and you should hear from @eileencodes (or someone else) soon.
If any changes to this PR are deemed necessary, please add them as extra commits. This ensures that the reviewer can see what has changed since they last reviewed the code. Due to the way GitHub handles out-of-date commits, this should also make it reasonably obvious what issues have or haven't been addressed. Large or tricky changes may require several passes of review and changes.
Please see [the contribution instructions](http://edgeguides.rubyonrails.org/contributing_to_ruby_on_rails.html) for more information.
","1","2015-11-19T13:53:58Z"
"247663","19886","158064472","1080678","eileencodes","Hi @jeffminnear thanks for the PR! Here are a couple of changes I think would make this better:
1) Add the SQL for the examples you added
2) Put the note about how `unscoped` and `scope` don't work together so you need to use a block. The change you made doesn't make it clear that you use a block when you need to scope and unscope.
3) Add `[ci skip]` to your commit message (for guides and documentation PR's) so that travis doesn't run.
Thanks!","1","2015-11-19T14:01:30Z"
"247664","19886","158074164","15134766","jeffminnear",">2) Put the note about how unscoped and scope don't work together so you need to use a block. The change you made doesn't make it clear that you use a block when you need to scope and unscope.
It actually seems that they do work together now. I have tested it in the Rails console written as both a scope and a class method, and it appears to be working fine.","1","2015-11-19T14:33:50Z"
"247665","19886","158673043","31698","eliotsykes","Confirmed `unscoped` chained with a named scope working, e.g.
```ruby
# Seen working
Subscription.expired.unscoped
Subscription.unscoped.expired
```","1","2015-11-21T19:10:43Z"
"247666","19886","159104678","1080678","eileencodes","Ok, thanks for checking the scoping! Can you squash your commits into one? ","1","2015-11-23T23:36:53Z"
"247667","19887","158152970","7468109","rails-bot","Thanks for the pull request, and welcome! The Rails team is excited to review your changes, and you should hear from @carlosantoniodasilva (or someone else) soon.
If any changes to this PR are deemed necessary, please add them as extra commits. This ensures that the reviewer can see what has changed since they last reviewed the code. Due to the way GitHub handles out-of-date commits, this should also make it reasonably obvious what issues have or haven't been addressed. Large or tricky changes may require several passes of review and changes.
Please see [the contribution instructions](http://edgeguides.rubyonrails.org/contributing_to_ruby_on_rails.html) for more information.
","1","2015-11-19T18:47:47Z"
"247668","19887","158660520","12844","masterkain","related https://github.com/rails/rails/issues/22346","1","2015-11-21T16:30:17Z"
"247669","19887","160653350","5402","senny","r? @senny","1","2015-11-30T14:58:20Z"
"247670","19887","160680455","5402","senny","@GUI thank you for the fix. I did a backport to `4-2-stable`.","1","2015-11-30T16:31:28Z"
"247671","19887","160689153","12112","GUI","Thanks for the merge and backport!","1","2015-11-30T16:57:39Z"
"247672","19888","158219132","7468109","rails-bot","r? @sgrif
(@rails-bot has picked a reviewer for you, use r? to override)","1","2015-11-19T22:22:17Z"
"247673","19888","158574403","5356517","yui-knk","@kamipo Thanks for your follow up :bow: :heart_eyes: ","1","2015-11-21T01:53:55Z"
"247674","19889","158223667","7468109","rails-bot","Thanks for the pull request, and welcome! The Rails team is excited to review your changes, and you should hear from @pixeltrix (or someone else) soon.
If any changes to this PR are deemed necessary, please add them as extra commits. This ensures that the reviewer can see what has changed since they last reviewed the code. Due to the way GitHub handles out-of-date commits, this should also make it reasonably obvious what issues have or haven't been addressed. Large or tricky changes may require several passes of review and changes.
Please see [the contribution instructions](http://edgeguides.rubyonrails.org/contributing_to_ruby_on_rails.html) for more information.
","1","2015-11-19T22:41:32Z"
"247675","19889","158231113","399968","kv109","Looks like tests are failing randomly? I've got definitely not related `Errno::EBADF: Bad file descriptor @ fptr_finalize` and so did @jeffminear in his [PR](https://github.com/rails/rails/pull/22343).","1","2015-11-19T23:19:00Z"
"247676","19889","159255032","6321","pixeltrix","@kv109 thanks - we know about the random failing test.","1","2015-11-24T12:34:55Z"
"247677","19890","158245475","7468109","rails-bot","Thanks for the pull request, and welcome! The Rails team is excited to review your changes, and you should hear from @eileencodes (or someone else) soon.
If any changes to this PR are deemed necessary, please add them as extra commits. This ensures that the reviewer can see what has changed since they last reviewed the code. Due to the way GitHub handles out-of-date commits, this should also make it reasonably obvious what issues have or haven't been addressed. Large or tricky changes may require several passes of review and changes.
Please see [the contribution instructions](http://edgeguides.rubyonrails.org/contributing_to_ruby_on_rails.html) for more information.
","1","2015-11-20T00:48:14Z"
"247678","19890","158246036","3099915","myrridin","I just noticed that the PR includes the merge I did back from rails core to my fork. I found out afterwards that adding rails as a remote would have worked better. Is there a good way to fix this, or should I recreate the branch/PR?","1","2015-11-20T00:52:02Z"
"247679","19890","158249408","1034","matthewd","Thanks, but we prefer not to add new things to ActiveSupport unless they're used in the framework itself.","1","2015-11-20T01:16:35Z"
"247680","19890","158249846","3099915","myrridin","I understand. Thanks for letting me know. I'll keep that in mind for future PRs :smile:","1","2015-11-20T01:19:51Z"
"247681","19892","158269961","7468109","rails-bot","Thanks for the pull request, and welcome! The Rails team is excited to review your changes, and you should hear from @arthurnn (or someone else) soon.
If any changes to this PR are deemed necessary, please add them as extra commits. This ensures that the reviewer can see what has changed since they last reviewed the code. Due to the way GitHub handles out-of-date commits, this should also make it reasonably obvious what issues have or haven't been addressed. Large or tricky changes may require several passes of review and changes.
Please see [the contribution instructions](http://edgeguides.rubyonrails.org/contributing_to_ruby_on_rails.html) for more information.
","1","2015-11-20T03:38:13Z"
"247682","19892","158313545","47848","rafaelfranca","> Sometimes options[:wait] can be a string
When? Is not the programer that is passing a string to it? If that is the case we should not support it. That argument expects a number.","1","2015-11-20T07:46:38Z"
"247683","19892","158323088","913958","anvyzhang","I read that hash from config, and yeah I can ensure that hash value to be a number, but maybe ```to_f``` here could be just better and no side effect.
Any way this is not a big issue, and I can check that in my config.","1","2015-11-20T08:34:00Z"
"247684","19892","158576606","913958","anvyzhang","@rafaelfranca So what do you think.","1","2015-11-21T02:03:39Z"
"247685","19893","158316338","7468109","rails-bot","r? @schneems
(@rails-bot has picked a reviewer for you, use r? to override)","1","2015-11-20T08:02:59Z"
"247686","19893","158395163","59744","schneems","r? @sgrif
We probably need your mysql2 branch to be merged into the official mysql2 gem before moving forwards","1","2015-11-20T13:05:00Z"
"247687","19893","158407523","1529387","sgrif","Yeah, this isn't actionable as is. I'm going to close just because there's 0 chance of this being merged right now. Please reopen one you've merged into MySQL 2","1","2015-11-20T13:49:40Z"
"247688","19893","158691726","39406","sodabrew","I'm planning to have the next mysql2 gem 0.4.2 released before US Thanksgiving next week, so if there's any possibility of incorporating this into the next Rails 4.2.5 release, that would be very exciting.","1","2015-11-22T00:00:10Z"
"247689","19893","159734201","39406","sodabrew","Here we go! mysql2 0.4.2 is released! Please let me know if I can help this PR in any way!","1","2015-11-25T21:22:22Z"
"247690","19893","159743347","1529387","sgrif","@kamipo If you want to update and open a new PR, that'd be great.
@sodabrew This won't make it into 4.2.x, we don't add new features in patch releases.","1","2015-11-25T22:12:55Z"
"247691","19893","159812200","12642","kamipo","Reopened at #22415.","1","2015-11-26T05:55:44Z"
"247692","19894","158352266","7468109","rails-bot","Thanks for the pull request, and welcome! The Rails team is excited to review your changes, and you should hear from @senny (or someone else) soon.
If any changes to this PR are deemed necessary, please add them as extra commits. This ensures that the reviewer can see what has changed since they last reviewed the code. Due to the way GitHub handles out-of-date commits, this should also make it reasonably obvious what issues have or haven't been addressed. Large or tricky changes may require several passes of review and changes.
Please see [the contribution instructions](http://edgeguides.rubyonrails.org/contributing_to_ruby_on_rails.html) for more information.
","1","2015-11-20T10:38:17Z"
"247693","19895","158389372","7468109","rails-bot","r? @carlosantoniodasilva
(@rails-bot has picked a reviewer for you, use r? to override)","1","2015-11-20T12:49:11Z"
"247694","19895","158409655","59744","schneems","Tests failed","1","2015-11-20T14:00:47Z"
"247695","19895","158473800","323028","nishantmodak","@rafaelfranca Fixed review comments
@schneems The failure is unrelated to this commit, but stems from earlier ones in activesupport","1","2015-11-20T17:53:50Z"
"247696","19896","158447762","7468109","rails-bot","r? @eileencodes
(@rails-bot has picked a reviewer for you, use r? to override)","1","2015-11-20T16:17:13Z"
"247697","19897","1642111","11994","cldwalker","@guilleiguaran Updated tests to use existing model. Personally, I don't see it as a good testing practice to be using one model for multiple unrelated tests. Leads to unnecessary coupling and hard to find bugs","1","2011-07-24T20:39:27Z"
"247698","19897","1642134","160941","guilleiguaran","I agree with you but we must try to avoid defining extra models since we already have tonnes of them and if every patch add a new model it would quickly get out of hand.
Your code and tests looks great, thanks!!!","1","2011-07-24T20:47:02Z"
"247699","19898","158575875","7468109","rails-bot","r? @kaspth
(@rails-bot has picked a reviewer for you, use r? to override)","1","2015-11-21T02:01:06Z"
"247700","19898","158577537","833383","arthurnn","I think this is a good step. I would like to see, maybe in a near future, the memcached returning some kinda object, so who is calling can decide what is the success and error path. That would make easier to implement resilient memcached calls.
cc @jnunemaker because I know you ❤️ those conversations.","1","2015-11-21T02:19:37Z"
"247701","19898","158636724","2420363","nonmadden","Cool!","1","2015-11-21T13:06:13Z"
"247702","19898","160777054","833383","arthurnn","thanks","1","2015-11-30T22:07:16Z"
"247703","19899","158577682","7468109","rails-bot","r? @senny
(@rails-bot has picked a reviewer for you, use r? to override)","1","2015-11-21T02:22:47Z"
"247704","19901","158625510","7468109","rails-bot","Thanks for the pull request, and welcome! The Rails team is excited to review your changes, and you should hear from @kaspth (or someone else) soon.
If any changes to this PR are deemed necessary, please add them as extra commits. This ensures that the reviewer can see what has changed since they last reviewed the code. Due to the way GitHub handles out-of-date commits, this should also make it reasonably obvious what issues have or haven't been addressed. Large or tricky changes may require several passes of review and changes.
Please see [the contribution instructions](http://edgeguides.rubyonrails.org/contributing_to_ruby_on_rails.html) for more information.
","1","2015-11-21T10:28:53Z"
"247705","19903","158661367","7468109","rails-bot","r? @chancancode
(@rails-bot has picked a reviewer for you, use r? to override)","1","2015-11-21T16:45:23Z"
"247706","19903","160582831","5402","senny","I'm a bit hesitant to adding documentation to the guides that is almost the same as what we have in the API docs. I know that some guides have a structure that encourages this but I'd rather give a brief intro in prose and maybe one example and then hand the user off to the API. Otherwise parts will get out of sync quickly. Also improvements made on one end won't be carried over to the other etc.","1","2015-11-30T10:02:30Z"
"247707","19903","162843564","7011819","andreynering","@senny Thank you for reviewing. I just updated it.","1","2015-12-08T10:35:30Z"
"247708","19904","158679951","7468109","rails-bot","Thanks for the pull request, and welcome! The Rails team is excited to review your changes, and you should hear from @matthewd (or someone else) soon.
If any changes to this PR are deemed necessary, please add them as extra commits. This ensures that the reviewer can see what has changed since they last reviewed the code. Due to the way GitHub handles out-of-date commits, this should also make it reasonably obvious what issues have or haven't been addressed. Large or tricky changes may require several passes of review and changes.
Please see [the contribution instructions](http://edgeguides.rubyonrails.org/contributing_to_ruby_on_rails.html) for more information.
","1","2015-11-21T20:49:14Z"
"247709","19905","1641926","22501","jasonnoble","Maybe we should add a configuration option for this? config.routing.log_redirect or something?","1","2011-07-24T19:40:46Z"
"247710","19905","1643175","479","jackdempsey","Yeah, I could imagine that being useful and more the correct way to go. Course I can see the ""will grow unmanageable/too numerous over time"" argument coming as well. I guess it depends on how configurable people want Rails to get. I think this helps often enough that I'd vote for the config option. ","1","2011-07-25T02:50:59Z"
"247711","19905","1643178","1637","josephgrossberg","No option -- convention over configuration! If you're logging debug-level statements, this is useful info.","1","2011-07-25T02:51:35Z"
"247712","19905","1645260","22501","jasonnoble","yeah, but debug is on by default in development, so if you have a lot of redirects, your development log could be more bloated.
I like the config option because I can choose to turn debugging redirect_to on, when I'm having a problem with redirect_to.","1","2011-07-25T12:17:43Z"
"247713","19905","5398476","651597","isaacsanders","@jackdempsey Is this still an issue?","1","2012-04-28T17:26:21Z"
"247714","19905","5409637","479","jackdempsey","hey @isaacsanders , yes this is still valid. It's grown to be indispensable to me. I've never felt like it was bloating the logs, but would happy to take direction from core as to enabling/disabling it via config, or just always adding it. ","1","2012-04-29T23:03:36Z"
"247715","19905","5410982","651597","isaacsanders","@josevalim @tenderlove Thoughts?","1","2012-04-30T02:24:47Z"
"247716","19905","5412032","22501","jasonnoble","I still vote the the config option, but now leaning towards having it enabled by default (in development only maybe?).","1","2012-04-30T05:23:12Z"
"247717","19905","5412732","9582","josevalim","There is no need for config option, although please check as well if logger is already at debug level `if logger && logger.debug?` so we don't calculate it unnecessarily.
@tenderlove what do you think about adding logger.debug { }, logger.info { } and so forth? Useful when generating the messages are expensive.","1","2012-04-30T07:03:44Z"
"247718","19905","5417518","22501","jasonnoble","+1 for logger.debug { }","1","2012-04-30T13:44:44Z"
"247719","19905","5418164","22501","jasonnoble","https://github.com/ruby/ruby/pull/123 First Ruby pull request, so no idea what else I need to do to get that accepted. Probably add some for .info and so forth. Thoughts @tenderlove?","1","2012-04-30T14:15:02Z"
"247720","19905","5681020","27786","steveklabnik","@jasonnoble just as a general note, if you say "" ruby/ruby#123 "" it will link to the pull or issue properly. ;) Not that what you did was bad, it's just a sweet GitHub feature.","1","2012-05-14T00:55:08Z"
"247721","19905","5681775","22501","jasonnoble","Thanks @steveklabnik ","1","2012-05-14T02:43:13Z"
"247722","19905","5754575","3124","tenderlove","`logger.debug { .. }` already exists on the default logger that ships with Ruby. If it doesn't work in rails, we should consider it a bug:
```
irb(main):001:0> require 'logger'
=> true
irb(main):002:0> x = Logger.new $stdout
=> #<Logger:0x007fa2211ae490 @progname=nil, @level=0, @default_formatter=#<Logger::Formatter:0x007fa2211ae468 @datetime_format=nil>, @formatter=nil, @logdev=#<Logger::LogDevice:0x007fa2211ae418 @shift_size=nil, @shift_age=nil, @filename=nil, @dev=#<IO:<STDOUT>>, @mutex=#<Logger::LogDevice::LogDeviceMutex:0x007fa2211ae3f0 @mon_owner=nil, @mon_count=0, @mon_mutex=#<Mutex:0x007fa2211ae3a0>>>>
irb(main):003:0> x.level = Logger::INFO
=> 1
irb(main):004:0> x.info { ""this is info"" }
I, [2012-05-16T16:12:13.824884 #3359] INFO -- : this is info
=> true
irb(main):005:0> x.debug { ""this is debug"" }
=> true
irb(main):006:0>
```
Just switch to the block form and I'll merge this in. :+1:","1","2012-05-16T23:13:05Z"
"247723","19905","5754850","651597","isaacsanders","Is the log supposed to log all levels above or below? Cause you were on INFO, not DEBUG.
On May 16, 2012, at 6:13 PM, Aaron Patterson<reply@reply.github.com> wrote:
> `logger.debug { .. }` already exists on the default logger that ships with Ruby. If it doesn't work in rails, we should consider it a bug:
>
> ```
> irb(main):001:0> require 'logger'
> => true
> irb(main):002:0> x = Logger.new $stdout
> => #<Logger:0x007fa2211ae490 @progname=nil, @level=0, @default_formatter=#<Logger::Formatter:0x007fa2211ae468 @datetime_format=nil>, @formatter=nil, @logdev=#<Logger::LogDevice:0x007fa2211ae418 @shift_size=nil, @shift_age=nil, @filename=nil, @dev=#<IO:<STDOUT>>, @mutex=#<Logger::LogDevice::LogDeviceMutex:0x007fa2211ae3f0 @mon_owner=nil, @mon_count=0, @mon_mutex=#<Mutex:0x007fa2211ae3a0>>>>
> irb(main):003:0> x.level = Logger::INFO
> => 1
> irb(main):004:0> x.info { ""this is info"" }
> I, [2012-05-16T16:12:13.824884 #3359] INFO -- : this is info
> => true
> irb(main):005:0> x.debug { ""this is debug"" }
> => true
> irb(main):006:0>
> ```
>
> Just switch to the block form and I'll merge this in. :+1:
>
> ---
> Reply to this email directly or view it on GitHub:
> https://github.com/rails/rails/pull/2237#issuecomment-5754575","1","2012-05-16T23:30:21Z"
"247724","19905","5754906","479","jackdempsey","@isaacsanders all levels below.
I've just changed to use block format, squashed commit and force pushed.","1","2012-05-16T23:34:23Z"
"247725","19905","5754910","3124","tenderlove","@isaacsanders greater than or equal to the level.","1","2012-05-16T23:34:47Z"
"247726","19905","5755066","651597","isaacsanders","Thanks :D
On May 16, 2012, at 6:34 PM, Aaron Patterson<reply@reply.github.com> wrote:
> @isaacsanders greater than or equal to the level.
>
> ---
> Reply to this email directly or view it on GitHub:
> https://github.com/rails/rails/pull/2237#issuecomment-5754910","1","2012-05-16T23:44:18Z"
"247727","19905","5756452","479","jackdempsey","I love how my answer is exactly opposite tenderlove...though I guess it depends on what's 'above' vs 'below'?
thx for the merge kind sir.","1","2012-05-17T01:38:11Z"
"247728","19905","5756847","1637","josephgrossberg","LOL @ @jackdempsey ","1","2012-05-17T02:16:10Z"
"247729","19905","5757626","3948","arunagw","After this PR build started failing http://travis-ci.org/#!/rails/rails/jobs/1350865
@jackdempsey can you look into this?","1","2012-05-17T03:39:12Z"
"247730","19905","5758053","479","jackdempsey","@arunagw definitely. Just verified @tenderlove's example works fine here too. I guess debug works differently inside Rails? Given your comment ""If it doesn't work in rails, we should consider it a bug:"", it looks like this might be a bug :-)
Will go take a look and see what I find. ","1","2012-05-17T04:26:16Z"
"247731","19905","5758120","479","jackdempsey","Looking at the definition of ActiveSupport::LogSubscriber::TestHelper::MockLogger and it's method missing definition:
64 def method_missing(level, message)
65 @logged[level] << message
66 end
at first glance I'd guess that could be it. So as @tenderlove mentioned, perhaps this needs to be patched to accept this type of block passing call?","1","2012-05-17T04:34:06Z"
"247732","19905","5758192","18524","bcardarella","@jackdempsey I patched in https://github.com/rails/rails/pull/6360","1","2012-05-17T04:45:19Z"
"247733","19905","5758217","479","jackdempsey","@bcardarella definitely gets it done. Only thought I had was that allowing it to actually use the block might be good?
Something like:
```ruby
64 def method_missing(level, message)
65 if block_given?
66 @logged[level] << yield
67 else
68 @logged[level] << message
69 end
70 end
```","1","2012-05-17T04:47:38Z"
"247734","19905","5758252","18524","bcardarella","@jackdempsey it's only a MockLogger so my vote would be it being unnecessary. It would make sense to inherit from the `MockLogger` into a new logger class and overload the debug method to do what you want.","1","2012-05-17T04:52:39Z"
"247735","19905","5758261","479","jackdempsey","cool, don't feel strongly enough to put more time on it. i think the simple empty debut is certainly good enough. thanks for the patch!","1","2012-05-17T04:54:16Z"
"247736","19905","5759323","9582","josevalim","Although it is a mock logger, it is a public API and meant to be used by plugins, gems and etc. So i just went ahead and implemented yield, as @jackdempsey proposed.","1","2012-05-17T06:53:31Z"
"247737","19905","5765712","47848","rafaelfranca","I did a quick fix for it in 109899ec8e4801c13e2c887e884768e06ac66638. See if it is enough ","1","2012-05-17T14:59:04Z"
"247738","19926","159392779","199","jeremy","✨?⭐️✨","1","2015-11-24T20:16:35Z"
"247739","19927","864655","52642","spastorino","Pushed","1","2011-03-12T23:10:43Z"
"247740","19928","159379422","7468109","rails-bot","Thanks for the pull request, and welcome! The Rails team is excited to review your changes, and you should hear from @sgrif (or someone else) soon.
If any changes to this PR are deemed necessary, please add them as extra commits. This ensures that the reviewer can see what has changed since they last reviewed the code. Due to the way GitHub handles out-of-date commits, this should also make it reasonably obvious what issues have or haven't been addressed. Large or tricky changes may require several passes of review and changes.
Please see [the contribution instructions](http://edgeguides.rubyonrails.org/contributing_to_ruby_on_rails.html) for more information.
","1","2015-11-24T19:23:41Z"
"247741","19928","159403811","1529387","sgrif","https://github.com/rails/rails/pull/20933#issuecomment-122590487","1","2015-11-24T21:01:10Z"
"247742","19928","159407567","364548","siadat","Okay, thanks! :smile: ","1","2015-11-24T21:17:11Z"
"247743","19929","159449977","7468109","rails-bot","r? @kaspth
(@rails-bot has picked a reviewer for you, use r? to override)","1","2015-11-25T00:47:37Z"
"247744","19929","159683905","632942","cllns","@kaspth fixed!","1","2015-11-25T17:39:23Z"
"247745","19929","159684673","193936","simi","Actually this PR changes also (only some!) units in CSS.","1","2015-11-25T17:42:50Z"
"247746","19929","159705681","350807","kaspth","@simi it didn't when I first looked at it :wink:
Looks good, but will let the build run first. Thanks :heart:","1","2015-11-25T19:18:40Z"
"247747","19929","159712427","632942","cllns","Woo, thanks :) ","1","2015-11-25T19:45:57Z"
"247748","19930","159482570","7468109","rails-bot","Thanks for the pull request, and welcome! The Rails team is excited to review your changes, and you should hear from @rafaelfranca (or someone else) soon.
If any changes to this PR are deemed necessary, please add them as extra commits. This ensures that the reviewer can see what has changed since they last reviewed the code. Due to the way GitHub handles out-of-date commits, this should also make it reasonably obvious what issues have or haven't been addressed. Large or tricky changes may require several passes of review and changes.
Please see [the contribution instructions](http://edgeguides.rubyonrails.org/contributing_to_ruby_on_rails.html) for more information.
","1","2015-11-25T03:49:48Z"
"247749","19930","159582903","6321","pixeltrix","@mastahyeti yes, deleting `PATH_INFO` before or after a call to process can break tests as I outlined in #13851. Since controller tests haven't historically been processed by the full stack people have often configured environment variables to make things work and this makes them very susceptible to failing when we tinker with this behaviour.
Given that we're suggesting people move away from controller tests to integration tests because we've made them faster than controller tests in Rails 5 I'm not sure what the best thing to do here is. One option is to remove support for setting `PATH_INFO` in controller tests and always use the generated path, however we'd need to go through a deprecation phase for that.","1","2015-11-25T11:45:21Z"
"247750","19930","159635798","1144197","mastahyeti","Oh, damn. I wish I found that issue earlier last night :smile:. ","1","2015-11-25T15:09:39Z"
"247751","19930","160652153","1144197","mastahyeti","I'm going to close this, as it isn't a great solution to the problem and the problem is well documented in https://github.com/rails/rails/issues/13851.","1","2015-11-30T14:53:22Z"
"247752","19931","159587390","6321","pixeltrix","@gwincr11 thanks for your contribution, but I think in this case I'd rather not expand the docs because the only interaction a Rails developer should have day-to-day with this code is by calling `rails g migration MigrationName` - they shouldn't be inheriting from this class and I'd rather we `:nodoc:` it instead..","1","2015-11-25T11:56:48Z"
"247753","19932","159494236","7468109","rails-bot","Thanks for the pull request, and welcome! The Rails team is excited to review your changes, and you should hear from @matthewd (or someone else) soon.
If any changes to this PR are deemed necessary, please add them as extra commits. This ensures that the reviewer can see what has changed since they last reviewed the code. Due to the way GitHub handles out-of-date commits, this should also make it reasonably obvious what issues have or haven't been addressed. Large or tricky changes may require several passes of review and changes.
Please see [the contribution instructions](http://edgeguides.rubyonrails.org/contributing_to_ruby_on_rails.html) for more information.
","1","2015-11-25T05:15:55Z"
"247754","19932","159495910","1034","matthewd","The method gets called both with and without the delegation; when called normally, the existing version is correct... so the problem is really in the delegate, rather than these methods themselves.
I think we need to sacrifice the elegance of the catch-all delegation, so the relevant methods can be specifically constructed to elide themselves from `caller`.","1","2015-11-25T05:32:54Z"
"247755","19932","159737014","19339","jrafanie","Thanks @matthewd, I'll have to see if I can fix it differently.","1","2015-11-25T21:38:59Z"
"247756","19933","159668132","7468109","rails-bot","Thanks for the pull request, and welcome! The Rails team is excited to review your changes, and you should hear from @matthewd (or someone else) soon.
If any changes to this PR are deemed necessary, please add them as extra commits. This ensures that the reviewer can see what has changed since they last reviewed the code. Due to the way GitHub handles out-of-date commits, this should also make it reasonably obvious what issues have or haven't been addressed. Large or tricky changes may require several passes of review and changes.
Please see [the contribution instructions](http://edgeguides.rubyonrails.org/contributing_to_ruby_on_rails.html) for more information.
","1","2015-11-25T16:46:40Z"
"247757","19933","159668927","117410","jippeholwerda","Is this something that can be backported to the 4-2-stable branch?","1","2015-11-25T16:49:53Z"
"247758","19933","159809257","1034","matthewd","The existing code seems consistent with other uses of `quoted_table_name`, to mean.. the quoted table name. Why does only this one need to change?","1","2015-11-26T05:26:20Z"
"247759","19933","159841091","6321","pixeltrix","@matthewd I think it's because you can't use `server.database.table` in `ORDER BY` clauses - is this correct @jippeholwerda ?","1","2015-11-26T07:59:20Z"
"247760","19933","159841335","6321","pixeltrix","@jippeholwerda are there other places where fully qualified identifiers can't be used? Are they only allowed in `FROM` and `JOIN` clauses?","1","2015-11-26T08:01:15Z"
"247761","19933","159842457","117410","jippeholwerda","@matthewd, @pixeltrix Indeed `server.database.table` cannot be used in `ORDER BY` clauses. Also not allowed in `SELECT` clause projections. So: `SELECT table.column FROM server.database.table` is correct, but `SELECT server.database.table.column FROM server.database.table` is not.
However, @matthewd is correct in that there are other places in the code (for instance `reverse_sql_order`) where the same change should have to be made.
I'll see if I can find and fix all cases.","1","2015-11-26T08:08:28Z"
"247762","19933","159843468","6321","pixeltrix","@jippeholwerda since FQIs are only allowed in FROM and JOIN clauses might it be easier to special case those rather than try to fix all the other places where we use `quoted_table_name` ?","1","2015-11-26T08:14:28Z"
"247763","19933","159925563","117410","jippeholwerda","@pixeltrix This is certainly possible. My initial reasoning was that having to use FQIs is a property of the model, and should be configured there. In that case, using the `table_name` is probably the only viable option?
However, I guess it could also be configured on the adapter level, meaning all models using that same connection are using FQIs. I think that makes sense.
I'll discuss this solution with the maintainer of the activerecord-sqlserver-adapter.
I guess in that case, this pull request is not strictly necessary anymore. However, I still feel like we should let Arel generate the SQL of the order clauses instead of hardcoding it in AR...","1","2015-11-26T14:17:17Z"
"247764","19963","161067897","350807","kaspth","@rafaelfranca wait, it isn't deprecated? ?","1","2015-12-01T19:18:52Z"
"247765","19963","161070163","47848","rafaelfranca","Seems not https://github.com/rails/rails/pull/22460#issuecomment-160953749","1","2015-12-01T19:27:15Z"
"247766","19963","161070886","350807","kaspth","Woah","1","2015-12-01T19:30:15Z"
"247767","19963","161168427","10076","claudiob","As [commented here](https://github.com/rails/rails/blob/master/activerecord/lib/active_record/callbacks.rb#L178-L191):
```ruby
# The callback macros usually accept a symbol for the method they're supposed to run, but you can also
# pass a ""method string"", which will then be evaluated within the binding of the callback. Example:
#
# class Topic < ActiveRecord::Base
# before_destroy 'self.class.delete_all ""parent_id = #{id}""'
# end
#
# Notice that single quotes (') are used so the <tt>#{id}</tt> part isn't evaluated until the callback
# is triggered. Also note that these inline callbacks can be stacked just like the regular ones:
#
# class Topic < ActiveRecord::Base
# before_destroy 'self.class.delete_all ""parent_id = #{id}""',
# 'puts ""Evaluated after parents are destroyed""'
# end
#
```","1","2015-12-02T03:29:03Z"
"247768","19963","161169239","10076","claudiob","Which, I believe, comes from this code in [ActiveSupport::Callbacks](https://github.com/rails/rails/blob/master/activesupport/lib/active_support/callbacks.rb#L363-L378):
```ruby
# Filters support:
#
# Symbols:: A method to call.
# Strings:: Some content to evaluate.
# Procs:: A proc to call with the object.
# Objects:: An object with a <tt>before_foo</tt> method on it to call.
#
# All of these objects are converted into a lambda and handled
# the same after this point.
def make_lambda(filter)
case filter
when Symbol
lambda { |target, _, &blk| target.send filter, &blk }
when String
l = eval ""lambda { |value| #{filter} }""
lambda { |target, value| target.instance_exec(value, &l) }
```","1","2015-12-02T03:31:44Z"
"247769","19963","161172450","5356517","yui-knk","Can we deprecate ""string callback"" at ActiveSupport?
Or only ActiveRecord?","1","2015-12-02T03:49:52Z"
"247770","19963","161180441","47848","rafaelfranca","If we can, from everything.","1","2015-12-02T04:53:54Z"
"247771","19963","165163938","5356517","yui-knk","Close this in favor of #22598 .","1","2015-12-16T16:23:48Z"
"247772","19964","160974310","7468109","rails-bot","Thanks for the pull request, and welcome! The Rails team is excited to review your changes, and you should hear from @sgrif (or someone else) soon.
If any changes to this PR are deemed necessary, please add them as extra commits. This ensures that the reviewer can see what has changed since they last reviewed the code. Due to the way GitHub handles out-of-date commits, this should also make it reasonably obvious what issues have or haven't been addressed. Large or tricky changes may require several passes of review and changes.
Please see [the contribution instructions](http://edgeguides.rubyonrails.org/contributing_to_ruby_on_rails.html) for more information.
","1","2015-12-01T13:45:59Z"
"247773","19964","164454101","1529387","sgrif","Closing in favor of #22500","1","2015-12-14T14:41:36Z"
"247774","19965","161010433","7468109","rails-bot","Thanks for the pull request, and welcome! The Rails team is excited to review your changes, and you should hear from @sgrif (or someone else) soon.
If any changes to this PR are deemed necessary, please add them as extra commits. This ensures that the reviewer can see what has changed since they last reviewed the code. Due to the way GitHub handles out-of-date commits, this should also make it reasonably obvious what issues have or haven't been addressed. Large or tricky changes may require several passes of review and changes.
Please see [the contribution instructions](http://edgeguides.rubyonrails.org/contributing_to_ruby_on_rails.html) for more information.
","1","2015-12-01T15:56:02Z"
"247775","19965","161032552","1529387","sgrif","As you can see, this implementation causes several failing tests. What's the use case for this? I don't think we need to add a configuration option for this.","1","2015-12-01T17:03:01Z"
"247776","19965","161068230","53159","lxsameer","The wrapping span is pain really specially when we want to us translation in element attributes. It will mess up the page. To get rid of the span the only way is to use open class technique and override the translate helper. But this little patch contains only few lines of code and is very simple. This won't hurt any one and i think would be very useful. Also i can take care of tests too","1","2015-12-01T19:19:56Z"
"247777","19965","161068810","53159","lxsameer","/cc @sgrif","1","2015-12-01T19:21:56Z"
"247778","19965","161070915","47848","rafaelfranca","@sgrif I agree with this https://github.com/rails/rails/pull/20761#issuecomment-120647873. r? @rafaelfranca","1","2015-12-01T19:30:21Z"
"247779","19965","161073461","47848","rafaelfranca","We need tests for this.","1","2015-12-01T19:39:57Z"
"247780","19965","161074949","53159","lxsameer","Ok sure i'll make it happen","1","2015-12-01T19:45:02Z"
"247781","19965","161290429","53159","lxsameer","@rafaelfranca is it alright now ?","1","2015-12-02T13:32:20Z"
"247782","19965","161794357","53159","lxsameer","@rafaelfranca Should I update this PR sinice it's behind the master?","1","2015-12-03T21:46:44Z"
"247783","19965","161796127","47848","rafaelfranca","yeah, it needs a rebase.","1","2015-12-03T21:51:56Z"
"247784","19965","161798254","53159","lxsameer","Ok i'll do that","1","2015-12-03T21:59:51Z"
"247785","19965","161877170","47848","rafaelfranca","This new configuration needs to be added to be configuring guide.","1","2015-12-04T04:59:19Z"
"247786","19965","161933472","53159","lxsameer","@rafaelfranca all done, Thanks for your improvement advice","1","2015-12-04T10:38:21Z"
"247787","19965","162212174","53159","lxsameer","@rafaelfranca can you please review this PR","1","2015-12-05T15:25:05Z"
"247788","19965","163696049","1034","matthewd","> The wrapping span is pain really specially when we want to us translation in element attributes.
This use case sounds like it'd be better served by a per-call option, rather than a single global setting, to me.","1","2015-12-10T17:29:24Z"
"247789","19965","163723781","53159","lxsameer","I ran to this problem a lot, so I think having both options can be awesome. ","1","2015-12-10T19:19:07Z"
"247790","19965","164189049","53159","lxsameer","@rafaelfranca is this PR ok to merge?","1","2015-12-12T20:38:25Z"
"247791","19965","165706028","53159","lxsameer","@rafaelfranca could you please check this PR out and merge it ?","1","2015-12-18T07:53:21Z"
"247792","19965","165795846","47848","rafaelfranca","> This use case sounds like it'd be better served by a per-call option, rather than a single global setting, to me.
The problem is that you would never remember to change the value of the configuration in the method call. I believe this is the better middle ground that we can have.
@lxsameer could you squash your commits?","1","2015-12-18T14:52:00Z"
"247793","19965","165875660","53159","lxsameer","@rafaelfranca done. It's ready","1","2015-12-18T19:21:25Z"
"247794","19966","161049862","7468109","rails-bot","Thanks for the pull request, and welcome! The Rails team is excited to review your changes, and you should hear from @schneems (or someone else) soon.
If any changes to this PR are deemed necessary, please add them as extra commits. This ensures that the reviewer can see what has changed since they last reviewed the code. Due to the way GitHub handles out-of-date commits, this should also make it reasonably obvious what issues have or haven't been addressed. Large or tricky changes may require several passes of review and changes.
Please see [the contribution instructions](http://edgeguides.rubyonrails.org/contributing_to_ruby_on_rails.html) for more information.
","1","2015-12-01T18:05:53Z"
"247795","19966","161058335","1529387","sgrif","I would prefer to move the bug reporting to the top. /cc @pixeltrix @rafaelfranca thoughts on this?","1","2015-12-01T18:41:23Z"
"247796","19966","161058418","1529387","sgrif","Whoops meant to ping @fxn too","1","2015-12-01T18:41:45Z"
"247797","19966","161058508","47848","rafaelfranca",":+1: to move to the top.","1","2015-12-01T18:42:09Z"
"247798","19966","161061558","10076","claudiob","I like where this is going! :ribbon:
I think we could give it another pass and streamline the information even more.
As you said, the main case for someone to stumble upon this file is a user who is about to create a GitHub issue or pull request and who clicks on the link ""Please review the guidelines for contributing to this repository."".
In that case, maybe we could remove even more links, such as ""join the team"" or ""open a new one""?
Additionally, we could make the text more readable by avoiding having lists nested under lists. The user is already about to open an issue or pull request, so we could simply say:
---
#### Thanks for contributing to Ruby on Rails
##### Did you find a bug?
1. Ensure the bug was not already reported by searching on GitHub under [Issues](https://github.com/rails/rails/issues).
1. Open a new GitHub issue addressing the problem. Please include a title and clear description, as much relevant information as possible and a **code sample** demonstrating the issue or an **executable test case** demonstrating the unexpected behavior.
1. If possible, use one of the following **bug report templates** to demonstrate the issue. Simply copy the content of the appropriate template into a .rb file, make the necessary changes and paste it into the issue description:
* Active Record issues (models, database): [stable](https://github.com/rails/rails/blob/master/guides/bug_report_templates/active_record_gem.rb) / [master](https://github.com/rails/rails/blob/master/guides/bug_report_templates/active_record_master.rb)
* Action Pack issues (controllers, routing): [stable](https://github.com/rails/rails/blob/master/guides/bug_report_templates/action_controller_gem.rb) / [master](https://github.com/rails/rails/blob/master/guides/bug_report_templates/action_controller_master.rb)
* Other issues: [stable](https://github.com/rails/rails/blob/master/guides/bug_report_templates/generic_gem.rb) / [master](https://github.com/rails/rails/blob/master/guides/bug_report_templates/generic_master.rb)
##### Did you write a patch that fixes a bug?
1. Open a new GitHub pull request with the patch.
2. Before submitting, please read the [Contributing to Ruby on Rails](http://edgeguides.rubyonrails.org/contributing_to_ruby_on_rails.html) guide to know more about coding conventions and benchmarks.
##### Do you intend to add a new feature or change an existing one?
1. Suggest your change in the [rubyonrails-core mailing list](https://groups.google.com/forum/?fromgroups#!forum/rubyonrails-core).
2. Do not open an issue on GitHub until you have collected positive feedback about the change. GitHub issues are primarily intended only for bug reports and fixes.
##### Do you have any other question about the source code?
1. Ask any question about how to use Ruby on Rails in the [rubyonrails-talk mailing list](https://groups.google.com/forum/?fromgroups#!forum/rubyonrails-talk).
Thanks! :heart: :heart: :heart:
The Rails Team
---","1","2015-12-01T18:54:13Z"
"247799","19966","161083072","3387","fxn",":+1: on the proposed changes.
I think side by side the prompts of @claudiob's proposal are great, it was way easier for me to quickly grasp the structure and look for my (hypothetical) need.
I like also that we still delegate to the guide, so we do not have two places to maintain. Also, moving too much here would make the impression that people do not need to read the guide. The balance is spot on I believe.
Would like to add a couple of remarks: I would not start the document saying ""thank you"", because potentially the reader does not have contributed yet. ""Thank you for what?"" I would wonder. Something more neutral like ""How to Contribute to Ruby on Rails"" or something in that line. A closing ""thank you"" and the hearts at the bottom is fine, it has a different role than the main opening header in the document.
The other remark is that the instructions to submit a patch do not depend on the nature of the patch. Bug fixes and new features can be proposed with a patch. We do not accept issues to discuss new features, but we do accept PRs for new features (which can be rejected).
","1","2015-12-01T20:15:59Z"
"247800","19966","161084835","59744","schneems","contributing is a giant bike shed. I think that suggestion is good. I think it is fine to pre-emptively say thanks. Thank them for getting started by reading the guide. If their intent is to contribute, I am thankful even if they are not fully successful. We will be more thankful when they do.
","1","2015-12-01T20:23:21Z"
"247801","19966","161091817","3387","fxn","You can thank for their interest, you can feel thankful by the mere action of accessing the endpoint, all that is good, but if the reader has not contributed yet, the sentence just does not make sense.
For me, the thankful feeling is fine at the end, but the header does not need that. Rather, if you say ""How To..."" and then there are clear sections ""Do you...?"", the structure is super clear and all make sense.","1","2015-12-01T20:52:27Z"
"247802","19966","161166321","10076","claudiob","Do you think we need to distinguish between ""stable"" and ""master"" when linking to the bug template?
I expect all issues to be opened against the `master` branch, so I suggest we only link to the ""master"" bug template. What do you think?","1","2015-12-02T03:11:17Z"
"247803","19966","161168093","10076","claudiob","@fxn I agree with your comment on the ""Thank you…"", it can be changed to something better.","1","2015-12-02T03:25:48Z"
"247804","19966","164104697","4148745","tjblonsk","Thanks for all the great feedback. I've pushed changes based on everybody's comments. ","1","2015-12-12T03:11:10Z"
"247805","19966","164114811","10076","claudiob",":shipit: ","1","2015-12-12T06:28:44Z"
"247806","19967","161100237","7468109","rails-bot","Thanks for the pull request, and welcome! The Rails team is excited to review your changes, and you should hear from @arthurnn (or someone else) soon.
If any changes to this PR are deemed necessary, please add them as extra commits. This ensures that the reviewer can see what has changed since they last reviewed the code. Due to the way GitHub handles out-of-date commits, this should also make it reasonably obvious what issues have or haven't been addressed. Large or tricky changes may require several passes of review and changes.
Please see [the contribution instructions](http://edgeguides.rubyonrails.org/contributing_to_ruby_on_rails.html) for more information.
","1","2015-12-01T21:24:52Z"
"247807","19968","161367670","7468109","rails-bot","r? @eileencodes
(@rails-bot has picked a reviewer for you, use r? to override)","1","2015-12-02T17:10:54Z"
"247808","19968","161370855","1034","matthewd","Nested modules can interfere with the autoloader... and would require us to assume all the parents are modules rather than classes.","1","2015-12-02T17:23:00Z"
"247809","19968","161462213","632942","cllns","Can you explain more @matthewd? If you could provide a failing test too, I'd be immensely grateful :)","1","2015-12-02T23:06:44Z"
"247810","19968","161464973","1034","matthewd","https://gist.github.com/matthewd/9bb2e3732b24ddb136c8 and https://gist.github.com/matthewd/aedf5432a04b5377baf0 should demonstrate what I'm talking about.
Admittedly untested, but if you drop them in an app as `app/models/a.rb` and `app/models/a/b.rb`, then run the victim code in a rails console (in development == no eager loading), you *should* see an exception from each. (Whereas both should succeed if you switch `a/b.rb` to use the compact `A::B` definition.)","1","2015-12-02T23:20:50Z"
"247811","19968","161472964","632942","cllns","Thanks @matthewd. I did indeed get an exception from the first one. However, if I don't call `require_dependency` then both work fine, in either order.
I'm confused about the second example, since we're defining a both a module and a class named `A`. Surely that's not supported?
I just found the [Autoloading and Reloading Constants](http://guides.rubyonrails.org/autoloading_and_reloading_constants.html) which is great so far. Going to give that a read and see if I can understand the problem better.","1","2015-12-03T00:09:16Z"
"247812","19968","161477379","1034","matthewd","> if I don't call require_dependency then both work fine
Well yes, that's why I put it in there :wink:... but calling it is not an unreasonable/unheard-of thing for people to do.
> I'm confused about the second example, since we're defining a both a module and a class named A. Surely that's not supported?
Isn't that my point? `class A; end; class A::B; end` is fine... but if we use the nested form for B, we have to guess whether A was a module or a class.","1","2015-12-03T00:33:10Z"
"247813","19968","162334415","1080678","eileencodes","r? @matthewd ","1","2015-12-06T18:22:05Z"
"247814","19969","161399909","7468109","rails-bot","Thanks for the pull request, and welcome! The Rails team is excited to review your changes, and you should hear from @arthurnn (or someone else) soon.
If any changes to this PR are deemed necessary, please add them as extra commits. This ensures that the reviewer can see what has changed since they last reviewed the code. Due to the way GitHub handles out-of-date commits, this should also make it reasonably obvious what issues have or haven't been addressed. Large or tricky changes may require several passes of review and changes.
Please see [the contribution instructions](http://edgeguides.rubyonrails.org/contributing_to_ruby_on_rails.html) for more information.
","1","2015-12-02T19:04:44Z"
"247815","19969","161400430","3860146","merhard","[Here](https://travis-ci.org/rails/rails/jobs/94433499#L4855) is the test failing on a recent travis build.","1","2015-12-02T19:06:48Z"
"247816","19969","161402430","47848","rafaelfranca","Ok, so we have two problems now. This one that you just fixed and the fact that the failing test was not being reported as failed. We need to fix the second problem before fixing this one. Could you take a look?","1","2015-12-02T19:14:51Z"
"247817","19969","161414063","3860146","merhard","@rafaelfranca Looks like this commit is the culprit: 5a0e0e7.
The old code used the `ruby` method from the `FileUtils` module. If any tests failed, a `RuntimeError` was raised which caused the rake task to exit with a non-zero status. The new code uses the `load` method from the `Kernel` module. This does run the tests but only fails if the file has any syntax errors, not failing tests.
Should that commit be reverted?","1","2015-12-02T19:54:11Z"
"247818","19969","161421855","47848","rafaelfranca",":+1: to revert for now.","1","2015-12-02T20:20:37Z"
"247819","19970","1645222","9582","josevalim","Hey man, thanks, but this test is asserting the same as this one:
https://github.com/dmathieu/rails/blob/07c9ff0b4adc41ebcb1116e4ed8ad89f1445d95f/railties/test/application/assets_test.rb#L49
i.e. it is simply asserting assets were compiled. to check the cache was used, you should check that something inside tmp/cache/assets was generated instead, no?","1","2011-07-25T12:09:59Z"
"247820","19970","1645245","9347","dmathieu","No. The test you're refering to just checks that an asset file is generated.
My test checks that asset_path is properly executed (see the assert_match).
perform_caching doesn't generate tmp files (or maybe internally, but I don't think testing private internal behavior is a good idea). It appends timestamps to filenames when using asset_path.
Both of these tests are very similar indeed.
I kept them separate in order to keep a test with the sole purpose of checking that precompile works on plain javascript files (the second one uses erb). But I can merge them if you want.","1","2011-07-25T12:14:36Z"
"247821","19970","1645277","9582","josevalim","So I am missing something. What happens when perform_caching is true? Why asset_path behaves differently and how? We should rename the tests cases to those more specific names then, wdyt?","1","2011-07-25T12:20:37Z"
"247822","19970","1645318","9347","dmathieu","What happens when perform_caching is true is that asset_path return the path to the file with md5 hash appended, like :
/assets/rails-2454c9082a1665b6d4299bcb0217ed2b.png
With perform_caching at false, it returns the path as provided :
/assets/rails.png
In development mode, we would expect it to be at false so we always see the newest file.
In production, we would expect to get the static file, generated by the assets:precompile task.
But in order to get it, the task needs to have perform_caching always set to true. This is what #2226 does.","1","2011-07-25T12:27:14Z"
"247823","19970","1645358","9582","josevalim","Awesome. Could you please provide another commit making the test case names more expressive then? Let's make it explicit that asset_path should point to the md5 file. Let's also change the first precompile test case to mention it is simply asserting files exists in the filesystem. Thanks!","1","2011-07-25T12:35:56Z"
"247824","19971","161402785","7468109","rails-bot","Thanks for the pull request, and welcome! The Rails team is excited to review your changes, and you should hear from @matthewd (or someone else) soon.
If any changes to this PR are deemed necessary, please add them as extra commits. This ensures that the reviewer can see what has changed since they last reviewed the code. Due to the way GitHub handles out-of-date commits, this should also make it reasonably obvious what issues have or haven't been addressed. Large or tricky changes may require several passes of review and changes.
Please see [the contribution instructions](http://edgeguides.rubyonrails.org/contributing_to_ruby_on_rails.html) for more information.
","1","2015-12-02T19:16:16Z"
"247825","19972","161427162","7468109","rails-bot","Thanks for the pull request, and welcome! The Rails team is excited to review your changes, and you should hear from @senny (or someone else) soon.
If any changes to this PR are deemed necessary, please add them as extra commits. This ensures that the reviewer can see what has changed since they last reviewed the code. Due to the way GitHub handles out-of-date commits, this should also make it reasonably obvious what issues have or haven't been addressed. Large or tricky changes may require several passes of review and changes.
Please see [the contribution instructions](http://edgeguides.rubyonrails.org/contributing_to_ruby_on_rails.html) for more information.
","1","2015-12-02T20:37:45Z"
"247826","19972","161427420","47848","rafaelfranca","cc @tenderlove ","1","2015-12-02T20:38:30Z"
"247827","19973","161460164","7468109","rails-bot","Thanks for the pull request, and welcome! The Rails team is excited to review your changes, and you should hear from @eileencodes (or someone else) soon.
If any changes to this PR are deemed necessary, please add them as extra commits. This ensures that the reviewer can see what has changed since they last reviewed the code. Due to the way GitHub handles out-of-date commits, this should also make it reasonably obvious what issues have or haven't been addressed. Large or tricky changes may require several passes of review and changes.
Please see [the contribution instructions](http://edgeguides.rubyonrails.org/contributing_to_ruby_on_rails.html) for more information.
","1","2015-12-02T22:56:08Z"
"247828","19973","161463201","1034","matthewd","See also https://github.com/rails/sprockets-rails/issues/240. I think the previous behaviour needs to be restored.","1","2015-12-02T23:11:44Z"
"247829","19973","161464750","199","jeremy","Agreed. This is a regression—don't want to remove it.","1","2015-12-02T23:19:40Z"
"247830","19973","161468432","23050","jordan-brough","Thank you!","1","2015-12-02T23:41:25Z"
"247831","19973","163922651","20772","Erol","Does this mean that #20423 needs to be reverted as well?","1","2015-12-11T12:02:26Z"
"247832","19973","163969549","199","jeremy","@Erol – If this is fixed, yes.","1","2015-12-11T15:47:21Z"
"247833","19974","161462841","7468109","rails-bot","Thanks for the pull request, and welcome! The Rails team is excited to review your changes, and you should hear from @matthewd (or someone else) soon.
If any changes to this PR are deemed necessary, please add them as extra commits. This ensures that the reviewer can see what has changed since they last reviewed the code. Due to the way GitHub handles out-of-date commits, this should also make it reasonably obvious what issues have or haven't been addressed. Large or tricky changes may require several passes of review and changes.
Please see [the contribution instructions](http://edgeguides.rubyonrails.org/contributing_to_ruby_on_rails.html) for more information.
","1","2015-12-02T23:09:56Z"
"247834","19974","161814037","8058230","TheSmartnik","Hi @rafaelfranca, could you please review this pr?
You've responded in #6478. So I thought, maybe you could take look at this one
","1","2015-12-03T22:51:13Z"
"247835","19974","161814969","47848","rafaelfranca","R? @rafaelfranca
On Thu, Dec 3, 2015, 20:51 TheSmartnik <notifications@github.com> wrote:
> Hi @rafaelfranca <https://github.com/rafaelfranca>, could you please
> review this pr?
> You've responded in #6478 <https://github.com/rails/rails/pull/6478>. So
> I thought, maybe you could take look at this one
>
> —
> Reply to this email directly or view it on GitHub
> <https://github.com/rails/rails/pull/22473#issuecomment-161814037>.
>
","1","2015-12-03T22:54:32Z"
"247836","19975","161492213","10076","claudiob","Note: this commit was originally part of a bigger PR: https://github.com/rails/rails/pull/21452
However, now that https://github.com/rails/rails/pull/17169 has been accepted, my original PR has conflicts, so I'm extracting from that PR the commits that still apply to master. :blush: ","1","2015-12-03T01:53:08Z"
"247837","19975","162555429","4912","sikachu",":+1: this is good to merge.","1","2015-12-07T15:21:09Z"
"247838","19976","161494164","10076","claudiob","Note: similarly to #22475 this commit was originally part of a bigger PR: https://github.com/rails/rails/pull/21452
However, now that https://github.com/rails/rails/pull/17169 has been accepted, my original PR has conflicts, so I have extracted from that PR the two commits that still apply to master. :blush:
","1","2015-12-03T02:07:06Z"
"247839","19977","161521577","7468109","rails-bot","Thanks for the pull request, and welcome! The Rails team is excited to review your changes, and you should hear from @rafaelfranca (or someone else) soon.
If any changes to this PR are deemed necessary, please add them as extra commits. This ensures that the reviewer can see what has changed since they last reviewed the code. Due to the way GitHub handles out-of-date commits, this should also make it reasonably obvious what issues have or haven't been addressed. Large or tricky changes may require several passes of review and changes.
Please see [the contribution instructions](http://edgeguides.rubyonrails.org/contributing_to_ruby_on_rails.html) for more information.
","1","2015-12-03T05:30:36Z"
"247840","19978","161522443","7468109","rails-bot","Thanks for the pull request, and welcome! The Rails team is excited to review your changes, and you should hear from @schneems (or someone else) soon.
If any changes to this PR are deemed necessary, please add them as extra commits. This ensures that the reviewer can see what has changed since they last reviewed the code. Due to the way GitHub handles out-of-date commits, this should also make it reasonably obvious what issues have or haven't been addressed. Large or tricky changes may require several passes of review and changes.
Please see [the contribution instructions](http://edgeguides.rubyonrails.org/contributing_to_ruby_on_rails.html) for more information.
","1","2015-12-03T05:39:23Z"
"247841","19978","161522665","59744","schneems","r? @jeremy","1","2015-12-03T05:41:35Z"
"247842","19978","161529904","10076","claudiob",":tada: :tada: :tada: Thanks for your contribution! :tada: :tada: :tada:
I tried to run the [redis-activesupport tests](https://github.com/redis-store/redis-activesupport/blob/master/test/active_support/cache/redis_store_test.rb#L343-L358) against your branch and the order of the notifications is now correct.
On the other hand, the tests are still failing because the notification is
```diff
-{:key=>""radiohead"", :super_operation=>:fetch}
+{:key=>""radiohead"", :super_operation=>:fetch, :hit=>false}
```
Of course this is not a bug, but the feature you added in https://github.com/rails/rails/pull/21631.
Nevertheless, since this is a change to a somewhat public API, I think it needs to be added to the `activesupport/CHANGELOG.md`.
Do you mind adding another commit (or amending the one above) where you add an entry to the CHANGELOG describing what changes after #21631? Thanks! :ribbon: ","1","2015-12-03T06:27:02Z"
"247843","19978","161531525","91281","RobinClowers","Oh good call, I'll do that first thing tomorrow. Thanks for the review!","1","2015-12-03T06:33:50Z"
"247844","19978","161721466","91281","RobinClowers","Actually, it looks like Jeremy added a changelog entry for me when he merged my original branch: https://github.com/rails/rails/blame/master/activesupport/CHANGELOG.md#L81. Let me know if there is anything else.","1","2015-12-03T17:20:26Z"
"247845","19978","161742133","10076","claudiob","You are right!! I hadn't seen that PR. Then for me this PR is ready to go!","1","2015-12-03T18:38:04Z"
"247846","19978","165938196","10076","claudiob","@jeremy since the failure of Travis is unrelated to the PR, is it okay to merge or should I ask @RobinClowers to rebase against master?","1","2015-12-19T02:43:47Z"
"247847","19979","1809012","24056","akaspick","+1","1","2011-08-15T17:25:19Z"
"247848","19979","1823390","234799","tbaba","+1 I've also got this problem.
ruby-1.8.7-p334 :001 > require 'rubygems'
=> false
ruby-1.8.7-p334 :002 > require 'active_support/all'
=> true
ruby-1.8.7-p334 :003 > ActiveSupport::SafeBuffer.new('aaa bbb').sub(/(\w+) (\w+)/){puts $1; puts $2}
nil
nil
=> """"","1","2011-08-17T05:25:18Z"
"247849","19979","1904701","191132","bradical","+1 Ran into this when using CGI.escape on a SafeBuffer.","1","2011-08-25T22:34:02Z"
"247850","19979","1991143","9347","dmathieu","I've just rebased this PR against master, fixing a conflict.","1","2011-09-04T12:48:33Z"
"247851","20006","162336240","2741","dhh","Lovely! You're fast ?","1","2015-12-06T18:43:32Z"
"247852","20007","162334382","7468109","rails-bot","Thanks for the pull request, and welcome! The Rails team is excited to review your changes, and you should hear from @pixeltrix (or someone else) soon.
If any changes to this PR are deemed necessary, please add them as extra commits. This ensures that the reviewer can see what has changed since they last reviewed the code. Due to the way GitHub handles out-of-date commits, this should also make it reasonably obvious what issues have or haven't been addressed. Large or tricky changes may require several passes of review and changes.
Please see [the contribution instructions](http://edgeguides.rubyonrails.org/contributing_to_ruby_on_rails.html) for more information.
","1","2015-12-06T18:21:16Z"
"247853","20008","162339895","7468109","rails-bot","Thanks for the pull request, and welcome! The Rails team is excited to review your changes, and you should hear from @kaspth (or someone else) soon.
If any changes to this PR are deemed necessary, please add them as extra commits. This ensures that the reviewer can see what has changed since they last reviewed the code. Due to the way GitHub handles out-of-date commits, this should also make it reasonably obvious what issues have or haven't been addressed. Large or tricky changes may require several passes of review and changes.
Please see [the contribution instructions](http://edgeguides.rubyonrails.org/contributing_to_ruby_on_rails.html) for more information.
","1","2015-12-06T19:31:33Z"
"247854","20008","162339903","1504464","RochesterinNYC","Addresses issue #21111","1","2015-12-06T19:31:49Z"
"247855","20008","162594817","1504464","RochesterinNYC","@kaspth any thoughts on this?","1","2015-12-07T17:07:06Z"
"247856","20008","162614330","350807","kaspth","Passing this onto Arthur, because he commented on the original issue :grin:
r? @arthurnn ","1","2015-12-07T18:23:52Z"
"247857","20008","163960806","1504464","RochesterinNYC","Anything I should do to improve this PR? Critique is welcome! @arthurnn","1","2015-12-11T15:15:53Z"
"247858","20008","163973835","1504464","RochesterinNYC","Thanks for all the feedback, btw!","1","2015-12-11T15:58:36Z"
"247859","20008","164237239","1504464","RochesterinNYC","@arthurnn Updated the PR with the removed `attr_reader` for `finder_methods_hash`.","1","2015-12-13T08:19:55Z"
"247860","20008","166075634","1504464","RochesterinNYC","@arthurnn anything else that needs to be done regarding this PR? Thanks for your time.","1","2015-12-20T07:02:29Z"
"247861","20009","162358273","7468109","rails-bot","r? @rafaelfranca
(@rails-bot has picked a reviewer for you, use r? to override)","1","2015-12-06T22:50:15Z"
"247862","20010","1645203","9582","josevalim","Is this broken on 3-1-stable as well? If so, could you please backport? Thanks!","1","2011-07-25T12:03:07Z"
"247863","20010","1645281","15688","thedarkone","This applies cleanly to `3-1-stable` as well. Do I need to open another pull request?","1","2011-07-25T12:21:12Z"
"247864","20010","1645320","9582","josevalim","Yes please ( I am in a computer without git :( ).","1","2011-07-25T12:27:36Z"
"247865","20011","162417434","7468109","rails-bot","Thanks for the pull request, and welcome! The Rails team is excited to review your changes, and you should hear from @arthurnn (or someone else) soon.
If any changes to this PR are deemed necessary, please add them as extra commits. This ensures that the reviewer can see what has changed since they last reviewed the code. Due to the way GitHub handles out-of-date commits, this should also make it reasonably obvious what issues have or haven't been addressed. Large or tricky changes may require several passes of review and changes.
Please see [the contribution instructions](http://edgeguides.rubyonrails.org/contributing_to_ruby_on_rails.html) for more information.
","1","2015-12-07T05:47:51Z"
"247866","20012","162468242","7468109","rails-bot","r? @eileencodes
(@rails-bot has picked a reviewer for you, use r? to override)","1","2015-12-07T09:58:27Z"
"247867","20012","162471240","350807","kaspth","This change has already been rejected once. We need to run the command twice. Thanks!","1","2015-12-07T10:11:59Z"
"247868","20013","162518374","7468109","rails-bot","Thanks for the pull request, and welcome! The Rails team is excited to review your changes, and you should hear from @eileencodes (or someone else) soon.
If any changes to this PR are deemed necessary, please add them as extra commits. This ensures that the reviewer can see what has changed since they last reviewed the code. Due to the way GitHub handles out-of-date commits, this should also make it reasonably obvious what issues have or haven't been addressed. Large or tricky changes may require several passes of review and changes.
Please see [the contribution instructions](http://edgeguides.rubyonrails.org/contributing_to_ruby_on_rails.html) for more information.
","1","2015-12-07T13:02:46Z"
"247869","20013","162521860","47848","rafaelfranca","Thank you for the pull request but I believe it is a bad idea to allow this feature without proper escaping. All what this is doing is calling `html_safe` if a `_html` suffix is provided. That may give the wrong impression that it is being properly escaped what is not true so I prefer to not give this impression.","1","2015-12-07T13:18:21Z"
"247870","20014","162519614","7468109","rails-bot","Thanks for the pull request, and welcome! The Rails team is excited to review your changes, and you should hear from @chancancode (or someone else) soon.
If any changes to this PR are deemed necessary, please add them as extra commits. This ensures that the reviewer can see what has changed since they last reviewed the code. Due to the way GitHub handles out-of-date commits, this should also make it reasonably obvious what issues have or haven't been addressed. Large or tricky changes may require several passes of review and changes.
Please see [the contribution instructions](http://edgeguides.rubyonrails.org/contributing_to_ruby_on_rails.html) for more information.
","1","2015-12-07T13:08:27Z"
"247871","20015","162553904","7468109","rails-bot","Thanks for the pull request, and welcome! The Rails team is excited to review your changes, and you should hear from @pixeltrix (or someone else) soon.
If any changes to this PR are deemed necessary, please add them as extra commits. This ensures that the reviewer can see what has changed since they last reviewed the code. Due to the way GitHub handles out-of-date commits, this should also make it reasonably obvious what issues have or haven't been addressed. Large or tricky changes may require several passes of review and changes.
Please see [the contribution instructions](http://edgeguides.rubyonrails.org/contributing_to_ruby_on_rails.html) for more information.
","1","2015-12-07T15:16:48Z"
"247872","20015","162566392","47848","rafaelfranca","Could you explain why you need this in the controller layer? Also does not `view_context.translate(:foo_html)` works in the controller?","1","2015-12-07T15:58:15Z"
"247873","20015","162572419","5897136","Friend-LGA","Сounter question: why translate helper for views and translate method for controllers work different, but implements the same thing? I think it will be better to understand, learn and use, if they will work in the same way.
```view_context.translate(:foo_html)``` I think it should work","1","2015-12-07T16:13:05Z"
"247874","20015","162573856","47848","rafaelfranca","They are dealing with different concepts. Views are dealing with templates that may be rendered as HTML so they need proper escaping, controllers are not HTML specific and should not know about HTML and things related to it. If `view_context.translate(:foo_html)` works so I prefer to not change how controllers works.
@matthewd @jeremy thoughts?","1","2015-12-07T16:18:28Z"
"247875","20015","162578962","5897136","Friend-LGA","If I try to get ```view_context.translate('.foo_html')``` it won't work, because can't use 'lazy lookup' inside controller","1","2015-12-07T16:28:52Z"
"247876","20015","162953201","6321","pixeltrix","@Friend-LGA are you trying to do `*_html` lookup in a controller to put HTML into a flash message? If so it's better to put the i18n key in the flash and then do the lookup in the view.
Given the new feature of API-only applications in Rails 5 I think adding this confuses things - it's not the controller's responsibility. Therefore it's a :-1: from me.","1","2015-12-08T17:28:19Z"
"247877","20015","162971870","1034","matthewd","It seems reasonably fair to me to handle the `_html` convention here... if you concatenate some strings to build HTML in the controller, we do address HTML safety: it's not truly a view-only concern.
I would consider it inappropriate to *default* to returning HTML, as we do in the missing-key case in view context, in the controller... but respecting an ~explicit `_html` feels safe enough... likely safer than leaving it up the caller to do it wrong.","1","2015-12-08T18:31:18Z"
"247878","20016","162615325","7468109","rails-bot","Thanks for the pull request, and welcome! The Rails team is excited to review your changes, and you should hear from @matthewd (or someone else) soon.
If any changes to this PR are deemed necessary, please add them as extra commits. This ensures that the reviewer can see what has changed since they last reviewed the code. Due to the way GitHub handles out-of-date commits, this should also make it reasonably obvious what issues have or haven't been addressed. Large or tricky changes may require several passes of review and changes.
Please see [the contribution instructions](http://edgeguides.rubyonrails.org/contributing_to_ruby_on_rails.html) for more information.
","1","2015-12-07T18:27:53Z"
"247879","20016","162622672","47848","rafaelfranca","Thank you for the pull request. Could you explain what is the use case for it?","1","2015-12-07T18:52:57Z"
"247880","20017","162701325","7468109","rails-bot","Thanks for the pull request, and welcome! The Rails team is excited to review your changes, and you should hear from @pixeltrix (or someone else) soon.
If any changes to this PR are deemed necessary, please add them as extra commits. This ensures that the reviewer can see what has changed since they last reviewed the code. Due to the way GitHub handles out-of-date commits, this should also make it reasonably obvious what issues have or haven't been addressed. Large or tricky changes may require several passes of review and changes.
Please see [the contribution instructions](http://edgeguides.rubyonrails.org/contributing_to_ruby_on_rails.html) for more information.
","1","2015-12-07T23:12:38Z"
"247881","20017","162701326","7468109","rails-bot","<img src=""http://www.joshmatthews.net/warning.svg"" alt=""warning"" height=20> **Warning** <img src=""http://www.joshmatthews.net/warning.svg"" alt=""warning"" height=20>
* Pull requests are usually filed against the master branch for this repo, but this one is against 3-2-stable. Please double check that you specified the right target!","1","2015-12-07T23:12:38Z"
"247882","20017","162705662","1034","matthewd","Rails 3.2 is no longer supported","1","2015-12-07T23:36:05Z"
"247883","20018","1645316","9582","josevalim","Tks!!!","1","2011-07-25T12:26:43Z"
"247884","20019","162858911","7468109","rails-bot","Thanks for the pull request, and welcome! The Rails team is excited to review your changes, and you should hear from @kaspth (or someone else) soon.
If any changes to this PR are deemed necessary, please add them as extra commits. This ensures that the reviewer can see what has changed since they last reviewed the code. Due to the way GitHub handles out-of-date commits, this should also make it reasonably obvious what issues have or haven't been addressed. Large or tricky changes may require several passes of review and changes.
Please see [the contribution instructions](http://edgeguides.rubyonrails.org/contributing_to_ruby_on_rails.html) for more information.
","1","2015-12-08T11:44:25Z"
"247885","20019","162858913","7468109","rails-bot","<img src=""http://www.joshmatthews.net/warning.svg"" alt=""warning"" height=20> **Warning** <img src=""http://www.joshmatthews.net/warning.svg"" alt=""warning"" height=20>
* Pull requests are usually filed against the master branch for this repo, but this one is against 4-1-stable. Please double check that you specified the right target!","1","2015-12-08T11:44:25Z"
"247886","20019","162887961","350807","kaspth","Unfortunately 4.1 only gets security fixes now, so this can be only be submitted to master and then we will backports to 4-2-stable. Thanks :heart:","1","2015-12-08T14:01:47Z"
"247887","20020","162905384","7468109","rails-bot","Thanks for the pull request, and welcome! The Rails team is excited to review your changes, and you should hear from @matthewd (or someone else) soon.
If any changes to this PR are deemed necessary, please add them as extra commits. This ensures that the reviewer can see what has changed since they last reviewed the code. Due to the way GitHub handles out-of-date commits, this should also make it reasonably obvious what issues have or haven't been addressed. Large or tricky changes may require several passes of review and changes.
Please see [the contribution instructions](http://edgeguides.rubyonrails.org/contributing_to_ruby_on_rails.html) for more information.
","1","2015-12-08T14:52:16Z"
"247888","20020","162909264","47848","rafaelfranca","Related with https://github.com/rails/rails/issues/22045. Same as https://github.com/rails/rails/pull/18412","1","2015-12-08T15:06:35Z"
"247889","20021","163114182","7468109","rails-bot","Thanks for the pull request, and welcome! The Rails team is excited to review your changes, and you should hear from @kaspth (or someone else) soon.
If any changes to this PR are deemed necessary, please add them as extra commits. This ensures that the reviewer can see what has changed since they last reviewed the code. Due to the way GitHub handles out-of-date commits, this should also make it reasonably obvious what issues have or haven't been addressed. Large or tricky changes may require several passes of review and changes.
Please see [the contribution instructions](http://edgeguides.rubyonrails.org/contributing_to_ruby_on_rails.html) for more information.
","1","2015-12-09T05:25:46Z"
"247890","20023","163222909","7468109","rails-bot","Thanks for the pull request, and welcome! The Rails team is excited to review your changes, and you should hear from @chancancode (or someone else) soon.
If any changes to this PR are deemed necessary, please add them as extra commits. This ensures that the reviewer can see what has changed since they last reviewed the code. Due to the way GitHub handles out-of-date commits, this should also make it reasonably obvious what issues have or haven't been addressed. Large or tricky changes may require several passes of review and changes.
Please see [the contribution instructions](http://edgeguides.rubyonrails.org/contributing_to_ruby_on_rails.html) for more information.
","1","2015-12-09T13:03:27Z"
"247891","20024","163247824","7468109","rails-bot","Thanks for the pull request, and welcome! The Rails team is excited to review your changes, and you should hear from @chancancode (or someone else) soon.
If any changes to this PR are deemed necessary, please add them as extra commits. This ensures that the reviewer can see what has changed since they last reviewed the code. Due to the way GitHub handles out-of-date commits, this should also make it reasonably obvious what issues have or haven't been addressed. Large or tricky changes may require several passes of review and changes.
Please see [the contribution instructions](http://edgeguides.rubyonrails.org/contributing_to_ruby_on_rails.html) for more information.
","1","2015-12-09T14:08:36Z"
"247892","20024","163286221","1034","matthewd","""misleading wording"" != ""incorrect statement""... and if that claim's not true, we should fix it.","1","2015-12-09T15:15:28Z"
"247893","20024","163310419","5836","jacobat","I have a proposal for a fix in #22542","1","2015-12-09T16:15:40Z"
"247894","20024","163314265","5836","jacobat","Thinking about it it's not really a fix if you want to maintain the ""session data is not loaded unless the application code accesses session data"" statement.","1","2015-12-09T16:26:32Z"
"247895","20025","163301631","7468109","rails-bot","Thanks for the pull request, and welcome! The Rails team is excited to review your changes, and you should hear from @rafaelfranca (or someone else) soon.
If any changes to this PR are deemed necessary, please add them as extra commits. This ensures that the reviewer can see what has changed since they last reviewed the code. Due to the way GitHub handles out-of-date commits, this should also make it reasonably obvious what issues have or haven't been addressed. Large or tricky changes may require several passes of review and changes.
Please see [the contribution instructions](http://edgeguides.rubyonrails.org/contributing_to_ruby_on_rails.html) for more information.
","1","2015-12-09T15:57:00Z"
"247896","20025","163339175","47848","rafaelfranca","Could you add a test case for this new behavior?","1","2015-12-09T17:53:49Z"
"247897","20025","163562829","5836","jacobat","I see that [test_doesnt_write_session_cookie_if_session_is_unchanged](https://github.com/rails/rails/blob/master/actionpack/test/dispatch/session/cookie_store_test.rb#L176-L184) already exists.
Yet the behaviour of my test app shows that if I make a request from a browser with a session cookie then the response contains a session cookie with new content. With this patch the response will not contain a session cookie if the session doesn't change.
So I'm not sure what's going on or if this is the right place to address the issue.","1","2015-12-10T10:05:14Z"
"247898","20026","163398631","7468109","rails-bot","Thanks for the pull request, and welcome! The Rails team is excited to review your changes, and you should hear from @schneems (or someone else) soon.
If any changes to this PR are deemed necessary, please add them as extra commits. This ensures that the reviewer can see what has changed since they last reviewed the code. Due to the way GitHub handles out-of-date commits, this should also make it reasonably obvious what issues have or haven't been addressed. Large or tricky changes may require several passes of review and changes.
Please see [the contribution instructions](http://edgeguides.rubyonrails.org/contributing_to_ruby_on_rails.html) for more information.
","1","2015-12-09T21:32:40Z"
"247899","20026","163402611","47848","rafaelfranca","Thanks! Backported in 57590fa and 7310a6d","1","2015-12-09T21:41:08Z"
"247900","20027","163520328","7468109","rails-bot","r? @senny
(@rails-bot has picked a reviewer for you, use r? to override)","1","2015-12-10T07:10:43Z"
"247901","20027","163524462","5402","senny","@y-yagi thank you :yellow_heart: ","1","2015-12-10T07:40:31Z"
"247902","20027","163525972","987638","y-yagi","Thanks!","1","2015-12-10T07:46:58Z"
"247903","20028","163547167","7468109","rails-bot","r? @chancancode
(@rails-bot has picked a reviewer for you, use r? to override)","1","2015-12-10T09:30:24Z"
"247904","20028","163937527","12642","kamipo","Follow up to #21664.","1","2015-12-11T13:36:20Z"
"247905","20028","165171630","5356517","yui-knk","Looks good to me :)
I think it is better to split `create_table_info_cache` to private method like:
```ruby
def create_table_info_cache
@ create_table_info_cache ||= {}
end
```
this hides how create_table_info works.
And ""Correctly cache create_table_info"" is suitable to commit message I feel :+1: ","1","2015-12-16T16:47:46Z"
"247906","20028","165256794","12642","kamipo","@yui-knk Thank you for your comment. I added `create_table_info_cache` and fixed commit message. Thanks!","1","2015-12-16T21:35:36Z"
"247907","20028","166184504","12642","kamipo","The number of calling `create_table_info` was increased to 2 times by #17569. This means that `rake db:schema:dump` to be slower than Rails 4.2. We need this fix.
@rafaelfranca What do you think about it?","1","2015-12-21T02:59:25Z"
"247908","20029","1645884","9582","josevalim","Unfortunately this has the performance downside of an extra method dispatch. /cc @tenderlove","1","2011-07-25T13:53:55Z"
"247909","20029","1645894","9347","dmathieu","Delegation is a very generic term and you set it a first-level class. That's gonna be a problem for many apps.
You should use `ActiveSupport::Delegation`.","1","2011-07-25T13:55:25Z"
"247910","20029","1645946","122436","bogdan","@josevalim Not sure I got you right. Did you mean that parse method call `Delegation.perform` in the eval string is slow or method call itself is slow?
@dmathieu will fix","1","2011-07-25T14:03:50Z"
"247911","20029","1646818","3124","tenderlove","@josevalim using delegate is already slow. I don't think an extra method call would make much difference.
I *think* I'm OK with this patch if `Delegation` is properly namespaced and has a `# :nodoc:` directive.","1","2011-07-25T16:00:57Z"
"247912","20029","1653946","122436","bogdan","Properly namespaced in #2275.","1","2011-07-26T13:20:08Z"
"247913","20053","164485020","350807","kaspth","Well done, Prem ?","1","2015-12-14T16:27:47Z"
"247914","20054","164473083","13086902","shakycode","Massive and amazing!","1","2015-12-14T15:50:40Z"
"247915","20054","164477914","47848","rafaelfranca","We need a railtie for action cable. We need to change [`rails/all`](https://github.com/rails/rails/blob/574f255629a45cd67babcfb9bb8e163e091a53b8/railties/lib/rails/all.rb) to load this new railtie. We will also need a `skip_actioncable` option and to update the [`application.rb`](https://github.com/rails/rails/blob/574f255629a45cd67babcfb9bb8e163e091a53b8/railties/lib/rails/generators/rails/app/templates/config/application.rb#L11) to take in consideration that.
All these missing things will address the @sgrif comment about redis being required.","1","2015-12-14T16:08:33Z"
"247916","20054","164482775","2741","dhh","Closed in favor of #22586.","1","2015-12-14T16:20:22Z"
"247917","20055","164598271","113026","tubbo","It is `Time.now.zone`.","1","2015-12-14T23:56:06Z"
"247918","20056","164542845","7468109","rails-bot","r? @schneems
(@rails-bot has picked a reviewer for you, use r? to override)","1","2015-12-14T20:00:37Z"
"247919","20056","164549501","632942","cllns","Looks like the travis build failure is unrelated to my code: `ActiveModel::Type::IntegerTest#test_casting_nan_and_infinity`","1","2015-12-14T20:27:01Z"
"247920","20057","164559585","7468109","rails-bot","r? @rafaelfranca
(@rails-bot has picked a reviewer for you, use r? to override)","1","2015-12-14T21:05:24Z"
"247921","20057","165956325","199","jeremy","Nice work!
Oracle, SQL Server, MariaDB, and others support virtual/computed/generated columns too. ""Generated"" seems to be the least common name: https://en.wikipedia.org/wiki/Virtual_column
Note that all the other column options don't make sense for a virtual column. Perhaps they should be explicitly declared as virtual columns rather than adding a handful of options to normal columns:
```diff
change_table :people do |t|
- t.string :lower_name, as: 'LOWER(name)'
+ t.virtual :lower_name, as: 'LOWER(name)'
end
```","1","2015-12-19T07:14:06Z"
"247922","20057","166182411","12642","kamipo","I added `virtual` method for declaring virtual columns such like oracle adapter.
https://github.com/rsim/oracle-enhanced/blob/3c42131db82b64ac41645db3affc6e4650289df6/spec/active_record/connection_adapters/oracle_enhanced_schema_dump_spec.rb#L370-L388
```ruby
create_table :generated_columns do |t|
t.string :name
t.virtual :upper_name, type: :string, as: 'UPPER(name)'
t.virtual :name_length, type: :integer, as: 'LENGTH(name)', stored: true
end
```
And added `AbstractAdapter#supports_virtual_columns?` and renamed `s/generated/virtual/`.
@jeremy What do you think about it?","1","2015-12-21T02:46:13Z"
"247923","20057","166199280","1034","matthewd","This seems awfully view-like. Is it DSL-worthy?
We generally take the position that if you need more advanced database features, you're better served by `structure.sql`.","1","2015-12-21T04:12:10Z"
"247924","20058","164564151","7468109","rails-bot","Thanks for the pull request, and welcome! The Rails team is excited to review your changes, and you should hear from @chancancode (or someone else) soon.
If any changes to this PR are deemed necessary, please add them as extra commits. This ensures that the reviewer can see what has changed since they last reviewed the code. Due to the way GitHub handles out-of-date commits, this should also make it reasonably obvious what issues have or haven't been addressed. Large or tricky changes may require several passes of review and changes.
Please see [the contribution instructions](http://edgeguides.rubyonrails.org/contributing_to_ruby_on_rails.html) for more information.
","1","2015-12-14T21:24:14Z"
"247925","20058","164564153","7468109","rails-bot","<img src=""http://www.joshmatthews.net/warning.svg"" alt=""warning"" height=20> **Warning** <img src=""http://www.joshmatthews.net/warning.svg"" alt=""warning"" height=20>
* Pull requests are usually filed against the master branch for this repo, but this one is against 2-0-stable. Please double check that you specified the right target!","1","2015-12-14T21:24:14Z"
"247926","20059","164582110","7468109","rails-bot","r? @chancancode
(@rails-bot has picked a reviewer for you, use r? to override)","1","2015-12-14T22:36:56Z"
"247927","20060","164583218","7468109","rails-bot","Thanks for the pull request, and welcome! The Rails team is excited to review your changes, and you should hear from @eileencodes (or someone else) soon.
If any changes to this PR are deemed necessary, please add them as extra commits. This ensures that the reviewer can see what has changed since they last reviewed the code. Due to the way GitHub handles out-of-date commits, this should also make it reasonably obvious what issues have or haven't been addressed. Large or tricky changes may require several passes of review and changes.
Please see [the contribution instructions](http://edgeguides.rubyonrails.org/contributing_to_ruby_on_rails.html) for more information.
","1","2015-12-14T22:41:58Z"
"247928","20060","165236405","1080678","eileencodes","Hi @nwjsmith, thanks for the PR. Can you squash your commits and leave out the changes where you removed spacing from files you didn't make other changes in? We prefer not to merge changes that just are cosmetic in nature because it's harder to see the history with `git blame`. ","1","2015-12-16T20:33:11Z"
"247929","20060","165247558","1348","nwjsmith","@eileencodes all set","1","2015-12-16T21:12:13Z"
"247930","20060","165286058","1080678","eileencodes","Thank you!","1","2015-12-16T23:31:18Z"
"247931","20060","165307875","1348","nwjsmith","Thanks for taking the time to go over this","1","2015-12-17T01:22:02Z"
"247932","20060","165594494","1080678","eileencodes","Hey @nwjsmith do you want to take a stab at adding documentation to the guides for this as well? I think it would be really useful for future users. ","1","2015-12-17T22:00:54Z"
"247933","20060","165874563","1348","nwjsmith","@eileencodes for sure. I'll get something done an posted by Sunday night. Thanks","1","2015-12-18T19:15:48Z"
"247934","20060","165876220","59744","schneems","On a tangential note, i'm thinking we need to add some sort of accessor to logger to see where it's source is going so then we could write code that says log to stdout unless you're already logging to stdout. I ran into this in https://github.com/heroku/rails_stdout_logging/pull/18","1","2015-12-18T19:24:28Z"
"247935","20060","165903329","3194530","marshall-lee","@schneems yep!","1","2015-12-18T21:39:29Z"
"247936","20061","164583797","7468109","rails-bot","Thanks for the pull request, and welcome! The Rails team is excited to review your changes, and you should hear from @pixeltrix (or someone else) soon.
If any changes to this PR are deemed necessary, please add them as extra commits. This ensures that the reviewer can see what has changed since they last reviewed the code. Due to the way GitHub handles out-of-date commits, this should also make it reasonably obvious what issues have or haven't been addressed. Large or tricky changes may require several passes of review and changes.
Please see [the contribution instructions](http://edgeguides.rubyonrails.org/contributing_to_ruby_on_rails.html) for more information.
","1","2015-12-14T22:44:42Z"
"247937","20061","164583883","1504464","RochesterinNYC","Addresses #22408 ","1","2015-12-14T22:45:06Z"
"247938","20061","165497700","1504464","RochesterinNYC","@pixeltrix any thoughts on this?","1","2015-12-17T16:14:42Z"
"247939","20061","165549353","1034","matthewd","This is extremely incorrect. If `a7` is already taken by some other query, we absolutely can't start calling that in place of this query next time.","1","2015-12-17T19:01:31Z"
"247940","20062","164684492","2741","dhh","?","1","2015-12-15T08:35:39Z"
"247941","20063","164642844","7468109","rails-bot","r? @eileencodes
(@rails-bot has picked a reviewer for you, use r? to override)","1","2015-12-15T04:33:58Z"
"247942","20063","164680265","350807","kaspth","You need to require the core_ext files that implement the methods you've added, so the isolation tests that run on merges pass. Thanks ?","1","2015-12-15T08:12:05Z"
"247943","20063","164720571","987638","y-yagi","oops sorry. I added the necessary require, and ran the isolation test.
Thanks for reviewing!
","1","2015-12-15T10:35:46Z"
"247944","20063","164774945","1080678","eileencodes","Thanks! :smile: ","1","2015-12-15T14:07:26Z"
"247945","20063","164777192","987638","y-yagi","Thanks!","1","2015-12-15T14:16:05Z"
"247946","20064","164746691","7468109","rails-bot","r? @pixeltrix
(@rails-bot has picked a reviewer for you, use r? to override)","1","2015-12-15T12:13:09Z"
"247947","20064","164746749","5356517","yui-knk","ref #22460 ","1","2015-12-15T12:13:25Z"
"247948","20064","164793991","10076","claudiob",":+1: @yui-knk :smile:
As part of this commit, I think you should also remove [this documentation](https://github.com/rails/rails/blob/master/activerecord/lib/active_record/callbacks.rb#L178-L191).","1","2015-12-15T15:13:46Z"
"247949","20064","165066964","5356517","yui-knk","@rafaelfranca I updatd :heart_eyes: ","1","2015-12-16T10:59:12Z"
"247950","20065","866507","9582","josevalim","applied, tks!","1","2011-03-13T18:57:02Z"
"247951","20067","164800976","7468109","rails-bot","Thanks for the pull request, and welcome! The Rails team is excited to review your changes, and you should hear from @eileencodes (or someone else) soon.
If any changes to this PR are deemed necessary, please add them as extra commits. This ensures that the reviewer can see what has changed since they last reviewed the code. Due to the way GitHub handles out-of-date commits, this should also make it reasonably obvious what issues have or haven't been addressed. Large or tricky changes may require several passes of review and changes.
Please see [the contribution instructions](http://edgeguides.rubyonrails.org/contributing_to_ruby_on_rails.html) for more information.
","1","2015-12-15T15:37:51Z"
"247952","20067","164800977","7468109","rails-bot","<img src=""http://www.joshmatthews.net/warning.svg"" alt=""warning"" height=20> **Warning** <img src=""http://www.joshmatthews.net/warning.svg"" alt=""warning"" height=20>
* Pull requests are usually filed against the master branch for this repo, but this one is against merge-action-cable. Please double check that you specified the right target!","1","2015-12-15T15:37:51Z"
"247953","20068","165006911","7468109","rails-bot","Thanks for the pull request, and welcome! The Rails team is excited to review your changes, and you should hear from @pixeltrix (or someone else) soon.
If any changes to this PR are deemed necessary, please add them as extra commits. This ensures that the reviewer can see what has changed since they last reviewed the code. Due to the way GitHub handles out-of-date commits, this should also make it reasonably obvious what issues have or haven't been addressed. Large or tricky changes may require several passes of review and changes.
Please see [the contribution instructions](http://edgeguides.rubyonrails.org/contributing_to_ruby_on_rails.html) for more information.
","1","2015-12-16T06:02:10Z"
"247954","20068","165012092","270688","nettofarah","ps: I started out by just removing `README.rdoc` altogether. But later on thought that it could be a good idea to keep both options for some time.","1","2015-12-16T06:16:38Z"
"247955","20068","165383879","270688","nettofarah","r? @rafaelfranca","1","2015-12-17T08:36:27Z"
"247956","20068","165426638","2741","dhh","Let's just move to .md as the default format. No need for an option. Feel free to open a new PR with that, thanks!","1","2015-12-17T11:17:50Z"
"247957","20068","165537446","270688","nettofarah","Sounds great! Will do!","1","2015-12-17T18:21:46Z"
"247958","20069","165021921","7468109","rails-bot","Thanks for the pull request, and welcome! The Rails team is excited to review your changes, and you should hear from @rafaelfranca (or someone else) soon.
If any changes to this PR are deemed necessary, please add them as extra commits. This ensures that the reviewer can see what has changed since they last reviewed the code. Due to the way GitHub handles out-of-date commits, this should also make it reasonably obvious what issues have or haven't been addressed. Large or tricky changes may require several passes of review and changes.
Please see [the contribution instructions](http://edgeguides.rubyonrails.org/contributing_to_ruby_on_rails.html) for more information.
","1","2015-12-16T07:25:30Z"
"247959","20069","165163879","47848","rafaelfranca"," :heart: :green_heart: :blue_heart: :yellow_heart: :purple_heart:","1","2015-12-16T16:23:32Z"
"247960","20070","1656458","111473","vatrai","autoloading ConnectionAdapters in active_record.rb. here(https://github.com/castlerock/rails/commit/1efd88283ef68d912df215125951a87526768a51).
No need to have a explicit require in mysql,sqlite and postgresql adapters.
/cc @tenderlove","1","2011-07-26T17:59:02Z"
"247961","20070","2420085","111473","vatrai","closing. mysql_adapter.rb is already changed. I will make a pull request for postgresql_adapter and sqlite_adapter","1","2011-10-16T09:29:55Z"
"247962","20071","1648053","10308","sferik","Oops, I didn't realize there was already a 3-1-stable branch. This patch was intended to apply to that, not master.","1","2011-07-25T18:49:37Z"
"247963","20071","1648985","9582","josevalim","But does this exist on master already? If not, we need to apply it on both
master and 3-1-stable!","1","2011-07-25T20:41:48Z"
"247964","20071","1649314","10308","sferik","@josevalim ping! This is ready to be pulled into master now.","1","2011-07-25T21:17:25Z"
"247965","20072","1648456","18524","bcardarella","Does this make sense for 3.1? It's already in release candiate, this should probably go to master","1","2011-07-25T19:40:14Z"
"247966","20072","1648532","10308","sferik","Sad face. If it has to wait until 3.2, I suppose it can wait.
I guess I'd argue it's a pretty obvious missing feature (i.e. the fact that you can say `:format => false` but not `:format => true` feels like a bug). Of course, the last thing I'd want to do is hinder the 3.1 release process.
To whoever gets to make the call: Just let me know what you want me to do. I'm happy to submit another pull request that applies to master.","1","2011-07-25T19:49:11Z"
"247967","20072","1648565","18524","bcardarella","Yeah, I hear you. It just feels dirty introducing new public api behavior in a RC cycle","1","2011-07-25T19:53:59Z"
"247968","20072","1648800","18524","bcardarella","pinging @tenderlove","1","2011-07-25T20:19:55Z"
"247969","20072","1649012","9582","josevalim","It is fine to go into 3-1-stable. @sferik, if this is not in master yet, please reopen that other pull request and ping me.","1","2011-07-25T20:44:55Z"
"247970","20072","1649026","18524","bcardarella","sweet :)","1","2011-07-25T20:45:54Z"
"247971","20073","1650120","3124","tenderlove","Any chance we could get a test along with this?","1","2011-07-25T22:53:28Z"
"247972","20073","1653086","75699","tanelsuurhans","This does not seem to fix the issue, still able to reproduce it. Will close this pull request.","1","2011-07-26T10:27:25Z"
"247973","20074","1648964","9582","josevalim","Thanks for the pull request. We are not changing the default value. By default we are going to run bundler.","1","2011-07-25T20:39:45Z"
"247974","20075","1651035","160941","guilleiguaran","Already done :)","1","2011-07-26T02:05:45Z"
"247975","20076","1651292","9582","josevalim","Isn't there a file missing in this commit?","1","2011-07-26T03:07:08Z"
"247976","20076","1651341","3948","arunagw","Closing this as it's done is master if different way by @spastorino","1","2011-07-26T03:21:21Z"
"247977","20077","1800230","51165","tekwiz","I agree that this is a much needed improvement. With our application, it can take up to 80 seconds to generate ActionView::Base#inspect for a NoMethodError. That said, I think this should be configurable since there is additional data that needs to be included in error reports. In the case of the ActionView::Base, the name of the controller is extremely important.","1","2011-08-14T02:38:08Z"
"247978","20077","5398533","651597","isaacsanders","@xaviershay Is this still an issue?","1","2012-04-28T17:30:52Z"
"247979","20077","5401692","1714","xaviershay","Probably not. I'll reopen if it troubles me.","1","2012-04-29T01:05:22Z"
"247980","20079","1652135","9347","dmathieu","What about the stylesheets then ?","1","2011-07-26T07:04:57Z"
"247981","20079","1652479","127960","nfm","I'm not sure about including stylesheets. In my mind they fall into a different category to application code and client-side code. I guess this wouldn't matter except that the aggregate stats (Code LOC, Test LOC, Code to Test Ratio) could be skewed significantly by them.
What do you think?","1","2011-07-26T08:18:48Z"
"247982","20079","3508337","127960","nfm","@josevalim While you're tackling code stats (#4478) can you please take a look at this pull request too?","1","2012-01-16T09:49:22Z"
"247983","20079","4409476","264590","dgilperez","+1","1","2012-03-09T03:51:05Z"
"247984","20079","4827914","8155","ebeigarts","+1","1","2012-03-29T18:35:41Z"
"247985","20079","5419132","17538","eviltrout","+1","1","2012-04-30T14:58:46Z"
"247986","20079","5680999","27786","steveklabnik","> Should I rebase on master and submit a second pull request?
As a general note, you can rebase whatever in your branch, and then force push, and GitHub will update the pull request properly.","1","2012-05-14T00:50:42Z"
"247987","20079","5683201","9582","josevalim","I think in this case, a new pull request needs to be sent because this one targets branch 3-1-stable and pull requests should be sent for master. Thanks!!","1","2012-05-14T06:07:10Z"
"247988","20079","6037028","47848","rafaelfranca","Closed by #6566","1","2012-05-31T14:19:41Z"
"247989","20083","1655450","6351","dasch","Have you benchmarked the impact this will have on performance? It'll add an extra level of indirection to all delegate calls.","1","2011-07-26T16:02:53Z"
"247990","20083","1662143","122436","bogdan","Here is my test file https://gist.github.com/1108920
The first benchmark is to test intialization.
The second benchmark is to test execution
Here is what I get on 1.8.7:
```
Rehearsal ------------------------------------
0.060000 0.010000 0.070000 ( 0.062110)
0.040000 0.000000 0.040000 ( 0.045726)
--------------------------- total: 0.110000sec
user system total real
0.060000 0.000000 0.060000 ( 0.070937)
0.050000 0.000000 0.050000 ( 0.049464)
Rehearsal ------------------------------------
0.010000 0.000000 0.010000 ( 0.014390)
0.010000 0.000000 0.010000 ( 0.007766)
--------------------------- total: 0.020000sec
user system total real
0.000000 0.000000 0.000000 ( 0.004052)
0.000000 0.000000 0.000000 ( 0.005466)
```
And for 1.9.2
```
Rehearsal ------------------------------------
0.090000 0.000000 0.090000 ( 0.099133)
0.090000 0.000000 0.090000 ( 0.083098)
--------------------------- total: 0.180000sec
user system total real
0.120000 0.010000 0.130000 ( 0.132569)
0.090000 0.000000 0.090000 ( 0.096892)
Rehearsal ------------------------------------
0.010000 0.000000 0.010000 ( 0.007009)
0.010000 0.000000 0.010000 ( 0.008096)
--------------------------- total: 0.020000sec
user system total real
0.010000 0.000000 0.010000 ( 0.002482)
0.000000 0.000000 0.000000 ( 0.002776)
```","1","2011-07-27T08:33:16Z"
"247991","20083","2341262","199","jeremy","Could you rebase against master?","1","2011-10-09T21:31:58Z"
"247992","20083","2359108","122436","bogdan","Closed. See #3290 instead.","1","2011-10-11T08:55:59Z"
"247993","20084","3521528","20319","claco","Funny. I just noticed it's documented as working this way, but doesn't:
http://api.rubyonrails.org/classes/ActiveRecord/QueryMethods.html#method-i-select
This method will also take multiple parameters:
>> Model.select(:field, :other_field, :and_one_more)
=> [#<Model field: ""value"", other_field: ""value"", and_one_more: ""value"">]","1","2012-01-17T01:27:01Z"
"247994","20084","3521736","335510","danshultz","Yeah docs are wrong - but it does work
```ruby
Model.select([:field, :other_field, :and_one_more]).first
=> #<Model field: value, other_field: value, and_one_more: value>
```","1","2012-01-17T01:47:49Z"
"247995","20084","5402724","48928","ahawkins","@danshultz The code is documented correctly. https://github.com/rails/rails/blob/master/activerecord/lib/active_record/relation/query_methods.rb#L111
You should submit a PR if you want this functionality.
@steveklabnik can you close this?","1","2012-04-29T05:09:02Z"
"247996","20084","5402740","47848","rafaelfranca","Closing it now. Please use the documented API.","1","2012-04-29T05:12:48Z"
"247997","20084","5404750","335510","danshultz","@twinturbo I'll review this further and decide if it's worth pursing but as a note - this issue (of documentation) was actually resolved 2 days after the comments on the pull request.
https://github.com/rails/rails/commit/e95e932fbe38617b72f21fde6cac53f49473d881
Thanks,
Dan","1","2012-04-29T12:46:13Z"
"247998","20088","876182","52642","spastorino","Pushed","1","2011-03-15T13:45:51Z"
"247999","20088","876191","5042","norman","Thank you sir. :)","1","2011-03-15T13:49:44Z"
"248000","20089","1655979","52642","spastorino","This was already fixed [here](https://github.com/jimweirich/rake/issues/51)","1","2011-07-26T17:06:36Z"
"248001","20091","1656603","3124","tenderlove","Please send this pull request for master. It's not fixing any bugs, so I won't merge to 3-1-stable. We can consider backporting after 3.1.0 is released.","1","2011-07-26T18:17:33Z"
"248002","20091","1656735","29122","dgeb","I will send this to master. However, there is one small bug that this addresses: the app/mailers directory isn't included in ""rails plugin new --full"". Let me know if you want me to submit a separate issue and pull request for that fix in 3-1-stable.","1","2011-07-26T18:36:59Z"
"248003","20091","1656989","9582","josevalim","Please provide a pull request adding app/mailers to 3-1-stable.","1","2011-07-26T19:09:05Z"
"248004","20091","1657335","29122","dgeb","Please see https://github.com/rails/rails/pull/2287 for the app/mailers fix.","1","2011-07-26T19:55:17Z"
"248005","20091","1657359","52642","spastorino","@dgeb also I'd like to see this for master but in atomic and more meaningful commits. You're doing lot of things in just one commit. Please split them, each of one should have one purpose. Thanks!","1","2011-07-26T19:59:21Z"
"248006","20091","1657445","29122","dgeb","Fair enough @spastorino - that's actually my normal process, but I lumped these changes together because I've seen requests on other pull requests to squash commits. Live and learn - I'm pretty new around here :)
Anyway, I'll restructure this pull request for master, albeit without the app/mailers fix already in 2287. Thanks for everyone's input.","1","2011-07-26T20:10:20Z"
"248007","20091","1657824","52642","spastorino","@dgeb We use to ask for squashes when people is committing atomic stuff in different commits.
I've seen pull requests with one commit, one which revert the original commit, another one to add a test, another adding more tests and another with the patch for this new test, true story :P.","1","2011-07-26T21:07:37Z"
"248008","20091","1657884","29122","dgeb","@spastorino - Crazy! No doubt squash can be both over AND under applied :)","1","2011-07-26T21:17:55Z"
"248009","20091","1660869","29122","dgeb","I've resubmitted this for master in several atomic commits: https://github.com/rails/rails/pull/2295
In testing, I determined that there actually is a bug that this addresses for 3-1-stable: ""rake test"" doesn't pass for generated plugins by default without specifying the ""--full"" or ""--mountable"" options. This is due to a missing dependency issue: the database database_gemfile_entry is only included for full or mountable plugins, and yet it's required to run tests regardless. On a related note, the database gem should probably be a development, not a base, dependency by default.
I'm not sure if these minor issues make my pull request worthwhile for 3-1-stable. However, I've had a lot of trouble determining best practices for using ""rails plugin new"", and I think these changes would help get developers off to a good start with this new feature.","1","2011-07-27T02:58:07Z"
"248010","20093","1656614","8701","joshk","Please apply this to 3-0-stable and 3-1-stable as well :)","1","2011-07-26T18:19:11Z"
"248011","20095","1661058","29122","dgeb","I am puzzled. This commit shows two diffs, yet shows only a single file in the github viewer. My intention was to also include the following directory by committing a .empty_directory file:
https://github.com/dgeb/rails/tree/3-1-mailers-in-plugins/railties/lib/rails/generators/rails/plugin_new/templates/app/mailers
The reason I wanted to include this directory is that it's apparently missing from:
https://github.com/rails/rails/tree/3-1-stable/railties/lib/rails/generators/rails/plugin_new/templates/app
I don't know why this directory and .empty_directory file seem to be missing from this commit. Perhaps it's there and there is a glitch in the github viewer?
Anyway, the point is that this needs to get into 3-1-stable so that the full app structure is available for new plugins. Thanks in advance.","1","2011-07-27T03:50:08Z"
"248012","20095","1666361","9582","josevalim","Merged. And yes, probably a github bug.","1","2011-07-27T18:37:58Z"
"248013","20095","1666703","29122","dgeb","Looks like the directory made it with the merge, so I guess you're right. Thanks for the merge and the clarification.","1","2011-07-27T19:16:23Z"
"248014","20095","1676121","29122","dgeb","@josevalim - looks like this still needs to be merged with master. For future reference, would it have been better for me to target master and then ask you to backport to 3-1-stable?","1","2011-07-28T20:21:20Z"
"248015","20095","1680254","9582","josevalim","Yes! Could you please provide a patch for master and ping me? :) Thanks for everything!","1","2011-07-29T10:24:59Z"
"248016","20095","1680771","29122","dgeb","@josevalim - Glad to help :) Please see https://github.com/rails/rails/pull/2339","1","2011-07-29T12:22:34Z"
"248017","20098","886359","3124","tenderlove","type_case_code should never return nil. Are you using mysql2 with edge rails by chance?","1","2011-03-17T18:46:24Z"
"248018","20098","887013","76936","damianham","yes I am","1","2011-03-17T21:27:39Z"
"248019","20098","887045","3124","tenderlove","If you're working against edge rails, please use edge mysql2. We've moved the database adapter from mysql2 in to rails master. That should fix this problem! :-)","1","2011-03-17T21:33:59Z"
"248020","20098","887939","76936","damianham","well I hate to be a pedant but this wasn't helpful. I am not a rails core committer - just a rails user that hit a problem that others will hit and tried to be helpful with a 1 line fix. Going by this quote from the Rails 3 release notes at http://guides.rubyonrails.org/3_0_release_notes.html
""On top of all that, we’ve tried our best to deprecate the old APIs with nice warnings. That means that you can move your existing application to Rails 3 without immediately rewriting all your old code to the latest best practices.""
I don't think it unreasonable to expect to be able to use the mysql2 gem with my rails 3 application. I found zero info when searching for various combinations of ""use edge mysql2"". So how do I how ""use edge mysql2"" with edge rails ? and wouldn't it be better to include this simple 1 line fix that tests for this case rather than just blow up if things aren't the exact way you want them ?","1","2011-03-18T03:00:24Z"
"248021","20098","888202","3124","tenderlove","The Rails Gemfile in master clearly works against the unreleased version of the mysql2 gem. If you are going to work against edge rails, you need to work against the dependencies listed in our Gemfile.","1","2011-03-18T05:26:15Z"
"248022","20099","1658945","52642","spastorino","We need a test case for this","1","2011-07-26T22:16:41Z"
"248023","20099","1665374","202410","thoefer","applying this patch also closes #2031","1","2011-07-27T16:39:02Z"
"248024","20099","1665463","9347","dmathieu","Could you squash your commits please ?
If you add ""Closes #2031"" in the commit message, the issue will be automatically closed when the pull request will be merged.","1","2011-07-27T16:49:29Z"
"248025","20099","1665523","202410","thoefer","Thanks for this hint regarding the commit message. Ok – I close this and provide a new PR. ","1","2011-07-27T16:55:56Z"
"248026","20099","1665572","9347","dmathieu","You don't have to close the PR. You can juste change the commits and push --force to the same branch, the PR will be automatically updated.","1","2011-07-27T17:01:13Z"
"248027","20101","1660480","52642","spastorino","This is due to a bug in rake https://github.com/jimweirich/rake/issues/51","1","2011-07-27T01:01:49Z"
"248028","20101","1661052","160941","guilleiguaran","@spastorino thanks for clarifying","1","2011-07-27T03:47:12Z"
"248029","20102","1667773","52642","spastorino","so @dgeb can you change the commits and make a push -f to your repo?","1","2011-07-27T21:10:46Z"
"248030","20102","1667827","29122","dgeb","Will do @spastorino - thanks for the code review.","1","2011-07-27T21:15:17Z"
"248031","20102","1672861","29122","dgeb","@spastorino - I've updated the commits with all the changes we've discussed.","1","2011-07-28T14:06:17Z"
"248032","20103","1661936","3387","fxn","Which are the changes in the second and third hunks?","1","2011-07-27T07:49:44Z"
"248033","20103","1661990","191128","lsylvester","respond_do? replaced with respond_to?","1","2011-07-27T08:03:03Z"
"248034","20104","406545","6180","carllerche","Pulled, thanks","1","2010-09-14T17:26:10Z"
"248035","20105","1057561","136796","SweeD","This ticket would be the begin of extending active resource with more restful features.
(like association link resolving as seen in Atomic-feeds)","1","2011-04-26T10:27:16Z"
"248036","20105","1064373","3359","miloops","What about belongs_to? If we add has_many and has_one is intuitive to have belongs_to associations, right?","1","2011-04-27T14:03:01Z"
"248037","20206","18416456","113548","likethesky","Thanks @vipulnsward ... I made a comment there asking if this will be backported to other Rails versions. I also confirmed that your fix does indeed fix our issue in both MRI (p429) and in JRuby (on 1.9.3-p392 [jruby 1.7.4], which surprisingly *doesn't* fail on MRI p392, even though it does on MRI p429!). Cheers.","1","2013-05-24T16:45:06Z"
"248038","20233","1754960","16925","ncri","Thanks. I opened an issue here: https://github.com/rails/rails/issues/2461","1","2011-08-08T15:17:44Z"
"248039","20277","981273","2741","dhh","inside/outside is a nice pair, but I like #in? a lot more than #inside? -- and given that in? is going to be a lot more common than it's negation, I think that takes precedence. But best suggestion I've heard so far on it!","1","2011-04-10T22:06:17Z"
"248040","20277","981277","2741","dhh","(BTW, thanks to everyone commenting on this, whether you agree or disagree. I like that we can have discussions like this about the syntactic sugar.)","1","2011-04-10T22:07:53Z"
"248041","20277","981303","10112","elight","I was contemplating #outside? but passed on mentioning it. It feels odd in contrast to #in?. Agreed that the negative case will be far less common. However, compared to the other syntactic sugar introduced by Rails, #in?/#outside? feels like a more awkward pairing. I'd like to be more constructive. Sadly, a brief visit to the thesaurus doesn't yield anything better either.
On Sunday, April 10, 2011 at 6:06 PM, dhh wrote:
> inside/outside is a nice pair, but I like #in? a lot more than #inside? -- and given that in? is going to be a lot more common than it's negation, I think that takes precedence. But best suggestion I've heard so far on it!
>
> --
> Reply to this email directly or view it on GitHub:
> https://github.com/rails/rails/pull/258#issuecomment-981273
>","1","2011-04-10T22:12:57Z"
"248042","20277","981361","472","sudara","> New restriction for the not #in? game -- it has to be a single word.
This isn't what you want to hear, but perhaps the best way to express the negative is as as you just did — ""not in."" The only other options seem more complex and probably are not as intuitive/memorable (such as ""absent from""). I understand the lack of sexiness, but maybe it's best to go with what is straightforward and simple.","1","2011-04-10T22:37:09Z"
"248043","20277","981368","2741","dhh","sudara, we already have the not version: !object.in?(enumerable) -- moving the not into the method name and adding an underscore isn't an improvement over what we already have.","1","2011-04-10T22:38:41Z"
"248044","20277","981375","472","sudara","dhh: Yeah, was thinking exactly about that after I posted. !object.in? is kind of freaky looking though. ","1","2011-04-10T22:41:48Z"
"248045","20277","981389","166528","phene","+1 for inside/outside, though another might be in?/omited?","1","2011-04-10T22:49:04Z"
"248046","20277","981455","2406","jamesarosen","It's a shame we can't write `object ∈ enumerable`. I'd be happy with `object.∈(enumerable)`, but it's a pain to type.","1","2011-04-10T23:17:13Z"
"248047","20277","981502","197567","leejarvis","-1 for inside/outside. Although `inside?` makes sense, `in?` is **much** nicer. `outside?` makes no sense at all. It's not a negative argument, it's positive. 'Foo is outside of bar' isn't telling us that foo isn't in bar, it's directly telling us it's outside of it, thus the lack of negativity. 'foo is not inside bar' would be more applicable, which is why `not_in?` works so well, but I agree the added underscore isn't nice.
I'm with @josevalim with a -1 on this. It feels backward and without a suitable antonym for `in?` I think it's a lost cause","1","2011-04-10T23:32:44Z"
"248048","20277","981507","1401","h3h","`Object#omitted?` and `Object#missing?` are the best proposals for an opposite to `#in?` that I've heard thus far.
For cheekiest, though, I'd pick `#awol?`.","1","2011-04-10T23:34:39Z"
"248049","20277","981514","197567","leejarvis","@h3h If something like this is to be added, I think it needs to fit perfectly and neither of those do. `person.omitted?(people)` doesn't make much sense, same for `person.missing?(people)` if anything `people.missing?(person)` would make more sense, with `missing_from?` and `omitted_from?` being the negative of those (again, back to ugly)","1","2011-04-10T23:37:35Z"
"248050","20277","981517","98601","jfirebaugh","+1 on `in?`, -1 on `either?`. ""Either"" implies exactly two alternatives; it isn't the right name for a function of arbitrary arity. Plus the expressiveness improvement of `object.either?(a, b)` over `object.in?([a, b])` just isn't that great.","1","2011-04-10T23:38:10Z"
"248051","20277","981570","1401","h3h","@injekt is right—English just isn't structured to encapsulate ""not in"" or ""missing from"" as a single world. One could invent a new pseudo-word that has all of the other desirable properties (except being a real word): `#nin?`.
I also tend to agree with @jfirebaugh: `#either?` makes no sense for calls with an arity other than 2. I think `#one_of` and `#none_of` would fit much better for arbitrary arity, but of course that pesky underscore is back.","1","2011-04-10T23:49:07Z"
"248052","20277","981662","2406","jamesarosen","I don't have an answer for the negative case, but perhaps `#among` would be a good one for the positive.","1","2011-04-11T00:27:55Z"
"248053","20277","981723","2406","jamesarosen","`#within?` and `#without?` are a nice pair. Most people use ""without"" to mean ""lacking"" rather than ""outside of,"" but the latter is a completely valid meaning of the word.","1","2011-04-11T00:52:18Z"
"248054","20277","981724","1111","patmaddox","I'd like to point out that the meaning of #either? was initially very confusing to me. My best guess at why it was named #either? was somewhat similar to #inject ... that it is idiomatic in functional programming, or carries over from some other language or paradigm. But as far as communicating intent goes, it went absolutely over my head. If the point is to ask an object whether it is one of a list of items, then I think foo.one_of?(1, 2, 3) makes a lot more sense to me. Or maybe #either_of? That reads more naturally to me, but I tend to prefer slightly more verbose method names than keeping them super terse, so that may just be a matter of personal preference.
I just spent a few minutes looking over the diff where include? was changed to in? or either?. I have to say, I do like it. I agree with David's comment about it making the important object front and center. The one criticism I have is that by adding these two new methods, you are adding to the body of stuff that programmers have to learn and remember. The distinction between these two methods is sensible to me - #in? is asking about a pre-existing collection, so that's made explicit. #Either? is asking about an abitrary list of objects, so that uses the splat. I remember when I was first getting into Rails, splat arguments caused me a lot of confusion. I'm better off for figuring them out though :)
I guess the question is, is the added expressiveness for seasoned Rails folks worth increasing the burden on beginning Ruby and Rails developers (and of course, whether there really *is* any added expressiveness, which in my opinion is yes). I’ll leave that up to you to sort out. In the mean time, I’ll just toss these into some pairing sessions and see how people react :)","1","2011-04-11T00:52:33Z"
"248055","20277","981780","39729","glongman","<code>either?</code> doesn't sit well with me. When I read ""either"" I think ""this or that"" and not ""this or that or that or that or .... or that"".
<code>within()?</code> is nice but <code>without?()</code> doesn't feel right.
I'd rather write <code>!""foo"".within?(""a"",""b"")</code> than <code>""foo"".without?(""a"",""b"")</code>","1","2011-04-11T01:12:11Z"
"248056","20277","982064","16054","plukevdh","I'm all for api expansion. It's not like it makes a big difference, guys.","1","2011-04-11T03:36:30Z"
"248057","20277","982234","166528","phene","plukevdh: Actually, it does:
https://github.com/rails/rails/commit/a9f3c9da01d721963d05949604ead909aaabbf36#commitcomment-336541","1","2011-04-11T05:26:46Z"
"248058","20277","982238","11460","pwnall","I really like in? and nin? as a pair.","1","2011-04-11T05:28:41Z"
"248059","20277","982681","2741","dhh","I looked up the definition on ""either"" and found: ""conjunction & adverb, 1 used before the first of two (or occasionally more) alternatives that are being specified (the other being introduced by “or”)"". So it seems fine to use it for a list including more than two elements.
pwnall, Not a fan of nin?
Keep the game going, though!","1","2011-04-11T08:45:02Z"
"248060","20277","983068","15641","samoli","How about Object#in? and Object#omits?
Edit: forget that, omits? doesn't make sense. Object#omitted? is better but doesn't read nicely.","1","2011-04-11T11:01:03Z"
"248061","20277","983187","585132","neverhood","Object#in? and Object#beyond? :)","1","2011-04-11T11:30:33Z"
"248062","20277","983821","384540","jazminschroeder","For what is worth..
Among non-developers out? is the best second choice (not_in? is number one)","1","2011-04-11T14:24:45Z"
"248063","20277","984047","198","croaky","+1 #in? and #either? They read beautifully in every one of the examples in the diff except for the not versions, like this line:
if method && !method.to_s.either?('get','post')
I want the ""not"" to be located right before the adjective, not separated by such distance.
if method && method.to_s.not_either?('get','post')
I write these kinds of methods in my own apps, but it's tiresome. It might be nice to have a more powerful abstraction in ActiveSupport:
if method && method.to_s.not.either?('get','post')
Essentially the same thing as [jQuery's .not() method](http://api.jquery.com/not-selector/).
Jay Fields wrote [an implementation of #not in Ruby](http://blog.jayfields.com/2007/08/ruby-adding-not-method-for-readability.html) in a few years ago.","1","2011-04-11T14:49:52Z"
"248064","20277","984129","2406","jamesarosen","@dhh ""either"" *can* be for more than two, but ""among"" is used for that *much* more often.
* [either](http://dictionary.reference.com/browse/either) -- ""Any one of two; one or the other""
* [among](http://www.thefreedictionary.com/among) -- "" In the group, number, or class of""
* [amid](http://www.thefreedictionary.com/amid) -- ""Surrounded by; in the middle of""
Specifically, see [amid, amidst, among](http://writingtips.wordpress.com/2007/09/01/amid-amidst-among/) -- ""Amidst (or amid) is often confused with among. The Online Dictionary defines amidst as being in the middle of or surrounded by something, and among as mingling or intermixing with distinct or separate objects.""
Thus, I think *among* is the proper word here.","1","2011-04-11T15:05:59Z"
"248065","20277","984303","2741","dhh","jamesarosen, I love it. among is exactly the right word here. We'll get it changed.","1","2011-04-11T15:42:46Z"
"248066","20277","984759","16927","BMorearty","@sikachu, thank you for graciously giving credit to me and John Reitano (@rubyduo) for the original patch and citing the original ticket & discussion--and for going beyond what we did by changing the Rails internals to use `Object#in?` where appropriate. (By the way, @rubyduo is both John Reitano and Adam King.)
@dhh @jamesarosen I agree that `among` is much better than `either`.
@dhh I believe @rubyduo's `Object#not_in` method was also intended for expressiveness, similar to Ruby's ""unless,"" which is why I added it to the original ticket cited above. My rationale for including it was that if the object is a complex expression, not_in puts the ""not"" in a place where it can be more easily seen:
if etc_etc.something.something && !foo_bar.xyz.abc.in?(some_list)
vs.
if etc_etc.something.something && foo_bar.xyz.abc.not_in?(some_list)
Of course one could argue such expressions could be broken up. :-)
Personally I don't mind the phrase ""not in"" but can understand if you dislike it. It probably does make sense to leave it out until a better name is suggested. ","1","2011-04-11T17:04:29Z"
"248067","20277","985516","111577","dtrasbo","I've been surfing dictionaries etc. around the web, and my best suggestion is `known?` and `unknown?`
If nothing else I hope this pair can be a source of other ideas.","1","2011-04-11T19:27:48Z"
"248068","20277","985545","111577","dtrasbo","Another idea could be to have `among?` accept either multiple arguments (converted to an array with the splat operator) or one argument which is an array. The opposite could be `outside?`","1","2011-04-11T19:32:17Z"
"248069","20277","985570","16927","BMorearty","@dtrasbo This comment in the original ticket describes why allowing multiple arguments or a single array argument will lead to ambiguous behavior:
https://rails.lighthouseapp.com/projects/8994/tickets/6321#ticket-6321-5","1","2011-04-11T19:36:00Z"
"248070","20277","985756","111577","dtrasbo","@Bmorearty Right, ok.
How about inside? and outside?
Multiple params could be among? if there is a good opposite.","1","2011-04-11T20:11:48Z"
"248071","20277","986195","1075","dchelimsky","Can't tell if the game is still on, but if it is, how about:
1.included?(1,2,3)
4.excluded?(1,2,3)
They're a clear positive/negative pair and they also align well with the Ruby method we're looking at in a mirror, making it more intuitive IMO:
[1,2,3].include?(1)
1.included?(1,2,3)
On a separate note, I find the in/either pairing confusing. I'd recommend just implementing one that takes a list:
def included?(*args); args.include?(self); end
Again, this aligns very nicely with the existing Ruby method, doesn't require understanding the subtle diff between `in` and `either`, and offers an intuitive symmetry with the existing API.","1","2011-04-11T21:24:06Z"
"248072","20277","986261","24681","pigoz","too bad most people don't speak Latin because I think `ex?` would make a nice contrary for `in?`. `included?` / `excluded?` would sound less esotic but you lose the brevity.
Alternatively, I vote for `out_of?`.","1","2011-04-11T21:35:39Z"
"248073","20277","986325","18524","bcardarella","@pigoz I'll +1 `ex?`","1","2011-04-11T21:47:35Z"
"248074","20277","986440","2741","dhh","I kinda like ex? as well. There's no rule that says we can't borrow a great word straight from latin.
Still need something for the opposite of among?.
dchelimsky, I like the clear pairing of included?/excluded? but I'm not too fond of the words themselves for this. It's still an awkward structure for me ""object included? array"" doesn't flow nearly as nice as ""object in? array"" or ""object among? option, option"".","1","2011-04-11T22:13:34Z"
"248075","20277","986479","1075","dchelimsky","@dhh - I feel the same way about ""assert equal 4 5"" ;)
srsly - what do you think about what I was saying about reducing this to a single method that accepts varargs?","1","2011-04-11T22:24:54Z"
"248076","20277","986508","1075","dchelimsky","e.g:
1.in?(1,2)
3.ex?(1,2)
There would be no support for `1.in?([1,2])`, but who wants to write _that_ when you can write `1.in?(1,2)`???","1","2011-04-11T22:31:21Z"
"248077","20277","986523","2741","dhh","Ha. Touché ;). On that front, one of the things that bugs me about the rspec way is the overloading of ==. I think something.should_equal(something_else) would offend my sense of aesthetics much less (there are other problems still, like how you can't just stick with a tiny set of asserts because you have to map out all possibilities when assert <SOMETHING> is such a powerful way to avoid test method proliferation). Anyway, back on topic :)
I don't like any of the words that could work for either. I love #in? when it's applied to an explicit array ""object in? array"", but I don't like it at all for when it's varargs ""object in? option, option"". That's the reason Object#in? never went anywhere a couple of years ago when we last considered it, because I just didn't like it applied to the varags. I think the in?/among? combo is the best deal for the positive case. I'm also very sold on ex? for the negative in? case but would like to have a great negative among? case too.","1","2011-04-11T22:33:30Z"
"248078","20277","986527","1401","h3h","> but who wants to write that when you can write 1.in?(1,2)
When the collection is a variable and not a finite enumeration in the code, e.g.:
user.in?(admins)","1","2011-04-11T22:34:23Z"
"248079","20277","986541","2741","dhh","Actually, I think there's an even strong argument for just going with in?/ex? and not allowing varargs at all. So you'd HAVE to do 1.in?([ 1, 2 ]). The reason being not only the ""object in? option, option"" dislike but also that you'd definitely want to support the named array. As in action.in?(accessible_actions).
But yeah, in?/ex? with no support for varargs is very appealing in my mind. Very simple, very short.","1","2011-04-11T22:36:37Z"
"248080","20277","986549","2741","dhh","Here's an example from the code:
@scope[:scope_level].among?(:collection, :member, :new)
@scope[:scope_level].in?([:collection, :member, :new])
The in? with forced array is actually shorter. I'm 70% convinced this is the way to go.","1","2011-04-11T22:38:10Z"
"248081","20277","986552","10112","elight","Latin is a touch obscure but +1 for ex?.
Evan Light
On Monday, April 11, 2011 at 6:22 PM, dhh wrote:
> I kinda like ex? as well. There's no rule that says we can't borrow a great word straight from latin.
>
> Still need something for the opposite of among?.
>
> dchelimsky, I like the clear pairing of included?/excluded? but I'm not too fond of the words themselves for this. It's still an awkward structure for me ""object included? array"" doesn't flow nearly as nice as ""object in? array"" or ""object among? option, option"".
>
> --
> Reply to this email directly or view it on GitHub:
> https://github.com/rails/rails/pull/258#issuecomment-986440
>","1","2011-04-11T22:38:38Z"
"248082","20277","986555","2741","dhh","(BTW, I must remark again on how wonderful this collaborative design process is. Great ideas coming alive!)","1","2011-04-11T22:38:52Z"
"248083","20277","986562","18524","bcardarella","@elight if this gets in every Ruby developer will now understand that 'ex' means in Latin.","1","2011-04-11T22:39:53Z"
"248084","20277","986866","4912","sikachu","I like `#ex?`. I think I'm +1 on that one.
Now if there's a word that opposite of `#among?` ... Maybe `#exmong?` (haha, I'm joking)
Thanks guys :)","1","2011-04-12T00:02:55Z"
"248085","20277","986888","34174","josiahivey","How about separate? as the antonym to among?. Alternatively, foreign? although that sounds a little weird.","1","2011-04-12T00:08:07Z"
"248086","20277","986903","34174","josiahivey","Even shorter - apart?","1","2011-04-12T00:13:04Z"
"248087","20277","986955","1075","dchelimsky","@dhh - not sure if this is the right venue for a long-winded discussion of the history of RSpec's equality matchers, so maybe I'll blog about it, but today you can say (and I find myself using) `actual.should eq(expected)` (for equivalence, i.e. ==) and `actual.should be(expected)` (for identity, i.e. equal?).
There's a lot more to say on this topic, and on the issue of test method proliferation, and I'm happy to get into it here but I'd rather find a different venue for it. Maybe you could submit a github issue to rspec-core saying something like ""what the fuck is up with should =="" and we can not only have a great conversation about it but maybe we can get everyone tweeting about it too :)","1","2011-04-12T00:25:59Z"
"248088","20277","987032","14947","ernie","+1 on apart as opposite of among. It's got a certain symmetry to it.","1","2011-04-12T00:49:20Z"
"248089","20277","987210","166528","phene","-1 for apart, because it's too much like ""a part of""
value.apart(of)?(:foo, :bar)","1","2011-04-12T01:43:54Z"
"248090","20277","987238","121051","sharp","-1 for apart, not necessary","1","2011-04-12T01:53:34Z"
"248091","20277","987384","18524","bcardarella","-1 on apart?, doesn't feel right. I hate to do this but I also don't like among? -1s all around!","1","2011-04-12T02:46:13Z"
"248092","20277","987412","34174","josiahivey","@phene ya, I see what you mean. I think separate? might be clearer. ","1","2011-04-12T02:56:13Z"
"248093","20277","987527","34174","josiahivey","@bcardarella absent? feels better to me, although there is a small sense of ambiguity there. absent_from? has been suggested, but you lose the terseness. ","1","2011-04-12T03:40:52Z"
"248094","20277","987530","18524","bcardarella","@josiahhivey well the clear opposite of absent? is present? and that's already being used","1","2011-04-12T03:41:54Z"
"248095","20277","988537","127208","Fonsan","They should definitely support varargs. Reading/Writing the array version is painful.
style.in? [BOLD,ITALIC]
style.in? BOLD, ITALIC","1","2011-04-12T09:34:18Z"
"248096","20277","988760","24681","pigoz","+1 for varargs, if the caller wants to use an array built programmatically they can always use `obj.in?(*ary)`","1","2011-04-12T10:41:26Z"
"248097","20277","988807","14947","ernie","Agreed. Absent? sounds like a partner to present?, unfortunately.
If there's a -1 all around option, then I retract my +1 for apart.
This discussion is like TDD for syntax, and I think the tests are telling us something.
in? Feels pretty natural, and is handy in the same way blank? and present? are. All of the rest just feel wrong.
I think this is because we're trying to solve a nonexistent problem. Someone mentioned earlier how the English language doesn't really have clear one-word negation options here. That's because in English, we would say ""3 is not in the set of 1, 2, 4"".
I think this tells us something, given that only real use for this method is in conditionals, to begin with (including the ternary operator). The rest aren't needed.
Where we ask ""if object.in?(array)"", the opposite is ""unless object.in?(array)"". If necessary, !object.in?(array) feels pretty natural as well.
This seems obvious, as we discuss this. blank? was handy given ruby's definition of truthiness, but present? was a welcome addition because negating a ""negative"" (!blank?) method like blank was often less expressive of intent. You don't ask ""is that space still blank?"" as often as you ask ""has it been filled in?""
Since the English idiom here is to say ""not in"", I think the standard Ruby idioms for negating the condition already complement in? nicely.","1","2011-04-12T10:55:56Z"
"248098","20277","989923","14947","ernie","https://github.com/ernie/notty - I'm considering this problem solved.","1","2011-04-12T14:54:26Z"
"248099","20277","989949","16927","BMorearty","@ernie Clever and expressive. :-)","1","2011-04-12T14:57:38Z"
"248100","20277","989957","4912","sikachu","@ernie clever but expensive.","1","2011-04-12T14:58:25Z"
"248101","20277","989963","18524","bcardarella","@ernie what @sikachu said, putting a regular expression call on Object's method_missing is going to add things up pretty quick","1","2011-04-12T14:59:23Z"
"248102","20277","990161","14947","ernie","So, I had a meme generator image here, and it said ""Y U NO RECOGNIZE JOKE?"". While that statement still holds true, I thought I should elaborate:
I find the fact that Notty was perceived as a serious suggestion (pretty sure @BMorearty got the joke), despite my comment immediately preceding it where I outlined how I really feel (ruby does a great job of handling negation expressively on its own, we don't need a method for every negative case) a bit disturbing, but I think it proves my point. When a caricature is mistaken for the real thing, we need to take a long, hard look at the road we're heading down. :(","1","2011-04-12T15:27:40Z"
"248103","20277","990171","4912","sikachu","@ernie Yeah I really didn't get the joke. There were a lot of stuff going on on this side after this one got merged in. So I took everything serious. >_<","1","2011-04-12T15:29:38Z"
"248104","20277","990203","14947","ernie","@sikachu No worries. I guess my sense of humor is a bit too dry for some. :/","1","2011-04-12T15:33:58Z"
"248105","20277","990709","4912","sikachu","After a long discussion on this, we've decide two things so far
1. Remove `#among?`
2. Add `#ex?`
I've submit the patch via pull request here: https://github.com/rails/rails/pull/265
I think this pull request can be closed now, and I would like to ask you guys to give me some more feedback on it too. Details are in the pull request ;)","1","2011-04-12T17:08:26Z"
"248106","20277","1185812","54991","guser","this is why I love ruby and this age we are now living in","1","2011-05-16T22:38:42Z"
"248107","20325","2108726","9582","josevalim","We should probably call it --skip-public-assets","1","2011-09-15T20:21:31Z"
"248108","28659","109705427","1924829","perk11","? had numerous deprecated warnings after upgrading to 2.7 and this PR solved all of them.","1","2015-06-07T06:51:12Z"
"248109","28659","109717389","1957048","xabbuh","The deprecation warnings are triggered intentionally to let you know what you need to change in your code to be forward compatible with Symfony 3.0.
You *could* silence them by changing your project's `error_reporting` level, but I'd rather update your code.","1","2015-06-07T08:12:50Z"
"248110","28659","109718644","243674","nicolas-grekas","This PR may be a good idea in fact don't you think?","1","2015-06-07T08:16:41Z"
"248111","28659","109720772","821060","elnur","The most profound PR I've ever seen. A must merge. :+1: ","1","2015-06-07T08:22:53Z"
"248112","28659","109721705","1957048","xabbuh","@nicolas-grekas Not sure if I understand. Which issue would this change actually solve?","1","2015-06-07T08:29:10Z"
"248113","28659","109721792","243674","nicolas-grekas","It switches deprecation notices from opt-out to opt-in","1","2015-06-07T08:31:25Z"
"248114","28659","109721852","1957048","xabbuh","Yeah, but is that really a good idea? I bet that many people then will never know about this and that they will be surprised when their apps break on Symfony 3.0. Not sure if that's a good experience either.","1","2015-06-07T08:34:04Z"
"248115","28659","109735633","525575","reecefowell","I think it is a good idea. @deprecated tags are sufficient, but calling trigger_error() is very shouty.
Googling most of the deprecated errors that come out result in most cases with the people discussing end suggesting and / or agreeing that muting E_DEPRECATED in php.ini is the best solution.
If the intent is to get people to prepare for 3.0 then, well people aren't. Instead they are just muting the warnings. Further more, for upgraders, seeing the messages for the first time, diagnosing / solving them the correct way is very difficult as google has little to offer in the way of answers.
Perhaps some of the deprecated calls don't actually have future ready implementations in place yet. I believe this was the case with the Form components OptionResolverInterface, which my IDE informs me was deprecated in (I think it was) 2.5 or so, but no alternative was provided until something like 2.6 (with OptionResolver).","1","2015-06-07T10:53:46Z"
"248116","28659","109735690","243674","nicolas-grekas","Still thinking about it, I really like the idea.
Upgrading to 3.0 is also an opt in, the upgrade path is clear.
I'm :+1:
Reopening to see what other @symfony/deciders think","1","2015-06-07T10:53:56Z"
"248117","28659","109737371","243674","nicolas-grekas","@reecefowell can you please enhance the commit message?","1","2015-06-07T11:00:40Z"
"248118","28659","109747122","439401","stof","@nicolas-grekas are these deprecation warnings still reported in the logs after being muted or no ?
And does the silencing add some overhead or no ?","1","2015-06-07T12:25:57Z"
"248119","28659","109756217","243674","nicolas-grekas","Yes, the debug handler ignores silencing for deprecations. The overhead is
not significant at all.
","1","2015-06-07T13:24:28Z"
"248120","28659","109784569","47313","fabpot","ping @symfony/deciders
If we agree on this one, I'd like to merge ASAP for at least two reasons:
* I want to release 2.7.1 ASAP
* Maintaining such a large patch is going to be difficult over time.
","1","2015-06-07T18:05:19Z"
"248121","37435","130249484","7401","joshuar","Expect update tomorrow ?
On 12 Aug 2015 8:17 pm, ""Clinton Gormley"" <notifications@github.com> wrote:
> ++
>
> —
> Reply to this email directly or view it on GitHub
> <https://github.com/elastic/elasticsearch/pull/12820#issuecomment-130249178>
> .
>
","1","2015-08-12T10:18:40Z"
"248122","37436","130214832","5524260","HarishAtGitHub","Doubts:
1) All tests passed except "" Failed to execute goal com.carrotsearch.randomizedtesting:junit4-maven-plugin:2.1.16:junit4 (tests) on project elasticsearch"" . Why am I getting this ? To check if my code brought in this , I had a same fork without my changes and there too it failed ? what am I to infer from this ?
Note: this is just the basic patch . please comment and give feedback and I can make changes.
I should make changes like making other terms also make this sort of check in compare and throw exception . Is this needed now or what should I do ?
If this approach is ok I can try to solve this similar issue too https://github.com/elastic/elasticsearch/issues/12675 .
Thanks in advance.
","1","2015-08-12T08:26:15Z"
"248123","37436","130290856","299848","jpountz","Thanks @HarishAtGitHub. This approach works, but I would rather proactively check that the Terms instances are compatibles instead of catching class-cast exceptions. Maybe we could just loop over the aggregations instances in `InternalTerms.doReduce` and raise an error if we find two different impls of InternalTerms (with the exception of UnmappedTerms, which can be merged with any other Terms instance)?
> All tests passed except "" Failed to execute goal com.carrotsearch.randomizedtesting:junit4-maven-plugin:2.1.16:junit4 (tests) on project elasticsearch"" . Why am I getting this ? To check if my code brought in this , I had a same fork without my changes and there too it failed ? what am I to infer from this ?
I suspect there is the actual error message right before or after this message, can you create a gist of the whole build log?","1","2015-08-12T12:53:50Z"
"248124","37436","130305630","5524260","HarishAtGitHub","Hi @jpountz ,
First of all thanks for the review (I was worried if people will be bored reading my huge commit message. I personally believe that the entire thought process should be in commit message. Thats y this hugeness.sorry if it bothered. ).Thank you very much . It was great help.
Ok now coming back. ...I thought about your way of checking terms prior ... But I was not confident because of these questions that arose in my mind(may be because I am a beginner for elasticsearch concepts)
1) what if there are many shards on which search occurred . For eg . say I am searching on 10 indices. and people used the default 10 shards per index. in that loop we might end up with 10 * 10 = 100 entries .
2) what if the 100 entries above had entries with all possible terms .. today may be there are some 5 terms(different) . may tomorrow it might go up to 10 or more (I don't know ..but)...
What I worried was that there are more possibilities of checking the compatibility between terms.
I was worried that this proactive check approach might end up doing more work .
But if we leave it for the normal loop itself to check , it is only one loop or one breakage.
But in proactive check approach will we not end up with (loopcheck + existinglogic) or (loopcheck & breakage) .
The tradeoff made me lean towards the present approach .
And also that these kinds of incompatibility breakage seems to be in a number of places. For eg . I saw this similar one https://github.com/elastic/elasticsearch/issues/12675.
If we follow the present approach all these places can be fixed without any effort(or looping proactively ). I thought that it might be performance efficient as well as we don't bring in any additional looping to check incompatibility and the normal business logic takes care of checking incompatibility.
Please share your thoughts .","1","2015-08-12T13:37:14Z"
"248125","37436","130314215","299848","jpountz","> 1) what if there are many shards on which search occurred . For eg . say I am searching on 10 indices. and people used the default 10 shards per index. in that loop we might end up with 10 * 10 = 100 entries .
2) what if the 100 entries above had entries with all possible terms .. today may be there are some 5 terms(different) . may tomorrow it might go up to 10 or more (I don't know ..but)...
1 is right, but I don't see it as an issue, we need to iterate over all aggs anyway if we want to reduce results. Regarding 2, I was not suggesting to iterate over the actual terms, but the aggregation object (which should be a sub-class or the `Terms` class).
I don't think performance would be an issue at all.","1","2015-08-12T13:56:37Z"
"248126","37436","130370413","5524260","HarishAtGitHub","Ok to get clarity to know if what I am thinking is correct.....
we already have a loop like
```java
for (InternalAggregation aggregation : aggregations) { ----> loop 1
..... N aggregations takes N loop
}
for (Collection<Bucket> l : buckets.asMap().values()) { ----> loop 2
...... M times ...Far less than N as it includes only matches' buckets (in our case with 10 shards only 2 qualifies)
}
```
> 1 is right, but I don't see it as an issue, we need to iterate over all aggs anyway
> Maybe we could just loop over the aggregations instances in InternalTerms.doReduce and raise an error if we find two different impls of InternalTerms
So you are asking me to do the buckets mismatch check in loop-1 itself. Right ?
But to do this I will have to iterate the bucket's again and check for each if there is mismatch.My doubt is why should we do it there when we are already doing it in the M-count loop(loop2).(but I agree that it is an indirect approach)
Another doubt is if there is no mismatch of buckets there will be two iterations of buckets .
one inside loop-1 another in loop-2 .
so net would be something like loop1 + [M*(M+1)/2]*inner bucket loops + loop2(which already again does this by means of comparison inside BucketPriorityQueue)
But if we do it in the present way it will always be just
loop1 + loop2(which already again does this by means of comparison inside BucketPriorityQueue.)
I can surely understand your point that if we do it your way we can directly interepret the mismatch here itself inside InternalTerms.
But what I cannot understand is just for this exception interpretation(which is done with the present approach in the patch already without extra computation) why should we bring in so many additional loops ?
","1","2015-08-12T17:01:21Z"
"248127","37436","130426455","5524260","HarishAtGitHub","> I suspect there is the actual error message right before or after this message, can you create a gist of the whole build log?
Yes. Now I fixed it. It was a org.elasticsearch.ExceptionSerializationTests.testExceptionRegistration test that was failing as my exception was not registered . Now fixed it and pushed it .Thanks.
Unfortunately I ran the mvn clean install at night 1 AM nearly to check any failure, hoping it will get over soon...but ahh it took lot of time nearly 40 minutes.","1","2015-08-12T19:55:32Z"
"248128","37436","130460530","289412","rjernst","Do we really need a new exception? I think `IllegalArgumentException` or `IllegalStateException` would suffice?","1","2015-08-12T22:00:33Z"
"248129","37436","130537891","5524260","HarishAtGitHub",">Do we really need a new exception? I think IllegalArgumentException or IllegalStateException would suffice?
@rjernst, I understand your concerns.... But the following was my thought process ....
I want to make normal user(who does not know much about coding and exceptions) to even interpret from the exception. I am just targetting users who know just about elasticsearch, that is elasticsearch users . May be users who have just read his [elasticsearch documentation link](https://www.elastic.co/guide/en/elasticsearch/reference/1.6/search-aggregations-bucket-terms-aggregation.html) . IllegalArgumentException would be good if it is just going to be in the logs inside the box which is not accessible to common user.
I want to have something that is not too broad and also conveys the meaning to normal elasticsearch user. But at the same time as you say we cannot create exceptions(for every usecase) and this would flood the code base with exception classes.
I want to stand somewhere in the middle satisfying both.
Thats y I chose to introduce new exception.
It is like this. We already have [IndexOutOfBoundsException](http://docs.oracle.com/javase/7/docs/api/java/lang/IndexOutOfBoundsException.html) . But despite having this, we have [ArrayIndexOutOfBoundsException](http://docs.oracle.com/javase/7/docs/api/java/lang/ArrayIndexOutOfBoundsException.html) and [StringIndexOutOfBoundsException](http://docs.oracle.com/javase/7/docs/api/java/lang/StringIndexOutOfBoundsException.html) . This is there just to convey the exact sense.
I am not saying that we should follow what java community has done . But just that this approach they have taken made sense to me.
And that this exception is to be shown to the user on api failures so I felt it is not a bad choice to be precise and exact and convey the sense and hence introduce a new one as none of the exceptions at purpose satisfied my need.
Just by seeing the returned error json I should be able to approach the problem.
> Harish says : Just by seeing the returned error json I should be able to approach the problem.
but again if you feel that the statement I made above is not the truth achieved with my fix approach, please let me know . I can just change the fix to make the error more readable and easily decipherable . I am fine with that . I can look for another way. My aim is to make user easily parse error message and interpret it the best possible right way.
","1","2015-08-13T05:16:52Z"
"248130","37436","130548829","289412","rjernst","I personally think the actual exception type is less meaningful (hence just tend to use builtin exceptions; we use `IllegalArgumentException` all over elasticsearch). The message is what is important. The user will quickly look at ""reason"" in structured exceptions. ","1","2015-08-13T06:03:57Z"
"248131","37436","130551332","5524260","HarishAtGitHub","@rjernst , Ya.. Fine agreed ... you are right ... Your argument makes a lot of sense ... message within exception itself is enough to convey the meaning to common user.
ok I will do it like this now ?
```java
StringTerms$Bucket
try {
compareTerm(.... typecast ...)
} catch (TypecastException e) {
IllegalAgrgumentException(""the buckets type could not be compared as they were incompatible"", e)
}
```
```java
InternalTerms
try{
ordered.insertWithOverflow(b);
catch(RuntimeException e) {
throw AggregationExecutionException(""merging/reducing the buckets failed"", e);
}
```
does the above makes sense ..
Now as you said we just used existing exceptions but still conveyed the meaning with the help of messages inside it.
so what ever runtimeexception is thrown within insertWithOverflow will result in throwing AggregationExecutionException as aggregation failed .
and this AggregationExecutionException will have the cause exception within it for more info ..
Ya this makes sense for me.
you are fine with this @rjernst ?
NOTE: I will make the messages better . but the above is just to convey the idea..","1","2015-08-13T06:23:34Z"
"248132","37436","130657980","299848","jpountz",">for (InternalAggregation aggregation : aggregations) { ----> loop 1
..... N aggregations takes N loop
}
for (Collection<Bucket> l : buckets.asMap().values()) { ----> loop 2
...... M times ...Far less than N as it includes only matches' buckets (in our case with 10 shards only 2 qualifies)
}
My point was that you don't need loop2, since an aggregation has all buckets of the same type, you could just do loop1.","1","2015-08-13T12:49:56Z"
"248133","37436","130679685","5524260","HarishAtGitHub","ok @jpountz , I will give it a try now ...Thanks ...","1","2015-08-13T13:51:03Z"
"248134","37436","131525346","5524260","HarishAtGitHub","Hi @jpountz , did it as per review comments .
Please give your review comments .
this is the final diff .. https://github.com/elastic/elasticsearch/pull/12821/files
(one commit I made to revert the line change I made in my first commit .)
(0 Test failures ..)","1","2015-08-16T11:10:23Z"
"248135","37436","131527394","5524260","HarishAtGitHub","@jpountz ,
new error message is like this
<b> Merging/Reducing the aggregations failed when computing the aggregation [ Name: NAME, Type: terms ] because: the field you gave in the aggregation query existed as two different types in two different indices </b>
```javascript
{
""error"":{
""root_cause"":[
],
""type"":""reduce_search_phase_exception"",
""reason"":""[reduce] "",
""phase"":""query"",
""grouped"":true,
""failed_shards"":[
],
""caused_by"":{
""type"":""aggregation_execution_exception"",
""reason"":""Merging/Reducing the aggregations failed when computing the aggregation [ Name: NAME, Type: terms ] because: the field you gave in the aggregation query existed as two different types in two different indices""
}
},
""status"":503
}
```","1","2015-08-16T11:18:35Z"
"248136","37436","131662694","5524260","HarishAtGitHub","@jpountz also a doubt, will there be cases when the aggregation and type will not be mandatory ?
I just tried the query and on leaving out either of these it said """"type"":""search_parse_exception"",""reason"":""Expected [START_OBJECT] under [field], but got a [VALUE_STRING] in [NAME]"",""line"":1,""col"":20}"" .
so can I assume it will work ? . or should I have a null pointer check on the params (for safety) I am introducing in aggregation_execution_exception ?
(but may be we can assume it will not be null as: only because it is terms agg's it came inside internalterms, and the previous step is aggregation separation by name so that name can also not be null .. can I take this freedom of conclusion ?) seems like [docs](https://www.elastic.co/guide/en/elasticsearch/reference/current/search-aggregations.html#_structuring_aggregations) confirms we need not have null check. what do u say @jpountz ?","1","2015-08-17T02:45:20Z"
"248137","37436","131707631","299848","jpountz","Thank you @HarishAtGitHub ","1","2015-08-17T07:37:08Z"
"248138","37436","131728335","5524260","HarishAtGitHub","May I know what was wrong in the patch ? . just for my learning @jpountz ?","1","2015-08-17T08:25:03Z"
"248139","37436","131728749","299848","jpountz","Nothing was wrong, I just squashed the commits.","1","2015-08-17T08:26:15Z"
"248140","37436","131728982","5524260","HarishAtGitHub","the comments said ""closed with UNMERGED commits"" thats y I was worried ...","1","2015-08-17T08:27:28Z"
"248141","37436","131730046","5524260","HarishAtGitHub","Thank you very much for the guidance ... your approach was easier and direct and exactly solved the issue.... learning from u ...Thanks...","1","2015-08-17T08:33:51Z"
"248142","37437","130235321","580421","martijnvg","LGTM","1","2015-08-12T09:27:59Z"
"248143","37437","130238279","299848","jpountz","@jaymode I pushed a new commit","1","2015-08-12T09:43:09Z"
"248144","37437","130240269","4339958","jaymode","LGTM","1","2015-08-12T09:46:08Z"
"248145","37438","130248889","274222","dadoonet","LGTM","1","2015-08-12T10:14:34Z"
"248146","37438","134366609","215970","nik9000","LGTM","1","2015-08-24T20:25:11Z"
"248147","37439","130243773","667544","spinscale","cant you circumvent name clashes, by simply grouping the stats by the plugin name, which should be unique or would that convulute the JSON?
also, should plugins only be able to register stats or also static information?","1","2015-08-12T09:59:37Z"
"248148","37440","130344162","289412","rjernst","One thought here is to split ExtensionPoint into two different variants, one for a Set and one for a Map. Right now it looks like we have a switch for this, with if/else in the impl. We just have those two types of extension points, either we keep a set of class impls, or we keep a map from name to impl. I think separating them would make the module code a little clearer, and less error prone when adding these (must choose the type of extension when defining, instead of accidentally calling the wrong register method).","1","2015-08-12T15:33:33Z"
"248149","37440","130356266","289412","rjernst","This looks great in general, I think it will simplify a lot where we have extension points, so we get the same logic/exception checking. I left a few comments/questions.","1","2015-08-12T16:04:04Z"
"248150","37440","130367463","289412","rjernst","LGTM. I left two more questions but those can be follow ups or ignored.","1","2015-08-12T16:49:43Z"
"248151","37441","130262118","973334","s1monw","LGTM","1","2015-08-12T11:03:48Z"
"248152","37443","1915249","274222","dadoonet","Here is the documentation pull request : https://github.com/elasticsearch/elasticsearch.github.com/pull/72","1","2011-08-26T17:55:29Z"
"248153","37443","1931671","41300","kimchy","Pushed, with some cleanups..., thanks!","1","2011-08-29T14:55:27Z"
"248154","37444","130646263","299848","jpountz","I gave it a quick look and I think the fact that most aggregation objects track their parent is going to make the refactoring a bit less straightforward than for queries (see comments about serialization and checking for parents in equals)","1","2015-08-13T12:17:04Z"
"248155","37444","131085042","236731","colings86","@jpountz I've pushed a commit addressing your comments. If you could especially check the equals and hashCode methods in AggregatoryFactory, ValuesSourceAggregatorFactory, PipelineAggregatorFactory and AggregatorFactories, that would be great","1","2015-08-14T11:46:14Z"
"248156","37444","131102245","832460","javanna","I had a look and this looks good to me, I think the main concern around equality checks has been addressed, all good besides that","1","2015-08-14T13:17:01Z"
"248157","37444","131131879","299848","jpountz","LGTM","1","2015-08-14T14:45:58Z"
"248158","37446","131134316","299848","jpountz","LGTM","1","2015-08-14T14:51:46Z"
"248159","37446","155806404","236731","colings86","@jpountz could you re-review this? It has changed a bit since you LGTM'ed it","1","2015-11-11T15:06:24Z"
"248160","37446","155913446","299848","jpountz","LGTM","1","2015-11-11T21:19:08Z"
"248161","37447","130648772","299848","jpountz","This sounds reasonable to me and tests passed. Thanks @saschamarkus","1","2015-08-13T12:26:06Z"
"248162","37448","130383614","19060","dakrone","@rjernst can you take a look?","1","2015-08-12T17:27:46Z"
"248163","37448","130384321","289412","rjernst","LGTM","1","2015-08-12T17:30:54Z"
"248164","37449","134600355","274222","dadoonet","@s1monw wanna review this change?","1","2015-08-25T14:16:56Z"
"248165","37449","135659467","274222","dadoonet","@bleskes Could you help me on this?","1","2015-08-28T07:18:53Z"
"248166","37449","135865969","1006375","bleskes","I took a look and left some minor comments. I'm not expert in this code nor what it is expected to do, so I'm not sure how much it's worth but LGTM. I did expect to find some kind of integration test with ES's ZenDiscovery . Maybe use the fact we can mock the AWS services and try to form a cluster?","1","2015-08-28T19:23:07Z"
"248167","37449","138321215","274222","dadoonet","@bleskes I adressed your comments. Thanks!
I also rebased on latest 2.0 branch.
@rjernst Do you think you can also give a look to this?","1","2015-09-07T15:10:02Z"
"248168","37449","139232926","274222","dadoonet","Closed by fe74219 in 2.x branch.
Will follow up with another PR for master branch because of the split between s3 and ec2.","1","2015-09-10T13:22:24Z"
"248169","37450","130691455","19060","dakrone","LGTM, left a couple of questions","1","2015-08-13T14:14:36Z"
"248170","37451","130564314","289412","rjernst","We should not do this. The exception message is already there. Structured exceptions must be not following the cause chain all the way?","1","2015-08-13T07:27:51Z"
"248171","37451","130566625","1799964","xuzha","Yea, pretty duplicated. ","1","2015-08-13T07:44:06Z"
"248172","37451","130570163","1799964","xuzha","OK, the code follows the cause chain down to the last ES exception. In this case the root cause is MapperParsingException, which caused by IllegalArgumentException. We have full description in IllegalArgumentException rather than in MapperParsingException.
When print root cause, it just get MapperParsingException detail message and print it out.
We should print caused_by block for MapperParsingException in side of the root cause block, but skipped that [here] (https://github.com/elastic/elasticsearch/blob/master/core/src/main/java/org/elasticsearch/ElasticsearchException.java#L295)
","1","2015-08-13T08:07:47Z"
"248173","37451","135957794","1799964","xuzha","Close this, we should not do this","1","2015-08-29T07:51:43Z"
"248174","37452","130580103","299848","jpountz","LGTM","1","2015-08-13T08:50:46Z"
"248175","37453","130590118","274222","dadoonet","Left 2 small comments. It looks good to me.","1","2015-08-13T09:27:41Z"
"248176","37453","136698419","667544","spinscale","fixed the review comments, rebased against master with a fair share of changes and only run the logic to copy `bin` and `config` dirs if actually needed, otherwise exit early
please give it another look","1","2015-09-01T12:33:29Z"
"248177","37453","137412022","274222","dadoonet","@spinscale I left some comments.","1","2015-09-03T11:26:24Z"
"248178","37453","140392467","215970","nik9000","@spinscale, there are a few comments around more you could do here but I think its an improvement as is. Its worth merging, I think.
I love the tests. Very descriptive method names help a ton.
If you want to add the tests for sourceConfigPath being a file instead of a dir I'd cause that to be an ""abort fast"" thing. Its a pretty broken plugin that does it.","1","2015-09-15T13:25:51Z"
"248179","37453","146160920","667544","spinscale","@dadoonet updated your last comment and rebased against master, mind to take another view?","1","2015-10-07T11:27:27Z"
"248180","37453","146254907","215970","nik9000","LGTM","1","2015-10-07T16:34:23Z"
"248181","37454","130610621","274222","dadoonet","@rmuir Could you tell me what you think about this?","1","2015-08-13T10:48:43Z"
"248182","37454","130614764","504194","rmuir","Sounds like elasticsearch has bad defaults to me. This will just hide those bad defaults.","1","2015-08-13T10:54:12Z"
"248183","37454","130615453","274222","dadoonet","Makes sense. @dakrone WDYT? Should we change Elasticsearch defaults to absolute values?","1","2015-08-13T10:56:13Z"
"248184","37454","130615836","504194","rmuir","Keep in mind every -D here makes the tests less realistic: there are already far too many -D's in the integration tests IMO.
Unless users start elasticsearch with 57 -D's, then we should not either.","1","2015-08-13T10:57:32Z"
"248185","37454","130679612","19060","dakrone","> Sounds like elasticsearch has bad defaults to me.
@rmuir explain why you think these are bad? I could see changing to 90/95% perhaps, but there isn't a good way to support the wide array of disk sizes people run ES on other than relative values.
> Should we change Elasticsearch defaults to absolute values?
No. I think relative values are the only way to support as many disk sizes as we can by default. And if not, that's why they are dynamically configurable.","1","2015-08-13T13:50:55Z"
"248186","37454","130744265","299848","jpountz","I see it as a test bug: the test makes incorrect assumptions about allocation rules.","1","2015-08-13T16:09:54Z"
"248187","37454","130745554","504194","rmuir","integration tests should test our defaults. if you are annoyed that tests fail because they don't work as expected when you are ""low"" on disk space, then users will be equally annoyed when they are in the same situation.","1","2015-08-13T16:12:55Z"
"248188","37454","130745662","504194","rmuir","please don't add the -D's. Fix the defaults.","1","2015-08-13T16:13:10Z"
"248189","37454","130746740","19060","dakrone","> please don't add the -D's. Fix the defaults.
""fixing"" the defaults to run QA tests is not a good solution. This is the same as saying we should ""fix"" the JVM checker to allow running old JVMs because the tests fail if you try to run them using an old version.
> users will be equally annoyed when they are in the same situation
I'll take ""equally annoyed"" versus ""out of disk space and with corrupted indices or translogs"" any day.
","1","2015-08-13T16:16:02Z"
"248190","37454","130749869","299848","jpountz","I agree we shouldn't add a`-D`, however I think we should fix the test to not expect all shards to be allocated instead of fixing our defaults (which look reasonable to me).","1","2015-08-13T16:23:25Z"
"248191","37454","130750189","274222","dadoonet","> I think we should fix the test to not expect all shards to be allocated instead of fixing our defaults (which look reasonable to me).
Agreed. Will come with an update.","1","2015-08-13T16:24:27Z"
"248192","37454","130754302","504194","rmuir","> I'll take ""equally annoyed"" versus ""out of disk space and with corrupted indices or translogs"" any day.
This has nothing to do with that. If elasticsearch has problems on disk full like that, then its because elasticsearch is broken.
Lucene does not have such problems.","1","2015-08-13T16:43:24Z"
"248193","37454","132142820","274222","dadoonet","@jpountz I added a new commit. It now does not check anymore if we have unassigned shards and wait for yellow instead of green.
We still check that we have 2 nodes running which is I think the first goal for this qa test.","1","2015-08-18T09:34:26Z"
"248194","37454","132146712","299848","jpountz","LGTM","1","2015-08-18T09:46:38Z"
"248195","37454","133351912","236731","colings86","@dadoonet this doesn't seem to have been backported to the 2.0 branch. Should it be backported?","1","2015-08-21T09:39:04Z"
"248196","37454","133353887","236731","colings86","@dadoonet sorry, my bad, it is in 2.0. Ignore the above","1","2015-08-21T09:42:47Z"
"248197","37455","130642837","5524260","HarishAtGitHub","pull request for the date replication reported in https://github.com/elastic/elasticsearch/issues/12790.
","1","2015-08-13T12:02:08Z"
"248198","37455","130643959","5524260","HarishAtGitHub","I have just commented out the if loop as so that this change can be easily tracked in case it results in some other bug .(doing this as getting from input settings code has lived for such a long time)","1","2015-08-13T12:04:22Z"
"248199","37455","132122483","5524260","HarishAtGitHub","In the changes made to fix the version.created problem , I went with the ""filtering params"" in the starting place though this would not be ideal in most of the cases. But in our case I thought it might fit because fixing in the MetaDataCreateIndexService(core) might not be appropriate because at this point we will not know who set the settings ""is he the user"" or ""from internal code"" ... Fixing in MetaDataCreateIndexService(core) was ok for created_date feature removal as the feature is to be removed for all .But Our aim is to block external users and not internal usage. so the logic would be to filter it at the doorsteps of various inlets.
But this too has a drawback. the drawback is we should find all the possible doors through which users can enter the MetaDataCreateIndexService . one is the fixed one in CreateIndexRequest which is used by RestCreateIndexAction .
Are there any other routes through which users can set settings in CreateIndexRequest and feed it to MetaDataCreateIndexService ? Is CreateIndexRequestBuilder as possible route ?
Also another problem is what if users directly set settings as CreateIndexRequest too has
```java
/**
* Constructs a new request to create an index with the specified name and settings.
*/
public CreateIndexRequest(String index, Settings settings) {
this.index = index;
this.settings = settings;
}
```","1","2015-08-18T08:48:34Z"
"248200","37455","133403818","973334","s1monw","there are more problems like this, you can also fake the `index.version.created` etc. yet, I think we need this ability in our tests so I guess there should be a way to by-pass this by the test infrastructure. I think it would make sense to have some switch on `MetaDataCreateIndexService` to allow overriding these?
The two I think of are:
* `index.creation_date`
* `index.version.created`
I can take care of this if you want but I wanted to give you a heads-up first
","1","2015-08-21T12:17:32Z"
"248201","37455","134517137","5524260","HarishAtGitHub","@s1monw thanks for the review .
sorry for the delay @s1monw .... I did not notice that you reviewed (pls add the review tag if possible in the issue, I was waiting for review but left it as as there was no tag) ....
I will work on it today nd tmrw (2 days) .... If I cannot find a way out in 2 days I will let you know and you can take it....","1","2015-08-25T08:09:57Z"
"248202","37455","135107031","5524260","HarishAtGitHub","Hi @s1monw, I cannot think of a good acceptable solution for this problem now. Ya may be you or someone else can take it up ... I can look into some other issue ... eager to see the solution ...","1","2015-08-26T16:55:51Z"
"248203","37455","135199812","289412","rjernst","I'm going to work on this soon.","1","2015-08-26T22:55:37Z"
"248204","41694","65806353","2588256","ashrafsarhan","Hi @clintongormley
URW ?
I had signed the CLA.","1","2014-12-05T15:37:50Z"
"248205","41694","66274795","56599","clintongormley","thanks @ashrafsarhan - merged","1","2014-12-09T12:23:13Z"
"248206","41695","75594380","4320215","brwe","Updated. I also moved the integration test to a separate class as DedicatedAggregationTests is hardly the right place.","1