learning – redpanthers.co

Lambda vs Proc Vs Blocks

coderhs — Tue, 23 Aug 2016 09:45:09 +0000

Blocks: They are called closures in other languages, it is a way of grouping code/statements. In ruby single line blocks are written in {} and multi-line blocks are represented using do..end An interesting fact about ruby is that all methods in ruby accept a block, even if you don’t declare a variable to accept it. So for example, take the method below

def my_method
  puts "Hello World"
end

It can accept a block as below

my_method { puts 'Hello Reader' }

The code is valid, but the output will have only puts “Hello World”. Why? because we passed in the block but it is not getting called. To run the block passed within your method you need to use the yield command.

def my_method
  puts 'Hello World'
  yield
end

Now it will print

Hello World.
Hello Reader.

But since we placed yield, it would now be expecting a block to be always passed in. So we need to write code to check if a block is given or not. The command to do that in ruby is block_given?.

def my_method
  puts 'Hello World'
  yield if block_given?
end

Proc Is a block itself, but it’s bound to a variable. So proc lets us save a code block to a variable, and pass it around in our application. A good example from the ruby docs is shown below

def gen_times(factor)
  return Proc.new {|n| n*factor }
end
times3 = gen_times(3)
times5 = gen_times(5)
times3.call(12)               #=> 36
times5.call(5)                #=> 25
times3.call(times5.call(4))   #=> 60

Lambda If you felt proc’s to be a refined version of block, then you can say lambda’s to be a refined version of proc. Lambda is essentially a proc itself but, the argument management is rigid. If it doesn’t get an argument or if the argument count is more or less it would raise an error. Example:

Proc.new {|a,b| [a,b] }.call(1,2,3)
=> [1,2]

