Re: [Rails-core] Validate absence of
I just worked this into rails and submitted a pull request: https://github.com/rails/rails/pull/7155 -- You received this message because you are subscribed to the Google Groups Ruby on Rails: Core group. To view this discussion on the web visit https://groups.google.com/d/msg/rubyonrails-core/-/WqPA-wN07LkJ. To post to this group, send email to rubyonrails-core@googlegroups.com. To unsubscribe from this group, send email to rubyonrails-core+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en.
Re: [Rails-core] Behavior of first_or_create
On Jul 24, 2012, at 5:42 PM, Jon Leighton wrote: On 24/07/12 21:29, Matt Jones wrote: Nope, that's not exactly what I observed; I'll try again. That code *does* call the create correctly, if there are no users with the correct first_name. The confusing part to me was that it wasn't quite the same as this: User.where(:first_name = 'Scarlett').find_or_create_by_last_name(O'Hara) The latter includes a condition on last_name in the find, where the former does not. This behaviour is intentional. The dynamic version did actually previously take an options hash of stuff that would get passed to create. So: User.where(:first_name = 'Scarlett').find_or_create_by_last_name(O'Hara, :age = 32) would do: User.where(:first_name = Scarlett, :last_name = O'Hara) and then: User.create(:first_name = Scarlett, :last_name = O'Hara, :age = 32) I believe the rationale is simply that you can put all of your conditions in a where() Who's got two thumbs and didn't know about this feature? THIS GUY! :) I also noted, after actually RTFM, that this works too: User.find_or_create_by_last_name(:last_name = O'Hara', :age = 32) where the named parameter in the dynamic matcher is selected out of the hash that's passed in. Any objections to adding an explicit converting from dynamic finders section to the documentation for first_or_create? I'll try to get something together this weekend. Thanks, --Matt Jones -- You received this message because you are subscribed to the Google Groups Ruby on Rails: Core group. To post to this group, send email to rubyonrails-core@googlegroups.com. To unsubscribe from this group, send email to rubyonrails-core+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en.
[Rails-core] A minor beef with JSON::decode
Hiya,
So, what was the impetus behind having ParamsParser create Date and
DateTime objects out of application/json requests? The project I'm on
expects parameters to be received as standard types (bools, numbers,
strings, arrays, and hashes). Rails shouldn't try to convert objects that
are explicitly passed as these types; it should be up to the application to
do that.
example:
JSON
request_parameters:{foo:2012-05-12}
Should get to our controller as
params[:foo] = 2012-05-12
But instead comes in as
params[:foo] = Date:0x2af5607
--
You received this message because you are subscribed to the Google Groups Ruby
on Rails: Core group.
To view this discussion on the web visit
https://groups.google.com/d/msg/rubyonrails-core/-/X6I3c0vSGrUJ.
To post to this group, send email to rubyonrails-core@googlegroups.com.
To unsubscribe from this group, send email to
rubyonrails-core+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/rubyonrails-core?hl=en.
[Rails-core] Add an option to not create/drop a table in a given environment
I'm trying to get some issues either closed or some hard TODO's attached. I'm looking at this issue and wanted to bring it up to the group: https://github.com/rails/rails/issues/2899#issuecomment-7257057 Problem: Production database differs from test environment. Workaround: Add conditionals to migrations, something like: if Rails.env.test? … Problem with the workaround: Now the schema we save is different for different environments. The suggested fix in the issue would be to let our create and drop table commands be aware of the environment. I've not worked with the schema writing code before, so I'm not sure the scope involved in such a request. If you have an opinion about this issue, or care to look into it. Please reply: https://github.com/rails/rails/issues/2899#issuecomment-7257057 -- Richard Schneeman http://heroku.com @schneems (http://twitter.com/schneems) -- You received this message because you are subscribed to the Google Groups Ruby on Rails: Core group. To post to this group, send email to rubyonrails-core@googlegroups.com. To unsubscribe from this group, send email to rubyonrails-core+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en.
Re: [Rails-core] A minor beef with JSON::decode
On Wed, Jul 25, 2012 at 11:09:06AM -0700, Josh Bourgeois wrote: Hiya, So, what was the impetus behind having ParamsParser create Date and DateTime objects out of application/json requests? The project I'm on expects parameters to be received as standard types (bools, numbers, strings, arrays, and hashes). Rails shouldn't try to convert objects that are explicitly passed as these types; it should be up to the application to do that. I think this ship has sailed. :-/ However, it looks like you can set ActiveSupport.parse_json_times to false: https://github.com/rails/rails/blob/3-2-stable/activesupport/lib/active_support/json/decoding.rb#L6-7 And it won't try to parse dates: https://github.com/rails/rails/blob/3-2-stable/activesupport/lib/active_support/json/decoding.rb#L19-23 -- Aaron Patterson http://tenderlovemaking.com/ pgppbhKW2vSpP.pgp Description: PGP signature
