Getting your bug fix/code pulled into the main repo really gets you excited & satisfied.
I never thought it could give me this much sense of enjoyment. Check it out.
I’m figuring out something in my rails app. I’m figuring out which one’s the worst:
Eager loading 100 rows of data you don’t actually need at the moment
or
10 queries giving 10 result set at once?
Here’s the code to explain it.
@event = Event.find(params[:event_id]) @event_attendees = @event.attendees.paginate(:page => params[:page], :per_page => 10)
In the view, for each attendees, it’s calling a purchase record. Since I’m using will_paginate and setting 10 records per page, for every 10 record of attendees, there’s 10 queries for a purchase record. Here’s the following SQL that will be generated:
SELECT * FROM `attendees` WHERE (`attendees`.event_id = 4) SELECT * FROM `purchases` WHERE (purchasable_type = 'Attendee' and purchasable_id = 1) LIMIT 1 SELECT * FROM `purchases` WHERE (purchasable_type = 'Attendee' and purchasable_id = 2) LIMIT 1 SELECT * FROM `purchases` WHERE (purchasable_type = 'Attendee' and purchasable_id = 3) LIMIT 1 SELECT * FROM `purchases` WHERE (purchasable_type = 'Attendee' and purchasable_id = 4) LIMIT 1 SELECT * FROM `purchases` WHERE (purchasable_type = 'Attendee' and purchasable_id = 5) LIMIT 1 SELECT * FROM `purchases` WHERE (purchasable_type = 'Attendee' and purchasable_id = 6) LIMIT 1 SELECT * FROM `purchases` WHERE (purchasable_type = 'Attendee' and purchasable_id = 7) LIMIT 1 SELECT * FROM `purchases` WHERE (purchasable_type = 'Attendee' and purchasable_id =LIMIT 1 SELECT * FROM `purchases` WHERE (purchasable_type = 'Attendee' and purchasable_id = 9) LIMIT 1 SELECT * FROM `purchases` WHERE (purchasable_type = 'Attendee' and purchasable_id = 10) LIMIT 1
Clearly you can that see the above code creates a n + 1 problem.
So I tried to modified it using eager loading like the following:
@event_attendees = @event.attendees.paginate(:include => :purchase, :page => params[:page], :per_page => 10)
Here’s the following SQL query generated:
SELECT * FROM `attendees` WHERE (`attendees`.event_id = 4) SELECT `purchases`.* FROM `purchases` WHERE (`purchases`.`purchasable_id` IN (1,2,3,4..100) and `purchases`.`purchasable_type` = 'Attendee') # query is shorten for brevity
You can see that it’s using 1 query that fetches 100 rows of data. At first I thought that it will limit the eager loading with my will_paginate per page settings. But clearly for every page that I’m viewing, it’s calling that query hence returning 100 rows of data for each page I’m viewing.
At the moment I’m using the query without eager loading. Simply because I’m concern the app is fetching 100 rows that I don’t need at once. I have no idea how to limit an eager loading association base on will _paginate per_page. Or probably I could eager load once and keep in cache. Or does rails does that automatically?
Will investigate though. Oh well, back to work!
Something peculiar happened when I was doing something trivial.
If you accidently named your restful route the following
resource :roles instead of resources :roles
When you point your app to /roles it won’t go to your index controller action but it will instead call your show action.
I had a problem when running git svn command on my ubuntu.
Can’t locate SVN/Core.pm in @INC
It turns out all I had to do is install libsvn-perl.
I had trouble reindexing the ferret index using the rake command (rake ferret:rebuild). I got this non-descriptive error regarding failing to rebuild it (Even in my development mode). So after googling for it, all one has to do is so simple.
Go into your rails script/console and just type
Model.rebuild_index
And you’re done.
This is how people are upset about Twitter.
http://iamrice.org/post/46208882/bullshit-hitler-twitters
For example:
id |category_id | inventory_id
1 384 1 #first entry 2 384 2 #this would be ok. 3 384 1 #this would not be ok
To ensure that a category_id doesn’t have any inventory_id duplicate:
class CategoryProduct < ActiveRecord::Base belongs_to :category belongs_to :inventory validates_uniqueness_of :category_id, :scope => :inventory_id end
A good read on table index.
http://www.railway.at/articles/2008/04/24/database-agnostic-database-ignorant
Sometimes, it is easy to forget when someone or something else handles it for you. For instance, ActiveRecords. Rails does not create foreign keys for you. It only creates the primary key. It does not impose constraint on the database level. The association is handled on the application level. So always remember to create an index for your model associations. It could save your database server from working too hard.
Do not name your database column with the name ‘no’.
You’ll get this error when you try to run your test
ActiveRecord::StatementInvalid: Mysql::Error: Unknown column ‘false’ in ‘field list’
If you’re someone who has multiple git branches on a project and seem to always do git branch to check which branch you’re in. Then here’s how you can make your bash aware of a git branch.
Well, I’m not sure if this works on others, but it sure does works in my Ubuntu Hardy. Just edit your .bashrc at your home folder.
vim .bashrc
Add the following at the very bottom of your .bashrc
parse_git_branch() {
git branch 2> /dev/null | sed -e '/^[^*]/d' -e 's/* \(.*\)/(\1)/'
}
PS1="${debian_chroot:+($debian_chroot)}\u@\h:\w\$(parse_git_branch) $ "
After that, save it and restart your terminal. You should see something like this at your terminal:
fadhli@atlantis:~/projects/crimson_mdec(master) $
I have a branch named biz_idea, so after a git checkout biz_idea
Switched to branch “biz_idea”
fadhli@atlantis:~/projects/crimson_mdec(biz_idea) $
LIMIT 1
SELECT * FROM `purchases` WHERE (purchasable_type = 'Attendee' and purchasable_id = 9) LIMIT 1
SELECT * FROM `purchases` WHERE (purchasable_type = 'Attendee' and purchasable_id = 10) LIMIT 1