lambda {|a,b| [a,b] }.call(1,2,3)
=>
ArgumentError: wrong number of arguments (3 for 2)
	from (irb):7:in `block in irb_binding'
	from (irb):7:in `call'
	from (irb):7
	from /home/dev1/.rvm/rubies/ruby-2.2.2/bin/irb:11:in `'
2.2.2 :008 > Proc.new {|a,b| [a,b] }.call(1,2,3)

Since it’s now clearer to you on what block, proc and lambda is, let’s start with the difference between the three. Lambda shortcut notation.

code = -> (x) { x*x }
code.call 4
=> 16

Lambda vs proc vs Blocks Proc and Blocks are the same, block is actually creating a single instance of proc which can’t be moved about in a variable. You can read about the similarity of Proc and Block here. If we do return within a lambda, it would just return from lambda and the method will continue.

def lambda_method
  lambda { return puts 'lambda' }.call
  return 'method'
end
lambda_method
=> method

If we do return with a proc, it would exit the method and return that value from proc.

def proc_method
  Proc.new { return puts 'proc' }.call
  puts 'method'
end
proc_method
=> proc

Arguments: The second difference between the three is the way they manage arguments. Block and Proc deal with them more or less the same, but lambda is totally different. Proc and Bloc, doesn’t mind about the number of arguments passed. But if we access a variable that is not present then it would raise an error.

def my_method
  yield 1, 2, 3
end
my_method { |x, y| puts "#{x} & #{y}" }
=> "1 & 2"

Proc.new { |x, y| puts "#{x} & #{y}" }.call(4, 5, 6)
=> "4 & 5"

lambda will raise an error

def my_method
  yield
end
my_method { |x, y| puts "#{x} & #{y}" }

Takeaways Block, Proc & Lambda are the three different ways of grouping the code: Block:

Is in between the curly braces and in between do and end.
No issue with number of arguments.
Blocks are basically a proc without a name

Proc:

Similar behaviour as Block.
Can be stored in a variable and move around.
No issue with number of arguments.
Return within the proc would exit the method from where it is called.

Lambda

Same as Proc, but closer to a method.
Strict regarding the arguments it gets and it needs.
Return within a lambda would exit it from the lambda and the method would continue executing.

]]>

Optimising PostgreSQL database query using indexes

coderhs — Thu, 11 Aug 2016 10:59:22 +0000

Database Indexes: Indexes are a special lookup table that the database search engine can use to speed up data retrieval. An Index is similar to a pointer to a particular row of a table. As a real world example, consider a Britannica Encyclopedia with 22 volumes of books, and an extra book listing the index,with which you can find out the item you are searching for in those 22 books. PostgreSQL 9.5, provides several index algorithms like B-tree, Hash, GiST, SP-GiST and GIN. When you create an index using Ruby on Rails migration, by default it would be using the B-Tree migration. Whereas, as we move on to the indexing algorithms, we need to check into the general classification of an index and the data to be indexed. Primary Keys In rails, when we generate a model , by default an ID column would be added to the table. It would have integers values and they would be unique as well. By default, when you set a column as a primary key, the database would build a unique index on it. So we don’t need to add migration for it. Foreign Keys When you build a relationship between two tables you add a foreign_key in the child table to point to parent, eg: user_id, group_id. We need to query through this relationship a lot in rails, for example to load all the comments of post or all members of a group. So we need to index that for speed.. If you are using some non id value to reference a table, lets say in your application ,you give all your users a unique URL which has the username. (Eg: http://csnipp.com/coderhs), in that case we would be using the username to query the data, so we need to have it indexed. In fact you should index all the columns you might be using in your where queries. Like if you are searching for users of a particular age or income frequents in your reports, then you should create an index for them as well. Note: What we explained above are single column indexes and multi column indexes. So if you are indexing just a single column in a table, its single column indexes.

CREATE INDEX index_name
ON prices (user_id);

Rails code:

add_index :prices, :user_id

When we index multiple columns, they are called multi column index.

CREATE INDEX index_name
ON user_views (user_id, article_id);

Rails code:

add_index :user_views, [:user_id, :article_id]

If you are joining two tables, using a column (which is not the already indexed foreign key) then you should index that as well. State column & Boolean column State and Boolean column are columns that should be indexed as there would be a lot of rows but only limited number of values in those columns. Boolean column would have only true or false (two values)and state columns will have more than two like eg: draft, published, pending. The speed of load would be faster for these columns as they are only limited keys that can be placed in the index, and on a single lookup we can load them. Partial indexes can be used in the above case, as the name suggests it’s an index over a subset of your table. The index would be building if it satisfies certain conditions. They can be most useful while writing scopes in rails. Lets say that you have a scope that picks up all the articles which are marked as SPAM. In your model you will write a scope like below

scope :articles, where(:spam => 'true')

So internally it’s a where query, one can add a partial index migration as follows:

CREATE INDEX index_name
on articles (spam is true);

Rails:

add_index :articles, :spam, name: "index_articles_on_spam", where: "(spam IS true)"

When not to use indexes Using indexes speeds up the SELECT and WHERE command, but it does slows down the execution of INSERT. So avoid indexing when we have table that has a lot of insert and update So we should avoid using Indexes when we have a table that holds a huge number of raw data, where we do a lot of batch updates and insert. For example, in an IoT application we would pipe all the data from multiple devices to a single table , summarize and insert it into its proper tables. And by a lot of data, I am referring to at least 10+ MB of data per minute. In most cases, we would just truncate that table after processing, hence it would slow us down if we were to index it. If the table is too small and you know it will always be small If you have a setting table which just stores the application settings, that can be modified by an admin panel. Then it doesn’t seem to be worth having an index there. When you are manipulating the values of a column a lot Lets say the particular value of a column gets changes extremely a lot, like the website view count. Then indexing it is not highly recommended. Finally to complete this article. If you want to drop an index: SQL

DROP INDEX index_name;

Rails

remove_index :books, :created_at

Summary:

Index Primary key
Index Foreign key
Index all columns you would be passing into where clause
Index the keys used to Join tables
Index the date column (if you are going to call it frequent, like rankings of a particular date)
Index the type column in an STI or polymorphism.
Add partial index to scopes
Do not index tables with a lot of read, write
Do not index tables you know that will remain small, all through out its life time
Do not index columns where you will be manipulating lot of its values.

Keep visiting here to know more about the PostgreSQL indexing algorithms in part 2 of this article. References: https://www.postgresql.org/docs/9.2/static/indexes-types.html http://dev.mysql.com/doc/refman/5.7/en/mysql-indexes.html http://www.tutorialspoint.com/postgresql/postgresql_indexes.htm]]>

Database transaction in Rails

coderhs — Mon, 01 Aug 2016 11:38:48 +0000

A transaction is a sequence of operations performed as a single logical unit of work. A logical unit of work must exhibit four properties called the atomicity, consistency, isolation and durability (ACID) properties, to qualify as a transaction. We use database transactions to make sure that all the instructions we send to database are successful, and would cause changes to the database only if they are successful. Let’s say that you are working on a banking application which would withdraw money from one account and deposit into another account. The code for it would look like below

User.find(156).withdraw(1000)
User.find(157).deposit(1000)

But for some reason, the withdrawal was successful but the deposit was not, the amount was taken out but never deposited to the other user.To avoid these kind of issues, database has a functionality called transactions, in which you can build up each sql query. But if for any reason, any of the sql statements fails or an exception rises in the block, all the transactions are rolled back to their original form.

User.transaction do
  User.find(156).withdraw(1000)
  User.find(157).deposit(1000)
end

In rails, the transaction method is available as class method and instance method, but the functionality for both is same. There is no difference when you will use.

@user.transaction do
end

and

User.transaction do
end

The reason why rails provides this, is for better readability. One can also mix various model types in a transaction, as the transaction are bound to a database connection. So there is no issue in writing code like below.

User.transaction do
  Order.create order_attributes
  Purchase.create purchase_attribute
end

Nested Transactions: It is possible to write nested transactions. But it is to be noted that, it would just make each child transaction a part of the parent transaction. Taking the example from the Rails documentation. The below code

User.transaction do
  User.create(username: 'Kotori')
  User.transaction do
    User.create(username: 'Nemu')
    raise ActiveRecord::Rollback
  end
end

Creates both “Kotori” and “Nemu”. Reason is the ActiveRecord::Rollback exception in the nested block does not issue a ROLLBACK. Since these exceptions are captured in transaction blocks, the parent block does not see it and the real transaction is committed. Reference: https://technet.microsoft.com/en-us/library/ms190612(v=sql.105).aspx]]>