Sorry, but I'm out of the office until 10/17 and, because my new iPhone hasn't 
arrived yet, I won't have access to email. But don't fret, Jon Pirc may be able 
to help you with your inquiry: [email protected]

Thanks!

On Oct 17, 2011, at 8:11 AM, [email protected] wrote:

>   Today's Topic Summary
> Group: http://groups.google.com/group/rubyonrails-core/topics
>       •       Unobtrusive Image Mouseover [1 Update]
>       •       Uniqueness Validator and Case Sensitivity [1 Update]
>       •       A proper way to test that database is not accessed? [7 Updates]
>  Topic: Unobtrusive Image Mouseover
>       •       Tim Shaffer <[email protected]> Oct 17 04:54AM -0700 ^
>       •       
>  
>       •       Thanks for the input. That's exactly what I needed to know.
>       •        
>  Topic: Uniqueness Validator and Case Sensitivity
>       •       Panayotis Matsinopoulos <[email protected]> Oct 16 
> 12:25AM -0700 ^
>       •       
>  
>       •       Hi,
>       •        
>       •       I would like to ask what is the reason behind the fact that
>       •       ActiveRecord Uniqueness Validator does the following:
>       •        
>       •       if value.nil? || (options[:case_sensitive] || !column.text?)
>       •       sql = "#{sql_attribute} #{operator}"
>       •       else
>       •       sql = "LOWER(#{sql_attribute}) = LOWER(?)"
>       •       end
>       •        
>       •       In other words, why it sends the 'LOWER" when case sensitivity 
> is set
>       •       to false (for string attributes)
>       •        
>       •       This generates sql queries that do not use the index on the 
> attribute.
>       •        
>       •       My opinion is that ActiveRecod should just pass the requirement 
> (case
>       •       sensitive or not) to adapter (e.g. mysql2) and let the
>       •       adapter decide how to do the job/construct the query (which 
> would
>       •       probably take into account db colation or do nothing and let db 
> decide
>       •       how to handle it)
>       •        
>       •       Moreover, I find it inconsistent the fact that default behaviour
>       •       of :uniqueness validator is case sensitive TRUE when finders 
> are all
>       •       case insensitive "don't care". Maybe, as a workaround, except 
> from
>       •       false and true, you can consider something like :uniqueness =>
>       •       {:case_sensitive => :db} and the db colation decide about it.
>       •        
>       •       Currently, I have decided to stop using :uniqueness validator on
>       •       string type attributes, because of all this mess with MySQL 
> colation.
>       •        
>       •       Panayotis
>       •        
>  Topic: A proper way to test that database is not accessed?
>       •       "Mislav Marohnić" <[email protected]> Oct 16 05:52PM 
> +0200 ^
>       •       
>  
>       •       On Oct 16, 2011, at 8:35 AM, KIR wrote:
>       •        
>       •       > ActiveRecord::Base.establish_connection Rails.env
>       •        
>       •       > I don't quite understand what do you mean here?
>       •        
>       •       I know what your problem is. If because of changes to Rails 
> reconnecting to the db by using the old connection doesn't work, then I 
> suggested that you give up on using the old connection and just instruct AR 
> to connect as if the application was just booting up. Have you tried what I 
> suggested at all? Are you having the same problem?
>       •        
>       •       def without_database_connection
>       •       ActiveRecord::Base.remove_connection
>       •       begin
>       •       yield
>       •       ensure
>       •       ActiveRecord::Base.establish_connection Rails.env
>       •       end
>       •       end
>       •        
>       •       KIR <[email protected]> Oct 16 06:22PM +0200 ^
>       •       
>  
>       •       > ActiveRecord::Base.establish_connection Rails.env
>       •       > end
>       •       > end
>       •        
>       •       Thanks Mislav, I tried your suggestion, but it doesn't work.
>       •        
>       •       My actual problem is not about restoring the connection (but 
> thanks for
>       •       the tip, I may need it eventually).
>       •       It is about the fact that I _always_ get exception when I'm 
> trying to
>       •       access model attributes when connection was removed with 
> remove_connection
>       •       (i.e. I get exception in the yield part).
>       •        
>       •       BTW, have you tried your helper on Rails 3.1.1?
>       •        
>       •       Thanks,
>       •       KIR
>       •        
>       •        
>       •        
>       •        
>       •       > [email protected].
>       •       > For more options, visit this group at
>       •       > http://groups.google.com/group/rubyonrails-core?hl=en.
>       •        
>       •       -- 
>       •        
>       •       Kirill (KIR) Maximov
>       •        
>       •       Software Engineer & Starter
>       •        
>       •        
>       •       Twitter: http://twitter.com/maxkir
>       •        
>       •       Skype: maxkir
>       •        
>       •       http://kirblog.idetalk.com | http://checkvist.com |
>       •       http://www.jetbrains.com/teamcity
>       •        
>       •       "Mislav Marohnić" <[email protected]> Oct 16 07:19PM 
> +0200 ^
>       •       
>  
>       •       On Oct 16, 2011, at 6:22 PM, KIR wrote:
>       •        
>       •       > BTW, have you tried your helper on Rails 3.1.1?
>       •        
>       •       I haven't tried my code, I just pulled it out of the air. Sorry 
> that I misunderstood your problem – I thought it was about reconnecting.
>       •        
>       •       I have the feeling that others also didn't get what you were 
> saying; people who got notified about your comment on the issue tracker 
> probably thought that you have a problem in your custom helper.
>       •        
>       •       The most important thing right now to establish whether this is 
> a real bug or not. The behavior which you relied on before the offending 
> change might not have been intentional. It's possible that you might be 
> testing wrong things in your application.
>       •        
>       •       You should describe what are you doing inside the no connection 
> block. (You mentioned using attribute accessors, but in order to generate 
> these accessors, AR must have an open connection so it can fetch information 
> about table columns.) Describe shortly what you were expecting to get and how 
> the new behavior surprises you and breaks your tests.
>       •        
>       •       KIR <[email protected]> Oct 16 07:42PM +0200 ^
>       •       
>  
>       •       > accessors, AR must have an open connection so it can fetch 
> information about
>       •       > table columns.) Describe shortly what you were expecting to 
> get and how the
>       •       > new behavior surprises you and breaks your tests.
>       •        
>       •       Basically, I have a test that I don't have N+1 problem when 
> collecting
>       •       data.
>       •       I do something like this:
>       •        
>       •       # in the production, this may generate hundreds of items (which 
> have own
>       •       associations)
>       •       sub_model_items = model.preload_subitems
>       •        
>       •       assert_no_database {
>       •       json = sub_model_items.build_json
>       •       }
>       •        
>       •       What I'm trying to test - that my code doesn't perform SQL 
> operations
>       •       when building json, i.e. all data should be preloaded.
>       •        
>       •       Thanks,
>       •       KIR
>       •        
>       •        
>       •       -- 
>       •        
>       •       Kirill (KIR) Maximov
>       •        
>       •       Software Engineer & Starter
>       •        
>       •        
>       •       Twitter: http://twitter.com/maxkir
>       •        
>       •       Skype: maxkir
>       •        
>       •       http://kirblog.idetalk.com | http://checkvist.com |
>       •       http://www.jetbrains.com/teamcity
>       •        
>       •       "Mislav Marohnić" <[email protected]> Oct 16 07:58PM 
> +0200 ^
>       •       
>  
>       •       On Oct 16, 2011, at 7:42 PM, KIR wrote:
>       •       > What I'm trying to test - that my code doesn't perform SQL 
> operations when building json, i.e. all data should be preloaded.
>       •        
>       •       That's a perfectly valid thing to test. Looks like it might be 
> a regression. I suggest that you update the issue (where you commented on) 
> with this information, including your own code related to this and provide a 
> stack trace pasted into a Gist.
>       •        
>       •       Until you have a solution for this problem, I suggest testing 
> this another way. In will_paginate, I subscribe to all SQL queries performed 
> and then I check them in tests to see whether there have been too many 
> executed during a particular test.
>       •        
>       •       KIR <[email protected]> Oct 16 09:08PM +0200 ^
>       •       
>  
>       •       > way. In will_paginate, I subscribe to all SQL queries 
> performed<https://github.com/mislav/will_paginate/blob/d56a8436/spec/finders/activerecord_test_connector.rb#L5-23>
>  and
>       •       > then I check them in tests to see whether there have been too 
> many executed
>       •       > during a particular test.
>       •        
>       •       Thanks a lot for the hint, will investigate it.
>       •       May be, I'll be able to rewrite my assert_no_database assertion 
> using
>       •       its approach.
>       •        
>       •       All the best,
>       •       KIR
>       •        
>       •        
>       •       > [email protected].
>       •       > For more options, visit this group at
>       •       > http://groups.google.com/group/rubyonrails-core?hl=en.
>       •        
>       •       -- 
>       •        
>       •       Kirill (KIR) Maximov
>       •        
>       •       Software Engineer & Starter
>       •        
>       •        
>       •       Twitter: http://twitter.com/maxkir
>       •        
>       •       Skype: maxkir
>       •        
>       •       http://kirblog.idetalk.com | http://checkvist.com |
>       •       http://www.jetbrains.com/teamcity
>       •        
>       •       Will Bryant <[email protected]> Oct 17 03:54PM +1300 ^
>       •       
>  
>       •       On 17/10/2011, at 08:08 , KIR wrote:
>       •        
>       •        
>       •       > Thanks a lot for the hint, will investigate it. 
>       •       > May be, I'll be able to rewrite my assert_no_database 
> assertion using its approach.
>       •        
>       •       There's assert_queries/assert_no_queries in the test case 
> support code, which sound quite similar to what you want. But it needs a 
> subscriber implementation (such as Mislav was talking about for 
> will_paginate), which you need to feed into the global variable that the 
> assertions check.
>       •        
>       •       Rails has a subscriber implementation for its own tests, but it 
> isn't exposed. IMHO it would be great it did, so we could just instantiate 
> that in app test code without having to copy it in (it's somewhat 
> version-specific).
>       •        
>       •       Have a look at activerecord/test/cases/helper.rb to see how it 
> works. The assertions that use it are defined in 
> activerecord/lib/active_record/test_case.rb, so they are exposed, which 
> doesn't make much sense at the moment.
>       •        
> 
> -- 
> 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 [email protected].
> To unsubscribe from this group, send email to 
> [email protected].
> For more options, visit this group at 
> http://groups.google.com/group/rubyonrails-core?hl=en.

-- 
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 [email protected].
To unsubscribe from this group, send email to 
[email protected].
For more options, visit this group at 
http://groups.google.com/group/rubyonrails-core?hl=en.

Reply via email to