Senior Software Engineer: Love Writing and Reading Software, Taking Entrepreneurial Risks, Teaching Computer Programming & Blogging here or in many other places. I also Love Music and I can call myself a small pianist!
I have been using Solr the last two years for quite some projects. My work was always done using sunspot
(via sunspot_rails when one has Rails application), a gem that is a client library for Solr.
You need to know few things about Solr, when using sunspot to access it and do most of the things. sunspot is a fantastic gem and relieves you from
huge amounts of work when storing data in a Solr database.
Hence, I decided to take a journey to Solr. And this will be a registration of my steps to this journey. Understanding how Solr works, will make me manage
better what I can do and achieve with sunspot too.
Did you know that you can execute migration commands from rails console? Assume that you want to change the column ‘name’ of the ‘Product’ model, to have a limit of 32 characters and set it to not null. Here is what you can do:
Example of ActiveRecord Migration run from Rails Console
Capistrano is a great tool for deploying Ruby on Rails applications on remote server machines. If you have ever used it, you may already know that it creates new directory structures for each new release that it realizes and sets “current” to point to the latest one.
This is very fine, but there are cases in your application that you might want to share the same directory data among releases. You can declare in your “deploy.rb” file the directories that will be shared among your releases. By default, the directories “log”, “public/system” and “tmp/pids” are already shared. Hence, you do not have to do anything for them. But, if, for example, you want to share the “my_custom_data” directory that you have inside your application structure, you need to add the following line inside your “deploy.rb” file:
I consider testing one of the most important phase in application development and Rails does a very good job on that. However, testing documentation on Rails Guides is still work under development.
Here is a short tutorial on how you can test that a reponse has rendered the correct template and the correct layout.
If you want to make sure that the response rendered the correct template and layout, you can use the assert_template method:
test"index should render correct template and layout"doget:indexassert_template:indexassert_template:layout=>"layouts/application"end
Note that you cannot test for template and layout at the same time, with one call to assert_template method. Also, for the layout test, you can give a regular expression instead of a string, but using the string, makes things clearer. On the other hand, you have to include the “layouts” directory name even if you save your layout file in this standard layout directory. Hence,
This will not work
will not work.
Gotcha: Watch out if your view renders any partial
If your view renders any partial, when asserting for the layout, you have to assert for the partial at the same time. Otherwise, assertion will fail.
Correct way to assert for the layout
test"new should render correct layout"doget:newassert_template:layout=>"layouts/application",:partial=>"_form"end
is the correct way to assert for the layout when the view renders a partial with name_form. Omitting the :partial key in your assert_template call will complain.
This week I have decided to use octopus, a fantastic gem for realizing replication or sharding. I have already implemented MySQL Replication (Master / Slave) and I wanted to have my Ruby on Rails application actually use it!