It looks like a recent documentation commit finally removed references to this method... http://github.com/rails/rails/commit/c6372d604952a8eef16ce73a06814aa143b94779 In lieu of having #proxy_options available, is there another method which replaces that functionality (access to a hash of all the options from a scope), or is it recommended to compare the to_sql output or use the == on Relation or something? (For actual app use I prefer actually creating records to run through scopes and asserting things about that output...but for tool use and debugging, the hash from proxy_options was useful). -Matt -- 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+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en.
On Apr 9, 9:06 pm, Matt Jankowski <jankow...@gmail.com> wrote:> It looks like a recent documentation commit finally removed references > to this method... > > http://github.com/rails/rails/commit/c6372d604952a8eef16ce73a06814aa1... > > In lieu of having #proxy_options available, is there another method > which replaces that functionality (access to a hash of all the options > from a scope), or is it recommended to compare the to_sql output or > use the == on Relation or something? >Does comparing the @where_values, @having_values, etc on the Relation do the trick for you? That doesn''t require a call to #to_sql, and might be preferable since you''ll be able to see more clearly what''s different about the structure of the relation object. Those values are the definitive source regarding what''s been built up by the chain and what will eventually be generated by to_sql. -- 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+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en.
> Does comparing the @where_values, @having_values, etc on the Relation > do the trick for you? That doesn''t require a call to #to_sql, and > might be preferable since you''ll be able to see more clearly what''s > different about the structure of the relation object. Those values are > the definitive source regarding what''s been built up by the chain and > what will eventually be generated by to_sql.Yeah, that does work, but it''s not the same as what proxy_options was. For example, if you have something which previously would have shown you... [''users.admin = ?'', true] ...this is now going to be something like this... "users".admin = ''t'' "users".admin = 1 ...depending which database driver you''re using. My guess is that''s probably fine, most of the time within one application -- because you are probably using the same DB for test/dev/production/etc. But, within plugins/gems/modules/etc that you might want to use across projects, you''d have to pick some DB to use in the test suite for that plugin, test it like that, and sort of hope for the best in other DBs. That''s not the end of the world, but I''m just curious if it''s still even possible to access the "original" (ie, not serialized to some db-specific format) versions of the various scope options? -Matt -- 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+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en.