Expertiza_Wiki - User contributions [en]

CSC/ECE 517 Fall 2014/oss E1465 oak

2014-10-30T01:06:40Z

Knimgao: /* Comparison of Original and Refactored Code */

=Expertiza - Refactoring UsersController=

__TOC__

==Introduction==
Expertiza<ref name="expertiza>''Expertiza'' http://wikis.lib.ncsu.edu/index.php/Expertiza</ref> is a web application available to both students and professors. The Expertiza project is a system to create reusable learning objects through peer review. Expertiza supports team projects and the submission of almost any document type, including URLs and wiki pages. Students can keep a track of their assignments, teammates and can conduct peer reviews on diverse topics and projects. It is an open source project developed on Ruby on Rails platform. More information on Expertiza can be found [https://github.com/expertiza/expertiza here]. The source code can be forked and cloned for making modifications.

As a part of the coursework of Object Oriented Design and Development, we were expected to refactor the funtionality of some modules of Expertiza. This wiki provides an insight into our contributions to the Open Source Software project 'Expertiza' by Refactoring the Users Controller.

==Project Description==
The Users Controller deals with managing activities peripheral to the User registered with Expertiza. Users are mapped to different roles like super-admin, admin, instructor, teaching assistant and student with each role having different access permissions. The Manage Users module can be accessed by roles other than the student. It provides users with the functionality to search other users based on keywords like username, email, etc. New user can be created and existing user information and role can be updated.

Classes : users_controller.rb 
What it does : Manage Users i.e.search and list users, create new user, edit/update existing users, delete users. 
What has to be changed : 
* Modify methods to conform to RESTful style
* Reducing the number of instance variables per action to one
* Code cleanup by using string interpolation instead of concatenation, replacing '==' with eql? and :key =>'value' with key: 'value', modifying declarations of Arrays and Hashes and removing commented out code
* Use of routing helpers instead of hardcoded URLs
* Replace find_by with where to follow Rails 4.0 conventions

==Modification to Existing Code==

===RESTful style implementation===
* Modifications to users_controller.rb : The purpose of the index method in Users Controller is to list all registered users. The list method was called from the index method to list all users. This implementation did not conform to RESTful guidelines. Hence, we refactored the list method in users controller to index. Further, we refactored all the references of list method in UserControllers, Users views, Users tests and routes.rb to the index method.

Before Refactoring :
<pre>
def index
if (current_user_role? == "Student")
redirect_to(:action => AuthHelper::get_home_action(session[:user]), :controller => AuthHelper::get_home_controller(session[:user]))
else
list
render :action => 'list'
end
end

#for displaying the list of users
def list
user = session[:user]
role = Role.find(user.role_id)
all_users = User.order('name').where( ['role_id in (?) or id = ?', role.get_available_roles, user.id])

letter = params[:letter]
session[:letter] = letter
if letter == nil
letter = all_users.first.name[0,1].downcase
end
logger.info "#{letter}"
@letters = Array.new

@per_page = 1

# Check if the "Show" button for pagination is clicked
# If yes, set @per_page to the value of the selection dropdown
# Else, if the request is from one of the letter links on the top
# set @per_page to 1 (25 names per page).
# Else, set @per_page to the :num_users param passed in from
# the will_paginate method from the 'pagination' partial.
if params[:paginate_show]
@per_page = params[:num_users]
elsif params[:from_letter]
@per_page = 1
else
@per_page = params[:num_users]
end

# Get the users list to show on current page
@users = paginate_list(role, user.id, letter)

@letters = ('A'..'Z').to_a
end
</pre>

After Refactoring :

<pre>
#for displaying the list of users
def index
if (current_user_role? == "Student")
redirect_to(:action => AuthHelper::get_home_action(session[:user]), :controller => AuthHelper::get_home_controller(session[:user]))
else
#list method's implementation
end
end
</pre>

===Instance Variable Reductions===
It is a bad practice to have more than one instance variables in a controller's method as it indicates increased coupling. Coupling must be as less as possible and the view should have direct access to as few instance variables as possible. Helper methods should be defined in controllers through which the view can access variables of the controller class. The code has been refactored to make use of helper methods for the instance variables in index action.

Before Refactoring

users_controller.rb
<pre>

def get_role
if @user && @user.role_id
@role = Role.find(@user.role_id)
elsif @user
@role = Role.new(:id => nil, :name => '(none)')
end
end
</pre>

show.html.erb

<pre>
<tr><th>Role:</th>
<td><%= link_to @role.name, :controller => 'roles',
:action => 'show', :id => @role.id %></td>
</tr>
</pre>

After Refactoring

users_controller.rb
<pre>
def get_role
if @user && @user.role_id
role = Role.find(@user.role_id)
elsif @user
role = Role.new(id: nil, name: '(none)')
end
return role
end
</pre>

show.html.erb

<pre>
<tr><th>Role:</th>
<td><%= link_to get_role.name, :controller => 'roles',
:action => 'show', :id => get_role.id %></td>
</tr>

</table>
</pre>

Similar approach for reduction of instance variables has been implemented in other methods like index, show_selection, etc.

===Code Cleanup===
Code cleanup in the controller so that the code conforms closely to Rails conventions and further enhances the readability of the code.
* Replaced String concats with #{} in paginate_list
Before Refactoring :

<pre>
#paginate_list
search_filter = letter + '%'
search_filter = '%' + letter + '%'
</pre>

After Refactoring :

<pre>
#paginate_list
search_filter = "#{letter}%"
search_filter = "%#{letter}%"
</pre>

* Replaced '==' with eql?
Before Refactoring :
<pre>
#index
if (current_user_role? == "Student")
...
letter == nil

#show_selection
@role.parent_id == nil || @role.parent_id < (session[:user]).role_id || @user.id == (session[:user]).id

#show
if (params[:id].nil?) || ((current_user_role? == "Student") && (session[:user].id != params[:id].to_i))

#create
if @user.role.name == "Instructor" or @user.role.name == "Administrator"

#keys
if (params[:id].nil?) || ((current_user_role? == "Student") && (session[:user].id != params[:id].to_i))

#paginate_list
if @search_by == '1'
</pre>

After Refactoring :
<pre>
#index
if (current_user_role.eql? "Student")
...
if letter.eql? nil

#show_selection
if role.parent_id.eql? nil || role.parent_id < (session[:user]).role_id || @user.id.eql?(session[:user]).id

#show
if (params[:id].nil?) || ((current_user_role.eql? "Student") && (session[:user].id != params[:id].to_i))

#create
if @user.role.name.eql? "Instructor" or @user.role.name.eql? "Administrator"

#keys
if (params[:id].nil?) || ((current_user_role.eql? "Student") && (session[:user].id != params[:id].to_i))

#paginate_list
if @search_by.eql? '1' #search by user name
</pre>

* Replaced :key =>'value' with key: 'value'

Before Refactoring :
<pre>
#index
redirect_to(:action => AuthHelper::get_home_action(session[:user]), :controller => AuthHelper::get_home_controller(session[:user]))

#show_selection
render :action => 'show'

#create
AssignmentQuestionnaire.create(:user_id => @user.id)
</pre>

After Refactoring :
<pre>
#index
redirect_to(action: AuthHelper::get_home_action(session[:user]), controller: AuthHelper::get_home_controller(session[:user]))

#show_selection
render action: 'show'

#create
AssignmentQuestionnaire.create(user_id: @user.id)
</pre>

*Modified declarations of Arrays and Hashes
Before Refactoring :
<pre>
#index
@letters = Array.new

#paginate_list
paginate_options = {"1" => 25, "2" => 50, "3" => 100}
</pre>

After Refactoring :
<pre>
#index
@letters =[]

#paginate_list
paginate_options = Hash["1" ,25 , "2", 50, "3", 100]
</pre>

*Removed unused methods like self.participants_in and commented out code.

===Use of Routing Helpers===
Routing helpers are a simpler alternative to the otherwise complex hard coded URLs which reduce the readability of the code.Routing helpers allow us to declare possible common routes for a given controller. Routing helpers have been implemented since they maintain consistency even if changes are made to the routing paths.

Before Refactoring:
 
<pre>
def show_selection
@user = User.find_by_name(params[:user][:name])
if @user != nil
get_role
if @role.parent_id == nil || @role.parent_id < (session[:user]).role_id || @user.id == (session[:user]).id
render :action => 'show'
else
flash[:note] = 'The specified user is not available for editing.'
redirect_to :action => 'list'
end
else
flash[:note] = params[:user][:name]+' does not exist.'
redirect_to :action => 'list'
end
end
</pre>
 
After Refactoring
 
<pre>
def show_selection
@user = User.where(name: params[:user][:name]).take
if @user != nil
role=get_role
if role.parent_id.eql? nil || role.parent_id < (session[:user]).role_id || @user.id.eql?(session[:user]).id
render action: 'show'
else
flash[:note] = 'The specified user is not available for editing.'
redirect_to users_path #Replaced URL with routing helper
end
else
flash[:note] = params[:user][:name]+' does not exist.'
redirect_to users_path #Replaced URL with routing helper
end
end
</pre>
 

===Replace find_by_.. with where in querying===
Rails 4 conventions dictate the use of 'where()' over the use of 'find_by_...' methods while querying ActiveRecords. The code has been refactored to replace the usages of find_by.. with where().

Before Refactoring
<pre>
def show_selection
@user = User.find_by_name(params[:user][:name])
if @user != nil
</pre>

After Refactoring
<pre>
def show_selection
@user = User.where(name: params[:user][:name]).take
if @user != nil
</pre>

==Comparison of Original and Refactored Code==

Major refactoring revolved around moving lines of codes between methods, modifying array and hash declarations, using helper methods for avoiding multiple instance variables in controller methods and implementing Ruby Conventions. 

*Lines of Code

Original : 248 
Post Refactoring : 224

*Code Complexity (Compared on Code Climate)

Original UsersController<ref name="originaluserscontroller>''Original UsersController'' https://codeclimate.com/github/expertiza/expertiza/UsersController</ref>
 
Refactored UsersController<ref name="refactoreduserscontroller>''Refactored UsersController'' https://codeclimate.com/repos/5450f2eae30ba012a6011c01/UsersController</ref>

==Further Readings==
1.[https://github.com/ameyp1992/expertiza.git Git Repository]

2.[http://wiki.expertiza.ncsu.edu/index.php/Development:Setup:Linux:Debian Expertiza Setup]

3.[https://docs.google.com/document/d/1FZCL9KWSdVNsX9BowuZ3gxbCOJoiWX-GVLctSZei3No/edit?pli=1#heading=h.2y12n9sli9rd Project requirements]

==References==

<references/>

CSC/ECE 517 Fall 2014/oss E1465 oak

2014-10-30T01:02:10Z

Knimgao:

=Expertiza - Refactoring UsersController=

__TOC__

==Introduction==
Expertiza<ref name="expertiza>''Expertiza'' http://wikis.lib.ncsu.edu/index.php/Expertiza</ref> is a web application available to both students and professors. The Expertiza project is a system to create reusable learning objects through peer review. Expertiza supports team projects and the submission of almost any document type, including URLs and wiki pages. Students can keep a track of their assignments, teammates and can conduct peer reviews on diverse topics and projects. It is an open source project developed on Ruby on Rails platform. More information on Expertiza can be found [https://github.com/expertiza/expertiza here]. The source code can be forked and cloned for making modifications.

As a part of the coursework of Object Oriented Design and Development, we were expected to refactor the funtionality of some modules of Expertiza. This wiki provides an insight into our contributions to the Open Source Software project 'Expertiza' by Refactoring the Users Controller.

==Project Description==
The Users Controller deals with managing activities peripheral to the User registered with Expertiza. Users are mapped to different roles like super-admin, admin, instructor, teaching assistant and student with each role having different access permissions. The Manage Users module can be accessed by roles other than the student. It provides users with the functionality to search other users based on keywords like username, email, etc. New user can be created and existing user information and role can be updated.

Classes : users_controller.rb 
What it does : Manage Users i.e.search and list users, create new user, edit/update existing users, delete users. 
What has to be changed : 
* Modify methods to conform to RESTful style
* Reducing the number of instance variables per action to one
* Code cleanup by using string interpolation instead of concatenation, replacing '==' with eql? and :key =>'value' with key: 'value', modifying declarations of Arrays and Hashes and removing commented out code
* Use of routing helpers instead of hardcoded URLs
* Replace find_by with where to follow Rails 4.0 conventions

==Modification to Existing Code==

===RESTful style implementation===
* Modifications to users_controller.rb : The purpose of the index method in Users Controller is to list all registered users. The list method was called from the index method to list all users. This implementation did not conform to RESTful guidelines. Hence, we refactored the list method in users controller to index. Further, we refactored all the references of list method in UserControllers, Users views, Users tests and routes.rb to the index method.

Before Refactoring :
<pre>
def index
if (current_user_role? == "Student")
redirect_to(:action => AuthHelper::get_home_action(session[:user]), :controller => AuthHelper::get_home_controller(session[:user]))
else
list
render :action => 'list'
end
end

#for displaying the list of users
def list
user = session[:user]
role = Role.find(user.role_id)
all_users = User.order('name').where( ['role_id in (?) or id = ?', role.get_available_roles, user.id])

letter = params[:letter]
session[:letter] = letter
if letter == nil
letter = all_users.first.name[0,1].downcase
end
logger.info "#{letter}"
@letters = Array.new

@per_page = 1

# Check if the "Show" button for pagination is clicked
# If yes, set @per_page to the value of the selection dropdown
# Else, if the request is from one of the letter links on the top
# set @per_page to 1 (25 names per page).
# Else, set @per_page to the :num_users param passed in from
# the will_paginate method from the 'pagination' partial.
if params[:paginate_show]
@per_page = params[:num_users]
elsif params[:from_letter]
@per_page = 1
else
@per_page = params[:num_users]
end

# Get the users list to show on current page
@users = paginate_list(role, user.id, letter)

@letters = ('A'..'Z').to_a
end
</pre>

After Refactoring :

<pre>
#for displaying the list of users
def index
if (current_user_role? == "Student")
redirect_to(:action => AuthHelper::get_home_action(session[:user]), :controller => AuthHelper::get_home_controller(session[:user]))
else
#list method's implementation
end
end
</pre>

===Instance Variable Reductions===
It is a bad practice to have more than one instance variables in a controller's method as it indicates increased coupling. Coupling must be as less as possible and the view should have direct access to as few instance variables as possible. Helper methods should be defined in controllers through which the view can access variables of the controller class. The code has been refactored to make use of helper methods for the instance variables in index action.

Before Refactoring

users_controller.rb
<pre>

def get_role
if @user && @user.role_id
@role = Role.find(@user.role_id)
elsif @user
@role = Role.new(:id => nil, :name => '(none)')
end
end
</pre>

show.html.erb

<pre>
<tr><th>Role:</th>
<td><%= link_to @role.name, :controller => 'roles',
:action => 'show', :id => @role.id %></td>
</tr>
</pre>

After Refactoring

users_controller.rb
<pre>
def get_role
if @user && @user.role_id
role = Role.find(@user.role_id)
elsif @user
role = Role.new(id: nil, name: '(none)')
end
return role
end
</pre>

show.html.erb

<pre>
<tr><th>Role:</th>
<td><%= link_to get_role.name, :controller => 'roles',
:action => 'show', :id => get_role.id %></td>
</tr>

</table>
</pre>

Similar approach for reduction of instance variables has been implemented in other methods like index, show_selection, etc.

===Code Cleanup===
Code cleanup in the controller so that the code conforms closely to Rails conventions and further enhances the readability of the code.
* Replaced String concats with #{} in paginate_list
Before Refactoring :

<pre>
#paginate_list
search_filter = letter + '%'
search_filter = '%' + letter + '%'
</pre>

After Refactoring :

<pre>
#paginate_list
search_filter = "#{letter}%"
search_filter = "%#{letter}%"
</pre>

* Replaced '==' with eql?
Before Refactoring :
<pre>
#index
if (current_user_role? == "Student")
...
letter == nil

#show_selection
@role.parent_id == nil || @role.parent_id < (session[:user]).role_id || @user.id == (session[:user]).id

#show
if (params[:id].nil?) || ((current_user_role? == "Student") && (session[:user].id != params[:id].to_i))

#create
if @user.role.name == "Instructor" or @user.role.name == "Administrator"

#keys
if (params[:id].nil?) || ((current_user_role? == "Student") && (session[:user].id != params[:id].to_i))

#paginate_list
if @search_by == '1'
</pre>

After Refactoring :
<pre>
#index
if (current_user_role.eql? "Student")
...
if letter.eql? nil

#show_selection
if role.parent_id.eql? nil || role.parent_id < (session[:user]).role_id || @user.id.eql?(session[:user]).id

#show
if (params[:id].nil?) || ((current_user_role.eql? "Student") && (session[:user].id != params[:id].to_i))

#create
if @user.role.name.eql? "Instructor" or @user.role.name.eql? "Administrator"

#keys
if (params[:id].nil?) || ((current_user_role.eql? "Student") && (session[:user].id != params[:id].to_i))

#paginate_list
if @search_by.eql? '1' #search by user name
</pre>

* Replaced :key =>'value' with key: 'value'

Before Refactoring :
<pre>
#index
redirect_to(:action => AuthHelper::get_home_action(session[:user]), :controller => AuthHelper::get_home_controller(session[:user]))

#show_selection
render :action => 'show'

#create
AssignmentQuestionnaire.create(:user_id => @user.id)
</pre>

After Refactoring :
<pre>
#index
redirect_to(action: AuthHelper::get_home_action(session[:user]), controller: AuthHelper::get_home_controller(session[:user]))

#show_selection
render action: 'show'

#create
AssignmentQuestionnaire.create(user_id: @user.id)
</pre>

*Modified declarations of Arrays and Hashes
Before Refactoring :
<pre>
#index
@letters = Array.new

#paginate_list
paginate_options = {"1" => 25, "2" => 50, "3" => 100}
</pre>

After Refactoring :
<pre>
#index
@letters =[]

#paginate_list
paginate_options = Hash["1" ,25 , "2", 50, "3", 100]
</pre>

*Removed unused methods like self.participants_in and commented out code.

===Use of Routing Helpers===
Routing helpers are a simpler alternative to the otherwise complex hard coded URLs which reduce the readability of the code.Routing helpers allow us to declare possible common routes for a given controller. Routing helpers have been implemented since they maintain consistency even if changes are made to the routing paths.

Before Refactoring:
 
<pre>
def show_selection
@user = User.find_by_name(params[:user][:name])
if @user != nil
get_role
if @role.parent_id == nil || @role.parent_id < (session[:user]).role_id || @user.id == (session[:user]).id
render :action => 'show'
else
flash[:note] = 'The specified user is not available for editing.'
redirect_to :action => 'list'
end
else
flash[:note] = params[:user][:name]+' does not exist.'
redirect_to :action => 'list'
end
end
</pre>
 
After Refactoring
 
<pre>
def show_selection
@user = User.where(name: params[:user][:name]).take
if @user != nil
role=get_role
if role.parent_id.eql? nil || role.parent_id < (session[:user]).role_id || @user.id.eql?(session[:user]).id
render action: 'show'
else
flash[:note] = 'The specified user is not available for editing.'
redirect_to users_path #Replaced URL with routing helper
end
else
flash[:note] = params[:user][:name]+' does not exist.'
redirect_to users_path #Replaced URL with routing helper
end
end
</pre>
 

===Replace find_by_.. with where in querying===
Rails 4 conventions dictate the use of 'where()' over the use of 'find_by_...' methods while querying ActiveRecords. The code has been refactored to replace the usages of find_by.. with where().

Before Refactoring
<pre>
def show_selection
@user = User.find_by_name(params[:user][:name])
if @user != nil
</pre>

After Refactoring
<pre>
def show_selection
@user = User.where(name: params[:user][:name]).take
if @user != nil
</pre>

==Comparison of Original and Refactored Code==

Major refactoring revolved around moving lines of codes between methods, modifying array and hash declarations, using helper methods for avoiding multiple instance variables and implementing Ruby Conventions. 

*Lines of Code

Original : 248 
Post Refactoring : 224

*Code Complexity (Compared on Code Climate)

Original UsersController<ref name="originaluserscontroller>''Original UsersController'' https://codeclimate.com/github/expertiza/expertiza/UsersController</ref>
 
Refactored UsersController<ref name="refactoreduserscontroller>''Refactored UsersController'' https://codeclimate.com/repos/5450f2eae30ba012a6011c01/UsersController</ref>

==Further Readings==
1.[https://github.com/ameyp1992/expertiza.git Git Repository]

2.[http://wiki.expertiza.ncsu.edu/index.php/Development:Setup:Linux:Debian Expertiza Setup]

3.[https://docs.google.com/document/d/1FZCL9KWSdVNsX9BowuZ3gxbCOJoiWX-GVLctSZei3No/edit?pli=1#heading=h.2y12n9sli9rd Project requirements]

==References==

<references/>

CSC/ECE 517 Fall 2014/oss E1465 oak

2014-10-30T00:53:02Z

Knimgao: /* Project Description */

=Expertiza - Refactoring UsersController=

__TOC__

==Introduction==
Expertiza<ref name="expertiza>''Expertiza'' http://wikis.lib.ncsu.edu/index.php/Expertiza</ref> is a web application available to both students and professors. The Expertiza project is a system to create reusable learning objects through peer review. Expertiza supports team projects and the submission of almost any document type, including URLs and wiki pages. Students can keep a track of their assignments, teammates and can conduct peer reviews on diverse topics and projects. It is an open source project developed on Ruby on Rails platform. More information on Expertiza can be found [https://github.com/expertiza/expertiza here]. The source code can be forked and cloned for making modifications.

As a part of the coursework of Object Oriented Design and Development, we were expected to refactor the funtionality of some modules of Expertiza. This wiki provides an insight into our contributions to the Open Source Software project 'Expertiza' by Refactoring the Users Controller.

==Project Description==
The Users Controller deals with managing activities peripheral to the User registered with Expertiza. Users are mapped to different roles like super-admin, admin, instructor, teaching assistant and student with each role having different access permissions. The Manage Users module can be accessed by roles other than the student. It provides users with the functionality to search other users based on keywords like username, email, etc. New user can be created and existing user information and role can be updated.

Classes : users_controller.rb 
What it does : Manage Users i.e.search and list users, create new user, edit/update existing users, delete users. 
What has to be changed : 
* Modify methods to conform to RESTful style
* Reducing the number of instance variables per action to one
* Code cleanup by using string interpolation instead of concatenation, replacing '==' with eql? and :key =>'value' with key: 'value', modifying declarations of Arrays and Hashes and removing commented out code
* Use of routing helpers instead of hardcoded URLs
* Replace find_by with where to follow Rails 4.0 conventions

==Modification to Existing Code==

===RESTful style implementation===
* Modifications to users_controller.rb : The purpose of the index method in Users Controller is to list all registered users. The list method was called from the index method to list all users. This implementation did not conform to RESTful guidelines. Hence, we refactored the list method in users controller to index. Further, we refactored all the references of list method in UserControllers, Users views, Users tests and routes.rb to the index method.

Before Refactoring :
<pre>
def index
if (current_user_role? == "Student")
redirect_to(:action => AuthHelper::get_home_action(session[:user]), :controller => AuthHelper::get_home_controller(session[:user]))
else
list
render :action => 'list'
end
end

#for displaying the list of users
def list
user = session[:user]
role = Role.find(user.role_id)
all_users = User.order('name').where( ['role_id in (?) or id = ?', role.get_available_roles, user.id])

letter = params[:letter]
session[:letter] = letter
if letter == nil
letter = all_users.first.name[0,1].downcase
end
logger.info "#{letter}"
@letters = Array.new

@per_page = 1

# Check if the "Show" button for pagination is clicked
# If yes, set @per_page to the value of the selection dropdown
# Else, if the request is from one of the letter links on the top
# set @per_page to 1 (25 names per page).
# Else, set @per_page to the :num_users param passed in from
# the will_paginate method from the 'pagination' partial.
if params[:paginate_show]
@per_page = params[:num_users]
elsif params[:from_letter]
@per_page = 1
else
@per_page = params[:num_users]
end

# Get the users list to show on current page
@users = paginate_list(role, user.id, letter)

@letters = ('A'..'Z').to_a
end
</pre>

After Refactoring :

<pre>
#for displaying the list of users
def index
if (current_user_role? == "Student")
redirect_to(:action => AuthHelper::get_home_action(session[:user]), :controller => AuthHelper::get_home_controller(session[:user]))
else
#list method's implementation
end
end
</pre>

===Instance Variable Reductions===
It is a bad practice to have more than one instance variables in a controller's method as it indicates increased coupling. Coupling must be as less as possible and the view should have direct access to as few instance variables as possible. Helper methods should be defined in controllers through which the view can access variables of the controller class. The code has been refactored to make use of helper methods for the instance variables in index action.

Before Refactoring

users_controller.rb
<pre>

def get_role
if @user && @user.role_id
@role = Role.find(@user.role_id)
elsif @user
@role = Role.new(:id => nil, :name => '(none)')
end
end
</pre>

show.html.erb

<pre>
<tr><th>Role:</th>
<td><%= link_to @role.name, :controller => 'roles',
:action => 'show', :id => @role.id %></td>
</tr>
</pre>

After Refactoring

users_controller.rb
<pre>
def get_role
if @user && @user.role_id
role = Role.find(@user.role_id)
elsif @user
role = Role.new(id: nil, name: '(none)')
end
return role
end
</pre>

show.html.erb

<pre>
<tr><th>Role:</th>
<td><%= link_to get_role.name, :controller => 'roles',
:action => 'show', :id => get_role.id %></td>
</tr>

</table>
</pre>

Similar approach for reduction of instance variables has been implemented in other methods like index, show_selection, etc.

===Code Cleanup===
Code cleanup in the controller so that the code conforms closely to Rails conventions and further enhances the readability of the code.
* Replaced String concats with #{} in paginate_list
Before Refactoring :

<pre>
#paginate_list
search_filter = letter + '%'
search_filter = '%' + letter + '%'
</pre>

After Refactoring :

<pre>
#paginate_list
search_filter = "#{letter}%"
search_filter = "%#{letter}%"
</pre>

* Replaced '==' with eql?
Before Refactoring :
<pre>
#index
if (current_user_role? == "Student")
...
letter == nil

#show_selection
@role.parent_id == nil || @role.parent_id < (session[:user]).role_id || @user.id == (session[:user]).id

#show
if (params[:id].nil?) || ((current_user_role? == "Student") && (session[:user].id != params[:id].to_i))

#create
if @user.role.name == "Instructor" or @user.role.name == "Administrator"

#keys
if (params[:id].nil?) || ((current_user_role? == "Student") && (session[:user].id != params[:id].to_i))

#paginate_list
if @search_by == '1'
</pre>

After Refactoring :
<pre>
#index
if (current_user_role.eql? "Student")
...
if letter.eql? nil

#show_selection
if role.parent_id.eql? nil || role.parent_id < (session[:user]).role_id || @user.id.eql?(session[:user]).id

#show
if (params[:id].nil?) || ((current_user_role.eql? "Student") && (session[:user].id != params[:id].to_i))

#create
if @user.role.name.eql? "Instructor" or @user.role.name.eql? "Administrator"

#keys
if (params[:id].nil?) || ((current_user_role.eql? "Student") && (session[:user].id != params[:id].to_i))

#paginate_list
if @search_by.eql? '1' #search by user name
</pre>

* Replaced :key =>'value' with key: 'value'

Before Refactoring :
<pre>
#index
redirect_to(:action => AuthHelper::get_home_action(session[:user]), :controller => AuthHelper::get_home_controller(session[:user]))

#show_selection
render :action => 'show'

#create
AssignmentQuestionnaire.create(:user_id => @user.id)
</pre>

After Refactoring :
<pre>
#index
redirect_to(action: AuthHelper::get_home_action(session[:user]), controller: AuthHelper::get_home_controller(session[:user]))

#show_selection
render action: 'show'

#create
AssignmentQuestionnaire.create(user_id: @user.id)
</pre>

*Modified declarations of Arrays and Hashes
Before Refactoring :
<pre>
#index
@letters = Array.new

#paginate_list
paginate_options = {"1" => 25, "2" => 50, "3" => 100}
</pre>

After Refactoring :
<pre>
#index
@letters =[]

#paginate_list
paginate_options = Hash["1" ,25 , "2", 50, "3", 100]
</pre>

*Removed unused methods like self.participants_in and commented out code.

===Use of Routing Helpers===
Routing helpers are a simpler alternative to the otherwise complex hard coded URLs which reduce the readability of the code.Routing helpers allow us to declare possible common routes for a given controller. Routing helpers have been implemented since they maintain consistency even if changes are made to the routing paths.

Before Refactoring:
 
<pre>
def show_selection
@user = User.find_by_name(params[:user][:name])
if @user != nil
get_role
if @role.parent_id == nil || @role.parent_id < (session[:user]).role_id || @user.id == (session[:user]).id
render :action => 'show'
else
flash[:note] = 'The specified user is not available for editing.'
redirect_to :action => 'list'
end
else
flash[:note] = params[:user][:name]+' does not exist.'
redirect_to :action => 'list'
end
end
</pre>
 
After Refactoring
 
<pre>
def show_selection
@user = User.where(name: params[:user][:name]).take
if @user != nil
role=get_role
if role.parent_id.eql? nil || role.parent_id < (session[:user]).role_id || @user.id.eql?(session[:user]).id
render action: 'show'
else
flash[:note] = 'The specified user is not available for editing.'
redirect_to users_path #Replaced URL with routing helper
end
else
flash[:note] = params[:user][:name]+' does not exist.'
redirect_to users_path #Replaced URL with routing helper
end
end
</pre>
 

===Replace find_by_.. with where in querying===
Rails 4 conventions dictate the use of 'where()' over the use of 'find_by_...' methods while querying ActiveRecords. The code has been refactored to replace the usages of find_by.. with where().

Before Refactoring
<pre>
def show_selection
@user = User.find_by_name(params[:user][:name])
if @user != nil
</pre>

After Refactoring
<pre>
def show_selection
@user = User.where(name: params[:user][:name]).take
if @user != nil
</pre>

==Further Readings==
1.[https://github.com/ameyp1992/expertiza.git Git Repository]

2.[http://wiki.expertiza.ncsu.edu/index.php/Development:Setup:Linux:Debian Expertiza Setup]

3.[https://docs.google.com/document/d/1FZCL9KWSdVNsX9BowuZ3gxbCOJoiWX-GVLctSZei3No/edit?pli=1#heading=h.2y12n9sli9rd Project requirements]

==References==

<references/>

CSC/ECE 517 Fall 2014/oss E1465 oak

2014-10-29T04:57:10Z

Knimgao:

=Expertiza - Refactoring UsersController=

__TOC__

==Introduction==
Expertiza<ref name="expertiza>''Expertiza'' http://wikis.lib.ncsu.edu/index.php/Expertiza</ref> is a web application available to both students and professors. The Expertiza project is a system to create reusable learning objects through peer review. Expertiza supports team projects and the submission of almost any document type, including URLs and wiki pages. Students can keep a track of their assignments, teammates and can conduct peer reviews on diverse topics and projects. It is an open source project developed on Ruby on Rails platform. More information on Expertiza can be found [https://github.com/expertiza/expertiza here]. The source code can be forked and cloned for making modifications.

As a part of the coursework of Object Oriented Design and Development, we were expected to refactor the funtionality of some modules of Expertiza. This wiki provides an insight into our contributions to the Open Source Software project 'Expertiza' by Refactoring the Users Controller.

==Project Description==
The Users Controller deals with managing activities peripheral to the User registered with Expertiza. Users are mapped to different roles like super-admin, admin, instructor, teaching assistant and student with each role having different access permissions. The Manage Users module can be accessed by roles other than the student. It provides users with the functionality to search other users based on keywords like username, email, etc. New user can be created and existing user information and role can be updated.

Classes : users_controller.rb 
What it does : Manage Users i.e.search and list users, create new user, edit/update existing users, delete users. 
What has to be changed : 
* Modify methods to conform to RESTful style
* Reducing the number of instance variables per action to one
* Code cleanup by using string interpolation instead of concatenation, replacing '==' with eql? and :key =>'value' with key: 'value', modifying declarations of Arrays and Hashes and removing commented out code
* Use of routing helpers instead of hardcoded URLs
* Replace find_by with where to follow Rails 4.0 conventions

Original lines of code : 243

Lines after refactoring: 225

==Modification to Existing Code==

===RESTful style implementation===
* Modifications to users_controller.rb : The purpose of the index method in Users Controller is to list all registered users. The list method was called from the index method to list all users. This implementation did not conform to RESTful guidelines. Hence, we refactored the list method in users controller to index. Further, we refactored all the references of list method in UserControllers, Users views, Users tests and routes.rb to the index method.

Before Refactoring :
<pre>
def index
if (current_user_role? == "Student")
redirect_to(:action => AuthHelper::get_home_action(session[:user]), :controller => AuthHelper::get_home_controller(session[:user]))
else
list
render :action => 'list'
end
end

#for displaying the list of users
def list
user = session[:user]
role = Role.find(user.role_id)
all_users = User.order('name').where( ['role_id in (?) or id = ?', role.get_available_roles, user.id])

letter = params[:letter]
session[:letter] = letter
if letter == nil
letter = all_users.first.name[0,1].downcase
end
logger.info "#{letter}"
@letters = Array.new

@per_page = 1

# Check if the "Show" button for pagination is clicked
# If yes, set @per_page to the value of the selection dropdown
# Else, if the request is from one of the letter links on the top
# set @per_page to 1 (25 names per page).
# Else, set @per_page to the :num_users param passed in from
# the will_paginate method from the 'pagination' partial.
if params[:paginate_show]
@per_page = params[:num_users]
elsif params[:from_letter]
@per_page = 1
else
@per_page = params[:num_users]
end

# Get the users list to show on current page
@users = paginate_list(role, user.id, letter)

@letters = ('A'..'Z').to_a
end
</pre>

After Refactoring :

<pre>
#for displaying the list of users
def index
if (current_user_role? == "Student")
redirect_to(:action => AuthHelper::get_home_action(session[:user]), :controller => AuthHelper::get_home_controller(session[:user]))
else
#list method's implementation
end
end
</pre>

===Instance Variable Reductions===
It is a bad practice to have more than one instance variables in a controller's method as it indicates increased coupling. Coupling must be as less as possible and the view should have direct access to as few instance variables as possible. Helper methods should be defined in controllers through which the view can access variables of the controller class. The code has been refactored to make use of helper methods for the instance variables in index action.

Before Refactoring

users_controller.rb
<pre>

def get_role
if @user && @user.role_id
@role = Role.find(@user.role_id)
elsif @user
@role = Role.new(:id => nil, :name => '(none)')
end
end
</pre>

show.html.erb

<pre>
<tr><th>Role:</th>
<td><%= link_to @role.name, :controller => 'roles',
:action => 'show', :id => @role.id %></td>
</tr>
</pre>

After Refactoring

users_controller.rb
<pre>
def get_role
if @user && @user.role_id
role = Role.find(@user.role_id)
elsif @user
role = Role.new(id: nil, name: '(none)')
end
return role
end
</pre>

show.html.erb

<pre>
<tr><th>Role:</th>
<td><%= link_to get_role.name, :controller => 'roles',
:action => 'show', :id => get_role.id %></td>
</tr>

</table>
</pre>

Similar approach for reduction of instance variables has been implemented in other methods like index, show_selection, etc.

===Code Cleanup===
Code cleanup in the controller so that the code conforms closely to Rails conventions and further enhances the readability of the code.
* Replaced String concats with #{} in paginate_list
Before Refactoring :

<pre>
#paginate_list
search_filter = letter + '%'
search_filter = '%' + letter + '%'
</pre>

After Refactoring :

<pre>
#paginate_list
search_filter = "#{letter}%"
search_filter = "%#{letter}%"
</pre>

* Replaced '==' with eql?
Before Refactoring :
<pre>
#index
if (current_user_role? == "Student")
...
letter == nil

#show_selection
@role.parent_id == nil || @role.parent_id < (session[:user]).role_id || @user.id == (session[:user]).id

#show
if (params[:id].nil?) || ((current_user_role? == "Student") && (session[:user].id != params[:id].to_i))

#create
if @user.role.name == "Instructor" or @user.role.name == "Administrator"

#keys
if (params[:id].nil?) || ((current_user_role? == "Student") && (session[:user].id != params[:id].to_i))

#paginate_list
if @search_by == '1'
</pre>

After Refactoring :
<pre>
#index
if (current_user_role.eql? "Student")
...
if letter.eql? nil

#show_selection
if role.parent_id.eql? nil || role.parent_id < (session[:user]).role_id || @user.id.eql?(session[:user]).id

#show
if (params[:id].nil?) || ((current_user_role.eql? "Student") && (session[:user].id != params[:id].to_i))

#create
if @user.role.name.eql? "Instructor" or @user.role.name.eql? "Administrator"

#keys
if (params[:id].nil?) || ((current_user_role.eql? "Student") && (session[:user].id != params[:id].to_i))

#paginate_list
if @search_by.eql? '1' #search by user name
</pre>

* Replaced :key =>'value' with key: 'value'

Before Refactoring :
<pre>
#index
redirect_to(:action => AuthHelper::get_home_action(session[:user]), :controller => AuthHelper::get_home_controller(session[:user]))

#show_selection
render :action => 'show'

#create
AssignmentQuestionnaire.create(:user_id => @user.id)
</pre>

After Refactoring :
<pre>
#index
redirect_to(action: AuthHelper::get_home_action(session[:user]), controller: AuthHelper::get_home_controller(session[:user]))

#show_selection
render action: 'show'

#create
AssignmentQuestionnaire.create(user_id: @user.id)
</pre>

*Modified declarations of Arrays and Hashes
Before Refactoring :
<pre>
#index
@letters = Array.new

#paginate_list
paginate_options = {"1" => 25, "2" => 50, "3" => 100}
</pre>

After Refactoring :
<pre>
#index
@letters =[]

#paginate_list
paginate_options = Hash["1" ,25 , "2", 50, "3", 100]
</pre>

*Removed unused methods like self.participants_in and commented out code.

===Use of Routing Helpers===
Routing helpers are a simpler alternative to the otherwise complex hard coded URLs which reduce the readability of the code.Routing helpers allow us to declare possible common routes for a given controller. Routing helpers have been implemented since they maintain consistency even if changes are made to the routing paths.

Before Refactoring:
 
<pre>
def show_selection
@user = User.find_by_name(params[:user][:name])
if @user != nil
get_role
if @role.parent_id == nil || @role.parent_id < (session[:user]).role_id || @user.id == (session[:user]).id
render :action => 'show'
else
flash[:note] = 'The specified user is not available for editing.'
redirect_to :action => 'list'
end
else
flash[:note] = params[:user][:name]+' does not exist.'
redirect_to :action => 'list'
end
end
</pre>
 
After Refactoring
 
<pre>
def show_selection
@user = User.where(name: params[:user][:name]).take
if @user != nil
role=get_role
if role.parent_id.eql? nil || role.parent_id < (session[:user]).role_id || @user.id.eql?(session[:user]).id
render action: 'show'
else
flash[:note] = 'The specified user is not available for editing.'
redirect_to users_path #Replaced URL with routing helper
end
else
flash[:note] = params[:user][:name]+' does not exist.'
redirect_to users_path #Replaced URL with routing helper
end
end
</pre>
 

===Replace find_by_.. with where in querying===
Rails 4 conventions dictate the use of 'where()' over the use of 'find_by_...' methods while querying ActiveRecords. The code has been refactored to replace the usages of find_by.. with where().

Before Refactoring
<pre>
def show_selection
@user = User.find_by_name(params[:user][:name])
if @user != nil
</pre>

After Refactoring
<pre>
def show_selection
@user = User.where(name: params[:user][:name]).take
if @user != nil
</pre>

==Further Readings==
1.[https://github.com/ameyp1992/expertiza.git Git Repository]

2.[http://wiki.expertiza.ncsu.edu/index.php/Development:Setup:Linux:Debian Expertiza Setup]

3.[https://docs.google.com/document/d/1FZCL9KWSdVNsX9BowuZ3gxbCOJoiWX-GVLctSZei3No/edit?pli=1#heading=h.2y12n9sli9rd Project requirements]

==References==

<references/>

CSC/ECE 517 Fall 2014/oss E1465 oak

2014-10-29T04:56:41Z

Knimgao: /* References */

=Expertiza - Refactoring UsersController=

__TOC__

==Introduction==
Expertiza<ref name="expertiza>''Expertiza'' http://wikis.lib.ncsu.edu/index.php/Expertiza</ref> is a web application available to both students and professors. The Expertiza project is a system to create reusable learning objects through peer review. Expertiza supports team projects and the submission of almost any document type, including URLs and wiki pages. Students can keep a track of their assignments, teammates and can conduct peer reviews on diverse topics and projects. It is an open source project developed on Ruby on Rails platform. More information on Expertiza can be found [https://github.com/expertiza/expertiza here]. The source code can be forked and cloned for making modifications.

As a part of the coursework of Object Oriented Design and Development, we were expected to refactor the funtionality of some modules of Expertiza. This wiki provides an insight into our contributions to the Open Source Software project 'Expertiza' by Refactoring the Users Controller.

==Project Description==
The Users Controller deals with managing activities peripheral to the User registered with Expertiza. Users are mapped to different roles like super-admin, admin, instructor, teaching assistant and student with each role having different access permissions. The Manage Users module can be accessed by roles other than the student. It provides users with the functionality to search other users based on keywords like username, email, etc. New user can be created and existing user information and role can be updated.

Classes : users_controller.rb 
What it does : Manage Users i.e.search and list users, create new user, edit/update existing users, delete users. 
What has to be changed : 
* Modify methods to conform to RESTful style
* Reducing the number of instance variables per action to one
* Code cleanup by using string interpolation instead of concatenation, replacing '==' with eql? and :key =>'value' with key: 'value', modifying declarations of Arrays and Hashes and removing commented out code
* Use of routing helpers instead of hardcoded URLs
* Replace find_by with where to follow Rails 4.0 conventions

Original lines of code : 243

Lines after refactoring: 225

==Modification to Existing Code==

===RESTful style implementation===
* Modifications to users_controller.rb : The purpose of the index method in Users Controller is to list all registered users. The list method was called from the index method to list all users. This implementation did not conform to RESTful guidelines. Hence, we refactored the list method in users controller to index. Further, we refactored all the references of list method in UserControllers, Users views, Users tests and routes.rb to the index method.

Before Refactoring :
<pre>
def index
if (current_user_role? == "Student")
redirect_to(:action => AuthHelper::get_home_action(session[:user]), :controller => AuthHelper::get_home_controller(session[:user]))
else
list
render :action => 'list'
end
end

#for displaying the list of users
def list
user = session[:user]
role = Role.find(user.role_id)
all_users = User.order('name').where( ['role_id in (?) or id = ?', role.get_available_roles, user.id])

letter = params[:letter]
session[:letter] = letter
if letter == nil
letter = all_users.first.name[0,1].downcase
end
logger.info "#{letter}"
@letters = Array.new

@per_page = 1

# Check if the "Show" button for pagination is clicked
# If yes, set @per_page to the value of the selection dropdown
# Else, if the request is from one of the letter links on the top
# set @per_page to 1 (25 names per page).
# Else, set @per_page to the :num_users param passed in from
# the will_paginate method from the 'pagination' partial.
if params[:paginate_show]
@per_page = params[:num_users]
elsif params[:from_letter]
@per_page = 1
else
@per_page = params[:num_users]
end

# Get the users list to show on current page
@users = paginate_list(role, user.id, letter)

@letters = ('A'..'Z').to_a
end
</pre>

After Refactoring :

<pre>
#for displaying the list of users
def index
if (current_user_role? == "Student")
redirect_to(:action => AuthHelper::get_home_action(session[:user]), :controller => AuthHelper::get_home_controller(session[:user]))
else
#list method's implementation
end
end
</pre>

===Instance Variable Reductions===
It is a bad practice to have more than one instance variables in a controller's method as it indicates increased coupling. Coupling must be as less as possible and the view should have direct access to as few instance variables as possible. Helper methods should be defined in controllers through which the view can access variables of the controller class. The code has been refactored to make use of helper methods for the instance variables in index action.

Before Refactoring

users_controller.rb
<pre>

def get_role
if @user && @user.role_id
@role = Role.find(@user.role_id)
elsif @user
@role = Role.new(:id => nil, :name => '(none)')
end
end
</pre>

show.html.erb

<pre>
<tr><th>Role:</th>
<td><%= link_to @role.name, :controller => 'roles',
:action => 'show', :id => @role.id %></td>
</tr>
</pre>

After Refactoring

users_controller.rb
<pre>
def get_role
if @user && @user.role_id
role = Role.find(@user.role_id)
elsif @user
role = Role.new(id: nil, name: '(none)')
end
return role
end
</pre>

show.html.erb

<pre>
<tr><th>Role:</th>
<td><%= link_to get_role.name, :controller => 'roles',
:action => 'show', :id => get_role.id %></td>
</tr>

</table>
</pre>

Similar approach for reduction of instance variables has been implemented in other methods like index, show_selection, etc.

===Code Cleanup===
Code cleanup in the controller so that the code conforms closely to Rails conventions and further enhances the readability of the code.
* Replaced String concats with #{} in paginate_list
Before Refactoring :

<pre>
#paginate_list
search_filter = letter + '%'
search_filter = '%' + letter + '%'
</pre>

After Refactoring :

<pre>
#paginate_list
search_filter = "#{letter}%"
search_filter = "%#{letter}%"
</pre>

* Replaced '==' with eql?
Before Refactoring :
<pre>
#index
if (current_user_role? == "Student")
...
letter == nil

#show_selection
@role.parent_id == nil || @role.parent_id < (session[:user]).role_id || @user.id == (session[:user]).id

#show
if (params[:id].nil?) || ((current_user_role? == "Student") && (session[:user].id != params[:id].to_i))

#create
if @user.role.name == "Instructor" or @user.role.name == "Administrator"

#keys
if (params[:id].nil?) || ((current_user_role? == "Student") && (session[:user].id != params[:id].to_i))

#paginate_list
if @search_by == '1'
</pre>

After Refactoring :
<pre>
#index
if (current_user_role.eql? "Student")
...
if letter.eql? nil

#show_selection
if role.parent_id.eql? nil || role.parent_id < (session[:user]).role_id || @user.id.eql?(session[:user]).id

#show
if (params[:id].nil?) || ((current_user_role.eql? "Student") && (session[:user].id != params[:id].to_i))

#create
if @user.role.name.eql? "Instructor" or @user.role.name.eql? "Administrator"

#keys
if (params[:id].nil?) || ((current_user_role.eql? "Student") && (session[:user].id != params[:id].to_i))

#paginate_list
if @search_by.eql? '1' #search by user name
</pre>

* Replaced :key =>'value' with key: 'value'

Before Refactoring :
<pre>
#index
redirect_to(:action => AuthHelper::get_home_action(session[:user]), :controller => AuthHelper::get_home_controller(session[:user]))

#show_selection
render :action => 'show'

#create
AssignmentQuestionnaire.create(:user_id => @user.id)
</pre>

After Refactoring :
<pre>
#index
redirect_to(action: AuthHelper::get_home_action(session[:user]), controller: AuthHelper::get_home_controller(session[:user]))

#show_selection
render action: 'show'

#create
AssignmentQuestionnaire.create(user_id: @user.id)
</pre>

*Modified declarations of Arrays and Hashes
Before Refactoring :
<pre>
#index
@letters = Array.new

#paginate_list
paginate_options = {"1" => 25, "2" => 50, "3" => 100}
</pre>

After Refactoring :
<pre>
#index
@letters =[]

#paginate_list
paginate_options = Hash["1" ,25 , "2", 50, "3", 100]
</pre>

*Removed unused methods like self.participants_in and commented out code.

===Use of Routing Helpers===
Routing helpers are a simpler alternative to the otherwise complex hard coded URLs which reduce the readability of the code.Routing helpers allow us to declare possible common routes for a given controller. Routing helpers have been implemented since they maintain consistency even if changes are made to the routing paths.

Before Refactoring:
 
<pre>
def show_selection
@user = User.find_by_name(params[:user][:name])
if @user != nil
get_role
if @role.parent_id == nil || @role.parent_id < (session[:user]).role_id || @user.id == (session[:user]).id
render :action => 'show'
else
flash[:note] = 'The specified user is not available for editing.'
redirect_to :action => 'list'
end
else
flash[:note] = params[:user][:name]+' does not exist.'
redirect_to :action => 'list'
end
end
</pre>
 
After Refactoring
 
<pre>
def show_selection
@user = User.where(name: params[:user][:name]).take
if @user != nil
role=get_role
if role.parent_id.eql? nil || role.parent_id < (session[:user]).role_id || @user.id.eql?(session[:user]).id
render action: 'show'
else
flash[:note] = 'The specified user is not available for editing.'
redirect_to users_path #Replaced URL with routing helper
end
else
flash[:note] = params[:user][:name]+' does not exist.'
redirect_to users_path #Replaced URL with routing helper
end
end
</pre>
 

===Replace find_by_.. with where in querying===
Rails 4 conventions dictate the use of 'where()' over the use of 'find_by_...' methods while querying ActiveRecords. The code has been refactored to replace the usages of find_by.. with where().

Before Refactoring
<pre>
def show_selection
@user = User.find_by_name(params[:user][:name])
if @user != nil
</pre>

After Refactoring
<pre>
def show_selection
@user = User.where(name: params[:user][:name]).take
if @user != nil
</pre>

==References==

<references/>

CSC/ECE 517 Fall 2014/oss E1465 oak

2014-10-29T04:55:27Z

Knimgao: /* References */

=Expertiza - Refactoring UsersController=

__TOC__

==Introduction==
Expertiza<ref name="expertiza>''Expertiza'' http://wikis.lib.ncsu.edu/index.php/Expertiza</ref> is a web application available to both students and professors. The Expertiza project is a system to create reusable learning objects through peer review. Expertiza supports team projects and the submission of almost any document type, including URLs and wiki pages. Students can keep a track of their assignments, teammates and can conduct peer reviews on diverse topics and projects. It is an open source project developed on Ruby on Rails platform. More information on Expertiza can be found [https://github.com/expertiza/expertiza here]. The source code can be forked and cloned for making modifications.

As a part of the coursework of Object Oriented Design and Development, we were expected to refactor the funtionality of some modules of Expertiza. This wiki provides an insight into our contributions to the Open Source Software project 'Expertiza' by Refactoring the Users Controller.

==Project Description==
The Users Controller deals with managing activities peripheral to the User registered with Expertiza. Users are mapped to different roles like super-admin, admin, instructor, teaching assistant and student with each role having different access permissions. The Manage Users module can be accessed by roles other than the student. It provides users with the functionality to search other users based on keywords like username, email, etc. New user can be created and existing user information and role can be updated.

Classes : users_controller.rb 
What it does : Manage Users i.e.search and list users, create new user, edit/update existing users, delete users. 
What has to be changed : 
* Modify methods to conform to RESTful style
* Reducing the number of instance variables per action to one
* Code cleanup by using string interpolation instead of concatenation, replacing '==' with eql? and :key =>'value' with key: 'value', modifying declarations of Arrays and Hashes and removing commented out code
* Use of routing helpers instead of hardcoded URLs
* Replace find_by with where to follow Rails 4.0 conventions

Original lines of code : 243

Lines after refactoring: 225

==Modification to Existing Code==

===RESTful style implementation===
* Modifications to users_controller.rb : The purpose of the index method in Users Controller is to list all registered users. The list method was called from the index method to list all users. This implementation did not conform to RESTful guidelines. Hence, we refactored the list method in users controller to index. Further, we refactored all the references of list method in UserControllers, Users views, Users tests and routes.rb to the index method.

Before Refactoring :
<pre>
def index
if (current_user_role? == "Student")
redirect_to(:action => AuthHelper::get_home_action(session[:user]), :controller => AuthHelper::get_home_controller(session[:user]))
else
list
render :action => 'list'
end
end

#for displaying the list of users
def list
user = session[:user]
role = Role.find(user.role_id)
all_users = User.order('name').where( ['role_id in (?) or id = ?', role.get_available_roles, user.id])

letter = params[:letter]
session[:letter] = letter
if letter == nil
letter = all_users.first.name[0,1].downcase
end
logger.info "#{letter}"
@letters = Array.new

@per_page = 1

# Check if the "Show" button for pagination is clicked
# If yes, set @per_page to the value of the selection dropdown
# Else, if the request is from one of the letter links on the top
# set @per_page to 1 (25 names per page).
# Else, set @per_page to the :num_users param passed in from
# the will_paginate method from the 'pagination' partial.
if params[:paginate_show]
@per_page = params[:num_users]
elsif params[:from_letter]
@per_page = 1
else
@per_page = params[:num_users]
end

# Get the users list to show on current page
@users = paginate_list(role, user.id, letter)

@letters = ('A'..'Z').to_a
end
</pre>

After Refactoring :

<pre>
#for displaying the list of users
def index
if (current_user_role? == "Student")
redirect_to(:action => AuthHelper::get_home_action(session[:user]), :controller => AuthHelper::get_home_controller(session[:user]))
else
#list method's implementation
end
end
</pre>

===Instance Variable Reductions===
It is a bad practice to have more than one instance variables in a controller's method as it indicates increased coupling. Coupling must be as less as possible and the view should have direct access to as few instance variables as possible. Helper methods should be defined in controllers through which the view can access variables of the controller class. The code has been refactored to make use of helper methods for the instance variables in index action.

Before Refactoring

users_controller.rb
<pre>

def get_role
if @user && @user.role_id
@role = Role.find(@user.role_id)
elsif @user
@role = Role.new(:id => nil, :name => '(none)')
end
end
</pre>

show.html.erb

<pre>
<tr><th>Role:</th>
<td><%= link_to @role.name, :controller => 'roles',
:action => 'show', :id => @role.id %></td>
</tr>
</pre>

After Refactoring

users_controller.rb
<pre>
def get_role
if @user && @user.role_id
role = Role.find(@user.role_id)
elsif @user
role = Role.new(id: nil, name: '(none)')
end
return role
end
</pre>

show.html.erb

<pre>
<tr><th>Role:</th>
<td><%= link_to get_role.name, :controller => 'roles',
:action => 'show', :id => get_role.id %></td>
</tr>

</table>
</pre>

Similar approach for reduction of instance variables has been implemented in other methods like index, show_selection, etc.

===Code Cleanup===
Code cleanup in the controller so that the code conforms closely to Rails conventions and further enhances the readability of the code.
* Replaced String concats with #{} in paginate_list
Before Refactoring :

<pre>
#paginate_list
search_filter = letter + '%'
search_filter = '%' + letter + '%'
</pre>

After Refactoring :

<pre>
#paginate_list
search_filter = "#{letter}%"
search_filter = "%#{letter}%"
</pre>

* Replaced '==' with eql?
Before Refactoring :
<pre>
#index
if (current_user_role? == "Student")
...
letter == nil

#show_selection
@role.parent_id == nil || @role.parent_id < (session[:user]).role_id || @user.id == (session[:user]).id

#show
if (params[:id].nil?) || ((current_user_role? == "Student") && (session[:user].id != params[:id].to_i))

#create
if @user.role.name == "Instructor" or @user.role.name == "Administrator"

#keys
if (params[:id].nil?) || ((current_user_role? == "Student") && (session[:user].id != params[:id].to_i))

#paginate_list
if @search_by == '1'
</pre>

After Refactoring :
<pre>
#index
if (current_user_role.eql? "Student")
...
if letter.eql? nil

#show_selection
if role.parent_id.eql? nil || role.parent_id < (session[:user]).role_id || @user.id.eql?(session[:user]).id

#show
if (params[:id].nil?) || ((current_user_role.eql? "Student") && (session[:user].id != params[:id].to_i))

#create
if @user.role.name.eql? "Instructor" or @user.role.name.eql? "Administrator"

#keys
if (params[:id].nil?) || ((current_user_role.eql? "Student") && (session[:user].id != params[:id].to_i))

#paginate_list
if @search_by.eql? '1' #search by user name
</pre>

* Replaced :key =>'value' with key: 'value'

Before Refactoring :
<pre>
#index
redirect_to(:action => AuthHelper::get_home_action(session[:user]), :controller => AuthHelper::get_home_controller(session[:user]))

#show_selection
render :action => 'show'

#create
AssignmentQuestionnaire.create(:user_id => @user.id)
</pre>

After Refactoring :
<pre>
#index
redirect_to(action: AuthHelper::get_home_action(session[:user]), controller: AuthHelper::get_home_controller(session[:user]))

#show_selection
render action: 'show'

#create
AssignmentQuestionnaire.create(user_id: @user.id)
</pre>

*Modified declarations of Arrays and Hashes
Before Refactoring :
<pre>
#index
@letters = Array.new

#paginate_list
paginate_options = {"1" => 25, "2" => 50, "3" => 100}
</pre>

After Refactoring :
<pre>
#index
@letters =[]

#paginate_list
paginate_options = Hash["1" ,25 , "2", 50, "3", 100]
</pre>

*Removed unused methods like self.participants_in and commented out code.

===Use of Routing Helpers===
Routing helpers are a simpler alternative to the otherwise complex hard coded URLs which reduce the readability of the code.Routing helpers allow us to declare possible common routes for a given controller. Routing helpers have been implemented since they maintain consistency even if changes are made to the routing paths.

Before Refactoring:
 
<pre>
def show_selection
@user = User.find_by_name(params[:user][:name])
if @user != nil
get_role
if @role.parent_id == nil || @role.parent_id < (session[:user]).role_id || @user.id == (session[:user]).id
render :action => 'show'
else
flash[:note] = 'The specified user is not available for editing.'
redirect_to :action => 'list'
end
else
flash[:note] = params[:user][:name]+' does not exist.'
redirect_to :action => 'list'
end
end
</pre>
 
After Refactoring
 
<pre>
def show_selection
@user = User.where(name: params[:user][:name]).take
if @user != nil
role=get_role
if role.parent_id.eql? nil || role.parent_id < (session[:user]).role_id || @user.id.eql?(session[:user]).id
render action: 'show'
else
flash[:note] = 'The specified user is not available for editing.'
redirect_to users_path #Replaced URL with routing helper
end
else
flash[:note] = params[:user][:name]+' does not exist.'
redirect_to users_path #Replaced URL with routing helper
end
end
</pre>
 

===Replace find_by_.. with where in querying===
Rails 4 conventions dictate the use of 'where()' over the use of 'find_by_...' methods while querying ActiveRecords. The code has been refactored to replace the usages of find_by.. with where().

Before Refactoring
<pre>
def show_selection
@user = User.find_by_name(params[:user][:name])
if @user != nil
</pre>

After Refactoring
<pre>
def show_selection
@user = User.where(name: params[:user][:name]).take
if @user != nil
</pre>

==References==
1.[https://github.com/ameyp1992/expertiza.git Git Repository]

2.[http://wiki.expertiza.ncsu.edu/index.php/Development:Setup:Linux:Debian Expertiza Setup]

3.[https://docs.google.com/document/d/1FZCL9KWSdVNsX9BowuZ3gxbCOJoiWX-GVLctSZei3No/edit?pli=1#heading=h.2y12n9sli9rd Project requirements]
<references/>

CSC/ECE 517 Fall 2014/oss E1465 oak

2014-10-29T04:54:44Z

Knimgao: /* References */

=Expertiza - Refactoring UsersController=

__TOC__

==Introduction==
Expertiza<ref name="expertiza>''Expertiza'' http://wikis.lib.ncsu.edu/index.php/Expertiza</ref> is a web application available to both students and professors. The Expertiza project is a system to create reusable learning objects through peer review. Expertiza supports team projects and the submission of almost any document type, including URLs and wiki pages. Students can keep a track of their assignments, teammates and can conduct peer reviews on diverse topics and projects. It is an open source project developed on Ruby on Rails platform. More information on Expertiza can be found [https://github.com/expertiza/expertiza here]. The source code can be forked and cloned for making modifications.

As a part of the coursework of Object Oriented Design and Development, we were expected to refactor the funtionality of some modules of Expertiza. This wiki provides an insight into our contributions to the Open Source Software project 'Expertiza' by Refactoring the Users Controller.

==Project Description==
The Users Controller deals with managing activities peripheral to the User registered with Expertiza. Users are mapped to different roles like super-admin, admin, instructor, teaching assistant and student with each role having different access permissions. The Manage Users module can be accessed by roles other than the student. It provides users with the functionality to search other users based on keywords like username, email, etc. New user can be created and existing user information and role can be updated.

Classes : users_controller.rb 
What it does : Manage Users i.e.search and list users, create new user, edit/update existing users, delete users. 
What has to be changed : 
* Modify methods to conform to RESTful style
* Reducing the number of instance variables per action to one
* Code cleanup by using string interpolation instead of concatenation, replacing '==' with eql? and :key =>'value' with key: 'value', modifying declarations of Arrays and Hashes and removing commented out code
* Use of routing helpers instead of hardcoded URLs
* Replace find_by with where to follow Rails 4.0 conventions

Original lines of code : 243

Lines after refactoring: 225

==Modification to Existing Code==

===RESTful style implementation===
* Modifications to users_controller.rb : The purpose of the index method in Users Controller is to list all registered users. The list method was called from the index method to list all users. This implementation did not conform to RESTful guidelines. Hence, we refactored the list method in users controller to index. Further, we refactored all the references of list method in UserControllers, Users views, Users tests and routes.rb to the index method.

Before Refactoring :
<pre>
def index
if (current_user_role? == "Student")
redirect_to(:action => AuthHelper::get_home_action(session[:user]), :controller => AuthHelper::get_home_controller(session[:user]))
else
list
render :action => 'list'
end
end

#for displaying the list of users
def list
user = session[:user]
role = Role.find(user.role_id)
all_users = User.order('name').where( ['role_id in (?) or id = ?', role.get_available_roles, user.id])

letter = params[:letter]
session[:letter] = letter
if letter == nil
letter = all_users.first.name[0,1].downcase
end
logger.info "#{letter}"
@letters = Array.new

@per_page = 1

# Check if the "Show" button for pagination is clicked
# If yes, set @per_page to the value of the selection dropdown
# Else, if the request is from one of the letter links on the top
# set @per_page to 1 (25 names per page).
# Else, set @per_page to the :num_users param passed in from
# the will_paginate method from the 'pagination' partial.
if params[:paginate_show]
@per_page = params[:num_users]
elsif params[:from_letter]
@per_page = 1
else
@per_page = params[:num_users]
end

# Get the users list to show on current page
@users = paginate_list(role, user.id, letter)

@letters = ('A'..'Z').to_a
end
</pre>

After Refactoring :

<pre>
#for displaying the list of users
def index
if (current_user_role? == "Student")
redirect_to(:action => AuthHelper::get_home_action(session[:user]), :controller => AuthHelper::get_home_controller(session[:user]))
else
#list method's implementation
end
end
</pre>

===Instance Variable Reductions===
It is a bad practice to have more than one instance variables in a controller's method as it indicates increased coupling. Coupling must be as less as possible and the view should have direct access to as few instance variables as possible. Helper methods should be defined in controllers through which the view can access variables of the controller class. The code has been refactored to make use of helper methods for the instance variables in index action.

Before Refactoring

users_controller.rb
<pre>

def get_role
if @user && @user.role_id
@role = Role.find(@user.role_id)
elsif @user
@role = Role.new(:id => nil, :name => '(none)')
end
end
</pre>

show.html.erb

<pre>
<tr><th>Role:</th>
<td><%= link_to @role.name, :controller => 'roles',
:action => 'show', :id => @role.id %></td>
</tr>
</pre>

After Refactoring

users_controller.rb
<pre>
def get_role
if @user && @user.role_id
role = Role.find(@user.role_id)
elsif @user
role = Role.new(id: nil, name: '(none)')
end
return role
end
</pre>

show.html.erb

<pre>
<tr><th>Role:</th>
<td><%= link_to get_role.name, :controller => 'roles',
:action => 'show', :id => get_role.id %></td>
</tr>

</table>
</pre>

Similar approach for reduction of instance variables has been implemented in other methods like index, show_selection, etc.

===Code Cleanup===
Code cleanup in the controller so that the code conforms closely to Rails conventions and further enhances the readability of the code.
* Replaced String concats with #{} in paginate_list
Before Refactoring :

<pre>
#paginate_list
search_filter = letter + '%'
search_filter = '%' + letter + '%'
</pre>

After Refactoring :

<pre>
#paginate_list
search_filter = "#{letter}%"
search_filter = "%#{letter}%"
</pre>

* Replaced '==' with eql?
Before Refactoring :
<pre>
#index
if (current_user_role? == "Student")
...
letter == nil

#show_selection
@role.parent_id == nil || @role.parent_id < (session[:user]).role_id || @user.id == (session[:user]).id

#show
if (params[:id].nil?) || ((current_user_role? == "Student") && (session[:user].id != params[:id].to_i))

#create
if @user.role.name == "Instructor" or @user.role.name == "Administrator"

#keys
if (params[:id].nil?) || ((current_user_role? == "Student") && (session[:user].id != params[:id].to_i))

#paginate_list
if @search_by == '1'
</pre>

After Refactoring :
<pre>
#index
if (current_user_role.eql? "Student")
...
if letter.eql? nil

#show_selection
if role.parent_id.eql? nil || role.parent_id < (session[:user]).role_id || @user.id.eql?(session[:user]).id

#show
if (params[:id].nil?) || ((current_user_role.eql? "Student") && (session[:user].id != params[:id].to_i))

#create
if @user.role.name.eql? "Instructor" or @user.role.name.eql? "Administrator"

#keys
if (params[:id].nil?) || ((current_user_role.eql? "Student") && (session[:user].id != params[:id].to_i))

#paginate_list
if @search_by.eql? '1' #search by user name
</pre>

* Replaced :key =>'value' with key: 'value'

Before Refactoring :
<pre>
#index
redirect_to(:action => AuthHelper::get_home_action(session[:user]), :controller => AuthHelper::get_home_controller(session[:user]))

#show_selection
render :action => 'show'

#create
AssignmentQuestionnaire.create(:user_id => @user.id)
</pre>

After Refactoring :
<pre>
#index
redirect_to(action: AuthHelper::get_home_action(session[:user]), controller: AuthHelper::get_home_controller(session[:user]))

#show_selection
render action: 'show'

#create
AssignmentQuestionnaire.create(user_id: @user.id)
</pre>

*Modified declarations of Arrays and Hashes
Before Refactoring :
<pre>
#index
@letters = Array.new

#paginate_list
paginate_options = {"1" => 25, "2" => 50, "3" => 100}
</pre>

After Refactoring :
<pre>
#index
@letters =[]

#paginate_list
paginate_options = Hash["1" ,25 , "2", 50, "3", 100]
</pre>

*Removed unused methods like self.participants_in and commented out code.

===Use of Routing Helpers===
Routing helpers are a simpler alternative to the otherwise complex hard coded URLs which reduce the readability of the code.Routing helpers allow us to declare possible common routes for a given controller. Routing helpers have been implemented since they maintain consistency even if changes are made to the routing paths.

Before Refactoring:
 
<pre>
def show_selection
@user = User.find_by_name(params[:user][:name])
if @user != nil
get_role
if @role.parent_id == nil || @role.parent_id < (session[:user]).role_id || @user.id == (session[:user]).id
render :action => 'show'
else
flash[:note] = 'The specified user is not available for editing.'
redirect_to :action => 'list'
end
else
flash[:note] = params[:user][:name]+' does not exist.'
redirect_to :action => 'list'
end
end
</pre>
 
After Refactoring
 
<pre>
def show_selection
@user = User.where(name: params[:user][:name]).take
if @user != nil
role=get_role
if role.parent_id.eql? nil || role.parent_id < (session[:user]).role_id || @user.id.eql?(session[:user]).id
render action: 'show'
else
flash[:note] = 'The specified user is not available for editing.'
redirect_to users_path #Replaced URL with routing helper
end
else
flash[:note] = params[:user][:name]+' does not exist.'
redirect_to users_path #Replaced URL with routing helper
end
end
</pre>
 

===Replace find_by_.. with where in querying===
Rails 4 conventions dictate the use of 'where()' over the use of 'find_by_...' methods while querying ActiveRecords. The code has been refactored to replace the usages of find_by.. with where().

Before Refactoring
<pre>
def show_selection
@user = User.find_by_name(params[:user][:name])
if @user != nil
</pre>

After Refactoring
<pre>
def show_selection
@user = User.where(name: params[:user][:name]).take
if @user != nil
</pre>

==References==
#[https://github.com/ameyp1992/expertiza.git Git Repository]

#[http://wiki.expertiza.ncsu.edu/index.php/Development:Setup:Linux:Debian Expertiza Setup]

#[https://docs.google.com/document/d/1FZCL9KWSdVNsX9BowuZ3gxbCOJoiWX-GVLctSZei3No/edit?pli=1#heading=h.2y12n9sli9rd Project requirements]
<references/>

CSC/ECE 517 Fall 2014/oss E1465 oak

2014-10-29T04:53:07Z

Knimgao:

=Expertiza - Refactoring UsersController=

__TOC__

==Introduction==
Expertiza<ref name="expertiza>''Expertiza'' http://wikis.lib.ncsu.edu/index.php/Expertiza</ref> is a web application available to both students and professors. The Expertiza project is a system to create reusable learning objects through peer review. Expertiza supports team projects and the submission of almost any document type, including URLs and wiki pages. Students can keep a track of their assignments, teammates and can conduct peer reviews on diverse topics and projects. It is an open source project developed on Ruby on Rails platform. More information on Expertiza can be found [https://github.com/expertiza/expertiza here]. The source code can be forked and cloned for making modifications.

As a part of the coursework of Object Oriented Design and Development, we were expected to refactor the funtionality of some modules of Expertiza. This wiki provides an insight into our contributions to the Open Source Software project 'Expertiza' by Refactoring the Users Controller.

==Project Description==
The Users Controller deals with managing activities peripheral to the User registered with Expertiza. Users are mapped to different roles like super-admin, admin, instructor, teaching assistant and student with each role having different access permissions. The Manage Users module can be accessed by roles other than the student. It provides users with the functionality to search other users based on keywords like username, email, etc. New user can be created and existing user information and role can be updated.

Classes : users_controller.rb 
What it does : Manage Users i.e.search and list users, create new user, edit/update existing users, delete users. 
What has to be changed : 
* Modify methods to conform to RESTful style
* Reducing the number of instance variables per action to one
* Code cleanup by using string interpolation instead of concatenation, replacing '==' with eql? and :key =>'value' with key: 'value', modifying declarations of Arrays and Hashes and removing commented out code
* Use of routing helpers instead of hardcoded URLs
* Replace find_by with where to follow Rails 4.0 conventions

Original lines of code : 243

Lines after refactoring: 225

==Modification to Existing Code==

===RESTful style implementation===
* Modifications to users_controller.rb : The purpose of the index method in Users Controller is to list all registered users. The list method was called from the index method to list all users. This implementation did not conform to RESTful guidelines. Hence, we refactored the list method in users controller to index. Further, we refactored all the references of list method in UserControllers, Users views, Users tests and routes.rb to the index method.

Before Refactoring :
<pre>
def index
if (current_user_role? == "Student")
redirect_to(:action => AuthHelper::get_home_action(session[:user]), :controller => AuthHelper::get_home_controller(session[:user]))
else
list
render :action => 'list'
end
end

#for displaying the list of users
def list
user = session[:user]
role = Role.find(user.role_id)
all_users = User.order('name').where( ['role_id in (?) or id = ?', role.get_available_roles, user.id])

letter = params[:letter]
session[:letter] = letter
if letter == nil
letter = all_users.first.name[0,1].downcase
end
logger.info "#{letter}"
@letters = Array.new

@per_page = 1

# Check if the "Show" button for pagination is clicked
# If yes, set @per_page to the value of the selection dropdown
# Else, if the request is from one of the letter links on the top
# set @per_page to 1 (25 names per page).
# Else, set @per_page to the :num_users param passed in from
# the will_paginate method from the 'pagination' partial.
if params[:paginate_show]
@per_page = params[:num_users]
elsif params[:from_letter]
@per_page = 1
else
@per_page = params[:num_users]
end

# Get the users list to show on current page
@users = paginate_list(role, user.id, letter)

@letters = ('A'..'Z').to_a
end
</pre>

After Refactoring :

<pre>
#for displaying the list of users
def index
if (current_user_role? == "Student")
redirect_to(:action => AuthHelper::get_home_action(session[:user]), :controller => AuthHelper::get_home_controller(session[:user]))
else
#list method's implementation
end
end
</pre>

===Instance Variable Reductions===
It is a bad practice to have more than one instance variables in a controller's method as it indicates increased coupling. Coupling must be as less as possible and the view should have direct access to as few instance variables as possible. Helper methods should be defined in controllers through which the view can access variables of the controller class. The code has been refactored to make use of helper methods for the instance variables in index action.

Before Refactoring

users_controller.rb
<pre>

def get_role
if @user && @user.role_id
@role = Role.find(@user.role_id)
elsif @user
@role = Role.new(:id => nil, :name => '(none)')
end
end
</pre>

show.html.erb

<pre>
<tr><th>Role:</th>
<td><%= link_to @role.name, :controller => 'roles',
:action => 'show', :id => @role.id %></td>
</tr>
</pre>

After Refactoring

users_controller.rb
<pre>
def get_role
if @user && @user.role_id
role = Role.find(@user.role_id)
elsif @user
role = Role.new(id: nil, name: '(none)')
end
return role
end
</pre>

show.html.erb

<pre>
<tr><th>Role:</th>
<td><%= link_to get_role.name, :controller => 'roles',
:action => 'show', :id => get_role.id %></td>
</tr>

</table>
</pre>

Similar approach for reduction of instance variables has been implemented in other methods like index, show_selection, etc.

===Code Cleanup===
Code cleanup in the controller so that the code conforms closely to Rails conventions and further enhances the readability of the code.
* Replaced String concats with #{} in paginate_list
Before Refactoring :

<pre>
#paginate_list
search_filter = letter + '%'
search_filter = '%' + letter + '%'
</pre>

After Refactoring :

<pre>
#paginate_list
search_filter = "#{letter}%"
search_filter = "%#{letter}%"
</pre>

* Replaced '==' with eql?
Before Refactoring :
<pre>
#index
if (current_user_role? == "Student")
...
letter == nil

#show_selection
@role.parent_id == nil || @role.parent_id < (session[:user]).role_id || @user.id == (session[:user]).id

#show
if (params[:id].nil?) || ((current_user_role? == "Student") && (session[:user].id != params[:id].to_i))

#create
if @user.role.name == "Instructor" or @user.role.name == "Administrator"

#keys
if (params[:id].nil?) || ((current_user_role? == "Student") && (session[:user].id != params[:id].to_i))

#paginate_list
if @search_by == '1'
</pre>

After Refactoring :
<pre>
#index
if (current_user_role.eql? "Student")
...
if letter.eql? nil

#show_selection
if role.parent_id.eql? nil || role.parent_id < (session[:user]).role_id || @user.id.eql?(session[:user]).id

#show
if (params[:id].nil?) || ((current_user_role.eql? "Student") && (session[:user].id != params[:id].to_i))

#create
if @user.role.name.eql? "Instructor" or @user.role.name.eql? "Administrator"

#keys
if (params[:id].nil?) || ((current_user_role.eql? "Student") && (session[:user].id != params[:id].to_i))

#paginate_list
if @search_by.eql? '1' #search by user name
</pre>

* Replaced :key =>'value' with key: 'value'

Before Refactoring :
<pre>
#index
redirect_to(:action => AuthHelper::get_home_action(session[:user]), :controller => AuthHelper::get_home_controller(session[:user]))

#show_selection
render :action => 'show'

#create
AssignmentQuestionnaire.create(:user_id => @user.id)
</pre>

After Refactoring :
<pre>
#index
redirect_to(action: AuthHelper::get_home_action(session[:user]), controller: AuthHelper::get_home_controller(session[:user]))

#show_selection
render action: 'show'

#create
AssignmentQuestionnaire.create(user_id: @user.id)
</pre>

*Modified declarations of Arrays and Hashes
Before Refactoring :
<pre>
#index
@letters = Array.new

#paginate_list
paginate_options = {"1" => 25, "2" => 50, "3" => 100}
</pre>

After Refactoring :
<pre>
#index
@letters =[]

#paginate_list
paginate_options = Hash["1" ,25 , "2", 50, "3", 100]
</pre>

*Removed unused methods like self.participants_in and commented out code.

===Use of Routing Helpers===
Routing helpers are a simpler alternative to the otherwise complex hard coded URLs which reduce the readability of the code.Routing helpers allow us to declare possible common routes for a given controller. Routing helpers have been implemented since they maintain consistency even if changes are made to the routing paths.

Before Refactoring:
 
<pre>
def show_selection
@user = User.find_by_name(params[:user][:name])
if @user != nil
get_role
if @role.parent_id == nil || @role.parent_id < (session[:user]).role_id || @user.id == (session[:user]).id
render :action => 'show'
else
flash[:note] = 'The specified user is not available for editing.'
redirect_to :action => 'list'
end
else
flash[:note] = params[:user][:name]+' does not exist.'
redirect_to :action => 'list'
end
end
</pre>
 
After Refactoring
 
<pre>
def show_selection
@user = User.where(name: params[:user][:name]).take
if @user != nil
role=get_role
if role.parent_id.eql? nil || role.parent_id < (session[:user]).role_id || @user.id.eql?(session[:user]).id
render action: 'show'
else
flash[:note] = 'The specified user is not available for editing.'
redirect_to users_path #Replaced URL with routing helper
end
else
flash[:note] = params[:user][:name]+' does not exist.'
redirect_to users_path #Replaced URL with routing helper
end
end
</pre>
 

===Replace find_by_.. with where in querying===
Rails 4 conventions dictate the use of 'where()' over the use of 'find_by_...' methods while querying ActiveRecords. The code has been refactored to replace the usages of find_by.. with where().

Before Refactoring
<pre>
def show_selection
@user = User.find_by_name(params[:user][:name])
if @user != nil
</pre>

After Refactoring
<pre>
def show_selection
@user = User.where(name: params[:user][:name]).take
if @user != nil
</pre>

==References==
*[https://github.com/ameyp1992/expertiza.git Git Repository]

*[http://wiki.expertiza.ncsu.edu/index.php/Development:Setup:Linux:Debian Expertiza Setup]

*[https://docs.google.com/document/d/1FZCL9KWSdVNsX9BowuZ3gxbCOJoiWX-GVLctSZei3No/edit?pli=1#heading=h.2y12n9sli9rd Project requirements]
<references/>

CSC/ECE 517 Fall 2014/oss E1465 oak

2014-10-29T04:46:05Z

Knimgao: /* Code Cleanup */

=Expertiza - Refactoring UsersController=

__TOC__

==Introduction==
Expertiza<ref name="expertiza>''Expertiza'' http://wikis.lib.ncsu.edu/index.php/Expertiza</ref> is a web application available to both students and professors. The Expertiza project is a system to create reusable learning objects through peer review. Expertiza supports team projects and the submission of almost any document type, including URLs and wiki pages. Students can keep a track of their assignments, teammates and can conduct peer reviews on diverse topics and projects. It is an open source project developed on Ruby on Rails platform. More information on Expertiza can be found [https://github.com/expertiza/expertiza here]. The source code can be forked and cloned for making modifications.

As a part of the coursework of Object Oriented Design and Development, we were expected to refactor the funtionality of some modules of Expertiza. This wiki provides an insight into our contributions to the Open Source Software project 'Expertiza' by Refactoring the Users Controller.

==Project Description==
The Users Controller deals with managing activities peripheral to the User registered with Expertiza. Users are mapped to different roles like super-admin, admin, instructor, teaching assistant and student with each role having different access permissions. The Manage Users module can be accessed by roles other than the student. It provides users with the functionality to search other users based on keywords like username, email, etc. New user can be created and existing user information and role can be updated.

Classes : users_controller.rb 
What it does : Manage Users i.e.search and list users, create new user, edit/update existing users, delete users. 
What has to be changed : 
* Modify methods to conform to RESTful style
* Reducing the number of instance variables per action to one
* Code cleanup by using string interpolation instead of concatenation, replacing '==' with eql? and :key =>'value' with key: 'value', modifying declarations of Arrays and Hashes and removing commented out code
* Use of routing helpers instead of hardcoded URLs
* Replace find_by with where to follow Rails 4.0 conventions

Original lines of code : 243

Lines after refactoring: 225

==Modification to Existing Code==

===RESTful style implementation===
* Modifications to users_controller.rb : The purpose of the index method in Users Controller is to list all registered users. The list method was called from the index method to list all users. This implementation did not conform to RESTful guidelines. Hence, we refactored the list method in users controller to index. Further, we refactored all the references of list method in UserControllers, Users views, Users tests and routes.rb to the index method.

Before Refactoring :
<pre>
def index
if (current_user_role? == "Student")
redirect_to(:action => AuthHelper::get_home_action(session[:user]), :controller => AuthHelper::get_home_controller(session[:user]))
else
list
render :action => 'list'
end
end

#for displaying the list of users
def list
user = session[:user]
role = Role.find(user.role_id)
all_users = User.order('name').where( ['role_id in (?) or id = ?', role.get_available_roles, user.id])

letter = params[:letter]
session[:letter] = letter
if letter == nil
letter = all_users.first.name[0,1].downcase
end
logger.info "#{letter}"
@letters = Array.new

@per_page = 1

# Check if the "Show" button for pagination is clicked
# If yes, set @per_page to the value of the selection dropdown
# Else, if the request is from one of the letter links on the top
# set @per_page to 1 (25 names per page).
# Else, set @per_page to the :num_users param passed in from
# the will_paginate method from the 'pagination' partial.
if params[:paginate_show]
@per_page = params[:num_users]
elsif params[:from_letter]
@per_page = 1
else
@per_page = params[:num_users]
end

# Get the users list to show on current page
@users = paginate_list(role, user.id, letter)

@letters = ('A'..'Z').to_a
end
</pre>

After Refactoring :

<pre>
#for displaying the list of users
def index
if (current_user_role? == "Student")
redirect_to(:action => AuthHelper::get_home_action(session[:user]), :controller => AuthHelper::get_home_controller(session[:user]))
else
#list method's implementation
end
end
</pre>

===Instance Variable Reductions===
It is a bad practice to have more than one instance variables in a controller's method as it indicates increased coupling. Coupling must be as less as possible and the view should have direct access to as few instance variables as possible. Helper methods should be defined in controllers through which the view can access variables of the controller class. The code has been refactored to make use of helper methods for the instance variables in index action.

Before Refactoring

users_controller.rb
<pre>

def get_role
if @user && @user.role_id
@role = Role.find(@user.role_id)
elsif @user
@role = Role.new(:id => nil, :name => '(none)')
end
end
</pre>

show.html.erb

<pre>
<tr><th>Role:</th>
<td><%= link_to @role.name, :controller => 'roles',
:action => 'show', :id => @role.id %></td>
</tr>
</pre>

After Refactoring

users_controller.rb
<pre>
def get_role
if @user && @user.role_id
role = Role.find(@user.role_id)
elsif @user
role = Role.new(id: nil, name: '(none)')
end
return role
end
</pre>

show.html.erb

<pre>
<tr><th>Role:</th>
<td><%= link_to get_role.name, :controller => 'roles',
:action => 'show', :id => get_role.id %></td>
</tr>

</table>
</pre>

Similar approach for reduction of instance variables has been implemented in other methods like index, show_selection, etc.

===Code Cleanup===
Code cleanup in the controller so that the code conforms closely to Rails conventions and further enhances the readability of the code.
* Replaced String concats with #{} in paginate_list
Before Refactoring :

<pre>
#paginate_list
search_filter = letter + '%'
search_filter = '%' + letter + '%'
</pre>

After Refactoring :

<pre>
#paginate_list
search_filter = "#{letter}%"
search_filter = "%#{letter}%"
</pre>

* Replaced '==' with eql?
Before Refactoring :
<pre>
#index
if (current_user_role? == "Student")
...
letter == nil

#show_selection
@role.parent_id == nil || @role.parent_id < (session[:user]).role_id || @user.id == (session[:user]).id

#show
if (params[:id].nil?) || ((current_user_role? == "Student") && (session[:user].id != params[:id].to_i))

#create
if @user.role.name == "Instructor" or @user.role.name == "Administrator"

#keys
if (params[:id].nil?) || ((current_user_role? == "Student") && (session[:user].id != params[:id].to_i))

#paginate_list
if @search_by == '1'
</pre>

After Refactoring :
<pre>
#index
if (current_user_role.eql? "Student")
...
if letter.eql? nil

#show_selection
if role.parent_id.eql? nil || role.parent_id < (session[:user]).role_id || @user.id.eql?(session[:user]).id

#show
if (params[:id].nil?) || ((current_user_role.eql? "Student") && (session[:user].id != params[:id].to_i))

#create
if @user.role.name.eql? "Instructor" or @user.role.name.eql? "Administrator"

#keys
if (params[:id].nil?) || ((current_user_role.eql? "Student") && (session[:user].id != params[:id].to_i))

#paginate_list
if @search_by.eql? '1' #search by user name
</pre>

* Replaced :key =>'value' with key: 'value'

Before Refactoring :
<pre>
#index
redirect_to(:action => AuthHelper::get_home_action(session[:user]), :controller => AuthHelper::get_home_controller(session[:user]))

#show_selection
render :action => 'show'

#create
AssignmentQuestionnaire.create(:user_id => @user.id)
</pre>

After Refactoring :
<pre>
#index
redirect_to(action: AuthHelper::get_home_action(session[:user]), controller: AuthHelper::get_home_controller(session[:user]))

#show_selection
render action: 'show'

#create
AssignmentQuestionnaire.create(user_id: @user.id)
</pre>

*Modified declarations of Arrays and Hashes
Before Refactoring :
<pre>
#index
@letters = Array.new

#paginate_list
paginate_options = {"1" => 25, "2" => 50, "3" => 100}
</pre>

After Refactoring :
<pre>
#index
@letters =[]

#paginate_list
paginate_options = Hash["1" ,25 , "2", 50, "3", 100]
</pre>

*Removed unused methods like self.participants_in and commented out code.

===Use of Routing Helpers===
Routing helpers are a simpler alternative to the otherwise complex hard coded URLs which reduce the readability of the code.Routing helpers allow us to declare possible common routes for a given controller. Routing helpers have been implemented since they maintain consistency even if changes are made to the routing paths.

Before Refactoring:
 
<pre>
def show_selection
@user = User.find_by_name(params[:user][:name])
if @user != nil
get_role
if @role.parent_id == nil || @role.parent_id < (session[:user]).role_id || @user.id == (session[:user]).id
render :action => 'show'
else
flash[:note] = 'The specified user is not available for editing.'
redirect_to :action => 'list'
end
else
flash[:note] = params[:user][:name]+' does not exist.'
redirect_to :action => 'list'
end
end
</pre>
 
After Refactoring
 
<pre>
def show_selection
@user = User.where(name: params[:user][:name]).take
if @user != nil
role=get_role
if role.parent_id.eql? nil || role.parent_id < (session[:user]).role_id || @user.id.eql?(session[:user]).id
render action: 'show'
else
flash[:note] = 'The specified user is not available for editing.'
redirect_to users_path #Replaced URL with routing helper
end
else
flash[:note] = params[:user][:name]+' does not exist.'
redirect_to users_path #Replaced URL with routing helper
end
end
</pre>
 

===Replace find_by_.. with where in querying===
Rails 4 conventions dictate the use of 'where()' over the use of 'find_by_...' methods while querying ActiveRecords. The code has been refactored to replace the usages of find_by.. with where().

Before Refactoring
<pre>
def show_selection
@user = User.find_by_name(params[:user][:name])
if @user != nil
</pre>

After Refactoring
<pre>
def show_selection
@user = User.where(name: params[:user][:name]).take
if @user != nil
</pre>

==References==
[https://github.com/ameyp1992/expertiza.git Git Repository]

[http://wiki.expertiza.ncsu.edu/index.php/Development:Setup:Linux:Debian Expertiza Setup]

[https://docs.google.com/document/d/1FZCL9KWSdVNsX9BowuZ3gxbCOJoiWX-GVLctSZei3No/edit?pli=1#heading=h.2y12n9sli9rd Project requirements]
<references/>

CSC/ECE 517 Fall 2014/oss E1465 oak

2014-10-29T04:44:37Z

Knimgao: /* Instance Variable Reductions */

=Expertiza - Refactoring UsersController=

__TOC__

==Introduction==
Expertiza<ref name="expertiza>''Expertiza'' http://wikis.lib.ncsu.edu/index.php/Expertiza</ref> is a web application available to both students and professors. The Expertiza project is a system to create reusable learning objects through peer review. Expertiza supports team projects and the submission of almost any document type, including URLs and wiki pages. Students can keep a track of their assignments, teammates and can conduct peer reviews on diverse topics and projects. It is an open source project developed on Ruby on Rails platform. More information on Expertiza can be found [https://github.com/expertiza/expertiza here]. The source code can be forked and cloned for making modifications.

As a part of the coursework of Object Oriented Design and Development, we were expected to refactor the funtionality of some modules of Expertiza. This wiki provides an insight into our contributions to the Open Source Software project 'Expertiza' by Refactoring the Users Controller.

==Project Description==
The Users Controller deals with managing activities peripheral to the User registered with Expertiza. Users are mapped to different roles like super-admin, admin, instructor, teaching assistant and student with each role having different access permissions. The Manage Users module can be accessed by roles other than the student. It provides users with the functionality to search other users based on keywords like username, email, etc. New user can be created and existing user information and role can be updated.

Classes : users_controller.rb 
What it does : Manage Users i.e.search and list users, create new user, edit/update existing users, delete users. 
What has to be changed : 
* Modify methods to conform to RESTful style
* Reducing the number of instance variables per action to one
* Code cleanup by using string interpolation instead of concatenation, replacing '==' with eql? and :key =>'value' with key: 'value', modifying declarations of Arrays and Hashes and removing commented out code
* Use of routing helpers instead of hardcoded URLs
* Replace find_by with where to follow Rails 4.0 conventions

Original lines of code : 243

Lines after refactoring: 225

==Modification to Existing Code==

===RESTful style implementation===
* Modifications to users_controller.rb : The purpose of the index method in Users Controller is to list all registered users. The list method was called from the index method to list all users. This implementation did not conform to RESTful guidelines. Hence, we refactored the list method in users controller to index. Further, we refactored all the references of list method in UserControllers, Users views, Users tests and routes.rb to the index method.

Before Refactoring :
<pre>
def index
if (current_user_role? == "Student")
redirect_to(:action => AuthHelper::get_home_action(session[:user]), :controller => AuthHelper::get_home_controller(session[:user]))
else
list
render :action => 'list'
end
end

#for displaying the list of users
def list
user = session[:user]
role = Role.find(user.role_id)
all_users = User.order('name').where( ['role_id in (?) or id = ?', role.get_available_roles, user.id])

letter = params[:letter]
session[:letter] = letter
if letter == nil
letter = all_users.first.name[0,1].downcase
end
logger.info "#{letter}"
@letters = Array.new

@per_page = 1

# Check if the "Show" button for pagination is clicked
# If yes, set @per_page to the value of the selection dropdown
# Else, if the request is from one of the letter links on the top
# set @per_page to 1 (25 names per page).
# Else, set @per_page to the :num_users param passed in from
# the will_paginate method from the 'pagination' partial.
if params[:paginate_show]
@per_page = params[:num_users]
elsif params[:from_letter]
@per_page = 1
else
@per_page = params[:num_users]
end

# Get the users list to show on current page
@users = paginate_list(role, user.id, letter)

@letters = ('A'..'Z').to_a
end
</pre>

After Refactoring :

<pre>
#for displaying the list of users
def index
if (current_user_role? == "Student")
redirect_to(:action => AuthHelper::get_home_action(session[:user]), :controller => AuthHelper::get_home_controller(session[:user]))
else
#list method's implementation
end
end
</pre>

===Instance Variable Reductions===
It is a bad practice to have more than one instance variables in a controller's method as it indicates increased coupling. Coupling must be as less as possible and the view should have direct access to as few instance variables as possible. Helper methods should be defined in controllers through which the view can access variables of the controller class. The code has been refactored to make use of helper methods for the instance variables in index action.

Before Refactoring

users_controller.rb
<pre>

def get_role
if @user && @user.role_id
@role = Role.find(@user.role_id)
elsif @user
@role = Role.new(:id => nil, :name => '(none)')
end
end
</pre>

show.html.erb

<pre>
<tr><th>Role:</th>
<td><%= link_to @role.name, :controller => 'roles',
:action => 'show', :id => @role.id %></td>
</tr>
</pre>

After Refactoring

users_controller.rb
<pre>
def get_role
if @user && @user.role_id
role = Role.find(@user.role_id)
elsif @user
role = Role.new(id: nil, name: '(none)')
end
return role
end
</pre>

show.html.erb

<pre>
<tr><th>Role:</th>
<td><%= link_to get_role.name, :controller => 'roles',
:action => 'show', :id => get_role.id %></td>
</tr>

</table>
</pre>

Similar approach for reduction of instance variables has been implemented in other methods like index, show_selection, etc.

===Code Cleanup===
Code cleanup in the controller so that the code conforms closely to Rails conventions and enhanced readability of code.
* Replaced String concats with #{} in paginate_list
Before Refactoring :

<pre>
#paginate_list
search_filter = letter + '%'
search_filter = '%' + letter + '%'
</pre>

After Refactoring :

<pre>
#paginate_list
search_filter = "#{letter}%"
search_filter = "%#{letter}%"
</pre>

* Replaced '==' with eql?
Before Refactoring :
<pre>
#index
if (current_user_role? == "Student")
...
letter == nil

#show_selection
@role.parent_id == nil || @role.parent_id < (session[:user]).role_id || @user.id == (session[:user]).id

#show
if (params[:id].nil?) || ((current_user_role? == "Student") && (session[:user].id != params[:id].to_i))

#create
if @user.role.name == "Instructor" or @user.role.name == "Administrator"

#keys
if (params[:id].nil?) || ((current_user_role? == "Student") && (session[:user].id != params[:id].to_i))

#paginate_list
if @search_by == '1'
</pre>

After Refactoring :
<pre>
#index
if (current_user_role.eql? "Student")
...
if letter.eql? nil

#show_selection
if role.parent_id.eql? nil || role.parent_id < (session[:user]).role_id || @user.id.eql?(session[:user]).id

#show
if (params[:id].nil?) || ((current_user_role.eql? "Student") && (session[:user].id != params[:id].to_i))

#create
if @user.role.name.eql? "Instructor" or @user.role.name.eql? "Administrator"

#keys
if (params[:id].nil?) || ((current_user_role.eql? "Student") && (session[:user].id != params[:id].to_i))

#paginate_list
if @search_by.eql? '1' #search by user name
</pre>

* Replaced :key =>'value' with key: 'value'

Before Refactoring :
<pre>
#index
redirect_to(:action => AuthHelper::get_home_action(session[:user]), :controller => AuthHelper::get_home_controller(session[:user]))

#show_selection
render :action => 'show'

#create
AssignmentQuestionnaire.create(:user_id => @user.id)
</pre>

After Refactoring :
<pre>
#index
redirect_to(action: AuthHelper::get_home_action(session[:user]), controller: AuthHelper::get_home_controller(session[:user]))

#show_selection
render action: 'show'

#create
AssignmentQuestionnaire.create(user_id: @user.id)
</pre>

*Modified declarations of Arrays and Hashes
Before Refactoring :
<pre>
#index
@letters = Array.new

#paginate_list
paginate_options = {"1" => 25, "2" => 50, "3" => 100}
</pre>

After Refactoring :
<pre>
#index
@letters =[]

#paginate_list
paginate_options = Hash["1" ,25 , "2", 50, "3", 100]
</pre>

*Removed unused methods like self.participants_in and commented out code.

===Use of Routing Helpers===
Routing helpers are a simpler alternative to the otherwise complex hard coded URLs which reduce the readability of the code.Routing helpers allow us to declare possible common routes for a given controller. Routing helpers have been implemented since they maintain consistency even if changes are made to the routing paths.

Before Refactoring:
 
<pre>
def show_selection
@user = User.find_by_name(params[:user][:name])
if @user != nil
get_role
if @role.parent_id == nil || @role.parent_id < (session[:user]).role_id || @user.id == (session[:user]).id
render :action => 'show'
else
flash[:note] = 'The specified user is not available for editing.'
redirect_to :action => 'list'
end
else
flash[:note] = params[:user][:name]+' does not exist.'
redirect_to :action => 'list'
end
end
</pre>
 
After Refactoring
 
<pre>
def show_selection
@user = User.where(name: params[:user][:name]).take
if @user != nil
role=get_role
if role.parent_id.eql? nil || role.parent_id < (session[:user]).role_id || @user.id.eql?(session[:user]).id
render action: 'show'
else
flash[:note] = 'The specified user is not available for editing.'
redirect_to users_path #Replaced URL with routing helper
end
else
flash[:note] = params[:user][:name]+' does not exist.'
redirect_to users_path #Replaced URL with routing helper
end
end
</pre>
 

===Replace find_by_.. with where in querying===
Rails 4 conventions dictate the use of 'where()' over the use of 'find_by_...' methods while querying ActiveRecords. The code has been refactored to replace the usages of find_by.. with where().

Before Refactoring
<pre>
def show_selection
@user = User.find_by_name(params[:user][:name])
if @user != nil
</pre>

After Refactoring
<pre>
def show_selection
@user = User.where(name: params[:user][:name]).take
if @user != nil
</pre>

==References==
[https://github.com/ameyp1992/expertiza.git Git Repository]

[http://wiki.expertiza.ncsu.edu/index.php/Development:Setup:Linux:Debian Expertiza Setup]

[https://docs.google.com/document/d/1FZCL9KWSdVNsX9BowuZ3gxbCOJoiWX-GVLctSZei3No/edit?pli=1#heading=h.2y12n9sli9rd Project requirements]
<references/>

CSC/ECE 517 Fall 2014/oss E1465 oak

2014-10-29T04:39:11Z

Knimgao: /* RESTful style implementation */

=Expertiza - Refactoring UsersController=

__TOC__

==Introduction==
Expertiza<ref name="expertiza>''Expertiza'' http://wikis.lib.ncsu.edu/index.php/Expertiza</ref> is a web application available to both students and professors. The Expertiza project is a system to create reusable learning objects through peer review. Expertiza supports team projects and the submission of almost any document type, including URLs and wiki pages. Students can keep a track of their assignments, teammates and can conduct peer reviews on diverse topics and projects. It is an open source project developed on Ruby on Rails platform. More information on Expertiza can be found [https://github.com/expertiza/expertiza here]. The source code can be forked and cloned for making modifications.

As a part of the coursework of Object Oriented Design and Development, we were expected to refactor the funtionality of some modules of Expertiza. This wiki provides an insight into our contributions to the Open Source Software project 'Expertiza' by Refactoring the Users Controller.

==Project Description==
The Users Controller deals with managing activities peripheral to the User registered with Expertiza. Users are mapped to different roles like super-admin, admin, instructor, teaching assistant and student with each role having different access permissions. The Manage Users module can be accessed by roles other than the student. It provides users with the functionality to search other users based on keywords like username, email, etc. New user can be created and existing user information and role can be updated.

Classes : users_controller.rb 
What it does : Manage Users i.e.search and list users, create new user, edit/update existing users, delete users. 
What has to be changed : 
* Modify methods to conform to RESTful style
* Reducing the number of instance variables per action to one
* Code cleanup by using string interpolation instead of concatenation, replacing '==' with eql? and :key =>'value' with key: 'value', modifying declarations of Arrays and Hashes and removing commented out code
* Use of routing helpers instead of hardcoded URLs
* Replace find_by with where to follow Rails 4.0 conventions

Original lines of code : 243

Lines after refactoring: 225

==Modification to Existing Code==

===RESTful style implementation===
* Modifications to users_controller.rb : The purpose of the index method in Users Controller is to list all registered users. The list method was called from the index method to list all users. This implementation did not conform to RESTful guidelines. Hence, we refactored the list method in users controller to index. Further, we refactored all the references of list method in UserControllers, Users views, Users tests and routes.rb to the index method.

Before Refactoring :
<pre>
def index
if (current_user_role? == "Student")
redirect_to(:action => AuthHelper::get_home_action(session[:user]), :controller => AuthHelper::get_home_controller(session[:user]))
else
list
render :action => 'list'
end
end

#for displaying the list of users
def list
user = session[:user]
role = Role.find(user.role_id)
all_users = User.order('name').where( ['role_id in (?) or id = ?', role.get_available_roles, user.id])

letter = params[:letter]
session[:letter] = letter
if letter == nil
letter = all_users.first.name[0,1].downcase
end
logger.info "#{letter}"
@letters = Array.new

@per_page = 1

# Check if the "Show" button for pagination is clicked
# If yes, set @per_page to the value of the selection dropdown
# Else, if the request is from one of the letter links on the top
# set @per_page to 1 (25 names per page).
# Else, set @per_page to the :num_users param passed in from
# the will_paginate method from the 'pagination' partial.
if params[:paginate_show]
@per_page = params[:num_users]
elsif params[:from_letter]
@per_page = 1
else
@per_page = params[:num_users]
end

# Get the users list to show on current page
@users = paginate_list(role, user.id, letter)

@letters = ('A'..'Z').to_a
end
</pre>

After Refactoring :

<pre>
#for displaying the list of users
def index
if (current_user_role? == "Student")
redirect_to(:action => AuthHelper::get_home_action(session[:user]), :controller => AuthHelper::get_home_controller(session[:user]))
else
#list method's implementation
end
end
</pre>

===Instance Variable Reductions===
It is a bad practice to have more than one instance variables in a controller action as it indicates towards increased coupling. We want to reduce the coupling as much as possible and view should have direct access to as few instance variables as possible. Helper methods should be defined in controllers through which the view can access variables of the controller class. The code has been refactored to make use of helper methods for the instance variables in index action.

Before Refactoring

users_controller.rb
<pre>

def get_role
if @user && @user.role_id
@role = Role.find(@user.role_id)
elsif @user
@role = Role.new(:id => nil, :name => '(none)')
end
end
</pre>

show.html.erb

<pre>
<tr><th>Role:</th>
<td><%= link_to @role.name, :controller => 'roles',
:action => 'show', :id => @role.id %></td>
</tr>
</pre>

After Refactoring

users_controller.rb
<pre>
def get_role
if @user && @user.role_id
role = Role.find(@user.role_id)
elsif @user
role = Role.new(id: nil, name: '(none)')
end
return role
end
</pre>

show.html.erb

<pre>
<tr><th>Role:</th>
<td><%= link_to get_role.name, :controller => 'roles',
:action => 'show', :id => get_role.id %></td>
</tr>

</table>
</pre>

===Code Cleanup===
Code cleanup in the controller so that the code conforms closely to Rails conventions and enhanced readability of code.
* Replaced String concats with #{} in paginate_list
Before Refactoring :

<pre>
#paginate_list
search_filter = letter + '%'
search_filter = '%' + letter + '%'
</pre>

After Refactoring :

<pre>
#paginate_list
search_filter = "#{letter}%"
search_filter = "%#{letter}%"
</pre>

* Replaced '==' with eql?
Before Refactoring :
<pre>
#index
if (current_user_role? == "Student")
...
letter == nil

#show_selection
@role.parent_id == nil || @role.parent_id < (session[:user]).role_id || @user.id == (session[:user]).id

#show
if (params[:id].nil?) || ((current_user_role? == "Student") && (session[:user].id != params[:id].to_i))

#create
if @user.role.name == "Instructor" or @user.role.name == "Administrator"

#keys
if (params[:id].nil?) || ((current_user_role? == "Student") && (session[:user].id != params[:id].to_i))

#paginate_list
if @search_by == '1'
</pre>

After Refactoring :
<pre>
#index
if (current_user_role.eql? "Student")
...
if letter.eql? nil

#show_selection
if role.parent_id.eql? nil || role.parent_id < (session[:user]).role_id || @user.id.eql?(session[:user]).id

#show
if (params[:id].nil?) || ((current_user_role.eql? "Student") && (session[:user].id != params[:id].to_i))

#create
if @user.role.name.eql? "Instructor" or @user.role.name.eql? "Administrator"

#keys
if (params[:id].nil?) || ((current_user_role.eql? "Student") && (session[:user].id != params[:id].to_i))

#paginate_list
if @search_by.eql? '1' #search by user name
</pre>

* Replaced :key =>'value' with key: 'value'

Before Refactoring :
<pre>
#index
redirect_to(:action => AuthHelper::get_home_action(session[:user]), :controller => AuthHelper::get_home_controller(session[:user]))

#show_selection
render :action => 'show'

#create
AssignmentQuestionnaire.create(:user_id => @user.id)
</pre>

After Refactoring :
<pre>
#index
redirect_to(action: AuthHelper::get_home_action(session[:user]), controller: AuthHelper::get_home_controller(session[:user]))

#show_selection
render action: 'show'

#create
AssignmentQuestionnaire.create(user_id: @user.id)
</pre>

*Modified declarations of Arrays and Hashes
Before Refactoring :
<pre>
#index
@letters = Array.new

#paginate_list
paginate_options = {"1" => 25, "2" => 50, "3" => 100}
</pre>

After Refactoring :
<pre>
#index
@letters =[]

#paginate_list
paginate_options = Hash["1" ,25 , "2", 50, "3", 100]
</pre>

*Removed unused methods like self.participants_in and commented out code.

===Use of Routing Helpers===
Routing helpers are a simpler alternative to the otherwise complex hard coded URLs which reduce the readability of the code.Routing helpers allow us to declare possible common routes for a given controller. Routing helpers have been implemented since they maintain consistency even if changes are made to the routing paths.

Before Refactoring:
 
<pre>
def show_selection
@user = User.find_by_name(params[:user][:name])
if @user != nil
get_role
if @role.parent_id == nil || @role.parent_id < (session[:user]).role_id || @user.id == (session[:user]).id
render :action => 'show'
else
flash[:note] = 'The specified user is not available for editing.'
redirect_to :action => 'list'
end
else
flash[:note] = params[:user][:name]+' does not exist.'
redirect_to :action => 'list'
end
end
</pre>
 
After Refactoring
 
<pre>
def show_selection
@user = User.where(name: params[:user][:name]).take
if @user != nil
role=get_role
if role.parent_id.eql? nil || role.parent_id < (session[:user]).role_id || @user.id.eql?(session[:user]).id
render action: 'show'
else
flash[:note] = 'The specified user is not available for editing.'
redirect_to users_path #Replaced URL with routing helper
end
else
flash[:note] = params[:user][:name]+' does not exist.'
redirect_to users_path #Replaced URL with routing helper
end
end
</pre>
 

===Replace find_by_.. with where in querying===
Rails 4 conventions dictate the use of 'where()' over the use of 'find_by_...' methods while querying ActiveRecords. The code has been refactored to replace the usages of find_by.. with where().

Before Refactoring
<pre>
def show_selection
@user = User.find_by_name(params[:user][:name])
if @user != nil
</pre>

After Refactoring
<pre>
def show_selection
@user = User.where(name: params[:user][:name]).take
if @user != nil
</pre>

==References==
[https://github.com/ameyp1992/expertiza.git Git Repository]

[http://wiki.expertiza.ncsu.edu/index.php/Development:Setup:Linux:Debian Expertiza Setup]

[https://docs.google.com/document/d/1FZCL9KWSdVNsX9BowuZ3gxbCOJoiWX-GVLctSZei3No/edit?pli=1#heading=h.2y12n9sli9rd Project requirements]
<references/>

CSC/ECE 517 Fall 2014/oss E1465 oak

2014-10-29T04:37:45Z

Knimgao: /* Project Description */

=Expertiza - Refactoring UsersController=

__TOC__

==Introduction==
Expertiza<ref name="expertiza>''Expertiza'' http://wikis.lib.ncsu.edu/index.php/Expertiza</ref> is a web application available to both students and professors. The Expertiza project is a system to create reusable learning objects through peer review. Expertiza supports team projects and the submission of almost any document type, including URLs and wiki pages. Students can keep a track of their assignments, teammates and can conduct peer reviews on diverse topics and projects. It is an open source project developed on Ruby on Rails platform. More information on Expertiza can be found [https://github.com/expertiza/expertiza here]. The source code can be forked and cloned for making modifications.

As a part of the coursework of Object Oriented Design and Development, we were expected to refactor the funtionality of some modules of Expertiza. This wiki provides an insight into our contributions to the Open Source Software project 'Expertiza' by Refactoring the Users Controller.

==Project Description==
The Users Controller deals with managing activities peripheral to the User registered with Expertiza. Users are mapped to different roles like super-admin, admin, instructor, teaching assistant and student with each role having different access permissions. The Manage Users module can be accessed by roles other than the student. It provides users with the functionality to search other users based on keywords like username, email, etc. New user can be created and existing user information and role can be updated.

Classes : users_controller.rb 
What it does : Manage Users i.e.search and list users, create new user, edit/update existing users, delete users. 
What has to be changed : 
* Modify methods to conform to RESTful style
* Reducing the number of instance variables per action to one
* Code cleanup by using string interpolation instead of concatenation, replacing '==' with eql? and :key =>'value' with key: 'value', modifying declarations of Arrays and Hashes and removing commented out code
* Use of routing helpers instead of hardcoded URLs
* Replace find_by with where to follow Rails 4.0 conventions

Original lines of code : 243

Lines after refactoring: 225

==Modification to Existing Code==

===RESTful style implementation===
* Modifications to users_controller.rb : The purpose of the index method in Users Controller is to list all registered users. The list method was called from the index method to list all users. This implementation did not conform to RESTful guidelines. Hence, we refactored the list method in users controller to index. Further, we refactored all the references of list method in UserControllers, Users views, Users tests and routes.rb to index method.

Before Refactoring :
<pre>
def index
if (current_user_role? == "Student")
redirect_to(:action => AuthHelper::get_home_action(session[:user]), :controller => AuthHelper::get_home_controller(session[:user]))
else
list
render :action => 'list'
end
end

#for displaying the list of users
def list
user = session[:user]
role = Role.find(user.role_id)
all_users = User.order('name').where( ['role_id in (?) or id = ?', role.get_available_roles, user.id])

letter = params[:letter]
session[:letter] = letter
if letter == nil
letter = all_users.first.name[0,1].downcase
end
logger.info "#{letter}"
@letters = Array.new

@per_page = 1

# Check if the "Show" button for pagination is clicked
# If yes, set @per_page to the value of the selection dropdown
# Else, if the request is from one of the letter links on the top
# set @per_page to 1 (25 names per page).
# Else, set @per_page to the :num_users param passed in from
# the will_paginate method from the 'pagination' partial.
if params[:paginate_show]
@per_page = params[:num_users]
elsif params[:from_letter]
@per_page = 1
else
@per_page = params[:num_users]
end

# Get the users list to show on current page
@users = paginate_list(role, user.id, letter)

@letters = ('A'..'Z').to_a
end
</pre>

After Refactoring :

<pre>
#for displaying the list of users
def index
if (current_user_role? == "Student")
redirect_to(:action => AuthHelper::get_home_action(session[:user]), :controller => AuthHelper::get_home_controller(session[:user]))
else
#list method's implementation
end
end
</pre>

===Instance Variable Reductions===
It is a bad practice to have more than one instance variables in a controller action as it indicates towards increased coupling. We want to reduce the coupling as much as possible and view should have direct access to as few instance variables as possible. Helper methods should be defined in controllers through which the view can access variables of the controller class. The code has been refactored to make use of helper methods for the instance variables in index action.

Before Refactoring

users_controller.rb
<pre>

def get_role
if @user && @user.role_id
@role = Role.find(@user.role_id)
elsif @user
@role = Role.new(:id => nil, :name => '(none)')
end
end
</pre>

show.html.erb

<pre>
<tr><th>Role:</th>
<td><%= link_to @role.name, :controller => 'roles',
:action => 'show', :id => @role.id %></td>
</tr>
</pre>

After Refactoring

users_controller.rb
<pre>
def get_role
if @user && @user.role_id
role = Role.find(@user.role_id)
elsif @user
role = Role.new(id: nil, name: '(none)')
end
return role
end
</pre>

show.html.erb

<pre>
<tr><th>Role:</th>
<td><%= link_to get_role.name, :controller => 'roles',
:action => 'show', :id => get_role.id %></td>
</tr>

</table>
</pre>

===Code Cleanup===
Code cleanup in the controller so that the code conforms closely to Rails conventions and enhanced readability of code.
* Replaced String concats with #{} in paginate_list
Before Refactoring :

<pre>
#paginate_list
search_filter = letter + '%'
search_filter = '%' + letter + '%'
</pre>

After Refactoring :

<pre>
#paginate_list
search_filter = "#{letter}%"
search_filter = "%#{letter}%"
</pre>

* Replaced '==' with eql?
Before Refactoring :
<pre>
#index
if (current_user_role? == "Student")
...
letter == nil

#show_selection
@role.parent_id == nil || @role.parent_id < (session[:user]).role_id || @user.id == (session[:user]).id

#show
if (params[:id].nil?) || ((current_user_role? == "Student") && (session[:user].id != params[:id].to_i))

#create
if @user.role.name == "Instructor" or @user.role.name == "Administrator"

#keys
if (params[:id].nil?) || ((current_user_role? == "Student") && (session[:user].id != params[:id].to_i))

#paginate_list
if @search_by == '1'
</pre>

After Refactoring :
<pre>
#index
if (current_user_role.eql? "Student")
...
if letter.eql? nil

#show_selection
if role.parent_id.eql? nil || role.parent_id < (session[:user]).role_id || @user.id.eql?(session[:user]).id

#show
if (params[:id].nil?) || ((current_user_role.eql? "Student") && (session[:user].id != params[:id].to_i))

#create
if @user.role.name.eql? "Instructor" or @user.role.name.eql? "Administrator"

#keys
if (params[:id].nil?) || ((current_user_role.eql? "Student") && (session[:user].id != params[:id].to_i))

#paginate_list
if @search_by.eql? '1' #search by user name
</pre>

* Replaced :key =>'value' with key: 'value'

Before Refactoring :
<pre>
#index
redirect_to(:action => AuthHelper::get_home_action(session[:user]), :controller => AuthHelper::get_home_controller(session[:user]))

#show_selection
render :action => 'show'

#create
AssignmentQuestionnaire.create(:user_id => @user.id)
</pre>

After Refactoring :
<pre>
#index
redirect_to(action: AuthHelper::get_home_action(session[:user]), controller: AuthHelper::get_home_controller(session[:user]))

#show_selection
render action: 'show'

#create
AssignmentQuestionnaire.create(user_id: @user.id)
</pre>

*Modified declarations of Arrays and Hashes
Before Refactoring :
<pre>
#index
@letters = Array.new

#paginate_list
paginate_options = {"1" => 25, "2" => 50, "3" => 100}
</pre>

After Refactoring :
<pre>
#index
@letters =[]

#paginate_list
paginate_options = Hash["1" ,25 , "2", 50, "3", 100]
</pre>

*Removed unused methods like self.participants_in and commented out code.

===Use of Routing Helpers===
Routing helpers are a simpler alternative to the otherwise complex hard coded URLs which reduce the readability of the code.Routing helpers allow us to declare possible common routes for a given controller. Routing helpers have been implemented since they maintain consistency even if changes are made to the routing paths.

Before Refactoring:
 
<pre>
def show_selection
@user = User.find_by_name(params[:user][:name])
if @user != nil
get_role
if @role.parent_id == nil || @role.parent_id < (session[:user]).role_id || @user.id == (session[:user]).id
render :action => 'show'
else
flash[:note] = 'The specified user is not available for editing.'
redirect_to :action => 'list'
end
else
flash[:note] = params[:user][:name]+' does not exist.'
redirect_to :action => 'list'
end
end
</pre>
 
After Refactoring
 
<pre>
def show_selection
@user = User.where(name: params[:user][:name]).take
if @user != nil
role=get_role
if role.parent_id.eql? nil || role.parent_id < (session[:user]).role_id || @user.id.eql?(session[:user]).id
render action: 'show'
else
flash[:note] = 'The specified user is not available for editing.'
redirect_to users_path #Replaced URL with routing helper
end
else
flash[:note] = params[:user][:name]+' does not exist.'
redirect_to users_path #Replaced URL with routing helper
end
end
</pre>
 

===Replace find_by_.. with where in querying===
Rails 4 conventions dictate the use of 'where()' over the use of 'find_by_...' methods while querying ActiveRecords. The code has been refactored to replace the usages of find_by.. with where().

Before Refactoring
<pre>
def show_selection
@user = User.find_by_name(params[:user][:name])
if @user != nil
</pre>

After Refactoring
<pre>
def show_selection
@user = User.where(name: params[:user][:name]).take
if @user != nil
</pre>

==References==
[https://github.com/ameyp1992/expertiza.git Git Repository]

[http://wiki.expertiza.ncsu.edu/index.php/Development:Setup:Linux:Debian Expertiza Setup]

[https://docs.google.com/document/d/1FZCL9KWSdVNsX9BowuZ3gxbCOJoiWX-GVLctSZei3No/edit?pli=1#heading=h.2y12n9sli9rd Project requirements]
<references/>

CSC/ECE 517 Fall 2014/oss E1465 oak

2014-10-29T04:36:18Z

Knimgao: /* Introduction */

=Expertiza - Refactoring UsersController=

__TOC__

==Introduction==
Expertiza<ref name="expertiza>''Expertiza'' http://wikis.lib.ncsu.edu/index.php/Expertiza</ref> is a web application available to both students and professors. The Expertiza project is a system to create reusable learning objects through peer review. Expertiza supports team projects and the submission of almost any document type, including URLs and wiki pages. Students can keep a track of their assignments, teammates and can conduct peer reviews on diverse topics and projects. It is an open source project developed on Ruby on Rails platform. More information on Expertiza can be found [https://github.com/expertiza/expertiza here]. The source code can be forked and cloned for making modifications.

As a part of the coursework of Object Oriented Design and Development, we were expected to refactor the funtionality of some modules of Expertiza. This wiki provides an insight into our contributions to the Open Source Software project 'Expertiza' by Refactoring the Users Controller.

==Project Description==
The Users Controller deals with managing activities peripheral to the User registered with Expertiza. Users are mapped to different roles like super-admin, admin, instructor, teaching assistant and student with each role having different access permissions. The Manage Users module can be accessed by roles other than the student. It provides users with the functionality to search other users based on keywords like username, email, etc. New user can be created and existing user information and role can be updated.

Classes : users_controller.rb 
What it does : Manage Users i.e.search and list users, create new user, edit/update existing users, delete users. 
What has to be changed : 
* Modify methods to conform to RESTful style
* Reducing the number of instance variables per action to one
* Code cleanup by using string interpolation instead of concatenation, replacing '==' with eql? and :key =>'value' with key: 'value', modifying declarations of Arrays and Hashes,removing commented out code
* Use of routing helpers instead of hardcoded URLs
* Replace find_by with where to follow Rails 4.0 conventions

Original lines of code : 243

Lines after refactoring: 225

==Modification to Existing Code==

===RESTful style implementation===
* Modifications to users_controller.rb : The purpose of the index method in Users Controller is to list all registered users. The list method was called from the index method to list all users. This implementation did not conform to RESTful guidelines. Hence, we refactored the list method in users controller to index. Further, we refactored all the references of list method in UserControllers, Users views, Users tests and routes.rb to index method.

Before Refactoring :
<pre>
def index
if (current_user_role? == "Student")
redirect_to(:action => AuthHelper::get_home_action(session[:user]), :controller => AuthHelper::get_home_controller(session[:user]))
else
list
render :action => 'list'
end
end

#for displaying the list of users
def list
user = session[:user]
role = Role.find(user.role_id)
all_users = User.order('name').where( ['role_id in (?) or id = ?', role.get_available_roles, user.id])

letter = params[:letter]
session[:letter] = letter
if letter == nil
letter = all_users.first.name[0,1].downcase
end
logger.info "#{letter}"
@letters = Array.new

@per_page = 1

# Check if the "Show" button for pagination is clicked
# If yes, set @per_page to the value of the selection dropdown
# Else, if the request is from one of the letter links on the top
# set @per_page to 1 (25 names per page).
# Else, set @per_page to the :num_users param passed in from
# the will_paginate method from the 'pagination' partial.
if params[:paginate_show]
@per_page = params[:num_users]
elsif params[:from_letter]
@per_page = 1
else
@per_page = params[:num_users]
end

# Get the users list to show on current page
@users = paginate_list(role, user.id, letter)

@letters = ('A'..'Z').to_a
end
</pre>

After Refactoring :

<pre>
#for displaying the list of users
def index
if (current_user_role? == "Student")
redirect_to(:action => AuthHelper::get_home_action(session[:user]), :controller => AuthHelper::get_home_controller(session[:user]))
else
#list method's implementation
end
end
</pre>

===Instance Variable Reductions===
It is a bad practice to have more than one instance variables in a controller action as it indicates towards increased coupling. We want to reduce the coupling as much as possible and view should have direct access to as few instance variables as possible. Helper methods should be defined in controllers through which the view can access variables of the controller class. The code has been refactored to make use of helper methods for the instance variables in index action.

Before Refactoring

users_controller.rb
<pre>

def get_role
if @user && @user.role_id
@role = Role.find(@user.role_id)
elsif @user
@role = Role.new(:id => nil, :name => '(none)')
end
end
</pre>

show.html.erb

<pre>
<tr><th>Role:</th>
<td><%= link_to @role.name, :controller => 'roles',
:action => 'show', :id => @role.id %></td>
</tr>
</pre>

After Refactoring

users_controller.rb
<pre>
def get_role
if @user && @user.role_id
role = Role.find(@user.role_id)
elsif @user
role = Role.new(id: nil, name: '(none)')
end
return role
end
</pre>

show.html.erb

<pre>
<tr><th>Role:</th>
<td><%= link_to get_role.name, :controller => 'roles',
:action => 'show', :id => get_role.id %></td>
</tr>

</table>
</pre>

===Code Cleanup===
Code cleanup in the controller so that the code conforms closely to Rails conventions and enhanced readability of code.
* Replaced String concats with #{} in paginate_list
Before Refactoring :

<pre>
#paginate_list
search_filter = letter + '%'
search_filter = '%' + letter + '%'
</pre>

After Refactoring :

<pre>
#paginate_list
search_filter = "#{letter}%"
search_filter = "%#{letter}%"
</pre>

* Replaced '==' with eql?
Before Refactoring :
<pre>
#index
if (current_user_role? == "Student")
...
letter == nil

#show_selection
@role.parent_id == nil || @role.parent_id < (session[:user]).role_id || @user.id == (session[:user]).id

#show
if (params[:id].nil?) || ((current_user_role? == "Student") && (session[:user].id != params[:id].to_i))

#create
if @user.role.name == "Instructor" or @user.role.name == "Administrator"

#keys
if (params[:id].nil?) || ((current_user_role? == "Student") && (session[:user].id != params[:id].to_i))

#paginate_list
if @search_by == '1'
</pre>

After Refactoring :
<pre>
#index
if (current_user_role.eql? "Student")
...
if letter.eql? nil

#show_selection
if role.parent_id.eql? nil || role.parent_id < (session[:user]).role_id || @user.id.eql?(session[:user]).id

#show
if (params[:id].nil?) || ((current_user_role.eql? "Student") && (session[:user].id != params[:id].to_i))

#create
if @user.role.name.eql? "Instructor" or @user.role.name.eql? "Administrator"

#keys
if (params[:id].nil?) || ((current_user_role.eql? "Student") && (session[:user].id != params[:id].to_i))

#paginate_list
if @search_by.eql? '1' #search by user name
</pre>

* Replaced :key =>'value' with key: 'value'

Before Refactoring :
<pre>
#index
redirect_to(:action => AuthHelper::get_home_action(session[:user]), :controller => AuthHelper::get_home_controller(session[:user]))

#show_selection
render :action => 'show'

#create
AssignmentQuestionnaire.create(:user_id => @user.id)
</pre>

After Refactoring :
<pre>
#index
redirect_to(action: AuthHelper::get_home_action(session[:user]), controller: AuthHelper::get_home_controller(session[:user]))

#show_selection
render action: 'show'

#create
AssignmentQuestionnaire.create(user_id: @user.id)
</pre>

*Modified declarations of Arrays and Hashes
Before Refactoring :
<pre>
#index
@letters = Array.new

#paginate_list
paginate_options = {"1" => 25, "2" => 50, "3" => 100}
</pre>

After Refactoring :
<pre>
#index
@letters =[]

#paginate_list
paginate_options = Hash["1" ,25 , "2", 50, "3", 100]
</pre>

*Removed unused methods like self.participants_in and commented out code.

===Use of Routing Helpers===
Routing helpers are a simpler alternative to the otherwise complex hard coded URLs which reduce the readability of the code.Routing helpers allow us to declare possible common routes for a given controller. Routing helpers have been implemented since they maintain consistency even if changes are made to the routing paths.

Before Refactoring:
 
<pre>
def show_selection
@user = User.find_by_name(params[:user][:name])
if @user != nil
get_role
if @role.parent_id == nil || @role.parent_id < (session[:user]).role_id || @user.id == (session[:user]).id
render :action => 'show'
else
flash[:note] = 'The specified user is not available for editing.'
redirect_to :action => 'list'
end
else
flash[:note] = params[:user][:name]+' does not exist.'
redirect_to :action => 'list'
end
end
</pre>
 
After Refactoring
 
<pre>
def show_selection
@user = User.where(name: params[:user][:name]).take
if @user != nil
role=get_role
if role.parent_id.eql? nil || role.parent_id < (session[:user]).role_id || @user.id.eql?(session[:user]).id
render action: 'show'
else
flash[:note] = 'The specified user is not available for editing.'
redirect_to users_path #Replaced URL with routing helper
end
else
flash[:note] = params[:user][:name]+' does not exist.'
redirect_to users_path #Replaced URL with routing helper
end
end
</pre>
 

===Replace find_by_.. with where in querying===
Rails 4 conventions dictate the use of 'where()' over the use of 'find_by_...' methods while querying ActiveRecords. The code has been refactored to replace the usages of find_by.. with where().

Before Refactoring
<pre>
def show_selection
@user = User.find_by_name(params[:user][:name])
if @user != nil
</pre>

After Refactoring
<pre>
def show_selection
@user = User.where(name: params[:user][:name]).take
if @user != nil
</pre>

==References==
[https://github.com/ameyp1992/expertiza.git Git Repository]

[http://wiki.expertiza.ncsu.edu/index.php/Development:Setup:Linux:Debian Expertiza Setup]

[https://docs.google.com/document/d/1FZCL9KWSdVNsX9BowuZ3gxbCOJoiWX-GVLctSZei3No/edit?pli=1#heading=h.2y12n9sli9rd Project requirements]
<references/>

CSC/ECE 517 Fall 2014/oss E1465 oak

2014-10-29T04:32:38Z

Knimgao: /* Introduction */

=Expertiza - Refactoring UsersController=

__TOC__

==Introduction==
Expertiza<ref name="expertiza>''Expertiza'' http://wikis.lib.ncsu.edu/index.php/Expertiza</ref> is a web application available to both students and professors. The Expertiza project is a system to create reusable learning objects through peer review. Expertiza supports team projects and the submission of almost any document type, including URLs and wiki pages. Students can keep a track of their assignments, teammates and can conduct peer reviews on diverse topics and projects. It is an open source project developed on Ruby on Rails platform. More information on Expertiza can be found [https://github.com/expertiza/expertiza here]. The source code can be forked and cloned for making modifications.

As a part of the coursework of Object Oriented Design and Development, we were expected to refactor the funtionality of some modules of Expertiza. This wiki provides an insight into our contributions to the Open Source Software project Expertiza with main focus of Refactoring the Users Controller.

==Project Description==
The Users Controller deals with managing activities peripheral to the User registered with Expertiza. Users are mapped to different roles like super-admin, admin, instructor, teaching assistant and student with each role having different access permissions. The Manage Users module can be accessed by roles other than the student. It provides users with the functionality to search other users based on keywords like username, email, etc. New user can be created and existing user information and role can be updated.

Classes : users_controller.rb 
What it does : Manage Users i.e.search and list users, create new user, edit/update existing users, delete users. 
What has to be changed : 
* Modify methods to conform to RESTful style
* Reducing the number of instance variables per action to one
* Code cleanup by using string interpolation instead of concatenation, replacing '==' with eql? and :key =>'value' with key: 'value', modifying declarations of Arrays and Hashes,removing commented out code
* Use of routing helpers instead of hardcoded URLs
* Replace find_by with where to follow Rails 4.0 conventions

Original lines of code : 243

Lines after refactoring: 225

==Modification to Existing Code==

===RESTful style implementation===
* Modifications to users_controller.rb : The purpose of the index method in Users Controller is to list all registered users. The list method was called from the index method to list all users. This implementation did not conform to RESTful guidelines. Hence, we refactored the list method in users controller to index. Further, we refactored all the references of list method in UserControllers, Users views, Users tests and routes.rb to index method.

Before Refactoring :
<pre>
def index
if (current_user_role? == "Student")
redirect_to(:action => AuthHelper::get_home_action(session[:user]), :controller => AuthHelper::get_home_controller(session[:user]))
else
list
render :action => 'list'
end
end

#for displaying the list of users
def list
user = session[:user]
role = Role.find(user.role_id)
all_users = User.order('name').where( ['role_id in (?) or id = ?', role.get_available_roles, user.id])

letter = params[:letter]
session[:letter] = letter
if letter == nil
letter = all_users.first.name[0,1].downcase
end
logger.info "#{letter}"
@letters = Array.new

@per_page = 1

# Check if the "Show" button for pagination is clicked
# If yes, set @per_page to the value of the selection dropdown
# Else, if the request is from one of the letter links on the top
# set @per_page to 1 (25 names per page).
# Else, set @per_page to the :num_users param passed in from
# the will_paginate method from the 'pagination' partial.
if params[:paginate_show]
@per_page = params[:num_users]
elsif params[:from_letter]
@per_page = 1
else
@per_page = params[:num_users]
end

# Get the users list to show on current page
@users = paginate_list(role, user.id, letter)

@letters = ('A'..'Z').to_a
end
</pre>

After Refactoring :

<pre>
#for displaying the list of users
def index
if (current_user_role? == "Student")
redirect_to(:action => AuthHelper::get_home_action(session[:user]), :controller => AuthHelper::get_home_controller(session[:user]))
else
#list method's implementation
end
end
</pre>

===Instance Variable Reductions===
It is a bad practice to have more than one instance variables in a controller action as it indicates towards increased coupling. We want to reduce the coupling as much as possible and view should have direct access to as few instance variables as possible. Helper methods should be defined in controllers through which the view can access variables of the controller class. The code has been refactored to make use of helper methods for the instance variables in index action.

Before Refactoring

users_controller.rb
<pre>

def get_role
if @user && @user.role_id
@role = Role.find(@user.role_id)
elsif @user
@role = Role.new(:id => nil, :name => '(none)')
end
end
</pre>

show.html.erb

<pre>
<tr><th>Role:</th>
<td><%= link_to @role.name, :controller => 'roles',
:action => 'show', :id => @role.id %></td>
</tr>
</pre>

After Refactoring

users_controller.rb
<pre>
def get_role
if @user && @user.role_id
role = Role.find(@user.role_id)
elsif @user
role = Role.new(id: nil, name: '(none)')
end
return role
end
</pre>

show.html.erb

<pre>
<tr><th>Role:</th>
<td><%= link_to get_role.name, :controller => 'roles',
:action => 'show', :id => get_role.id %></td>
</tr>

</table>
</pre>

===Code Cleanup===
Code cleanup in the controller so that the code conforms closely to Rails conventions and enhanced readability of code.
* Replaced String concats with #{} in paginate_list
Before Refactoring :

<pre>
#paginate_list
search_filter = letter + '%'
search_filter = '%' + letter + '%'
</pre>

After Refactoring :

<pre>
#paginate_list
search_filter = "#{letter}%"
search_filter = "%#{letter}%"
</pre>

* Replaced '==' with eql?
Before Refactoring :
<pre>
#index
if (current_user_role? == "Student")
...
letter == nil

#show_selection
@role.parent_id == nil || @role.parent_id < (session[:user]).role_id || @user.id == (session[:user]).id

#show
if (params[:id].nil?) || ((current_user_role? == "Student") && (session[:user].id != params[:id].to_i))

#create
if @user.role.name == "Instructor" or @user.role.name == "Administrator"

#keys
if (params[:id].nil?) || ((current_user_role? == "Student") && (session[:user].id != params[:id].to_i))

#paginate_list
if @search_by == '1'
</pre>

After Refactoring :
<pre>
#index
if (current_user_role.eql? "Student")
...
if letter.eql? nil

#show_selection
if role.parent_id.eql? nil || role.parent_id < (session[:user]).role_id || @user.id.eql?(session[:user]).id

#show
if (params[:id].nil?) || ((current_user_role.eql? "Student") && (session[:user].id != params[:id].to_i))

#create
if @user.role.name.eql? "Instructor" or @user.role.name.eql? "Administrator"

#keys
if (params[:id].nil?) || ((current_user_role.eql? "Student") && (session[:user].id != params[:id].to_i))

#paginate_list
if @search_by.eql? '1' #search by user name
</pre>

* Replaced :key =>'value' with key: 'value'

Before Refactoring :
<pre>
#index
redirect_to(:action => AuthHelper::get_home_action(session[:user]), :controller => AuthHelper::get_home_controller(session[:user]))

#show_selection
render :action => 'show'

#create
AssignmentQuestionnaire.create(:user_id => @user.id)
</pre>

After Refactoring :
<pre>
#index
redirect_to(action: AuthHelper::get_home_action(session[:user]), controller: AuthHelper::get_home_controller(session[:user]))

#show_selection
render action: 'show'

#create
AssignmentQuestionnaire.create(user_id: @user.id)
</pre>

*Modified declarations of Arrays and Hashes
Before Refactoring :
<pre>
#index
@letters = Array.new

#paginate_list
paginate_options = {"1" => 25, "2" => 50, "3" => 100}
</pre>

After Refactoring :
<pre>
#index
@letters =[]

#paginate_list
paginate_options = Hash["1" ,25 , "2", 50, "3", 100]
</pre>

*Removed unused methods like self.participants_in and commented out code.

===Use of Routing Helpers===
Routing helpers are a simpler alternative to the otherwise complex hard coded URLs which reduce the readability of the code.Routing helpers allow us to declare possible common routes for a given controller. Routing helpers have been implemented since they maintain consistency even if changes are made to the routing paths.

Before Refactoring:
 
<pre>
def show_selection
@user = User.find_by_name(params[:user][:name])
if @user != nil
get_role
if @role.parent_id == nil || @role.parent_id < (session[:user]).role_id || @user.id == (session[:user]).id
render :action => 'show'
else
flash[:note] = 'The specified user is not available for editing.'
redirect_to :action => 'list'
end
else
flash[:note] = params[:user][:name]+' does not exist.'
redirect_to :action => 'list'
end
end
</pre>
 
After Refactoring
 
<pre>
def show_selection
@user = User.where(name: params[:user][:name]).take
if @user != nil
role=get_role
if role.parent_id.eql? nil || role.parent_id < (session[:user]).role_id || @user.id.eql?(session[:user]).id
render action: 'show'
else
flash[:note] = 'The specified user is not available for editing.'
redirect_to users_path #Replaced URL with routing helper
end
else
flash[:note] = params[:user][:name]+' does not exist.'
redirect_to users_path #Replaced URL with routing helper
end
end
</pre>
 

===Replace find_by_.. with where in querying===
Rails 4 conventions dictate the use of 'where()' over the use of 'find_by_...' methods while querying ActiveRecords. The code has been refactored to replace the usages of find_by.. with where().

Before Refactoring
<pre>
def show_selection
@user = User.find_by_name(params[:user][:name])
if @user != nil
</pre>

After Refactoring
<pre>
def show_selection
@user = User.where(name: params[:user][:name]).take
if @user != nil
</pre>

==References==
[https://github.com/ameyp1992/expertiza.git Git Repository]

[http://wiki.expertiza.ncsu.edu/index.php/Development:Setup:Linux:Debian Expertiza Setup]

[https://docs.google.com/document/d/1FZCL9KWSdVNsX9BowuZ3gxbCOJoiWX-GVLctSZei3No/edit?pli=1#heading=h.2y12n9sli9rd Project requirements]
<references/>

CSC/ECE 517 Fall 2014/oss E1465 oak

2014-10-25T04:49:09Z

Knimgao: /* Replace find_by_.. by where in querying */

=Expertiza - Refactoring UsersController=

__TOC__

==Introduction==
Expertiza<ref name="expertiza>''Expertiza'' http://wikis.lib.ncsu.edu/index.php/Expertiza</ref> is a web application available to both students and professors. The Expertiza project is a system to create reusable learning objects through peer review. Expertiza supports team projects, and the submission of almost any document type, including URLs and wiki pages. Students can keep a track of their assignments, teammates and can conduct peer reviews on diverse topics and projects. It is an open source project developed on Ruby on Rails platform. More information on Expertiza can be found [https://github.com/expertiza/expertiza here]. The source code can be forked and cloned for making modifications.

As a part of the coursework of Object Oriented Design and Development, we were expected to refactor the funtionality of some modules of Expertiza. This wiki provides an insight into our contributions to the Open Source Software project Expertiza with main focus of Refactoring the Users Controller.

==Project Description==
The Users Controller deals with managing activities peripheral to the User registered with Expertiza. Users are mapped to different roles like super-admin, admin, instructor, teaching assistant and student with each role having different access permissions. The Manage Users module can be accessed by roles other than the student. It provides users with the functionality to search other users based on keywords like username, email, etc. New user can be created and existing user information and role can be updated.

Classes : users_controller.rb 
What it does : Manage Users i.e.search and list users, create new user, edit/update existing users, delete users. 
What has to be changed : 
* Modify methods to conform to RESTful style
* Reducing the number of instance variables per action to one
* Code cleanup by using string interpolation instead of concatenation, replacing '==' with eql? and :key =>'value' with key: 'value', modifying declarations of Arrays and Hashes,removing commented out code
* Use of routing helpers instead of hardcoded URLs
* Replace find_by with where to follow Rails 4.0 conventions

==Modification to Existing Code==

===RESTful style implementation===
* Modifications to users_controller.rb : The purpose of the index method in Users Controller is to list all registered users. The list method was called from the index method to list all users. This implementation did not conform to RESTful guidelines. Hence, we refactored the list method in users controller to index. Further, we refactored all the references of list method in UserControllers, Users views, Users tests and routes.rb to index method.

Before Refactoring :
<pre>
def index
if (current_user_role? == "Student")
redirect_to(:action => AuthHelper::get_home_action(session[:user]), :controller => AuthHelper::get_home_controller(session[:user]))
else
list
render :action => 'list'
end
end

#for displaying the list of users
def list
user = session[:user]
role = Role.find(user.role_id)
all_users = User.order('name').where( ['role_id in (?) or id = ?', role.get_available_roles, user.id])

letter = params[:letter]
session[:letter] = letter
if letter == nil
letter = all_users.first.name[0,1].downcase
end
logger.info "#{letter}"
@letters = Array.new

@per_page = 1

# Check if the "Show" button for pagination is clicked
# If yes, set @per_page to the value of the selection dropdown
# Else, if the request is from one of the letter links on the top
# set @per_page to 1 (25 names per page).
# Else, set @per_page to the :num_users param passed in from
# the will_paginate method from the 'pagination' partial.
if params[:paginate_show]
@per_page = params[:num_users]
elsif params[:from_letter]
@per_page = 1
else
@per_page = params[:num_users]
end

# Get the users list to show on current page
@users = paginate_list(role, user.id, letter)

@letters = ('A'..'Z').to_a
end
</pre>

After Refactoring :

<pre>
#for displaying the list of users
def index
if (current_user_role? == "Student")
redirect_to(:action => AuthHelper::get_home_action(session[:user]), :controller => AuthHelper::get_home_controller(session[:user]))
else
#list method's implementation
end
end
</pre>

===Instance Variable Reductions===
It is a bad practice to have more than one instance variables in a controller action as it indicates towards increased coupling. We want to reduce the coupling as much as possible and view should have direct access to as few instance variables as possible. Helper methods should be defined in controllers through which the view can access variables of the controller class. The code has been refactored to make use of helper methods for the instance variables in index action.

Before Refactoring

users_controller.rb
<pre>

def get_role
if @user && @user.role_id
@role = Role.find(@user.role_id)
elsif @user
@role = Role.new(:id => nil, :name => '(none)')
end
end
</pre>

show.html.erb

<pre>
<tr><th>Role:</th>
<td><%= link_to @role.name, :controller => 'roles',
:action => 'show', :id => @role.id %></td>
</tr>
</pre>

After Refactoring

users_controller.rb
<pre>
def get_role
if @user && @user.role_id
role = Role.find(@user.role_id)
elsif @user
role = Role.new(id: nil, name: '(none)')
end
return role
end
</pre>

show.html.erb

<pre>
<tr><th>Role:</th>
<td><%= link_to get_role.name, :controller => 'roles',
:action => 'show', :id => get_role.id %></td>
</tr>

</table>
</pre>

===Code Cleanup===
Code cleanup in the controller so that the code conforms closely to Rails conventions and enhanced readability of code.
* Replaced String concats with #{} in paginate_list
Before Refactoring :

<pre>
#paginate_list
search_filter = letter + '%'
search_filter = '%' + letter + '%'
</pre>

After Refactoring :

<pre>
#paginate_list
search_filter = "#{letter}%"
search_filter = "%#{letter}%"
</pre>

* Replaced '==' with eql?
Before Refactoring :
<pre>
#index
if (current_user_role? == "Student")
...
letter == nil

#show_selection
@role.parent_id == nil || @role.parent_id < (session[:user]).role_id || @user.id == (session[:user]).id

#show
if (params[:id].nil?) || ((current_user_role? == "Student") && (session[:user].id != params[:id].to_i))

#create
if @user.role.name == "Instructor" or @user.role.name == "Administrator"

#keys
if (params[:id].nil?) || ((current_user_role? == "Student") && (session[:user].id != params[:id].to_i))

#paginate_list
if @search_by == '1'
</pre>

After Refactoring :
<pre>
#index
if (current_user_role.eql? "Student")
...
if letter.eql? nil

#show_selection
if role.parent_id.eql? nil || role.parent_id < (session[:user]).role_id || @user.id.eql?(session[:user]).id

#show
if (params[:id].nil?) || ((current_user_role.eql? "Student") && (session[:user].id != params[:id].to_i))

#create
if @user.role.name.eql? "Instructor" or @user.role.name.eql? "Administrator"

#keys
if (params[:id].nil?) || ((current_user_role.eql? "Student") && (session[:user].id != params[:id].to_i))

#paginate_list
if @search_by.eql? '1' #search by user name
</pre>

* Replaced :key =>'value' with key: 'value'

Before Refactoring :
<pre>
#index
redirect_to(:action => AuthHelper::get_home_action(session[:user]), :controller => AuthHelper::get_home_controller(session[:user]))

#show_selection
render :action => 'show'

#create
AssignmentQuestionnaire.create(:user_id => @user.id)
</pre>

After Refactoring :
<pre>
#index
redirect_to(action: AuthHelper::get_home_action(session[:user]), controller: AuthHelper::get_home_controller(session[:user]))

#show_selection
render action: 'show'

#create
AssignmentQuestionnaire.create(user_id: @user.id)
</pre>

==Use of Routing Helpers==
Routing helpers are a simpler alternative to the otherwise complex hard coded URLs which reduce the readability of the code.Routing helpers allow us to declare possible common routes for a given controller. Routing helpers have been implemented since they maintain consistency even if changes are made to the routing paths.

Before Refactoring:
 
<pre>
def show_selection
@user = User.find_by_name(params[:user][:name])
if @user != nil
get_role
if @role.parent_id == nil || @role.parent_id < (session[:user]).role_id || @user.id == (session[:user]).id
render :action => 'show'
else
flash[:note] = 'The specified user is not available for editing.'
redirect_to :action => 'list'
end
else
flash[:note] = params[:user][:name]+' does not exist.'
redirect_to :action => 'list'
end
end
</pre>
 
After Refactoring
 
<pre>
def show_selection
@user = User.where(name: params[:user][:name]).take
if @user != nil
role=get_role
if role.parent_id.eql? nil || role.parent_id < (session[:user]).role_id || @user.id.eql?(session[:user]).id
render action: 'show'
else
flash[:note] = 'The specified user is not available for editing.'
redirect_to users_path #Replaced URL with routing helper
end
else
flash[:note] = params[:user][:name]+' does not exist.'
redirect_to users_path #Replaced URL with routing helper
end
end
</pre>
 

==Replace find_by_.. with where in querying==
Rails 4 conventions dictate the use of 'where()' over the use of 'find_by_...' methods while querying ActiveRecords. The code has been refactored to replace the usages of find_by.. with where().

Before Refactoring
<pre>
def show_selection
@user = User.find_by_name(params[:user][:name])
if @user != nil
</pre>

After Refactoring
<pre>
def show_selection
@user = User.where(name: params[:user][:name]).take
if @user != nil
</pre>

==References==
<references/>

CSC/ECE 517 Fall 2014/oss E1465 oak

2014-10-25T04:47:48Z

Knimgao: /* Replace find_by_.. by where in querying */

=Expertiza - Refactoring UsersController=

__TOC__

==Introduction==
Expertiza<ref name="expertiza>''Expertiza'' http://wikis.lib.ncsu.edu/index.php/Expertiza</ref> is a web application available to both students and professors. The Expertiza project is a system to create reusable learning objects through peer review. Expertiza supports team projects, and the submission of almost any document type, including URLs and wiki pages. Students can keep a track of their assignments, teammates and can conduct peer reviews on diverse topics and projects. It is an open source project developed on Ruby on Rails platform. More information on Expertiza can be found [https://github.com/expertiza/expertiza here]. The source code can be forked and cloned for making modifications.

As a part of the coursework of Object Oriented Design and Development, we were expected to refactor the funtionality of some modules of Expertiza. This wiki provides an insight into our contributions to the Open Source Software project Expertiza with main focus of Refactoring the Users Controller.

==Project Description==
The Users Controller deals with managing activities peripheral to the User registered with Expertiza. Users are mapped to different roles like super-admin, admin, instructor, teaching assistant and student with each role having different access permissions. The Manage Users module can be accessed by roles other than the student. It provides users with the functionality to search other users based on keywords like username, email, etc. New user can be created and existing user information and role can be updated.

Classes : users_controller.rb 
What it does : Manage Users i.e.search and list users, create new user, edit/update existing users, delete users. 
What has to be changed : 
* Modify methods to conform to RESTful style
* Reducing the number of instance variables per action to one
* Code cleanup by using string interpolation instead of concatenation, replacing '==' with eql? and :key =>'value' with key: 'value', modifying declarations of Arrays and Hashes,removing commented out code
* Use of routing helpers instead of hardcoded URLs
* Replace find_by with where to follow Rails 4.0 conventions

==Modification to Existing Code==

===RESTful style implementation===
* Modifications to users_controller.rb : The purpose of the index method in Users Controller is to list all registered users. The list method was called from the index method to list all users. This implementation did not conform to RESTful guidelines. Hence, we refactored the list method in users controller to index. Further, we refactored all the references of list method in UserControllers, Users views, Users tests and routes.rb to index method.

Before Refactoring :
<pre>
def index
if (current_user_role? == "Student")
redirect_to(:action => AuthHelper::get_home_action(session[:user]), :controller => AuthHelper::get_home_controller(session[:user]))
else
list
render :action => 'list'
end
end

#for displaying the list of users
def list
user = session[:user]
role = Role.find(user.role_id)
all_users = User.order('name').where( ['role_id in (?) or id = ?', role.get_available_roles, user.id])

letter = params[:letter]
session[:letter] = letter
if letter == nil
letter = all_users.first.name[0,1].downcase
end
logger.info "#{letter}"
@letters = Array.new

@per_page = 1

# Check if the "Show" button for pagination is clicked
# If yes, set @per_page to the value of the selection dropdown
# Else, if the request is from one of the letter links on the top
# set @per_page to 1 (25 names per page).
# Else, set @per_page to the :num_users param passed in from
# the will_paginate method from the 'pagination' partial.
if params[:paginate_show]
@per_page = params[:num_users]
elsif params[:from_letter]
@per_page = 1
else
@per_page = params[:num_users]
end

# Get the users list to show on current page
@users = paginate_list(role, user.id, letter)

@letters = ('A'..'Z').to_a
end
</pre>

After Refactoring :

<pre>
#for displaying the list of users
def index
if (current_user_role? == "Student")
redirect_to(:action => AuthHelper::get_home_action(session[:user]), :controller => AuthHelper::get_home_controller(session[:user]))
else
#list method's implementation
end
end
</pre>

===Instance Variable Reductions===
It is a bad practice to have more than one instance variables in a controller action as it indicates towards increased coupling. We want to reduce the coupling as much as possible and view should have direct access to as few instance variables as possible. Helper methods should be defined in controllers through which the view can access variables of the controller class. The code has been refactored to make use of helper methods for the instance variables in index action.

Before Refactoring

users_controller.rb
<pre>

def get_role
if @user && @user.role_id
@role = Role.find(@user.role_id)
elsif @user
@role = Role.new(:id => nil, :name => '(none)')
end
end
</pre>

show.html.erb

<pre>
<tr><th>Role:</th>
<td><%= link_to @role.name, :controller => 'roles',
:action => 'show', :id => @role.id %></td>
</tr>
</pre>

After Refactoring

users_controller.rb
<pre>
def get_role
if @user && @user.role_id
role = Role.find(@user.role_id)
elsif @user
role = Role.new(id: nil, name: '(none)')
end
return role
end
</pre>

show.html.erb

<pre>
<tr><th>Role:</th>
<td><%= link_to get_role.name, :controller => 'roles',
:action => 'show', :id => get_role.id %></td>
</tr>

</table>
</pre>

===Code Cleanup===
Code cleanup in the controller so that the code conforms closely to Rails conventions and enhanced readability of code.
* Replaced String concats with #{} in paginate_list
Before Refactoring :

<pre>
#paginate_list
search_filter = letter + '%'
search_filter = '%' + letter + '%'
</pre>

After Refactoring :

<pre>
#paginate_list
search_filter = "#{letter}%"
search_filter = "%#{letter}%"
</pre>

* Replaced '==' with eql?
Before Refactoring :
<pre>
#index
if (current_user_role? == "Student")
...
letter == nil

#show_selection
@role.parent_id == nil || @role.parent_id < (session[:user]).role_id || @user.id == (session[:user]).id

#show
if (params[:id].nil?) || ((current_user_role? == "Student") && (session[:user].id != params[:id].to_i))

#create
if @user.role.name == "Instructor" or @user.role.name == "Administrator"

#keys
if (params[:id].nil?) || ((current_user_role? == "Student") && (session[:user].id != params[:id].to_i))

#paginate_list
if @search_by == '1'
</pre>

After Refactoring :
<pre>
#index
if (current_user_role.eql? "Student")
...
if letter.eql? nil

#show_selection
if role.parent_id.eql? nil || role.parent_id < (session[:user]).role_id || @user.id.eql?(session[:user]).id

#show
if (params[:id].nil?) || ((current_user_role.eql? "Student") && (session[:user].id != params[:id].to_i))

#create
if @user.role.name.eql? "Instructor" or @user.role.name.eql? "Administrator"

#keys
if (params[:id].nil?) || ((current_user_role.eql? "Student") && (session[:user].id != params[:id].to_i))

#paginate_list
if @search_by.eql? '1' #search by user name
</pre>

* Replaced :key =>'value' with key: 'value'

Before Refactoring :
<pre>
#index
redirect_to(:action => AuthHelper::get_home_action(session[:user]), :controller => AuthHelper::get_home_controller(session[:user]))

#show_selection
render :action => 'show'

#create
AssignmentQuestionnaire.create(:user_id => @user.id)
</pre>

After Refactoring :
<pre>
#index
redirect_to(action: AuthHelper::get_home_action(session[:user]), controller: AuthHelper::get_home_controller(session[:user]))

#show_selection
render action: 'show'

#create
AssignmentQuestionnaire.create(user_id: @user.id)
</pre>

==Use of Routing Helpers==
Routing helpers are a simpler alternative to the otherwise complex hard coded URLs which reduce the readability of the code.Routing helpers allow us to declare possible common routes for a given controller. Routing helpers have been implemented since they maintain consistency even if changes are made to the routing paths.

Before Refactoring:
 
<pre>
def show_selection
@user = User.find_by_name(params[:user][:name])
if @user != nil
get_role
if @role.parent_id == nil || @role.parent_id < (session[:user]).role_id || @user.id == (session[:user]).id
render :action => 'show'
else
flash[:note] = 'The specified user is not available for editing.'
redirect_to :action => 'list'
end
else
flash[:note] = params[:user][:name]+' does not exist.'
redirect_to :action => 'list'
end
end
</pre>
 
After Refactoring
 
<pre>
def show_selection
@user = User.where(name: params[:user][:name]).take
if @user != nil
role=get_role
if role.parent_id.eql? nil || role.parent_id < (session[:user]).role_id || @user.id.eql?(session[:user]).id
render action: 'show'
else
flash[:note] = 'The specified user is not available for editing.'
redirect_to users_path #Replaced URL with routing helper
end
else
flash[:note] = params[:user][:name]+' does not exist.'
redirect_to users_path #Replaced URL with routing helper
end
end
</pre>
 

==Replace find_by_.. by where in querying==
Rails 4 conventions dictate the use of 'where()' over the use of 'find_by_...' methods while querying ActiveRecords. The code has been refactored to replace the usages of find_by.. with where().

Before Refactoring
<pre>
def show_selection
@user = User.find_by_name(params[:user][:name])
if @user != nil
</pre>

After Refactoring
<pre>
def show_selection
@user = User.where(name: params[:user][:name]).take
if @user != nil
</pre>

==References==
<references/>

CSC/ECE 517 Fall 2014/oss E1465 oak

2014-10-25T04:43:08Z

Knimgao:

=Expertiza - Refactoring UsersController=

__TOC__

==Introduction==
Expertiza<ref name="expertiza>''Expertiza'' http://wikis.lib.ncsu.edu/index.php/Expertiza</ref> is a web application available to both students and professors. The Expertiza project is a system to create reusable learning objects through peer review. Expertiza supports team projects, and the submission of almost any document type, including URLs and wiki pages. Students can keep a track of their assignments, teammates and can conduct peer reviews on diverse topics and projects. It is an open source project developed on Ruby on Rails platform. More information on Expertiza can be found [https://github.com/expertiza/expertiza here]. The source code can be forked and cloned for making modifications.

As a part of the coursework of Object Oriented Design and Development, we were expected to refactor the funtionality of some modules of Expertiza. This wiki provides an insight into our contributions to the Open Source Software project Expertiza with main focus of Refactoring the Users Controller.

==Project Description==
The Users Controller deals with managing activities peripheral to the User registered with Expertiza. Users are mapped to different roles like super-admin, admin, instructor, teaching assistant and student with each role having different access permissions. The Manage Users module can be accessed by roles other than the student. It provides users with the functionality to search other users based on keywords like username, email, etc. New user can be created and existing user information and role can be updated.

Classes : users_controller.rb 
What it does : Manage Users i.e.search and list users, create new user, edit/update existing users, delete users. 
What has to be changed : 
* Modify methods to conform to RESTful style
* Reducing the number of instance variables per action to one
* Code cleanup by using string interpolation instead of concatenation, replacing '==' with eql? and :key =>'value' with key: 'value', modifying declarations of Arrays and Hashes,removing commented out code
* Use of routing helpers instead of hardcoded URLs
* Replace find_by with where to follow Rails 4.0 conventions

==Modification to Existing Code==

===RESTful style implementation===
* Modifications to users_controller.rb : The purpose of the index method in Users Controller is to list all registered users. The list method was called from the index method to list all users. This implementation did not conform to RESTful guidelines. Hence, we refactored the list method in users controller to index. Further, we refactored all the references of list method in UserControllers, Users views, Users tests and routes.rb to index method.

Before Refactoring :
<pre>
def index
if (current_user_role? == "Student")
redirect_to(:action => AuthHelper::get_home_action(session[:user]), :controller => AuthHelper::get_home_controller(session[:user]))
else
list
render :action => 'list'
end
end

#for displaying the list of users
def list
user = session[:user]
role = Role.find(user.role_id)
all_users = User.order('name').where( ['role_id in (?) or id = ?', role.get_available_roles, user.id])

letter = params[:letter]
session[:letter] = letter
if letter == nil
letter = all_users.first.name[0,1].downcase
end
logger.info "#{letter}"
@letters = Array.new

@per_page = 1

# Check if the "Show" button for pagination is clicked
# If yes, set @per_page to the value of the selection dropdown
# Else, if the request is from one of the letter links on the top
# set @per_page to 1 (25 names per page).
# Else, set @per_page to the :num_users param passed in from
# the will_paginate method from the 'pagination' partial.
if params[:paginate_show]
@per_page = params[:num_users]
elsif params[:from_letter]
@per_page = 1
else
@per_page = params[:num_users]
end

# Get the users list to show on current page
@users = paginate_list(role, user.id, letter)

@letters = ('A'..'Z').to_a
end
</pre>

After Refactoring :

<pre>
#for displaying the list of users
def index
if (current_user_role? == "Student")
redirect_to(:action => AuthHelper::get_home_action(session[:user]), :controller => AuthHelper::get_home_controller(session[:user]))
else
#list method's implementation
end
end
</pre>

===Instance Variable Reductions===
It is a bad practice to have more than one instance variables in a controller action as it indicates towards increased coupling. We want to reduce the coupling as much as possible and view should have direct access to as few instance variables as possible. Helper methods should be defined in controllers through which the view can access variables of the controller class. The code has been refactored to make use of helper methods for the instance variables in index action.

Before Refactoring

users_controller.rb
<pre>

def get_role
if @user && @user.role_id
@role = Role.find(@user.role_id)
elsif @user
@role = Role.new(:id => nil, :name => '(none)')
end
end
</pre>

show.html.erb

<pre>
<tr><th>Role:</th>
<td><%= link_to @role.name, :controller => 'roles',
:action => 'show', :id => @role.id %></td>
</tr>
</pre>

After Refactoring

users_controller.rb
<pre>
def get_role
if @user && @user.role_id
role = Role.find(@user.role_id)
elsif @user
role = Role.new(id: nil, name: '(none)')
end
return role
end
</pre>

show.html.erb

<pre>
<tr><th>Role:</th>
<td><%= link_to get_role.name, :controller => 'roles',
:action => 'show', :id => get_role.id %></td>
</tr>

</table>
</pre>

===Code Cleanup===
Code cleanup in the controller so that the code conforms closely to Rails conventions and enhanced readability of code.
* Replaced String concats with #{} in paginate_list
Before Refactoring :

<pre>
#paginate_list
search_filter = letter + '%'
search_filter = '%' + letter + '%'
</pre>

After Refactoring :

<pre>
#paginate_list
search_filter = "#{letter}%"
search_filter = "%#{letter}%"
</pre>

* Replaced '==' with eql?
Before Refactoring :
<pre>
#index
if (current_user_role? == "Student")
...
letter == nil

#show_selection
@role.parent_id == nil || @role.parent_id < (session[:user]).role_id || @user.id == (session[:user]).id

#show
if (params[:id].nil?) || ((current_user_role? == "Student") && (session[:user].id != params[:id].to_i))

#create
if @user.role.name == "Instructor" or @user.role.name == "Administrator"

#keys
if (params[:id].nil?) || ((current_user_role? == "Student") && (session[:user].id != params[:id].to_i))

#paginate_list
if @search_by == '1'
</pre>

After Refactoring :
<pre>
#index
if (current_user_role.eql? "Student")
...
if letter.eql? nil

#show_selection
if role.parent_id.eql? nil || role.parent_id < (session[:user]).role_id || @user.id.eql?(session[:user]).id

#show
if (params[:id].nil?) || ((current_user_role.eql? "Student") && (session[:user].id != params[:id].to_i))

#create
if @user.role.name.eql? "Instructor" or @user.role.name.eql? "Administrator"

#keys
if (params[:id].nil?) || ((current_user_role.eql? "Student") && (session[:user].id != params[:id].to_i))

#paginate_list
if @search_by.eql? '1' #search by user name
</pre>

* Replaced :key =>'value' with key: 'value'

Before Refactoring :
<pre>
#index
redirect_to(:action => AuthHelper::get_home_action(session[:user]), :controller => AuthHelper::get_home_controller(session[:user]))

#show_selection
render :action => 'show'

#create
AssignmentQuestionnaire.create(:user_id => @user.id)
</pre>

After Refactoring :
<pre>
#index
redirect_to(action: AuthHelper::get_home_action(session[:user]), controller: AuthHelper::get_home_controller(session[:user]))

#show_selection
render action: 'show'

#create
AssignmentQuestionnaire.create(user_id: @user.id)
</pre>

==Use of Routing Helpers==
Routing helpers are a simpler alternative to the otherwise complex hard coded URLs which reduce the readability of the code.Routing helpers allow us to declare possible common routes for a given controller. Routing helpers have been implemented since they maintain consistency even if changes are made to the routing paths.

Before Refactoring:
 
<pre>
def show_selection
@user = User.find_by_name(params[:user][:name])
if @user != nil
get_role
if @role.parent_id == nil || @role.parent_id < (session[:user]).role_id || @user.id == (session[:user]).id
render :action => 'show'
else
flash[:note] = 'The specified user is not available for editing.'
redirect_to :action => 'list'
end
else
flash[:note] = params[:user][:name]+' does not exist.'
redirect_to :action => 'list'
end
end
</pre>
 
After Refactoring
 
<pre>
def show_selection
@user = User.where(name: params[:user][:name]).take
if @user != nil
role=get_role
if role.parent_id.eql? nil || role.parent_id < (session[:user]).role_id || @user.id.eql?(session[:user]).id
render action: 'show'
else
flash[:note] = 'The specified user is not available for editing.'
redirect_to users_path #Replaced URL with routing helper
end
else
flash[:note] = params[:user][:name]+' does not exist.'
redirect_to users_path #Replaced URL with routing helper
end
end
</pre>
 

==Replace find_by_.. by where in querying==
==References==
<references/>

CSC/ECE 517 Fall 2014/oss E1465 oak

2014-10-25T04:32:00Z

Knimgao: /* Instance Variable Reductions */

CSC/ECE 517 Fall 2014/oss E1465 oak

2014-10-25T04:29:47Z

Knimgao:

CSC/ECE 517 Fall 2014/oss E1465 oak

2014-10-25T04:24:42Z

Knimgao: /* Instance Variable Reductions */

CSC/ECE 517 Fall 2014/oss E1465 oak

2014-10-25T00:34:33Z

Knimgao:

CSC/ECE 517 Fall 2014/oss E1465 oak

2014-10-25T00:33:22Z

Knimgao:

CSC/ECE 517 Fall 2014/oss E1465 oak

2014-10-25T00:05:25Z

Knimgao:

CSC/ECE 517 Fall 2014/oss E1465 oak

2014-10-25T00:04:40Z

Knimgao:

=Expertiza - Refactoring UsersController=

__TOC__

==Introduction==
Expertiza<ref name="expertiza>''Expertiza'' Retrieved from http://wikis.lib.ncsu.edu/index.php/Expertiza</ref> is a web application available to both students and professors. The Expertiza project is a system to create reusable learning objects through peer review. Expertiza supports team projects, and the submission of almost any document type, including URLs and wiki pages. Students can keep a track of their assignments, teammates and can conduct peer reviews on diverse topics and projects. It is an open source project developed on Ruby on Rails platform. More information on Expertiza can be found [https://github.com/expertiza/expertiza here]. The source code can be forked and cloned for making modifications.

As a part of the coursework of Object Oriented Design and Development, we were expected to refactor the funtionality of some modules of Expertiza. This wiki provides an insight into our contributions to the Open Source Software project Expertiza with main focus of Refactoring the Users Controller.

The Users Controller deals with managing activities peripheral to the User registered with Expertiza. Each user is mapped to different roles thus having access to restricted functionality based on associated role.
<references/>

CSC/ECE 517 Fall 2014/oss E1465 oak

2014-10-24T23:56:25Z

Knimgao: Created page with "=Expertiza - Refactoring UsersController= __TOC__ ==Introduction== Expertiza<ref name="expertiza>''Expertiza'' Retrieved from http://wikis.lib.ncsu.edu/index.php/Expertiza</ref..."

=Expertiza - Refactoring UsersController=

__TOC__

==Introduction==
Expertiza<ref name="expertiza>''Expertiza'' Retrieved from http://wikis.lib.ncsu.edu/index.php/Expertiza</ref> is a web application available to both students and professors. The Expertiza project is a system to create reusable learning objects through peer review. Expertiza supports team projects, and the submission of almost any document type, including URLs and wiki pages. Students can keep a track of their assignments, teammates and can conduct peer reviews on diverse topics and projects. It is an open source project developed on Ruby on Rails platform. More information on Expertiza can be found [https://github.com/expertiza/expertiza here]. The source code can be forked and cloned for making modifications.

This wiki provides an insight into our contributions to the Open Source Software project Expertiza with main focus refactoring the users controller. Reporting score functionality is handled by controllers/grades_controller.rb and rendered by views/grades/_view_my_score.html.erb. Improved User Interface using JQuery is our contribution to Expertiza. This new elegant UI uses tabs instead of tables which makes it look elegant and renders faster. Subtle code and design challenges, changes and the motivation to implement this design have been explained further.

CSC/ECE 517 Fall 2014/ch1a 25 ks

2014-09-24T23:59:14Z

Knimgao: /* Simple Explanation */

=Object Relational Mapping=

__TOC__

==Introduction==
Object Relation Mapping(ORM, O/RM, and O/R mapping) provides a technique to efficiently access data from a database in the form of objects which are mapped to the database records. This avoids the hassle of writing database specific queries and creates, in effect, a "virtual object database" that can be used from within the programming language. This wiki concentrates on features, advantages and disadvantages of using ORM, gives a general overview of various ORM frameworks such as Active records, ORM Adapter, Sequel etc. and provides a basic comparison of their features.

==Overview==
Object Relational Mapping is a programming technique in which a metadata descriptor is used to connect object code to a relational database. ORM converts data between type systems that are unable to coexist within relational databases and OOP languages.

In [http://en.wikipedia.org/wiki/Object-oriented_programming object-oriented programming], data management tasks act on object-oriented (OO) objects that are almost always non-scalar values. For example, consider an address book entry that represents a single person along with zero or more phone numbers and zero or more addresses. This could be modeled in an object-oriented implementation by a "Person object" with attributes/fields to hold each data item that the entry comprises: the person's name, a list of phone numbers, and a list of addresses. The list of phone numbers would itself contain "PhoneNumber objects" and so on. The address book entry is treated as a single object by the programming language (it can be referenced by a single variable containing a pointer to the object, for instance). Various methods can be associated with the object, such as a method to return the preferred phone number, the home address, and so on.

The heart of the problem is translating the logical representation of the objects into an atomized form that is capable of being stored in the database, while preserving the properties of the objects and their relationships so that they can be reloaded as objects when needed. If this storage and retrieval functionality is implemented, the objects are said to be persistent.

==Simple Explanation<ref>http://en.wikipedia.org/wiki/Object-relational_mapping</ref>==
A simple answer is that you wrap your tables or stored procedures in classes in your programming language, so that instead of writing SQL statements to interact with your database, you use methods and properties of objects.

In other words, instead of something like this:
<pre>
String sql = "SELECT ... FROM persons WHERE id = 10"
DbCommand cmd = new DbCommand(connection, sql);
Result res = cmd.Execute();
String name = res[0]["FIRST_NAME"];
</pre>
you do something like this:
<pre>
Person p = repository.GetPerson(10);
String name = p.FirstName;
</pre>
or similar code (lots of variations here.) Some frameworks also put a lot of the code in as static methods on the classes themselves, which means you could do something like this instead:
<pre>
Person p = Person.Get(10);
</pre>
Some also implement complex query systems, so you could do this:
<pre>
Person p = Person.Get(Person.Properties.Id == 10);
</pre>
The framework is what makes this code possible.

==Features<ref>http://wiki.expertiza.ncsu.edu/index.php/CSC/ECE_517_Spring_2013/ch1_1d_zk</ref>==
Object-relational Mapping (ORM) frameworks unburden the designer of the complex translation between database and object space.

Typical ORM features:
* Automatic mapping from classes to database tables
** Class instance variables to database columns
** Class instances to table rows
* Aggregation and association relationships between mapped classes are managed
** Example, :has_many, :belongs_to associations in ActiveRecord
** Inheritance cases are mapped to tables
* Validation of data prior to table storage
* Class extensions to enable search, as well as creation, read, update, and deletion (CRUD) of instances/records
* Usually abstracts the database from program space in such a way that alternate database types can be easily chosen (SQLite, Oracle, etc)

The diagram below depicts a simple mapping of an object to a database table….

[[Image:3j_ks_pic1.jpg]]

ORM framework is used to persist model objects to a relational database and retrieve them, and the ORM framework will take care of converting the data between the two otherwise incompatible states. Most ORM tools rely heavily on metadata about both the database and objects, so that the objects need to know nothing about the database and the database doesn’t need to know anything about how the data is structured in the application. ORM provides a clean separation of concerns in a well-designed data application, and the database and application can each work with data in its native form. Database rows map to objects, thus making the program more easily accessible and allowing the usage of information in a way that is internally consistent and easy to understand. The ORM gives the programmer an ability to manipulate data with the programming language, instead of having to manipulate each attribute as its data type as obtained by the database management system.

When applied to Ruby, implementations of ORM often leverage the language’s [http://en.wikipedia.org/wiki/Metaprogramming metaprogramming] strengths to create intuitive application-specific methods and otherwise extend classes to support database functionality. With the addition of Rails, the ORM becomes much more important, as it is necessary to have an ORM to connect the models of the MVC (model-view-controller) stack used by Ruby on Rails with the application's database. Since the models are Ruby objects, the ORM allows modifications to the database to be done through changes to these models, independent of the type of database used.

With the release of Rails 3.0, the platform became ORM independent. With this change, it is much easier to use the ORM most preferred by the programmer, rather than being corralled into using one particular one. To allow this, the ORM needed to be extracted from the model and the database, to be a pure mediator between the two. Then any ORM can be used as long as it can successfully understand the model and the database used.

==Advantages<ref>http://www.techopedia.com/definition/24200/object-relational-mapping--orm</ref>==
In addition to the [http://en.wikipedia.org/wiki/Data_access data access] technique, ORM's benefits also include:
*First of all, you hide the SQL away from your logic code. This has the benefit of allowing you to more easily support more database engines. For instance, MS SQL Server and Oracle has different names on typical functions, and different ways to do calculations with dates, so a query to "get me all persons edited the last 24 hours" might entail different SQL syntax just for those two database engines. This difference can be put away from your logic code.
*Additionally, you can focus on writing the logic, instead of getting all the SQL right. The code will typically be more readable as well, since it doesn't contain all the "plumbing" necessary to talk to the database.
*Simplified development because it automates object-to-table and table-to-object conversion, resulting in lower development and maintenance costs
*Less code compared to embedded SQL and handwritten stored procedures
*Transparent object caching in the application tier, improving system performance
*An optimized solution making an application faster and easier to maintain

==Disadvantages==
*ORM’s emergence in multiple application development has created disagreement among experts. Key concerns are that ORM does not perform well and that stored procedures might be a better solution.
*In addition, ORM dependence may result in poorly-designed databases in certain circumstances.
*Performance – like every "proxy" technology
*Complexity – learning curve
*Difficulty / inability to make complex queries

=ORM Frameworks=

==Active Records==
[http://guides.rubyonrails.org/active_record_basics.html Active Record] was described by Martin Fowler in his book Patterns of Enterprise Application Architecture. Active Record is the M in [http://guides.rubyonrails.org/getting_started.html#the-mvc-architecture MVC]- the model - which is the layer of the system responsible for representing business data and logic. In Active Record, objects carry both persistent data and behavior which operates on that data. A database table or view is wrapped into a class and an object instance is tied to a single row in the table. Each Active Record object has CRUD (Create, Read, Update, and Delete) methods for database access. In addition, Active Record allows you to validate the state of a model before it gets written into the database.

Active Record gives us several mechanisms, the most important being the ability to:
* Represent models and their data.
* Represent associations between these models.
* Represent inheritance hierarchies through related models.
* Validate models before they get persisted to the database.
* Perform database operations in an object-oriented fashion.

The naming conventions used in Active Records are :
* Database Table - Plural with underscores separating words (e.g., book_clubs).
* Model Class - Singular with the first letter of each word capitalized (e.g., BookClub).

To create a table, ActiveRecord makes use of a migration class rather than including table definition in the actual class being modeled. As an example, the following code creates a table ‘’users’’ to store a collection of class ‘’User’’ objects:
<pre>
class CreateUsers < ActiveRecord::Migration
def self.up
create_table :users do |t|
t.string :name
t.string :email
t.string :age
t.references :cheer
t.references :post

t.timestamps # add creation and modification timestamps
end
end

def self.down # undo the table creation
drop_table :users
end
end
</pre>

The ActiveRecord’s migration scheme provides a means for backing out changes via the ‘’self.down’’ method. In addition, a table key ‘’id’’ is added to the new table without an explicit definition and record creation and modification timestamps are included via the ‘’timestamps’’ method provided by ActiveRecord.

ActiveRecord manages associations between table elements and provides the means to define such associations in the model definition. For example, the ‘’User’’ class shown below defines a ‘’has_many’’ (one-to-many) association with both the cheers and posts tables. These associations are represented in the migration class with the references operator. Also note ActiveRecord’s integrated support for validation of table information when attempting an update.

<pre>
class User < ActiveRecord::Base
has_many :cheers
has_many :posts

validates_presence_of :name
validates_presence_of :age
validates_uniqueness_of :name
validates_length_of :name, :within => 3..20
end
</pre>

To access the data in the table one calls the class function related to that column. For example, to find the user who's name is Bob, one would use @user = User.find_by_name('Bob'). Then one could find Bob's e-mail by using @user.email. Users can be searched for by any attribute in this way, as find methods are created for every combination of attributes.
While ActiveRecord provides the flexibility to create more sophisticated table relationships to represent class hierarchy, its base scheme is a single table inheritance, which trades some storage efficiency for simplicity in the database design. The following figure illustrates this concept of simplicity over efficiency.

[[Image:3j_ks_pic2.jpg]]

'''Pros''' -
* Integrated with popular Rails development framework
* Dynamically created database search methods (eg: User.find_by_address) ease db queries and make queries database syntax independent
* DB creation/management using the migrate scheme provides a means for backing out unwanted table changes
'''Cons''' -
* DB creation/management is decoupled from the model, requiring a separate utility (rake/migrate) that must be kept in sync with application.

==ORM Adaptor==
[https://github.com/ianwhite/orm_adapter ORM Adaptors] provide a single point of entry for popular ruby ORMs. Its target audience is gem authors who want to support more than one ORM.
ORM Adapter's goal is to support a minimum API used by most of the plugins that needs agnosticism beyond Active Model.
ORM Adapter will support only basic methods, as get, find_first, create! and so forth. It is not ORM Adapter's goal to support different query constructions, handle table joins, etc.
ORM adapter provides a consistent API for these basic class or 'factory' methods. It does not attempt to unify the behaviour of model instances returned by these methods. This means that unifying the behaviour of methods such as `model.save`, and `model.valid?` is beyond the scope of orm_adapter.
If you need complex queries, it is recommended to subclass ORM Adapters in your plugin and extend it expressing these query conditions as part of your domain logic.
<pre>
Example :
require 'orm_adapter'
User # is it an ActiveRecord, DM Resource, MongoMapper or MongoId Document?
User.to_adapter.find_first :name => 'Fred' # we don't care!
user_model = User.to_adapter
user_model.get!(1) # find a record by id
user_model.find_first(:name => 'fred') # find first fred
user_model.find_first(:level => 'awesome', :id => 23) # find user 23, only if it's level is awesome
user_model.find_all # find all users
user_model.find_all(:name => 'fred') # find all freds
user_model.find_all(:order => :name) # find all freds, ordered by name
user_model.create!(:name => 'fred') # create a fred
user_model.destroy(object) # destroy the user object
</pre>

==Sequel==
[http://sequel.jeremyevans.net/documentation.html Sequel] was originally developed by Sharon Rosner and the first release was in March 2007. It is based on the active record pattern. Sequel and Active Record share a lot of common features , for example association and inheritance. But Sequel handles these features in a much more flexible manner. Currently Sequel is at version 3.44.0. Initially Sequel had three core modules - sequel, sequel_core and sequel_model. Starting from version 1.4 , sequel and sequel_model were merged. Sequel handles validations using a validation plug-in and helpers.

<pre>
class CreateUser < Sequel::Migration
def up
create_table(:user) {
primary_key :id
String :name
String :age
String :email}
end
def down
drop_table(:user)
end
end # CreateUser.apply(DB, :up)
</pre>

Sequel supports associations and validations similar to Active Record. The following example shows how validations and associations can be enforced in the User table that has been created above. It enforces one to many relationships between the user table and the cheers and posts tables. It also validates for the presence , uniqueness and the length of the attribute '''name'''.

<pre>
class User < Sequel::Model
one_to_many :cheers
one_to_many :posts

validates_presence [:name, :age]
validates_unique(:name)
validates_length_range 3..20, :name
end
</pre>

To access the data in Sequel, one can use where clauses. For instance, to find Bob again one would use DB[:items].where(Sequel.like(:name, 'Bob'). While the ability to use SQL-like where clauses is quite flexible, it is not quite as pure an object-oriented approach as Active Record's dynamically created find methods.

Some of the key features of sequel are,
* [http://sequel.jeremyevans.net/rdoc/classes/Sequel/ThreadedConnectionPool.html Connection Pooling]
* Thread Safety
* [http://guides.rubyonrails.org/active_record_querying.html#eager-loading-associations Eager Loading] / Lazy Loading
* Model Caching
* Supports advanced database features such as prepared statements, bound variables, stored procedures, savepoints, two-phase commit, transaction isolation, master/slave configurations, and database sharing.

==Data Mapper==
[http://datamapper.org/ DataMapper] is an Object Relational Mapper written in Ruby developed by Sam Smoot with the goal to create an ORM which is fast, thread-safe and feature rich.
A Data Mapper is a Data Access Layer that performs bidirectional transfer of data between a persistent data store (often a relational database) and an in memory data representation (the domain layer). The goal of the pattern is to keep the in memory representation and the persistent data store independent of each other and the data mapper itself. The layer is composed of one or more mappers (or Data Access Objects), performing the data transfer.
DataMapper comes with the ability to use the same API to talk to a multitude of different datastores. There are adapters for the usual RDBMS suspects, NoSQL stores, various file formats and some web services. With DataMapper, you define your mappings in your model. Your data store can develop independently of your model using Migrations.

Some features of Data Mapper are as follows :
* No need to write structural migrations
* Scoped relations
* Lazy loading on certain attribute types
* Strategic eager loading to avoid (N+1) queries
* Default support for composite and natural keys
* Query chaining, and not evaluating the query until absolutely necessary (using a lazy array implementation)
* An API not too heavily oriented to SQL databases

DataMapper was designed to be a more abstract ORM, not strictly SQL, based on Martin Fowler's enterprise pattern. As a result, DataMapper adapters have been built for other non-SQL databases, such as CouchDB, [http://github.com/lritter/dm-solr-adapter/tree/master Apache Solr], and webservices such as [http://github.com/halorgium/dm-salesforce/tree/master Salesforce].

Example of table definition in the model:
<pre>
class User
include DataMapper::Resource

property :id, Serial # key
property :name, String, :required => true, :unique => true
property :age, String, :required => true, :length => 3..20
property :email, String

has n, :posts # one to many association
has n, :cheers # one to many association
end
</pre>

Notice that in the example above , ":required = true" is an example for Auto Validation. Unlike ActiveRecord and Sequel, DataMapper supports auto validations , i.e. these in turn call the validation helpers to enforce basic validations such as length, uniqueness, format, presence etc.

==MyBatis/iBatis==
[http://en.wikipedia.org/wiki/MyBatis MyBatis/iBatis] was a persistence framework which allowed easy access of the database from a Rails application without being a full ORM. It was created by the Apache Foundation in 2002, and is available for several platforms, including Ruby (the Ruby release is known as RBatis). On 6/16/2010, after releasing iBATIS 3.0, the project team moved from Apache to Google Code, changed the project's name to MyBatis, and stopped supporting Ruby.

The MyBatis data mapper framework makes it easier to use a relational database with object-oriented applications. MyBatis couples objects with stored procedures or SQL statements using a XML descriptor. To use the MyBatis data mapper,we make use of our own objects, XML, and SQL.

SQL statements are stored in XML files or annotations. Following is a MyBatis mapper, that consists of a Java interface with some MyBatis annotations:
<pre>
package org.mybatis.example;

public interface BlogMapper {
@Select("select * from Blog where id = #{id}")
Blog selectBlog(int id);
}
</pre>
The sentence is executed as follows.
<pre>
BlogMapper mapper = session.getMapper(BlogMapper.class);
Blog blog = mapper.selectBlog(101);
</pre>

It can also be executed using MyBatis API.
<pre>
Blog blog = session.selectOne("org.mybatis.example.BlogMapper.selectBlog", 101);
</pre>

SQL statements and mappings can also be externalized to an XML file like this.
<pre>
<?xml version="1.0" encoding="UTF-8" ?>
<!DOCTYPE mapper PUBLIC "-//mybatis.org//DTD Mapper 3.0//EN" "http://mybatis.org/dtd/mybatis-3-mapper.dtd">

<mapper namespace="org.mybatis.example.BlogMapper">
<select id="selectBlog" parameterType="int" resultType="Blog">
select * from Blog where id = #{id}
</select>
</mapper>
</pre>

==Squeel==
[http://rubydoc.info/gems/squeel/1.1.1/frames Squeel]unlocks the power of Arel in Rails applications with a handy block-based syntax. It is supporting in Rails 3 and 4. With Squeel, you can write subqueries, access named functions provided by RDMBS and more without writing SQL strings.
Squeel lets you write your Active Record queries with fewer strings, and more Ruby, by making the Arel awesomeness that lies beneath Active Record more accessible.

Squeel lets you rewrite...

<pre>
Article.where ['created_at >= ?', 2.weeks.ago]
...as...
Article.where{created_at >= 2.weeks.ago}
</pre>

Squeel enhances the normal Active Record query methods by enabling them to accept blocks. Inside a block, the Squeel query DSL can be used. Note the use of curly braces in the above example instead of parentheses. {} denotes a Squeel DSL query.

Stubs and keypaths are the two primary building blocks used in a Squeel DSL query.

Stubs are, for most intents and purposes, just like Symbols in a normal call to Relation#where (note the need for doubling up on the curly braces here, the first ones start the block, the second are the hash braces):
<pre>
Person.where{{name => ‘Ernie’ }}
</pre>

You normally wouldn't bother using the DSL in this case, as a simple hash would suffice. However, stubs serve as a building block for keypaths, and keypaths are very handy.

A Squeel keypath is essentially a more concise and readable alternative to a deeply nested hash. For instance, in standard Active Record, you might join several associations like this to perform a query:
<pre>
Person.joins(:articles => { :comments => :person}).references(:all)
</pre>

With a keypath, this would look like:
<pre>
Person.joins{articles.comments.person}.references(:all)
</pre>

The Squeel DSL works its magic using instance_eval which means that inside a Squeel DSL block, self isn't the same thing that it is outside the block.
This carries with it an important implication: Instance variables and instance methods inside the block won't refer to your object's variables/methods.
Use one of the following methods to get access to the object's methods and variables:
* Assign the variable locally before the DSL block, and access it as you would normally.
* Supply an arity to the DSL block, as in Person.where{|q| q.name == @my_name} Downside: You'll need to prefix stubs, keypaths, and functions with the DSL object.
* Wrap the method or instance variable inside the block with my{}. Person.where{name == my{some_method_to_return_a_name}}

==Merb==
[http://en.wikipedia.org/wiki/Merb Merb], short for "Mongrel+Erb", is a model view controller framework written in Ruby. Merb was merged into Rails web framework on December 23, 2008 as part of the Ruby on Rails 3.0 release.
Merb itself provides only the controller of an MVC model which can be extended to create a full-stack application environment. This effectively means Merb itself is not an ORM but can accommodate other ORMs.
Some features of Merb are as follows :
* Speed - Merb is ORM, JavaScript library and template language agnostic, preferring plugins that add support for features rather than producing a monolithic library with everything in the core.
* Lightweight - Rather than trying to cram every feature into a single code, things are kept bare minimum without sacrificing anything important.
* Powerful and extensible - For any features not covered in Merb’s core, there are plugins.
Some basic Command distinction between Ruby on Rails and Merb :
{| class="comparison" border="1"
! Action
! Ruby on Rails
! Merb
|-
| Create new application 'app1' || rails new app1 || merb-gen app app1
|-
| Start server || rails server || merb
|-
| Start cluster of 3 beginning at port 3000 || N/A || merb -p 3000 -c 3
|-
| Interactive console || rails console || merb -i
|}

=Alternative to ORM=
==NonSQL databases<ref>http://wiki.expertiza.ncsu.edu/index.php/CSC/ECE_517_Fall_2013/ch1_1w43_sm</ref>==
Instead of ORM we can also use Object-Oriented Database Management System (OODBMS) or document-oriented database like XML, where in databases are designed to store object oriented values, thus eliminating the need to convert data to and from its SQL form. Document oriented databases also eliminates the need to retrieve objects as data rows. Query languages like XQuery can be used to retrieve data sets.

The only issue is we won't be able to create application independent queries for retrieving data without restrictions to access path. Also OODBMS limits the extent of processing SQL queries.
A Relational database allows concurrent access to data, locking, indexing (fast search), as well as many other features that are not available while using XML files.

Other OODBMS (such as RavenDB) provide replication to SQL databases, as a means of addressing the need for ad-hoc queries, while preserving the increased performance and reduced complexity that may be achieved with an OODBMS for an application that has well-known query patterns.

NonSQL databases don’t provide mechanism to maintain relationship between tables. In real life though, business objects or entities do have relationship among them. ORM solutions may allow you to define these relationships in business objects and handle their storage and retrieval behind the scene

=Comparison of ORM Features=

{|cellspacing="0" border="1"
!style="width:8%"|Features
!style="width:23%"|ActiveRecord
!style="width:23%"|Sequel
!style="width:23%"|DataMapper
!style="width:23%"|MyBatis
|-
! Databases 
| MySQL, PostgreSQL, SQLite, Oracle, SQLServer, and DB2
| ADO, DataObjects, DB2, DBI, Firebird, Informix, JDBC, MySQL, ODBC, OpenBase, Oracle, PostgreSQL and SQLite3
| SQLite, MySQL, PostgreSQL, Oracle, MongoDB, SimpleDB, many others, including CouchDB, Apache Solr, Google Data API
| MySQL, PostgreSQL, SQLite, Oracle, SQLServer, and DB2
|-
! Migrations 
| Yes
| Yes
| Yes, but optional
| Yes, provides migration by Mybatis schema migration system.
|-
! EagerLoading 
| Supported by scanning the SQL fragments
| Supported using eager (preloading) and eager_graph (joins)
| Strategic Eager Loading and by using :summary
| Yes.this can be enabled or disabled by setting the lazyLoadingEnabled flag
|-
! Flexible Overriding 
| No. Overriding is done using alias methods.
| Using methods and by calling 'super'
| Using methods
| No
|-
! Dynamic Finders 
| Yes. Uses 'Method Missing'
| No. Alternative is to use <Model>.FindOrCreate(:name=>"John")
| Yes. Using the dm_ar_finders plugin
| Similar feature is supported in the form of Dynamic SQL
|}

=Further Reading=
To get more information on ORM and the different type of ORM's available for Ruby , please look into the [http://wiki.expertiza.ncsu.edu/index.php/CSC/ECE_517_Spring_2013/ch1_1d_zk CSC/ECE 517 Spring 2013/ch1 1d zk] and [http://wiki.expertiza.ncsu.edu/index.php/CSC/ECE_517_Fall_2010/ch3_3f_ac Fall 2010 detailed ORM explanation] wiki pages.
# [http://www.cs.colorado.edu/~kena/classes/5448/f11/lectures/29-orm.pdf ORM - University of Colorado]
# [http://www.lynda.com/Ruby-Rails-tutorials/Understanding-ActiveRecord-ActiveRelation/139989/159093-4.html Active Record Tutorial]
# [http://digitalcommons.macalester.edu/context/mathcs_honors/article/1006/type/native/viewcontent/ Research papers on object relational mapping]
# [http://www.sitepoint.com/top-ruby-frameworks-rails-and-merb-join-forces/ Merb and Rails]

=Future Work=
More work can be done in the area of comparison between the different ORMs available for Ruby, especially a more detailed feature-by-feature comparison that includes performance differences between the ORMs.

=References =
# [http://en.wikipedia.org/wiki/Object-relational_mapping Object Relational Mapping]
# [http://en.wikipedia.org/wiki/Object-oriented_programming object-oriented programming]
# [http://en.wikipedia.org/wiki/Data_access data access]
# [http://en.wikipedia.org/wiki/Metaprogramming metaprogramming]
# [http://guides.rubyonrails.org/active_record_basics.html Active Record]
# [http://guides.rubyonrails.org/getting_started.html#the-mvc-architecture MVC]
# [http://sequel.jeremyevans.net/documentation.html Sequel]
# [http://datamapper.org/ DataMapper]
# [http://sequel.jeremyevans.net/rdoc/classes/Sequel/ThreadedConnectionPool.html Connection Pooling]
# [http://guides.rubyonrails.org/active_record_querying.html#eager-loading-associations Eager Loading]
# [http://rubydoc.info/gems/squeel/1.1.1/frames Squeel]
# [http://www.techopedia.com/definition/24200/object-relational-mapping--orm ORM]
# [http://en.wikipedia.org/wiki/Merb Merb]
# [http://www.merbivore.com/ Merb Website]
# [http://wiki.expertiza.ncsu.edu/index.php/CSC/ECE_517_Spring_2013/ch1_1d_zk Object Relational Mapping Spring 2013]

=Citations=
<references/>

CSC/ECE 517 Fall 2014/ch1a 25 ks

2014-09-24T23:35:43Z

Knimgao: /* Sequel */

=Object Relational Mapping=

__TOC__

==Introduction<ref>http://en.wikipedia.org/wiki/Object-relational_mapping</ref>==
Object Relation Mapping(ORM, O/RM, and O/R mapping) in computer science is a programming technique for converting data between incompatible type systems in object-oriented programming languages. This creates, in effect, a "virtual object database" that can be used from within the programming language. There are both free and commercial packages available that perform object-relational mapping, although some programmers opt to create their own ORM tools.

==Overview==
Object Relational Mapping is a programming technique in which a metadata descriptor is used to connect object code to a relational database. ORM converts data between type systems that are unable to coexist within relational databases and OOP languages.

In [http://en.wikipedia.org/wiki/Object-oriented_programming object-oriented programming], data management tasks act on object-oriented (OO) objects that are almost always non-scalar values. For example, consider an address book entry that represents a single person along with zero or more phone numbers and zero or more addresses. This could be modeled in an object-oriented implementation by a "Person object" with attributes/fields to hold each data item that the entry comprises: the person's name, a list of phone numbers, and a list of addresses. The list of phone numbers would itself contain "PhoneNumber objects" and so on. The address book entry is treated as a single object by the programming language (it can be referenced by a single variable containing a pointer to the object, for instance). Various methods can be associated with the object, such as a method to return the preferred phone number, the home address, and so on.

The heart of the problem is translating the logical representation of the objects into an atomized form that is capable of being stored in the database, while preserving the properties of the objects and their relationships so that they can be reloaded as objects when needed. If this storage and retrieval functionality is implemented, the objects are said to be persistent.

==Simple Explanation==
A simple answer is that you wrap your tables or stored procedures in classes in your programming language, so that instead of writing SQL statements to interact with your database, you use methods and properties of objects.

In other words, instead of something like this:
<pre>
String sql = "SELECT ... FROM persons WHERE id = 10"
DbCommand cmd = new DbCommand(connection, sql);
Result res = cmd.Execute();
String name = res[0]["FIRST_NAME"];
</pre>
you do something like this:
<pre>
Person p = repository.GetPerson(10);
String name = p.FirstName;
</pre>
or similar code (lots of variations here.) Some frameworks also put a lot of the code in as static methods on the classes themselves, which means you could do something like this instead:
<pre>
Person p = Person.Get(10);
</pre>
Some also implement complex query systems, so you could do this:
<pre>
Person p = Person.Get(Person.Properties.Id == 10);
</pre>
The framework is what makes this code possible.

==Features<ref>http://wiki.expertiza.ncsu.edu/index.php/CSC/ECE_517_Spring_2013/ch1_1d_zk</ref>==
Object-relational Mapping (ORM) frameworks unburden the designer of the complex translation between database and object space.

Typical ORM features:
* Automatic mapping from classes to database tables
** Class instance variables to database columns
** Class instances to table rows
* Aggregation and association relationships between mapped classes are managed
** Example, :has_many, :belongs_to associations in ActiveRecord
** Inheritance cases are mapped to tables
* Validation of data prior to table storage
* Class extensions to enable search, as well as creation, read, update, and deletion (CRUD) of instances/records
* Usually abstracts the database from program space in such a way that alternate database types can be easily chosen (SQLite, Oracle, etc)

The diagram below depicts a simple mapping of an object to a database table….

[[Image:3j_ks_pic1.jpg]]

ORM framework is used to persist model objects to a relational database and retrieve them, and the ORM framework will take care of converting the data between the two otherwise incompatible states. Most ORM tools rely heavily on metadata about both the database and objects, so that the objects need to know nothing about the database and the database doesn’t need to know anything about how the data is structured in the application. ORM provides a clean separation of concerns in a well-designed data application, and the database and application can each work with data in its native form. Database rows map to objects, thus making the program more easily accessible and allowing the usage of information in a way that is internally consistent and easy to understand. The ORM gives the programmer an ability to manipulate data with the programming language, instead of having to manipulate each attribute as its data type as obtained by the database management system.

When applied to Ruby, implementations of ORM often leverage the language’s [http://en.wikipedia.org/wiki/Metaprogramming metaprogramming] strengths to create intuitive application-specific methods and otherwise extend classes to support database functionality. With the addition of Rails, the ORM becomes much more important, as it is necessary to have an ORM to connect the models of the MVC (model-view-controller) stack used by Ruby on Rails with the application's database. Since the models are Ruby objects, the ORM allows modifications to the database to be done through changes to these models, independent of the type of database used.

With the release of Rails 3.0, the platform became ORM independent. With this change, it is much easier to use the ORM most preferred by the programmer, rather than being corralled into using one particular one. To allow this, the ORM needed to be extracted from the model and the database, to be a pure mediator between the two. Then any ORM can be used as long as it can successfully understand the model and the database used.

==Advantages<ref>http://www.techopedia.com/definition/24200/object-relational-mapping--orm</ref>==
In addition to the [http://en.wikipedia.org/wiki/Data_access data access] technique, ORM's benefits also include:
*First of all, you hide the SQL away from your logic code. This has the benefit of allowing you to more easily support more database engines. For instance, MS SQL Server and Oracle has different names on typical functions, and different ways to do calculations with dates, so a query to "get me all persons edited the last 24 hours" might entail different SQL syntax just for those two database engines. This difference can be put away from your logic code.
*Additionally, you can focus on writing the logic, instead of getting all the SQL right. The code will typically be more readable as well, since it doesn't contain all the "plumbing" necessary to talk to the database.
*Simplified development because it automates object-to-table and table-to-object conversion, resulting in lower development and maintenance costs
*Less code compared to embedded SQL and handwritten stored procedures
*Transparent object caching in the application tier, improving system performance
*An optimized solution making an application faster and easier to maintain

==Disadvantages==
*ORM’s emergence in multiple application development has created disagreement among experts. Key concerns are that ORM does not perform well and that stored procedures might be a better solution.
*In addition, ORM dependence may result in poorly-designed databases in certain circumstances.
*Performance – like every "proxy" technology
*Complexity – learning curve
*Difficulty / inability to make complex queries

=ORM Frameworks=

==Active Records==
[http://guides.rubyonrails.org/active_record_basics.html Active Record] was described by Martin Fowler in his book Patterns of Enterprise Application Architecture. Active Record is the M in [http://guides.rubyonrails.org/getting_started.html#the-mvc-architecture MVC]- the model - which is the layer of the system responsible for representing business data and logic. In Active Record, objects carry both persistent data and behavior which operates on that data. A database table or view is wrapped into a class and an object instance is tied to a single row in the table. Each Active Record object has CRUD (Create, Read, Update, and Delete) methods for database access. In addition, Active Record allows you to validate the state of a model before it gets written into the database.

Active Record gives us several mechanisms, the most important being the ability to:
* Represent models and their data.
* Represent associations between these models.
* Represent inheritance hierarchies through related models.
* Validate models before they get persisted to the database.
* Perform database operations in an object-oriented fashion.

The naming conventions used in Active Records are :
* Database Table - Plural with underscores separating words (e.g., book_clubs).
* Model Class - Singular with the first letter of each word capitalized (e.g., BookClub).

To create a table, ActiveRecord makes use of a migration class rather than including table definition in the actual class being modeled. As an example, the following code creates a table ‘’users’’ to store a collection of class ‘’User’’ objects:
<pre>
class CreateUsers < ActiveRecord::Migration
def self.up
create_table :users do |t|
t.string :name
t.string :email
t.string :age
t.references :cheer
t.references :post

t.timestamps # add creation and modification timestamps
end
end

def self.down # undo the table creation
drop_table :users
end
end
</pre>

The ActiveRecord’s migration scheme provides a means for backing out changes via the ‘’self.down’’ method. In addition, a table key ‘’id’’ is added to the new table without an explicit definition and record creation and modification timestamps are included via the ‘’timestamps’’ method provided by ActiveRecord.

ActiveRecord manages associations between table elements and provides the means to define such associations in the model definition. For example, the ‘’User’’ class shown below defines a ‘’has_many’’ (one-to-many) association with both the cheers and posts tables. These associations are represented in the migration class with the references operator. Also note ActiveRecord’s integrated support for validation of table information when attempting an update.

<pre>
class User < ActiveRecord::Base
has_many :cheers
has_many :posts

validates_presence_of :name
validates_presence_of :age
validates_uniqueness_of :name
validates_length_of :name, :within => 3..20
end
</pre>

To access the data in the table one calls the class function related to that column. For example, to find the user who's name is Bob, one would use @user = User.find_by_name('Bob'). Then one could find Bob's e-mail by using @user.email. Users can be searched for by any attribute in this way, as find methods are created for every combination of attributes.
While ActiveRecord provides the flexibility to create more sophisticated table relationships to represent class hierarchy, its base scheme is a single table inheritance, which trades some storage efficiency for simplicity in the database design. The following figure illustrates this concept of simplicity over efficiency.

[[Image:3j_ks_pic2.jpg]]

'''Pros''' -
* Integrated with popular Rails development framework
* Dynamically created database search methods (eg: User.find_by_address) ease db queries and make queries database syntax independent
* DB creation/management using the migrate scheme provides a means for backing out unwanted table changes
'''Cons''' -
* DB creation/management is decoupled from the model, requiring a separate utility (rake/migrate) that must be kept in sync with application.

==ORM Adaptor==
[https://github.com/ianwhite/orm_adapter ORM Adaptors] provide a single point of entry for popular ruby ORMs. Its target audience is gem authors who want to support more than one ORM.
ORM Adapter's goal is to support a minimum API used by most of the plugins that needs agnosticism beyond Active Model.
ORM Adapter will support only basic methods, as get, find_first, create! and so forth. It is not ORM Adapter's goal to support different query constructions, handle table joins, etc.
ORM adapter provides a consistent API for these basic class or 'factory' methods. It does not attempt to unify the behaviour of model instances returned by these methods. This means that unifying the behaviour of methods such as `model.save`, and `model.valid?` is beyond the scope of orm_adapter.
If you need complex queries, it is recommended to subclass ORM Adapters in your plugin and extend it expressing these query conditions as part of your domain logic.
<pre>
Example :
require 'orm_adapter'
User # is it an ActiveRecord, DM Resource, MongoMapper or MongoId Document?
User.to_adapter.find_first :name => 'Fred' # we don't care!
user_model = User.to_adapter
user_model.get!(1) # find a record by id
user_model.find_first(:name => 'fred') # find first fred
user_model.find_first(:level => 'awesome', :id => 23) # find user 23, only if it's level is awesome
user_model.find_all # find all users
user_model.find_all(:name => 'fred') # find all freds
user_model.find_all(:order => :name) # find all freds, ordered by name
user_model.create!(:name => 'fred') # create a fred
user_model.destroy(object) # destroy the user object
</pre>

==Sequel==
[http://sequel.jeremyevans.net/documentation.html Sequel] was originally developed by Sharon Rosner and the first release was in March 2007. It is based on the active record pattern. Sequel and Active Record share a lot of common features , for example association and inheritance. But Sequel handles these features in a much more flexible manner. Currently Sequel is at version 3.44.0. Initially Sequel had three core modules - sequel, sequel_core and sequel_model. Starting from version 1.4 , sequel and sequel_model were merged. Sequel handles validations using a validation plug-in and helpers.

<pre>
class CreateUser < Sequel::Migration
def up
create_table(:user) {
primary_key :id
String :name
String :age
String :email}
end
def down
drop_table(:user)
end
end # CreateUser.apply(DB, :up)
</pre>

Sequel supports associations and validations similar to Active Record. The following example shows how validations and associations can be enforced in the User table that has been created above. It enforces one to many relationships between the user table and the cheers and posts tables. It also validates for the presence , uniqueness and the length of the attribute '''name'''.

<pre>
class User < Sequel::Model
one_to_many :cheers
one_to_many :posts

validates_presence [:name, :age]
validates_unique(:name)
validates_length_range 3..20, :name
end
</pre>

To access the data in Sequel, one can use where clauses. For instance, to find Bob again one would use DB[:items].where(Sequel.like(:name, 'Bob'). While the ability to use SQL-like where clauses is quite flexible, it is not quite as pure an object-oriented approach as Active Record's dynamically created find methods.

Some of the key features of sequel are,
* [http://sequel.jeremyevans.net/rdoc/classes/Sequel/ThreadedConnectionPool.html Connection Pooling]
* Thread Safety
* [http://guides.rubyonrails.org/active_record_querying.html#eager-loading-associations Eager Loading] / Lazy Loading
* Model Caching
* Supports advanced database features such as prepared statements, bound variables, stored procedures, savepoints, two-phase commit, transaction isolation, master/slave configurations, and database sharing.

==Data Mapper==
[http://datamapper.org/ DataMapper] is an Object Relational Mapper written in Ruby developed by Sam Smoot with the goal to create an ORM which is fast, thread-safe and feature rich.
A Data Mapper is a Data Access Layer that performs bidirectional transfer of data between a persistent data store (often a relational database) and an in memory data representation (the domain layer). The goal of the pattern is to keep the in memory representation and the persistent data store independent of each other and the data mapper itself. The layer is composed of one or more mappers (or Data Access Objects), performing the data transfer.
DataMapper comes with the ability to use the same API to talk to a multitude of different datastores. There are adapters for the usual RDBMS suspects, NoSQL stores, various file formats and some web services. With DataMapper, you define your mappings in your model. Your data store can develop independently of your model using Migrations.

Some features of Data Mapper are as follows :
* No need to write structural migrations
* Scoped relations
* Lazy loading on certain attribute types
* Strategic eager loading to avoid (N+1) queries
* Default support for composite and natural keys
* Query chaining, and not evaluating the query until absolutely necessary (using a lazy array implementation)
* An API not too heavily oriented to SQL databases

DataMapper was designed to be a more abstract ORM, not strictly SQL, based on Martin Fowler's enterprise pattern. As a result, DataMapper adapters have been built for other non-SQL databases, such as CouchDB, [http://github.com/lritter/dm-solr-adapter/tree/master Apache Solr], and webservices such as [http://github.com/halorgium/dm-salesforce/tree/master Salesforce].

Example of table definition in the model:
<pre>
class User
include DataMapper::Resource

property :id, Serial # key
property :name, String, :required => true, :unique => true
property :age, String, :required => true, :length => 3..20
property :email, String

has n, :posts # one to many association
has n, :cheers # one to many association
end
</pre>

Notice that in the example above , ":required = true" is an example for Auto Validation. Unlike ActiveRecord and Sequel, DataMapper supports auto validations , i.e. these in turn call the validation helpers to enforce basic validations such as length, uniqueness, format, presence etc.

==MyBatis/iBatis==
[http://en.wikipedia.org/wiki/MyBatis MyBatis/iBatis] was a persistence framework which allowed easy access of the database from a Rails application without being a full ORM. It was created by the Apache Foundation in 2002, and is available for several platforms, including Ruby (the Ruby release is known as RBatis). On 6/16/2010, after releasing iBATIS 3.0, the project team moved from Apache to Google Code, changed the project's name to MyBatis, and stopped supporting Ruby.

The MyBatis data mapper framework makes it easier to use a relational database with object-oriented applications. MyBatis couples objects with stored procedures or SQL statements using a XML descriptor. To use the MyBatis data mapper,we make use of our own objects, XML, and SQL.

SQL statements are stored in XML files or annotations. Following is a MyBatis mapper, that consists of a Java interface with some MyBatis annotations:
<pre>
package org.mybatis.example;

public interface BlogMapper {
@Select("select * from Blog where id = #{id}")
Blog selectBlog(int id);
}
</pre>
The sentence is executed as follows.
<pre>
BlogMapper mapper = session.getMapper(BlogMapper.class);
Blog blog = mapper.selectBlog(101);
</pre>

It can also be executed using MyBatis API.
<pre>
Blog blog = session.selectOne("org.mybatis.example.BlogMapper.selectBlog", 101);
</pre>

SQL statements and mappings can also be externalized to an XML file like this.
<pre>
<?xml version="1.0" encoding="UTF-8" ?>
<!DOCTYPE mapper PUBLIC "-//mybatis.org//DTD Mapper 3.0//EN" "http://mybatis.org/dtd/mybatis-3-mapper.dtd">

<mapper namespace="org.mybatis.example.BlogMapper">
<select id="selectBlog" parameterType="int" resultType="Blog">
select * from Blog where id = #{id}
</select>
</mapper>
</pre>

==Squeel==
[http://rubydoc.info/gems/squeel/1.1.1/frames Squeel]unlocks the power of Arel in Rails applications with a handy block-based syntax. It is supporting in Rails 3 and 4. With Squeel, you can write subqueries, access named functions provided by RDMBS and more without writing SQL strings.
Squeel lets you write your Active Record queries with fewer strings, and more Ruby, by making the Arel awesomeness that lies beneath Active Record more accessible.

Squeel lets you rewrite...

<pre>
Article.where ['created_at >= ?', 2.weeks.ago]
...as...
Article.where{created_at >= 2.weeks.ago}
</pre>

Squeel enhances the normal Active Record query methods by enabling them to accept blocks. Inside a block, the Squeel query DSL can be used. Note the use of curly braces in the above example instead of parentheses. {} denotes a Squeel DSL query.

Stubs and keypaths are the two primary building blocks used in a Squeel DSL query.

Stubs are, for most intents and purposes, just like Symbols in a normal call to Relation#where (note the need for doubling up on the curly braces here, the first ones start the block, the second are the hash braces):
<pre>
Person.where{{name => ‘Ernie’ }}
</pre>

You normally wouldn't bother using the DSL in this case, as a simple hash would suffice. However, stubs serve as a building block for keypaths, and keypaths are very handy.

A Squeel keypath is essentially a more concise and readable alternative to a deeply nested hash. For instance, in standard Active Record, you might join several associations like this to perform a query:
<pre>
Person.joins(:articles => { :comments => :person}).references(:all)
</pre>

With a keypath, this would look like:
<pre>
Person.joins{articles.comments.person}.references(:all)
</pre>

The Squeel DSL works its magic using instance_eval which means that inside a Squeel DSL block, self isn't the same thing that it is outside the block.
This carries with it an important implication: Instance variables and instance methods inside the block won't refer to your object's variables/methods.
Use one of the following methods to get access to the object's methods and variables:
* Assign the variable locally before the DSL block, and access it as you would normally.
* Supply an arity to the DSL block, as in Person.where{|q| q.name == @my_name} Downside: You'll need to prefix stubs, keypaths, and functions with the DSL object.
* Wrap the method or instance variable inside the block with my{}. Person.where{name == my{some_method_to_return_a_name}}

==Merb==
[http://en.wikipedia.org/wiki/Merb Merb], short for "Mongrel+Erb", is a model view controller framework written in Ruby. Merb was merged into Rails web framework on December 23, 2008 as part of the Ruby on Rails 3.0 release.
Merb itself provides only the controller of an MVC model which can be extended to create a full-stack application environment. This effectively means Merb itself is not an ORM but can accommodate other ORMs.
Some features of Merb are as follows :
* Speed - Merb is ORM, JavaScript library and template language agnostic, preferring plugins that add support for features rather than producing a monolithic library with everything in the core.
* Lightweight - Rather than trying to cram every feature into a single code, things are kept bare minimum without sacrificing anything important.
* Powerful and extensible - For any features not covered in Merb’s core, there are plugins.
Some basic Command distinction between Ruby on Rails and Merb :
{| class="comparison" border="1"
! Action
! Ruby on Rails
! Merb
|-
| Create new application 'app1' || rails new app1 || merb-gen app app1
|-
| Start server || rails server || merb
|-
| Start cluster of 3 beginning at port 3000 || N/A || merb -p 3000 -c 3
|-
| Interactive console || rails console || merb -i
|}

=Alternative to ORM=
==NonSQL databases==
Instead of ORM we can also use Object-Oriented Database Management System (OODBMS) or document-oriented database like XML, where in databases are designed to store object oriented values, thus eliminating the need to convert data to and from its SQL form. Document oriented databases also eliminates the need to retrieve objects as data rows. Query languages like XQuery can be used to retrieve data sets.

The only issue is we won't be able to create application independent queries for retrieving data without restrictions to access path. Also OODBMS limits the extent of processing SQL queries.
A Relational database allows concurrent access to data, locking, indexing (fast search), as well as many other features that are not available while using XML files.

Other OODBMS (such as RavenDB) provide replication to SQL databases, as a means of addressing the need for ad-hoc queries, while preserving the increased performance and reduced complexity that may be achieved with an OODBMS for an application that has well-known query patterns.

NonSQL databases don’t provide mechanism to maintain relationship between tables. In real life though, business objects or entities do have relationship among them. ORM solutions may allow you to define these relationships in business objects and handle their storage and retrieval behind the scene

=Comparison of ORM Features=

{|cellspacing="0" border="1"
!style="width:8%"|Features
!style="width:23%"|ActiveRecord
!style="width:23%"|Sequel
!style="width:23%"|DataMapper
!style="width:23%"|MyBatis
|-
! Databases 
| MySQL, PostgreSQL, SQLite, Oracle, SQLServer, and DB2
| ADO, DataObjects, DB2, DBI, Firebird, Informix, JDBC, MySQL, ODBC, OpenBase, Oracle, PostgreSQL and SQLite3
| SQLite, MySQL, PostgreSQL, Oracle, MongoDB, SimpleDB, many others, including CouchDB, Apache Solr, Google Data API
| MySQL, PostgreSQL, SQLite, Oracle, SQLServer, and DB2
|-
! Migrations 
| Yes
| Yes
| Yes, but optional
| Yes, provides migration by Mybatis schema migration system.
|-
! EagerLoading 
| Supported by scanning the SQL fragments
| Supported using eager (preloading) and eager_graph (joins)
| Strategic Eager Loading and by using :summary
| Yes.this can be enabled or disabled by setting the lazyLoadingEnabled flag
|-
! Flexible Overriding 
| No. Overriding is done using alias methods.
| Using methods and by calling 'super'
| Using methods
| No
|-
! Dynamic Finders 
| Yes. Uses 'Method Missing'
| No. Alternative is to use <Model>.FindOrCreate(:name=>"John")
| Yes. Using the dm_ar_finders plugin
| Similar feature is supported in the form of Dynamic SQL
|}

=Further Reading=
To get more information on ORM and the different type of ORM's available for Ruby , please look into the [http://wiki.expertiza.ncsu.edu/index.php/CSC/ECE_517_Spring_2013/ch1_1d_zk CSC/ECE 517 Spring 2013/ch1 1d zk] and [http://wiki.expertiza.ncsu.edu/index.php/CSC/ECE_517_Fall_2010/ch3_3f_ac Fall 2010 detailed ORM explanation] wiki pages.
# [http://www.cs.colorado.edu/~kena/classes/5448/f11/lectures/29-orm.pdf ORM - University of Colorado]
# [http://www.lynda.com/Ruby-Rails-tutorials/Understanding-ActiveRecord-ActiveRelation/139989/159093-4.html Active Record Tutorial]
# [http://digitalcommons.macalester.edu/context/mathcs_honors/article/1006/type/native/viewcontent/ Research papers on object relational mapping]
# [http://www.sitepoint.com/top-ruby-frameworks-rails-and-merb-join-forces/ Merb and Rails]

=Future Work=
More work can be done in the area of comparison between the different ORMs available for Ruby, especially a more detailed feature-by-feature comparison that includes performance differences between the ORMs.

=References =
# [http://en.wikipedia.org/wiki/Object-relational_mapping Object Relational Mapping]
# [http://en.wikipedia.org/wiki/Object-oriented_programming object-oriented programming]
# [http://en.wikipedia.org/wiki/Data_access data access]
# [http://en.wikipedia.org/wiki/Metaprogramming metaprogramming]
# [http://guides.rubyonrails.org/active_record_basics.html Active Record]
# [http://guides.rubyonrails.org/getting_started.html#the-mvc-architecture MVC]
# [http://sequel.jeremyevans.net/documentation.html Sequel]
# [http://datamapper.org/ DataMapper]
# [http://sequel.jeremyevans.net/rdoc/classes/Sequel/ThreadedConnectionPool.html Connection Pooling]
# [http://guides.rubyonrails.org/active_record_querying.html#eager-loading-associations Eager Loading]
# [http://rubydoc.info/gems/squeel/1.1.1/frames Squeel]
# [http://www.techopedia.com/definition/24200/object-relational-mapping--orm ORM]
# [http://en.wikipedia.org/wiki/Merb Merb]
# [http://www.merbivore.com/ Merb Website]
# [http://wiki.expertiza.ncsu.edu/index.php/CSC/ECE_517_Spring_2013/ch1_1d_zk Object Relational Mapping Spring 2013]

=Citations=
<references/>

CSC/ECE 517 Fall 2014/ch1a 25 ks

2014-09-24T23:34:16Z

Knimgao: /* Active Recordshttp://guides.rubyonrails.org/active_record_basics.html */

=Object Relational Mapping=

__TOC__

==Introduction<ref>http://en.wikipedia.org/wiki/Object-relational_mapping</ref>==
Object Relation Mapping(ORM, O/RM, and O/R mapping) in computer science is a programming technique for converting data between incompatible type systems in object-oriented programming languages. This creates, in effect, a "virtual object database" that can be used from within the programming language. There are both free and commercial packages available that perform object-relational mapping, although some programmers opt to create their own ORM tools.

==Overview==
Object Relational Mapping is a programming technique in which a metadata descriptor is used to connect object code to a relational database. ORM converts data between type systems that are unable to coexist within relational databases and OOP languages.

In [http://en.wikipedia.org/wiki/Object-oriented_programming object-oriented programming], data management tasks act on object-oriented (OO) objects that are almost always non-scalar values. For example, consider an address book entry that represents a single person along with zero or more phone numbers and zero or more addresses. This could be modeled in an object-oriented implementation by a "Person object" with attributes/fields to hold each data item that the entry comprises: the person's name, a list of phone numbers, and a list of addresses. The list of phone numbers would itself contain "PhoneNumber objects" and so on. The address book entry is treated as a single object by the programming language (it can be referenced by a single variable containing a pointer to the object, for instance). Various methods can be associated with the object, such as a method to return the preferred phone number, the home address, and so on.

The heart of the problem is translating the logical representation of the objects into an atomized form that is capable of being stored in the database, while preserving the properties of the objects and their relationships so that they can be reloaded as objects when needed. If this storage and retrieval functionality is implemented, the objects are said to be persistent.

==Simple Explanation==
A simple answer is that you wrap your tables or stored procedures in classes in your programming language, so that instead of writing SQL statements to interact with your database, you use methods and properties of objects.

In other words, instead of something like this:
<pre>
String sql = "SELECT ... FROM persons WHERE id = 10"
DbCommand cmd = new DbCommand(connection, sql);
Result res = cmd.Execute();
String name = res[0]["FIRST_NAME"];
</pre>
you do something like this:
<pre>
Person p = repository.GetPerson(10);
String name = p.FirstName;
</pre>
or similar code (lots of variations here.) Some frameworks also put a lot of the code in as static methods on the classes themselves, which means you could do something like this instead:
<pre>
Person p = Person.Get(10);
</pre>
Some also implement complex query systems, so you could do this:
<pre>
Person p = Person.Get(Person.Properties.Id == 10);
</pre>
The framework is what makes this code possible.

==Features<ref>http://wiki.expertiza.ncsu.edu/index.php/CSC/ECE_517_Spring_2013/ch1_1d_zk</ref>==
Object-relational Mapping (ORM) frameworks unburden the designer of the complex translation between database and object space.

Typical ORM features:
* Automatic mapping from classes to database tables
** Class instance variables to database columns
** Class instances to table rows
* Aggregation and association relationships between mapped classes are managed
** Example, :has_many, :belongs_to associations in ActiveRecord
** Inheritance cases are mapped to tables
* Validation of data prior to table storage
* Class extensions to enable search, as well as creation, read, update, and deletion (CRUD) of instances/records
* Usually abstracts the database from program space in such a way that alternate database types can be easily chosen (SQLite, Oracle, etc)

The diagram below depicts a simple mapping of an object to a database table….

[[Image:3j_ks_pic1.jpg]]

ORM framework is used to persist model objects to a relational database and retrieve them, and the ORM framework will take care of converting the data between the two otherwise incompatible states. Most ORM tools rely heavily on metadata about both the database and objects, so that the objects need to know nothing about the database and the database doesn’t need to know anything about how the data is structured in the application. ORM provides a clean separation of concerns in a well-designed data application, and the database and application can each work with data in its native form. Database rows map to objects, thus making the program more easily accessible and allowing the usage of information in a way that is internally consistent and easy to understand. The ORM gives the programmer an ability to manipulate data with the programming language, instead of having to manipulate each attribute as its data type as obtained by the database management system.

When applied to Ruby, implementations of ORM often leverage the language’s [http://en.wikipedia.org/wiki/Metaprogramming metaprogramming] strengths to create intuitive application-specific methods and otherwise extend classes to support database functionality. With the addition of Rails, the ORM becomes much more important, as it is necessary to have an ORM to connect the models of the MVC (model-view-controller) stack used by Ruby on Rails with the application's database. Since the models are Ruby objects, the ORM allows modifications to the database to be done through changes to these models, independent of the type of database used.

With the release of Rails 3.0, the platform became ORM independent. With this change, it is much easier to use the ORM most preferred by the programmer, rather than being corralled into using one particular one. To allow this, the ORM needed to be extracted from the model and the database, to be a pure mediator between the two. Then any ORM can be used as long as it can successfully understand the model and the database used.

==Advantages<ref>http://www.techopedia.com/definition/24200/object-relational-mapping--orm</ref>==
In addition to the [http://en.wikipedia.org/wiki/Data_access data access] technique, ORM's benefits also include:
*First of all, you hide the SQL away from your logic code. This has the benefit of allowing you to more easily support more database engines. For instance, MS SQL Server and Oracle has different names on typical functions, and different ways to do calculations with dates, so a query to "get me all persons edited the last 24 hours" might entail different SQL syntax just for those two database engines. This difference can be put away from your logic code.
*Additionally, you can focus on writing the logic, instead of getting all the SQL right. The code will typically be more readable as well, since it doesn't contain all the "plumbing" necessary to talk to the database.
*Simplified development because it automates object-to-table and table-to-object conversion, resulting in lower development and maintenance costs
*Less code compared to embedded SQL and handwritten stored procedures
*Transparent object caching in the application tier, improving system performance
*An optimized solution making an application faster and easier to maintain

==Disadvantages==
*ORM’s emergence in multiple application development has created disagreement among experts. Key concerns are that ORM does not perform well and that stored procedures might be a better solution.
*In addition, ORM dependence may result in poorly-designed databases in certain circumstances.
*Performance – like every "proxy" technology
*Complexity – learning curve
*Difficulty / inability to make complex queries

=ORM Frameworks=

==Active Records==
[http://guides.rubyonrails.org/active_record_basics.html Active Record] was described by Martin Fowler in his book Patterns of Enterprise Application Architecture. Active Record is the M in [http://guides.rubyonrails.org/getting_started.html#the-mvc-architecture MVC]- the model - which is the layer of the system responsible for representing business data and logic. In Active Record, objects carry both persistent data and behavior which operates on that data. A database table or view is wrapped into a class and an object instance is tied to a single row in the table. Each Active Record object has CRUD (Create, Read, Update, and Delete) methods for database access. In addition, Active Record allows you to validate the state of a model before it gets written into the database.

Active Record gives us several mechanisms, the most important being the ability to:
* Represent models and their data.
* Represent associations between these models.
* Represent inheritance hierarchies through related models.
* Validate models before they get persisted to the database.
* Perform database operations in an object-oriented fashion.

The naming conventions used in Active Records are :
* Database Table - Plural with underscores separating words (e.g., book_clubs).
* Model Class - Singular with the first letter of each word capitalized (e.g., BookClub).

To create a table, ActiveRecord makes use of a migration class rather than including table definition in the actual class being modeled. As an example, the following code creates a table ‘’users’’ to store a collection of class ‘’User’’ objects:
<pre>
class CreateUsers < ActiveRecord::Migration
def self.up
create_table :users do |t|
t.string :name
t.string :email
t.string :age
t.references :cheer
t.references :post

t.timestamps # add creation and modification timestamps
end
end

def self.down # undo the table creation
drop_table :users
end
end
</pre>

The ActiveRecord’s migration scheme provides a means for backing out changes via the ‘’self.down’’ method. In addition, a table key ‘’id’’ is added to the new table without an explicit definition and record creation and modification timestamps are included via the ‘’timestamps’’ method provided by ActiveRecord.

ActiveRecord manages associations between table elements and provides the means to define such associations in the model definition. For example, the ‘’User’’ class shown below defines a ‘’has_many’’ (one-to-many) association with both the cheers and posts tables. These associations are represented in the migration class with the references operator. Also note ActiveRecord’s integrated support for validation of table information when attempting an update.

<pre>
class User < ActiveRecord::Base
has_many :cheers
has_many :posts

validates_presence_of :name
validates_presence_of :age
validates_uniqueness_of :name
validates_length_of :name, :within => 3..20
end
</pre>

To access the data in the table one calls the class function related to that column. For example, to find the user who's name is Bob, one would use @user = User.find_by_name('Bob'). Then one could find Bob's e-mail by using @user.email. Users can be searched for by any attribute in this way, as find methods are created for every combination of attributes.
While ActiveRecord provides the flexibility to create more sophisticated table relationships to represent class hierarchy, its base scheme is a single table inheritance, which trades some storage efficiency for simplicity in the database design. The following figure illustrates this concept of simplicity over efficiency.

[[Image:3j_ks_pic2.jpg]]

'''Pros''' -
* Integrated with popular Rails development framework
* Dynamically created database search methods (eg: User.find_by_address) ease db queries and make queries database syntax independent
* DB creation/management using the migrate scheme provides a means for backing out unwanted table changes
'''Cons''' -
* DB creation/management is decoupled from the model, requiring a separate utility (rake/migrate) that must be kept in sync with application.

==ORM Adaptor==
[https://github.com/ianwhite/orm_adapter ORM Adaptors] provide a single point of entry for popular ruby ORMs. Its target audience is gem authors who want to support more than one ORM.
ORM Adapter's goal is to support a minimum API used by most of the plugins that needs agnosticism beyond Active Model.
ORM Adapter will support only basic methods, as get, find_first, create! and so forth. It is not ORM Adapter's goal to support different query constructions, handle table joins, etc.
ORM adapter provides a consistent API for these basic class or 'factory' methods. It does not attempt to unify the behaviour of model instances returned by these methods. This means that unifying the behaviour of methods such as `model.save`, and `model.valid?` is beyond the scope of orm_adapter.
If you need complex queries, it is recommended to subclass ORM Adapters in your plugin and extend it expressing these query conditions as part of your domain logic.
<pre>
Example :
require 'orm_adapter'
User # is it an ActiveRecord, DM Resource, MongoMapper or MongoId Document?
User.to_adapter.find_first :name => 'Fred' # we don't care!
user_model = User.to_adapter
user_model.get!(1) # find a record by id
user_model.find_first(:name => 'fred') # find first fred
user_model.find_first(:level => 'awesome', :id => 23) # find user 23, only if it's level is awesome
user_model.find_all # find all users
user_model.find_all(:name => 'fred') # find all freds
user_model.find_all(:order => :name) # find all freds, ordered by name
user_model.create!(:name => 'fred') # create a fred
user_model.destroy(object) # destroy the user object
</pre>

==Sequel==
[http://sequel.jeremyevans.net/documentation.html Sequel] was originally developed by Sharon Rosner and the first release was in March 2007. It is based on the active record pattern. Sequel and Active Record share a lot of common features , for example association and inheritance. But Sequel handles these features in a much more flexible manner. Currently Sequel is at version 3.44.0. Initially Sequel had three core modules - sequel, sequel_core and sequel_model. Starting from version 1.4 , sequel and sequel_model were merged. Sequel handles validations using a validation plug-in and helpers.

<pre>
class CreateUser < Sequel::Migration
def up
create_table(:user) {
primary_key :id
String :name
String :age
String :email}
end
def down
drop_table(:user)
end
end # CreateUser.apply(DB, :up)
</pre>

Sequel supports associations and validations similar to Active Record. The following example shows how validations and associations can be enforced in the User table that has been created above. It enforces one to many relationships between the user table and the cheers and posts tables. It also validates for the presence , uniqueness and the length of the attribute '''name'''.

<pre>
class User < Sequel::Model
one_to_many :cheers
one_to_many :posts

validates_presence [:name, :age]
validates_unique(:name)
validates_length_range 3..20, :name
end
</pre>

To access the data in Sequel, one can use where clauses. For instance, to find Bob again one would use DB[:items].where(Sequel.like(:name, 'Bob'). While the ability to use SQL-like where clauses is quite flexible, it is not quite as pure an object-oriented approach as Active Record's dynamically created find methods.

Some of the key features of sequel are,
* [http://sequel.jeremyevans.net/rdoc/classes/Sequel/ThreadedConnectionPool.html Connection Pooling]
* Thread Safety
* [http://guides.rubyonrails.org/active_record_querying.html#eager-loading-associations Eager Loading] / Lazy Loading
* Model Caching
* Supports advanced database features such as prepared statements, bound variables, stored procedures, savepoints, two-phase commit, transaction isolation, master/slave configurations, and database sharding.

==Data Mapper==
[http://datamapper.org/ DataMapper] is an Object Relational Mapper written in Ruby developed by Sam Smoot with the goal to create an ORM which is fast, thread-safe and feature rich.
A Data Mapper is a Data Access Layer that performs bidirectional transfer of data between a persistent data store (often a relational database) and an in memory data representation (the domain layer). The goal of the pattern is to keep the in memory representation and the persistent data store independent of each other and the data mapper itself. The layer is composed of one or more mappers (or Data Access Objects), performing the data transfer.
DataMapper comes with the ability to use the same API to talk to a multitude of different datastores. There are adapters for the usual RDBMS suspects, NoSQL stores, various file formats and some web services. With DataMapper, you define your mappings in your model. Your data store can develop independently of your model using Migrations.

Some features of Data Mapper are as follows :
* No need to write structural migrations
* Scoped relations
* Lazy loading on certain attribute types
* Strategic eager loading to avoid (N+1) queries
* Default support for composite and natural keys
* Query chaining, and not evaluating the query until absolutely necessary (using a lazy array implementation)
* An API not too heavily oriented to SQL databases

DataMapper was designed to be a more abstract ORM, not strictly SQL, based on Martin Fowler's enterprise pattern. As a result, DataMapper adapters have been built for other non-SQL databases, such as CouchDB, [http://github.com/lritter/dm-solr-adapter/tree/master Apache Solr], and webservices such as [http://github.com/halorgium/dm-salesforce/tree/master Salesforce].

Example of table definition in the model:
<pre>
class User
include DataMapper::Resource

property :id, Serial # key
property :name, String, :required => true, :unique => true
property :age, String, :required => true, :length => 3..20
property :email, String

has n, :posts # one to many association
has n, :cheers # one to many association
end
</pre>

Notice that in the example above , ":required = true" is an example for Auto Validation. Unlike ActiveRecord and Sequel, DataMapper supports auto validations , i.e. these in turn call the validation helpers to enforce basic validations such as length, uniqueness, format, presence etc.

==MyBatis/iBatis==
[http://en.wikipedia.org/wiki/MyBatis MyBatis/iBatis] was a persistence framework which allowed easy access of the database from a Rails application without being a full ORM. It was created by the Apache Foundation in 2002, and is available for several platforms, including Ruby (the Ruby release is known as RBatis). On 6/16/2010, after releasing iBATIS 3.0, the project team moved from Apache to Google Code, changed the project's name to MyBatis, and stopped supporting Ruby.

The MyBatis data mapper framework makes it easier to use a relational database with object-oriented applications. MyBatis couples objects with stored procedures or SQL statements using a XML descriptor. To use the MyBatis data mapper,we make use of our own objects, XML, and SQL.

SQL statements are stored in XML files or annotations. Following is a MyBatis mapper, that consists of a Java interface with some MyBatis annotations:
<pre>
package org.mybatis.example;

public interface BlogMapper {
@Select("select * from Blog where id = #{id}")
Blog selectBlog(int id);
}
</pre>
The sentence is executed as follows.
<pre>
BlogMapper mapper = session.getMapper(BlogMapper.class);
Blog blog = mapper.selectBlog(101);
</pre>

It can also be executed using MyBatis API.
<pre>
Blog blog = session.selectOne("org.mybatis.example.BlogMapper.selectBlog", 101);
</pre>

SQL statements and mappings can also be externalized to an XML file like this.
<pre>
<?xml version="1.0" encoding="UTF-8" ?>
<!DOCTYPE mapper PUBLIC "-//mybatis.org//DTD Mapper 3.0//EN" "http://mybatis.org/dtd/mybatis-3-mapper.dtd">

<mapper namespace="org.mybatis.example.BlogMapper">
<select id="selectBlog" parameterType="int" resultType="Blog">
select * from Blog where id = #{id}
</select>
</mapper>
</pre>

==Squeel==
[http://rubydoc.info/gems/squeel/1.1.1/frames Squeel]unlocks the power of Arel in Rails applications with a handy block-based syntax. It is supporting in Rails 3 and 4. With Squeel, you can write subqueries, access named functions provided by RDMBS and more without writing SQL strings.
Squeel lets you write your Active Record queries with fewer strings, and more Ruby, by making the Arel awesomeness that lies beneath Active Record more accessible.

Squeel lets you rewrite...

<pre>
Article.where ['created_at >= ?', 2.weeks.ago]
...as...
Article.where{created_at >= 2.weeks.ago}
</pre>

Squeel enhances the normal Active Record query methods by enabling them to accept blocks. Inside a block, the Squeel query DSL can be used. Note the use of curly braces in the above example instead of parentheses. {} denotes a Squeel DSL query.

Stubs and keypaths are the two primary building blocks used in a Squeel DSL query.

Stubs are, for most intents and purposes, just like Symbols in a normal call to Relation#where (note the need for doubling up on the curly braces here, the first ones start the block, the second are the hash braces):
<pre>
Person.where{{name => ‘Ernie’ }}
</pre>

You normally wouldn't bother using the DSL in this case, as a simple hash would suffice. However, stubs serve as a building block for keypaths, and keypaths are very handy.

A Squeel keypath is essentially a more concise and readable alternative to a deeply nested hash. For instance, in standard Active Record, you might join several associations like this to perform a query:
<pre>
Person.joins(:articles => { :comments => :person}).references(:all)
</pre>

With a keypath, this would look like:
<pre>
Person.joins{articles.comments.person}.references(:all)
</pre>

The Squeel DSL works its magic using instance_eval which means that inside a Squeel DSL block, self isn't the same thing that it is outside the block.
This carries with it an important implication: Instance variables and instance methods inside the block won't refer to your object's variables/methods.
Use one of the following methods to get access to the object's methods and variables:
* Assign the variable locally before the DSL block, and access it as you would normally.
* Supply an arity to the DSL block, as in Person.where{|q| q.name == @my_name} Downside: You'll need to prefix stubs, keypaths, and functions with the DSL object.
* Wrap the method or instance variable inside the block with my{}. Person.where{name == my{some_method_to_return_a_name}}

==Merb==
[http://en.wikipedia.org/wiki/Merb Merb], short for "Mongrel+Erb", is a model view controller framework written in Ruby. Merb was merged into Rails web framework on December 23, 2008 as part of the Ruby on Rails 3.0 release.
Merb itself provides only the controller of an MVC model which can be extended to create a full-stack application environment. This effectively means Merb itself is not an ORM but can accommodate other ORMs.
Some features of Merb are as follows :
* Speed - Merb is ORM, JavaScript library and template language agnostic, preferring plugins that add support for features rather than producing a monolithic library with everything in the core.
* Lightweight - Rather than trying to cram every feature into a single code, things are kept bare minimum without sacrificing anything important.
* Powerful and extensible - For any features not covered in Merb’s core, there are plugins.
Some basic Command distinction between Ruby on Rails and Merb :
{| class="comparison" border="1"
! Action
! Ruby on Rails
! Merb
|-
| Create new application 'app1' || rails new app1 || merb-gen app app1
|-
| Start server || rails server || merb
|-
| Start cluster of 3 beginning at port 3000 || N/A || merb -p 3000 -c 3
|-
| Interactive console || rails console || merb -i
|}

=Alternative to ORM=
==NonSQL databases==
Instead of ORM we can also use Object-Oriented Database Management System (OODBMS) or document-oriented database like XML, where in databases are designed to store object oriented values, thus eliminating the need to convert data to and from its SQL form. Document oriented databases also eliminates the need to retrieve objects as data rows. Query languages like XQuery can be used to retrieve data sets.

The only issue is we won't be able to create application independent queries for retrieving data without restrictions to access path. Also OODBMS limits the extent of processing SQL queries.
A Relational database allows concurrent access to data, locking, indexing (fast search), as well as many other features that are not available while using XML files.

Other OODBMS (such as RavenDB) provide replication to SQL databases, as a means of addressing the need for ad-hoc queries, while preserving the increased performance and reduced complexity that may be achieved with an OODBMS for an application that has well-known query patterns.

NonSQL databases don’t provide mechanism to maintain relationship between tables. In real life though, business objects or entities do have relationship among them. ORM solutions may allow you to define these relationships in business objects and handle their storage and retrieval behind the scene

=Comparison of ORM Features=

{|cellspacing="0" border="1"
!style="width:8%"|Features
!style="width:23%"|ActiveRecord
!style="width:23%"|Sequel
!style="width:23%"|DataMapper
!style="width:23%"|MyBatis
|-
! Databases 
| MySQL, PostgreSQL, SQLite, Oracle, SQLServer, and DB2
| ADO, DataObjects, DB2, DBI, Firebird, Informix, JDBC, MySQL, ODBC, OpenBase, Oracle, PostgreSQL and SQLite3
| SQLite, MySQL, PostgreSQL, Oracle, MongoDB, SimpleDB, many others, including CouchDB, Apache Solr, Google Data API
| MySQL, PostgreSQL, SQLite, Oracle, SQLServer, and DB2
|-
! Migrations 
| Yes
| Yes
| Yes, but optional
| Yes, provides migration by Mybatis schema migration system.
|-
! EagerLoading 
| Supported by scanning the SQL fragments
| Supported using eager (preloading) and eager_graph (joins)
| Strategic Eager Loading and by using :summary
| Yes.this can be enabled or disabled by setting the lazyLoadingEnabled flag
|-
! Flexible Overriding 
| No. Overriding is done using alias methods.
| Using methods and by calling 'super'
| Using methods
| No
|-
! Dynamic Finders 
| Yes. Uses 'Method Missing'
| No. Alternative is to use <Model>.FindOrCreate(:name=>"John")
| Yes. Using the dm_ar_finders plugin
| Similar feature is supported in the form of Dynamic SQL
|}

=Further Reading=
To get more information on ORM and the different type of ORM's available for Ruby , please look into the [http://wiki.expertiza.ncsu.edu/index.php/CSC/ECE_517_Spring_2013/ch1_1d_zk CSC/ECE 517 Spring 2013/ch1 1d zk] and [http://wiki.expertiza.ncsu.edu/index.php/CSC/ECE_517_Fall_2010/ch3_3f_ac Fall 2010 detailed ORM explanation] wiki pages.
# [http://www.cs.colorado.edu/~kena/classes/5448/f11/lectures/29-orm.pdf ORM - University of Colorado]
# [http://www.lynda.com/Ruby-Rails-tutorials/Understanding-ActiveRecord-ActiveRelation/139989/159093-4.html Active Record Tutorial]
# [http://digitalcommons.macalester.edu/context/mathcs_honors/article/1006/type/native/viewcontent/ Research papers on object relational mapping]
# [http://www.sitepoint.com/top-ruby-frameworks-rails-and-merb-join-forces/ Merb and Rails]

=Future Work=
More work can be done in the area of comparison between the different ORMs available for Ruby, especially a more detailed feature-by-feature comparison that includes performance differences between the ORMs.

=References =
# [http://en.wikipedia.org/wiki/Object-relational_mapping Object Relational Mapping]
# [http://en.wikipedia.org/wiki/Object-oriented_programming object-oriented programming]
# [http://en.wikipedia.org/wiki/Data_access data access]
# [http://en.wikipedia.org/wiki/Metaprogramming metaprogramming]
# [http://guides.rubyonrails.org/active_record_basics.html Active Record]
# [http://guides.rubyonrails.org/getting_started.html#the-mvc-architecture MVC]
# [http://sequel.jeremyevans.net/documentation.html Sequel]
# [http://datamapper.org/ DataMapper]
# [http://sequel.jeremyevans.net/rdoc/classes/Sequel/ThreadedConnectionPool.html Connection Pooling]
# [http://guides.rubyonrails.org/active_record_querying.html#eager-loading-associations Eager Loading]
# [http://rubydoc.info/gems/squeel/1.1.1/frames Squeel]
# [http://www.techopedia.com/definition/24200/object-relational-mapping--orm ORM]
# [http://en.wikipedia.org/wiki/Merb Merb]
# [http://www.merbivore.com/ Merb Website]
# [http://wiki.expertiza.ncsu.edu/index.php/CSC/ECE_517_Spring_2013/ch1_1d_zk Object Relational Mapping Spring 2013]

=Citations=
<references/>

CSC/ECE 517 Fall 2014/ch1a 25 ks

2014-09-24T23:31:37Z

Knimgao: /* Introductionhttp://en.wikipedia.org/wiki/Object-relational_mapping Object Relational Mapping */

=Object Relational Mapping=

__TOC__

==Introduction<ref>http://en.wikipedia.org/wiki/Object-relational_mapping</ref>==
Object Relation Mapping(ORM, O/RM, and O/R mapping) in computer science is a programming technique for converting data between incompatible type systems in object-oriented programming languages. This creates, in effect, a "virtual object database" that can be used from within the programming language. There are both free and commercial packages available that perform object-relational mapping, although some programmers opt to create their own ORM tools.

==Overview==
Object Relational Mapping is a programming technique in which a metadata descriptor is used to connect object code to a relational database. ORM converts data between type systems that are unable to coexist within relational databases and OOP languages.

In [http://en.wikipedia.org/wiki/Object-oriented_programming object-oriented programming], data management tasks act on object-oriented (OO) objects that are almost always non-scalar values. For example, consider an address book entry that represents a single person along with zero or more phone numbers and zero or more addresses. This could be modeled in an object-oriented implementation by a "Person object" with attributes/fields to hold each data item that the entry comprises: the person's name, a list of phone numbers, and a list of addresses. The list of phone numbers would itself contain "PhoneNumber objects" and so on. The address book entry is treated as a single object by the programming language (it can be referenced by a single variable containing a pointer to the object, for instance). Various methods can be associated with the object, such as a method to return the preferred phone number, the home address, and so on.

The heart of the problem is translating the logical representation of the objects into an atomized form that is capable of being stored in the database, while preserving the properties of the objects and their relationships so that they can be reloaded as objects when needed. If this storage and retrieval functionality is implemented, the objects are said to be persistent.

==Simple Explanation==
A simple answer is that you wrap your tables or stored procedures in classes in your programming language, so that instead of writing SQL statements to interact with your database, you use methods and properties of objects.

In other words, instead of something like this:
<pre>
String sql = "SELECT ... FROM persons WHERE id = 10"
DbCommand cmd = new DbCommand(connection, sql);
Result res = cmd.Execute();
String name = res[0]["FIRST_NAME"];
</pre>
you do something like this:
<pre>
Person p = repository.GetPerson(10);
String name = p.FirstName;
</pre>
or similar code (lots of variations here.) Some frameworks also put a lot of the code in as static methods on the classes themselves, which means you could do something like this instead:
<pre>
Person p = Person.Get(10);
</pre>
Some also implement complex query systems, so you could do this:
<pre>
Person p = Person.Get(Person.Properties.Id == 10);
</pre>
The framework is what makes this code possible.

==Features<ref>http://wiki.expertiza.ncsu.edu/index.php/CSC/ECE_517_Spring_2013/ch1_1d_zk</ref>==
Object-relational Mapping (ORM) frameworks unburden the designer of the complex translation between database and object space.

Typical ORM features:
* Automatic mapping from classes to database tables
** Class instance variables to database columns
** Class instances to table rows
* Aggregation and association relationships between mapped classes are managed
** Example, :has_many, :belongs_to associations in ActiveRecord
** Inheritance cases are mapped to tables
* Validation of data prior to table storage
* Class extensions to enable search, as well as creation, read, update, and deletion (CRUD) of instances/records
* Usually abstracts the database from program space in such a way that alternate database types can be easily chosen (SQLite, Oracle, etc)

The diagram below depicts a simple mapping of an object to a database table….

[[Image:3j_ks_pic1.jpg]]

ORM framework is used to persist model objects to a relational database and retrieve them, and the ORM framework will take care of converting the data between the two otherwise incompatible states. Most ORM tools rely heavily on metadata about both the database and objects, so that the objects need to know nothing about the database and the database doesn’t need to know anything about how the data is structured in the application. ORM provides a clean separation of concerns in a well-designed data application, and the database and application can each work with data in its native form. Database rows map to objects, thus making the program more easily accessible and allowing the usage of information in a way that is internally consistent and easy to understand. The ORM gives the programmer an ability to manipulate data with the programming language, instead of having to manipulate each attribute as its data type as obtained by the database management system.

When applied to Ruby, implementations of ORM often leverage the language’s [http://en.wikipedia.org/wiki/Metaprogramming metaprogramming] strengths to create intuitive application-specific methods and otherwise extend classes to support database functionality. With the addition of Rails, the ORM becomes much more important, as it is necessary to have an ORM to connect the models of the MVC (model-view-controller) stack used by Ruby on Rails with the application's database. Since the models are Ruby objects, the ORM allows modifications to the database to be done through changes to these models, independent of the type of database used.

With the release of Rails 3.0, the platform became ORM independent. With this change, it is much easier to use the ORM most preferred by the programmer, rather than being corralled into using one particular one. To allow this, the ORM needed to be extracted from the model and the database, to be a pure mediator between the two. Then any ORM can be used as long as it can successfully understand the model and the database used.

==Advantages<ref>http://www.techopedia.com/definition/24200/object-relational-mapping--orm</ref>==
In addition to the [http://en.wikipedia.org/wiki/Data_access data access] technique, ORM's benefits also include:
*First of all, you hide the SQL away from your logic code. This has the benefit of allowing you to more easily support more database engines. For instance, MS SQL Server and Oracle has different names on typical functions, and different ways to do calculations with dates, so a query to "get me all persons edited the last 24 hours" might entail different SQL syntax just for those two database engines. This difference can be put away from your logic code.
*Additionally, you can focus on writing the logic, instead of getting all the SQL right. The code will typically be more readable as well, since it doesn't contain all the "plumbing" necessary to talk to the database.
*Simplified development because it automates object-to-table and table-to-object conversion, resulting in lower development and maintenance costs
*Less code compared to embedded SQL and handwritten stored procedures
*Transparent object caching in the application tier, improving system performance
*An optimized solution making an application faster and easier to maintain

==Disadvantages==
*ORM’s emergence in multiple application development has created disagreement among experts. Key concerns are that ORM does not perform well and that stored procedures might be a better solution.
*In addition, ORM dependence may result in poorly-designed databases in certain circumstances.
*Performance – like every "proxy" technology
*Complexity – learning curve
*Difficulty / inability to make complex queries

=ORM Frameworks=

==Active Records<ref>http://guides.rubyonrails.org/active_record_basics.html</ref>==
Active Record was described by Martin Fowler in his book Patterns of Enterprise Application Architecture. Active Record is the M in [http://guides.rubyonrails.org/getting_started.html#the-mvc-architecture MVC]- the model - which is the layer of the system responsible for representing business data and logic. In Active Record, objects carry both persistent data and behavior which operates on that data. A database table or view is wrapped into a class and an object instance is tied to a single row in the table. Each Active Record object has CRUD (Create, Read, Update, and Delete) methods for database access. In addition, Active Record allows you to validate the state of a model before it gets written into the database.

Active Record gives us several mechanisms, the most important being the ability to:
* Represent models and their data.
* Represent associations between these models.
* Represent inheritance hierarchies through related models.
* Validate models before they get persisted to the database.
* Perform database operations in an object-oriented fashion.

The naming conventions used in Active Records are :
* Database Table - Plural with underscores separating words (e.g., book_clubs).
* Model Class - Singular with the first letter of each word capitalized (e.g., BookClub).

To create a table, ActiveRecord makes use of a migration class rather than including table definition in the actual class being modeled. As an example, the following code creates a table ‘’users’’ to store a collection of class ‘’User’’ objects:
<pre>
class CreateUsers < ActiveRecord::Migration
def self.up
create_table :users do |t|
t.string :name
t.string :email
t.string :age
t.references :cheer
t.references :post

t.timestamps # add creation and modification timestamps
end
end

def self.down # undo the table creation
drop_table :users
end
end
</pre>

The ActiveRecord’s migration scheme provides a means for backing out changes via the ‘’self.down’’ method. In addition, a table key ‘’id’’ is added to the new table without an explicit definition and record creation and modification timestamps are included via the ‘’timestamps’’ method provided by ActiveRecord.

ActiveRecord manages associations between table elements and provides the means to define such associations in the model definition. For example, the ‘’User’’ class shown below defines a ‘’has_many’’ (one-to-many) association with both the cheers and posts tables. These associations are represented in the migration class with the references operator. Also note ActiveRecord’s integrated support for validation of table information when attempting an update.

<pre>
class User < ActiveRecord::Base
has_many :cheers
has_many :posts

validates_presence_of :name
validates_presence_of :age
validates_uniqueness_of :name
validates_length_of :name, :within => 3..20
end
</pre>

To access the data in the table one calls the class function related to that column. For example, to find the user who's name is Bob, one would use @user = User.find_by_name('Bob'). Then one could find Bob's e-mail by using @user.email. Users can be searched for by any attribute in this way, as find methods are created for every combination of attributes.
While ActiveRecord provides the flexibility to create more sophisticated table relationships to represent class hierarchy, its base scheme is a single table inheritance, which trades some storage efficiency for simplicity in the database design. The following figure illustrates this concept of simplicity over efficiency.

[[Image:3j_ks_pic2.jpg]]

'''Pros''' -
* Integrated with popular Rails development framework
* Dynamically created database search methods (eg: User.find_by_address) ease db queries and make queries database syntax independent
* DB creation/management using the migrate scheme provides a means for backing out unwanted table changes
'''Cons''' -
* DB creation/management is decoupled from the model, requiring a separate utility (rake/migrate) that must be kept in sync with application.

==ORM Adaptor==
[https://github.com/ianwhite/orm_adapter ORM Adaptors] provide a single point of entry for popular ruby ORMs. Its target audience is gem authors who want to support more than one ORM.
ORM Adapter's goal is to support a minimum API used by most of the plugins that needs agnosticism beyond Active Model.
ORM Adapter will support only basic methods, as get, find_first, create! and so forth. It is not ORM Adapter's goal to support different query constructions, handle table joins, etc.
ORM adapter provides a consistent API for these basic class or 'factory' methods. It does not attempt to unify the behaviour of model instances returned by these methods. This means that unifying the behaviour of methods such as `model.save`, and `model.valid?` is beyond the scope of orm_adapter.
If you need complex queries, it is recommended to subclass ORM Adapters in your plugin and extend it expressing these query conditions as part of your domain logic.
<pre>
Example :
require 'orm_adapter'
User # is it an ActiveRecord, DM Resource, MongoMapper or MongoId Document?
User.to_adapter.find_first :name => 'Fred' # we don't care!
user_model = User.to_adapter
user_model.get!(1) # find a record by id
user_model.find_first(:name => 'fred') # find first fred
user_model.find_first(:level => 'awesome', :id => 23) # find user 23, only if it's level is awesome
user_model.find_all # find all users
user_model.find_all(:name => 'fred') # find all freds
user_model.find_all(:order => :name) # find all freds, ordered by name
user_model.create!(:name => 'fred') # create a fred
user_model.destroy(object) # destroy the user object
</pre>

==Sequel==
[http://sequel.jeremyevans.net/documentation.html Sequel] was originally developed by Sharon Rosner and the first release was in March 2007. It is based on the active record pattern. Sequel and Active Record share a lot of common features , for example association and inheritance. But Sequel handles these features in a much more flexible manner. Currently Sequel is at version 3.44.0. Initially Sequel had three core modules - sequel, sequel_core and sequel_model. Starting from version 1.4 , sequel and sequel_model were merged. Sequel handles validations using a validation plug-in and helpers.

<pre>
class CreateUser < Sequel::Migration
def up
create_table(:user) {
primary_key :id
String :name
String :age
String :email}
end
def down
drop_table(:user)
end
end # CreateUser.apply(DB, :up)
</pre>

Sequel supports associations and validations similar to Active Record. The following example shows how validations and associations can be enforced in the User table that has been created above. It enforces one to many relationships between the user table and the cheers and posts tables. It also validates for the presence , uniqueness and the length of the attribute '''name'''.

<pre>
class User < Sequel::Model
one_to_many :cheers
one_to_many :posts

validates_presence [:name, :age]
validates_unique(:name)
validates_length_range 3..20, :name
end
</pre>

To access the data in Sequel, one can use where clauses. For instance, to find Bob again one would use DB[:items].where(Sequel.like(:name, 'Bob'). While the ability to use SQL-like where clauses is quite flexible, it is not quite as pure an object-oriented approach as Active Record's dynamically created find methods.

Some of the key features of sequel are,
* [http://sequel.jeremyevans.net/rdoc/classes/Sequel/ThreadedConnectionPool.html Connection Pooling]
* Thread Safety
* [http://guides.rubyonrails.org/active_record_querying.html#eager-loading-associations Eager Loading] / Lazy Loading
* Model Caching
* Supports advanced database features such as prepared statements, bound variables, stored procedures, savepoints, two-phase commit, transaction isolation, master/slave configurations, and database sharding.

==Data Mapper==
[http://datamapper.org/ DataMapper] is an Object Relational Mapper written in Ruby developed by Sam Smoot with the goal to create an ORM which is fast, thread-safe and feature rich.
A Data Mapper is a Data Access Layer that performs bidirectional transfer of data between a persistent data store (often a relational database) and an in memory data representation (the domain layer). The goal of the pattern is to keep the in memory representation and the persistent data store independent of each other and the data mapper itself. The layer is composed of one or more mappers (or Data Access Objects), performing the data transfer.
DataMapper comes with the ability to use the same API to talk to a multitude of different datastores. There are adapters for the usual RDBMS suspects, NoSQL stores, various file formats and some web services. With DataMapper, you define your mappings in your model. Your data store can develop independently of your model using Migrations.

Some features of Data Mapper are as follows :
* No need to write structural migrations
* Scoped relations
* Lazy loading on certain attribute types
* Strategic eager loading to avoid (N+1) queries
* Default support for composite and natural keys
* Query chaining, and not evaluating the query until absolutely necessary (using a lazy array implementation)
* An API not too heavily oriented to SQL databases

DataMapper was designed to be a more abstract ORM, not strictly SQL, based on Martin Fowler's enterprise pattern. As a result, DataMapper adapters have been built for other non-SQL databases, such as CouchDB, [http://github.com/lritter/dm-solr-adapter/tree/master Apache Solr], and webservices such as [http://github.com/halorgium/dm-salesforce/tree/master Salesforce].

Example of table definition in the model:
<pre>
class User
include DataMapper::Resource

property :id, Serial # key
property :name, String, :required => true, :unique => true
property :age, String, :required => true, :length => 3..20
property :email, String

has n, :posts # one to many association
has n, :cheers # one to many association
end
</pre>

Notice that in the example above , ":required = true" is an example for Auto Validation. Unlike ActiveRecord and Sequel, DataMapper supports auto validations , i.e. these in turn call the validation helpers to enforce basic validations such as length, uniqueness, format, presence etc.

==MyBatis/iBatis==
[http://en.wikipedia.org/wiki/MyBatis MyBatis/iBatis] was a persistence framework which allowed easy access of the database from a Rails application without being a full ORM. It was created by the Apache Foundation in 2002, and is available for several platforms, including Ruby (the Ruby release is known as RBatis). On 6/16/2010, after releasing iBATIS 3.0, the project team moved from Apache to Google Code, changed the project's name to MyBatis, and stopped supporting Ruby.

The MyBatis data mapper framework makes it easier to use a relational database with object-oriented applications. MyBatis couples objects with stored procedures or SQL statements using a XML descriptor. To use the MyBatis data mapper,we make use of our own objects, XML, and SQL.

SQL statements are stored in XML files or annotations. Following is a MyBatis mapper, that consists of a Java interface with some MyBatis annotations:
<pre>
package org.mybatis.example;

public interface BlogMapper {
@Select("select * from Blog where id = #{id}")
Blog selectBlog(int id);
}
</pre>
The sentence is executed as follows.
<pre>
BlogMapper mapper = session.getMapper(BlogMapper.class);
Blog blog = mapper.selectBlog(101);
</pre>

It can also be executed using MyBatis API.
<pre>
Blog blog = session.selectOne("org.mybatis.example.BlogMapper.selectBlog", 101);
</pre>

SQL statements and mappings can also be externalized to an XML file like this.
<pre>
<?xml version="1.0" encoding="UTF-8" ?>
<!DOCTYPE mapper PUBLIC "-//mybatis.org//DTD Mapper 3.0//EN" "http://mybatis.org/dtd/mybatis-3-mapper.dtd">

<mapper namespace="org.mybatis.example.BlogMapper">
<select id="selectBlog" parameterType="int" resultType="Blog">
select * from Blog where id = #{id}
</select>
</mapper>
</pre>

==Squeel==
[http://rubydoc.info/gems/squeel/1.1.1/frames Squeel]unlocks the power of Arel in Rails applications with a handy block-based syntax. It is supporting in Rails 3 and 4. With Squeel, you can write subqueries, access named functions provided by RDMBS and more without writing SQL strings.
Squeel lets you write your Active Record queries with fewer strings, and more Ruby, by making the Arel awesomeness that lies beneath Active Record more accessible.

Squeel lets you rewrite...

<pre>
Article.where ['created_at >= ?', 2.weeks.ago]
...as...
Article.where{created_at >= 2.weeks.ago}
</pre>

Squeel enhances the normal Active Record query methods by enabling them to accept blocks. Inside a block, the Squeel query DSL can be used. Note the use of curly braces in the above example instead of parentheses. {} denotes a Squeel DSL query.

Stubs and keypaths are the two primary building blocks used in a Squeel DSL query.

Stubs are, for most intents and purposes, just like Symbols in a normal call to Relation#where (note the need for doubling up on the curly braces here, the first ones start the block, the second are the hash braces):
<pre>
Person.where{{name => ‘Ernie’ }}
</pre>

You normally wouldn't bother using the DSL in this case, as a simple hash would suffice. However, stubs serve as a building block for keypaths, and keypaths are very handy.

A Squeel keypath is essentially a more concise and readable alternative to a deeply nested hash. For instance, in standard Active Record, you might join several associations like this to perform a query:
<pre>
Person.joins(:articles => { :comments => :person}).references(:all)
</pre>

With a keypath, this would look like:
<pre>
Person.joins{articles.comments.person}.references(:all)
</pre>

The Squeel DSL works its magic using instance_eval which means that inside a Squeel DSL block, self isn't the same thing that it is outside the block.
This carries with it an important implication: Instance variables and instance methods inside the block won't refer to your object's variables/methods.
Use one of the following methods to get access to the object's methods and variables:
* Assign the variable locally before the DSL block, and access it as you would normally.
* Supply an arity to the DSL block, as in Person.where{|q| q.name == @my_name} Downside: You'll need to prefix stubs, keypaths, and functions with the DSL object.
* Wrap the method or instance variable inside the block with my{}. Person.where{name == my{some_method_to_return_a_name}}

==Merb==
[http://en.wikipedia.org/wiki/Merb Merb], short for "Mongrel+Erb", is a model view controller framework written in Ruby. Merb was merged into Rails web framework on December 23, 2008 as part of the Ruby on Rails 3.0 release.
Merb itself provides only the controller of an MVC model which can be extended to create a full-stack application environment. This effectively means Merb itself is not an ORM but can accommodate other ORMs.
Some features of Merb are as follows :
* Speed - Merb is ORM, JavaScript library and template language agnostic, preferring plugins that add support for features rather than producing a monolithic library with everything in the core.
* Lightweight - Rather than trying to cram every feature into a single code, things are kept bare minimum without sacrificing anything important.
* Powerful and extensible - For any features not covered in Merb’s core, there are plugins.
Some basic Command distinction between Ruby on Rails and Merb :
{| class="comparison" border="1"
! Action
! Ruby on Rails
! Merb
|-
| Create new application 'app1' || rails new app1 || merb-gen app app1
|-
| Start server || rails server || merb
|-
| Start cluster of 3 beginning at port 3000 || N/A || merb -p 3000 -c 3
|-
| Interactive console || rails console || merb -i
|}

=Alternative to ORM=
==NonSQL databases==
Instead of ORM we can also use Object-Oriented Database Management System (OODBMS) or document-oriented database like XML, where in databases are designed to store object oriented values, thus eliminating the need to convert data to and from its SQL form. Document oriented databases also eliminates the need to retrieve objects as data rows. Query languages like XQuery can be used to retrieve data sets.

The only issue is we won't be able to create application independent queries for retrieving data without restrictions to access path. Also OODBMS limits the extent of processing SQL queries.
A Relational database allows concurrent access to data, locking, indexing (fast search), as well as many other features that are not available while using XML files.

Other OODBMS (such as RavenDB) provide replication to SQL databases, as a means of addressing the need for ad-hoc queries, while preserving the increased performance and reduced complexity that may be achieved with an OODBMS for an application that has well-known query patterns.

NonSQL databases don’t provide mechanism to maintain relationship between tables. In real life though, business objects or entities do have relationship among them. ORM solutions may allow you to define these relationships in business objects and handle their storage and retrieval behind the scene

=Comparison of ORM Features=

{|cellspacing="0" border="1"
!style="width:8%"|Features
!style="width:23%"|ActiveRecord
!style="width:23%"|Sequel
!style="width:23%"|DataMapper
!style="width:23%"|MyBatis
|-
! Databases 
| MySQL, PostgreSQL, SQLite, Oracle, SQLServer, and DB2
| ADO, DataObjects, DB2, DBI, Firebird, Informix, JDBC, MySQL, ODBC, OpenBase, Oracle, PostgreSQL and SQLite3
| SQLite, MySQL, PostgreSQL, Oracle, MongoDB, SimpleDB, many others, including CouchDB, Apache Solr, Google Data API
| MySQL, PostgreSQL, SQLite, Oracle, SQLServer, and DB2
|-
! Migrations 
| Yes
| Yes
| Yes, but optional
| Yes, provides migration by Mybatis schema migration system.
|-
! EagerLoading 
| Supported by scanning the SQL fragments
| Supported using eager (preloading) and eager_graph (joins)
| Strategic Eager Loading and by using :summary
| Yes.this can be enabled or disabled by setting the lazyLoadingEnabled flag
|-
! Flexible Overriding 
| No. Overriding is done using alias methods.
| Using methods and by calling 'super'
| Using methods
| No
|-
! Dynamic Finders 
| Yes. Uses 'Method Missing'
| No. Alternative is to use <Model>.FindOrCreate(:name=>"John")
| Yes. Using the dm_ar_finders plugin
| Similar feature is supported in the form of Dynamic SQL
|}

=Further Reading=
To get more information on ORM and the different type of ORM's available for Ruby , please look into the [http://wiki.expertiza.ncsu.edu/index.php/CSC/ECE_517_Spring_2013/ch1_1d_zk CSC/ECE 517 Spring 2013/ch1 1d zk] and [http://wiki.expertiza.ncsu.edu/index.php/CSC/ECE_517_Fall_2010/ch3_3f_ac Fall 2010 detailed ORM explanation] wiki pages.
# [http://www.cs.colorado.edu/~kena/classes/5448/f11/lectures/29-orm.pdf ORM - University of Colorado]
# [http://www.lynda.com/Ruby-Rails-tutorials/Understanding-ActiveRecord-ActiveRelation/139989/159093-4.html Active Record Tutorial]
# [http://digitalcommons.macalester.edu/context/mathcs_honors/article/1006/type/native/viewcontent/ Research papers on object relational mapping]
# [http://www.sitepoint.com/top-ruby-frameworks-rails-and-merb-join-forces/ Merb and Rails]

=Future Work=
More work can be done in the area of comparison between the different ORMs available for Ruby, especially a more detailed feature-by-feature comparison that includes performance differences between the ORMs.

=References =
# [http://en.wikipedia.org/wiki/Object-relational_mapping Object Relational Mapping]
# [http://en.wikipedia.org/wiki/Object-oriented_programming object-oriented programming]
# [http://en.wikipedia.org/wiki/Data_access data access]
# [http://en.wikipedia.org/wiki/Metaprogramming metaprogramming]
# [http://guides.rubyonrails.org/active_record_basics.html Active Record]
# [http://guides.rubyonrails.org/getting_started.html#the-mvc-architecture MVC]
# [http://sequel.jeremyevans.net/documentation.html Sequel]
# [http://datamapper.org/ DataMapper]
# [http://sequel.jeremyevans.net/rdoc/classes/Sequel/ThreadedConnectionPool.html Connection Pooling]
# [http://guides.rubyonrails.org/active_record_querying.html#eager-loading-associations Eager Loading]
# [http://rubydoc.info/gems/squeel/1.1.1/frames Squeel]
# [http://www.techopedia.com/definition/24200/object-relational-mapping--orm ORM]
# [http://en.wikipedia.org/wiki/Merb Merb]
# [http://www.merbivore.com/ Merb Website]
# [http://wiki.expertiza.ncsu.edu/index.php/CSC/ECE_517_Spring_2013/ch1_1d_zk Object Relational Mapping Spring 2013]

=Citations=
<references/>

CSC/ECE 517 Fall 2014/ch1a 25 ks

2014-09-24T23:29:26Z

Knimgao: /* Active Records */

Object Relational Mapping

__TOC__

==Introduction<ref>http://en.wikipedia.org/wiki/Object-relational_mapping Object Relational Mapping</ref>==
Object Relation Mapping(ORM, O/RM, and O/R mapping) in computer science is a programming technique for converting data between incompatible type systems in object-oriented programming languages. This creates, in effect, a "virtual object database" that can be used from within the programming language. There are both free and commercial packages available that perform object-relational mapping, although some programmers opt to create their own ORM tools.

==Overview==
Object Relational Mapping is a programming technique in which a metadata descriptor is used to connect object code to a relational database. ORM converts data between type systems that are unable to coexist within relational databases and OOP languages.

In [http://en.wikipedia.org/wiki/Object-oriented_programming object-oriented programming], data management tasks act on object-oriented (OO) objects that are almost always non-scalar values. For example, consider an address book entry that represents a single person along with zero or more phone numbers and zero or more addresses. This could be modeled in an object-oriented implementation by a "Person object" with attributes/fields to hold each data item that the entry comprises: the person's name, a list of phone numbers, and a list of addresses. The list of phone numbers would itself contain "PhoneNumber objects" and so on. The address book entry is treated as a single object by the programming language (it can be referenced by a single variable containing a pointer to the object, for instance). Various methods can be associated with the object, such as a method to return the preferred phone number, the home address, and so on.

The heart of the problem is translating the logical representation of the objects into an atomized form that is capable of being stored in the database, while preserving the properties of the objects and their relationships so that they can be reloaded as objects when needed. If this storage and retrieval functionality is implemented, the objects are said to be persistent.

==Simple Explanation==
A simple answer is that you wrap your tables or stored procedures in classes in your programming language, so that instead of writing SQL statements to interact with your database, you use methods and properties of objects.

In other words, instead of something like this:
<pre>
String sql = "SELECT ... FROM persons WHERE id = 10"
DbCommand cmd = new DbCommand(connection, sql);
Result res = cmd.Execute();
String name = res[0]["FIRST_NAME"];
</pre>
you do something like this:
<pre>
Person p = repository.GetPerson(10);
String name = p.FirstName;
</pre>
or similar code (lots of variations here.) Some frameworks also put a lot of the code in as static methods on the classes themselves, which means you could do something like this instead:
<pre>
Person p = Person.Get(10);
</pre>
Some also implement complex query systems, so you could do this:
<pre>
Person p = Person.Get(Person.Properties.Id == 10);
</pre>
The framework is what makes this code possible.

==Features<ref>http://wiki.expertiza.ncsu.edu/index.php/CSC/ECE_517_Spring_2013/ch1_1d_zk</ref>==
Object-relational Mapping (ORM) frameworks unburden the designer of the complex translation between database and object space.

Typical ORM features:
* Automatic mapping from classes to database tables
** Class instance variables to database columns
** Class instances to table rows
* Aggregation and association relationships between mapped classes are managed
** Example, :has_many, :belongs_to associations in ActiveRecord
** Inheritance cases are mapped to tables
* Validation of data prior to table storage
* Class extensions to enable search, as well as creation, read, update, and deletion (CRUD) of instances/records
* Usually abstracts the database from program space in such a way that alternate database types can be easily chosen (SQLite, Oracle, etc)

The diagram below depicts a simple mapping of an object to a database table….

[[Image:3j_ks_pic1.jpg]]

ORM framework is used to persist model objects to a relational database and retrieve them, and the ORM framework will take care of converting the data between the two otherwise incompatible states. Most ORM tools rely heavily on metadata about both the database and objects, so that the objects need to know nothing about the database and the database doesn’t need to know anything about how the data is structured in the application. ORM provides a clean separation of concerns in a well-designed data application, and the database and application can each work with data in its native form. Database rows map to objects, thus making the program more easily accessible and allowing the usage of information in a way that is internally consistent and easy to understand. The ORM gives the programmer an ability to manipulate data with the programming language, instead of having to manipulate each attribute as its data type as obtained by the database management system.

When applied to Ruby, implementations of ORM often leverage the language’s [http://en.wikipedia.org/wiki/Metaprogramming metaprogramming] strengths to create intuitive application-specific methods and otherwise extend classes to support database functionality. With the addition of Rails, the ORM becomes much more important, as it is necessary to have an ORM to connect the models of the MVC (model-view-controller) stack used by Ruby on Rails with the application's database. Since the models are Ruby objects, the ORM allows modifications to the database to be done through changes to these models, independent of the type of database used.

With the release of Rails 3.0, the platform became ORM independent. With this change, it is much easier to use the ORM most preferred by the programmer, rather than being corralled into using one particular one. To allow this, the ORM needed to be extracted from the model and the database, to be a pure mediator between the two. Then any ORM can be used as long as it can successfully understand the model and the database used.

==Advantages<ref>http://www.techopedia.com/definition/24200/object-relational-mapping--orm</ref>==
In addition to the [http://en.wikipedia.org/wiki/Data_access data access] technique, ORM's benefits also include:
*First of all, you hide the SQL away from your logic code. This has the benefit of allowing you to more easily support more database engines. For instance, MS SQL Server and Oracle has different names on typical functions, and different ways to do calculations with dates, so a query to "get me all persons edited the last 24 hours" might entail different SQL syntax just for those two database engines. This difference can be put away from your logic code.
*Additionally, you can focus on writing the logic, instead of getting all the SQL right. The code will typically be more readable as well, since it doesn't contain all the "plumbing" necessary to talk to the database.
*Simplified development because it automates object-to-table and table-to-object conversion, resulting in lower development and maintenance costs
*Less code compared to embedded SQL and handwritten stored procedures
*Transparent object caching in the application tier, improving system performance
*An optimized solution making an application faster and easier to maintain

==Disadvantages==
*ORM’s emergence in multiple application development has created disagreement among experts. Key concerns are that ORM does not perform well and that stored procedures might be a better solution.
*In addition, ORM dependence may result in poorly-designed databases in certain circumstances.
*Performance – like every "proxy" technology
*Complexity – learning curve
*Difficulty / inability to make complex queries

=ORM Frameworks=

==Active Records<ref>http://guides.rubyonrails.org/active_record_basics.html</ref>==
Active Record was described by Martin Fowler in his book Patterns of Enterprise Application Architecture. Active Record is the M in [http://guides.rubyonrails.org/getting_started.html#the-mvc-architecture MVC]- the model - which is the layer of the system responsible for representing business data and logic. In Active Record, objects carry both persistent data and behavior which operates on that data. A database table or view is wrapped into a class and an object instance is tied to a single row in the table. Each Active Record object has CRUD (Create, Read, Update, and Delete) methods for database access. In addition, Active Record allows you to validate the state of a model before it gets written into the database.

Active Record gives us several mechanisms, the most important being the ability to:
* Represent models and their data.
* Represent associations between these models.
* Represent inheritance hierarchies through related models.
* Validate models before they get persisted to the database.
* Perform database operations in an object-oriented fashion.

The naming conventions used in Active Records are :
* Database Table - Plural with underscores separating words (e.g., book_clubs).
* Model Class - Singular with the first letter of each word capitalized (e.g., BookClub).

To create a table, ActiveRecord makes use of a migration class rather than including table definition in the actual class being modeled. As an example, the following code creates a table ‘’users’’ to store a collection of class ‘’User’’ objects:
<pre>
class CreateUsers < ActiveRecord::Migration
def self.up
create_table :users do |t|
t.string :name
t.string :email
t.string :age
t.references :cheer
t.references :post

t.timestamps # add creation and modification timestamps
end
end

def self.down # undo the table creation
drop_table :users
end
end
</pre>

The ActiveRecord’s migration scheme provides a means for backing out changes via the ‘’self.down’’ method. In addition, a table key ‘’id’’ is added to the new table without an explicit definition and record creation and modification timestamps are included via the ‘’timestamps’’ method provided by ActiveRecord.

ActiveRecord manages associations between table elements and provides the means to define such associations in the model definition. For example, the ‘’User’’ class shown below defines a ‘’has_many’’ (one-to-many) association with both the cheers and posts tables. These associations are represented in the migration class with the references operator. Also note ActiveRecord’s integrated support for validation of table information when attempting an update.

<pre>
class User < ActiveRecord::Base
has_many :cheers
has_many :posts

validates_presence_of :name
validates_presence_of :age
validates_uniqueness_of :name
validates_length_of :name, :within => 3..20
end
</pre>

To access the data in the table one calls the class function related to that column. For example, to find the user who's name is Bob, one would use @user = User.find_by_name('Bob'). Then one could find Bob's e-mail by using @user.email. Users can be searched for by any attribute in this way, as find methods are created for every combination of attributes.
While ActiveRecord provides the flexibility to create more sophisticated table relationships to represent class hierarchy, its base scheme is a single table inheritance, which trades some storage efficiency for simplicity in the database design. The following figure illustrates this concept of simplicity over efficiency.

[[Image:3j_ks_pic2.jpg]]

'''Pros''' -
* Integrated with popular Rails development framework
* Dynamically created database search methods (eg: User.find_by_address) ease db queries and make queries database syntax independent
* DB creation/management using the migrate scheme provides a means for backing out unwanted table changes
'''Cons''' -
* DB creation/management is decoupled from the model, requiring a separate utility (rake/migrate) that must be kept in sync with application.

==ORM Adaptor==
[https://github.com/ianwhite/orm_adapter ORM Adaptors] provide a single point of entry for popular ruby ORMs. Its target audience is gem authors who want to support more than one ORM.
ORM Adapter's goal is to support a minimum API used by most of the plugins that needs agnosticism beyond Active Model.
ORM Adapter will support only basic methods, as get, find_first, create! and so forth. It is not ORM Adapter's goal to support different query constructions, handle table joins, etc.
ORM adapter provides a consistent API for these basic class or 'factory' methods. It does not attempt to unify the behaviour of model instances returned by these methods. This means that unifying the behaviour of methods such as `model.save`, and `model.valid?` is beyond the scope of orm_adapter.
If you need complex queries, it is recommended to subclass ORM Adapters in your plugin and extend it expressing these query conditions as part of your domain logic.
<pre>
Example :
require 'orm_adapter'
User # is it an ActiveRecord, DM Resource, MongoMapper or MongoId Document?
User.to_adapter.find_first :name => 'Fred' # we don't care!
user_model = User.to_adapter
user_model.get!(1) # find a record by id
user_model.find_first(:name => 'fred') # find first fred
user_model.find_first(:level => 'awesome', :id => 23) # find user 23, only if it's level is awesome
user_model.find_all # find all users
user_model.find_all(:name => 'fred') # find all freds
user_model.find_all(:order => :name) # find all freds, ordered by name
user_model.create!(:name => 'fred') # create a fred
user_model.destroy(object) # destroy the user object
</pre>

==Sequel==
[http://sequel.jeremyevans.net/documentation.html Sequel] was originally developed by Sharon Rosner and the first release was in March 2007. It is based on the active record pattern. Sequel and Active Record share a lot of common features , for example association and inheritance. But Sequel handles these features in a much more flexible manner. Currently Sequel is at version 3.44.0. Initially Sequel had three core modules - sequel, sequel_core and sequel_model. Starting from version 1.4 , sequel and sequel_model were merged. Sequel handles validations using a validation plug-in and helpers.

<pre>
class CreateUser < Sequel::Migration
def up
create_table(:user) {
primary_key :id
String :name
String :age
String :email}
end
def down
drop_table(:user)
end
end # CreateUser.apply(DB, :up)
</pre>

Sequel supports associations and validations similar to Active Record. The following example shows how validations and associations can be enforced in the User table that has been created above. It enforces one to many relationships between the user table and the cheers and posts tables. It also validates for the presence , uniqueness and the length of the attribute '''name'''.

<pre>
class User < Sequel::Model
one_to_many :cheers
one_to_many :posts

validates_presence [:name, :age]
validates_unique(:name)
validates_length_range 3..20, :name
end
</pre>

To access the data in Sequel, one can use where clauses. For instance, to find Bob again one would use DB[:items].where(Sequel.like(:name, 'Bob'). While the ability to use SQL-like where clauses is quite flexible, it is not quite as pure an object-oriented approach as Active Record's dynamically created find methods.

Some of the key features of sequel are,
* [http://sequel.jeremyevans.net/rdoc/classes/Sequel/ThreadedConnectionPool.html Connection Pooling]
* Thread Safety
* [http://guides.rubyonrails.org/active_record_querying.html#eager-loading-associations Eager Loading] / Lazy Loading
* Model Caching
* Supports advanced database features such as prepared statements, bound variables, stored procedures, savepoints, two-phase commit, transaction isolation, master/slave configurations, and database sharding.

==Data Mapper==
[http://datamapper.org/ DataMapper] is an Object Relational Mapper written in Ruby developed by Sam Smoot with the goal to create an ORM which is fast, thread-safe and feature rich.
A Data Mapper is a Data Access Layer that performs bidirectional transfer of data between a persistent data store (often a relational database) and an in memory data representation (the domain layer). The goal of the pattern is to keep the in memory representation and the persistent data store independent of each other and the data mapper itself. The layer is composed of one or more mappers (or Data Access Objects), performing the data transfer.
DataMapper comes with the ability to use the same API to talk to a multitude of different datastores. There are adapters for the usual RDBMS suspects, NoSQL stores, various file formats and some web services. With DataMapper, you define your mappings in your model. Your data store can develop independently of your model using Migrations.

Some features of Data Mapper are as follows :
* No need to write structural migrations
* Scoped relations
* Lazy loading on certain attribute types
* Strategic eager loading to avoid (N+1) queries
* Default support for composite and natural keys
* Query chaining, and not evaluating the query until absolutely necessary (using a lazy array implementation)
* An API not too heavily oriented to SQL databases

DataMapper was designed to be a more abstract ORM, not strictly SQL, based on Martin Fowler's enterprise pattern. As a result, DataMapper adapters have been built for other non-SQL databases, such as CouchDB, [http://github.com/lritter/dm-solr-adapter/tree/master Apache Solr], and webservices such as [http://github.com/halorgium/dm-salesforce/tree/master Salesforce].

Example of table definition in the model:
<pre>
class User
include DataMapper::Resource

property :id, Serial # key
property :name, String, :required => true, :unique => true
property :age, String, :required => true, :length => 3..20
property :email, String

has n, :posts # one to many association
has n, :cheers # one to many association
end
</pre>

Notice that in the example above , ":required = true" is an example for Auto Validation. Unlike ActiveRecord and Sequel, DataMapper supports auto validations , i.e. these in turn call the validation helpers to enforce basic validations such as length, uniqueness, format, presence etc.

==MyBatis/iBatis==
[http://en.wikipedia.org/wiki/MyBatis MyBatis/iBatis] was a persistence framework which allowed easy access of the database from a Rails application without being a full ORM. It was created by the Apache Foundation in 2002, and is available for several platforms, including Ruby (the Ruby release is known as RBatis). On 6/16/2010, after releasing iBATIS 3.0, the project team moved from Apache to Google Code, changed the project's name to MyBatis, and stopped supporting Ruby.

The MyBatis data mapper framework makes it easier to use a relational database with object-oriented applications. MyBatis couples objects with stored procedures or SQL statements using a XML descriptor. To use the MyBatis data mapper,we make use of our own objects, XML, and SQL.

SQL statements are stored in XML files or annotations. Following is a MyBatis mapper, that consists of a Java interface with some MyBatis annotations:
<pre>
package org.mybatis.example;

public interface BlogMapper {
@Select("select * from Blog where id = #{id}")
Blog selectBlog(int id);
}
</pre>
The sentence is executed as follows.
<pre>
BlogMapper mapper = session.getMapper(BlogMapper.class);
Blog blog = mapper.selectBlog(101);
</pre>

It can also be executed using MyBatis API.
<pre>
Blog blog = session.selectOne("org.mybatis.example.BlogMapper.selectBlog", 101);
</pre>

SQL statements and mappings can also be externalized to an XML file like this.
<pre>
<?xml version="1.0" encoding="UTF-8" ?>
<!DOCTYPE mapper PUBLIC "-//mybatis.org//DTD Mapper 3.0//EN" "http://mybatis.org/dtd/mybatis-3-mapper.dtd">

<mapper namespace="org.mybatis.example.BlogMapper">
<select id="selectBlog" parameterType="int" resultType="Blog">
select * from Blog where id = #{id}
</select>
</mapper>
</pre>

==Squeel==
[http://rubydoc.info/gems/squeel/1.1.1/frames Squeel]unlocks the power of Arel in Rails applications with a handy block-based syntax. It is supporting in Rails 3 and 4. With Squeel, you can write subqueries, access named functions provided by RDMBS and more without writing SQL strings.
Squeel lets you write your Active Record queries with fewer strings, and more Ruby, by making the Arel awesomeness that lies beneath Active Record more accessible.

Squeel lets you rewrite...

<pre>
Article.where ['created_at >= ?', 2.weeks.ago]
...as...
Article.where{created_at >= 2.weeks.ago}
</pre>

Squeel enhances the normal Active Record query methods by enabling them to accept blocks. Inside a block, the Squeel query DSL can be used. Note the use of curly braces in the above example instead of parentheses. {} denotes a Squeel DSL query.

Stubs and keypaths are the two primary building blocks used in a Squeel DSL query.

Stubs are, for most intents and purposes, just like Symbols in a normal call to Relation#where (note the need for doubling up on the curly braces here, the first ones start the block, the second are the hash braces):
<pre>
Person.where{{name => ‘Ernie’ }}
</pre>

You normally wouldn't bother using the DSL in this case, as a simple hash would suffice. However, stubs serve as a building block for keypaths, and keypaths are very handy.

A Squeel keypath is essentially a more concise and readable alternative to a deeply nested hash. For instance, in standard Active Record, you might join several associations like this to perform a query:
<pre>
Person.joins(:articles => { :comments => :person}).references(:all)
</pre>

With a keypath, this would look like:
<pre>
Person.joins{articles.comments.person}.references(:all)
</pre>

The Squeel DSL works its magic using instance_eval which means that inside a Squeel DSL block, self isn't the same thing that it is outside the block.
This carries with it an important implication: Instance variables and instance methods inside the block won't refer to your object's variables/methods.
Use one of the following methods to get access to the object's methods and variables:
* Assign the variable locally before the DSL block, and access it as you would normally.
* Supply an arity to the DSL block, as in Person.where{|q| q.name == @my_name} Downside: You'll need to prefix stubs, keypaths, and functions with the DSL object.
* Wrap the method or instance variable inside the block with my{}. Person.where{name == my{some_method_to_return_a_name}}

==Merb==
[http://en.wikipedia.org/wiki/Merb Merb], short for "Mongrel+Erb", is a model view controller framework written in Ruby. Merb was merged into Rails web framework on December 23, 2008 as part of the Ruby on Rails 3.0 release.
Merb itself provides only the controller of an MVC model which can be extended to create a full-stack application environment. This effectively means Merb itself is not an ORM but can accommodate other ORMs.
Some features of Merb are as follows :
* Speed - Merb is ORM, JavaScript library and template language agnostic, preferring plugins that add support for features rather than producing a monolithic library with everything in the core.
* Lightweight - Rather than trying to cram every feature into a single code, things are kept bare minimum without sacrificing anything important.
* Powerful and extensible - For any features not covered in Merb’s core, there are plugins.
Some basic Command distinction between Ruby on Rails and Merb :
{| class="comparison" border="1"
! Action
! Ruby on Rails
! Merb
|-
| Create new application 'app1' || rails new app1 || merb-gen app app1
|-
| Start server || rails server || merb
|-
| Start cluster of 3 beginning at port 3000 || N/A || merb -p 3000 -c 3
|-
| Interactive console || rails console || merb -i
|}

=Alternative to ORM=
==NonSQL databases==
Instead of ORM we can also use Object-Oriented Database Management System (OODBMS) or document-oriented database like XML, where in databases are designed to store object oriented values, thus eliminating the need to convert data to and from its SQL form. Document oriented databases also eliminates the need to retrieve objects as data rows. Query languages like XQuery can be used to retrieve data sets.

The only issue is we won't be able to create application independent queries for retrieving data without restrictions to access path. Also OODBMS limits the extent of processing SQL queries.
A Relational database allows concurrent access to data, locking, indexing (fast search), as well as many other features that are not available while using XML files.

Other OODBMS (such as RavenDB) provide replication to SQL databases, as a means of addressing the need for ad-hoc queries, while preserving the increased performance and reduced complexity that may be achieved with an OODBMS for an application that has well-known query patterns.

NonSQL databases don’t provide mechanism to maintain relationship between tables. In real life though, business objects or entities do have relationship among them. ORM solutions may allow you to define these relationships in business objects and handle their storage and retrieval behind the scene

=Comparison of ORM Features=

{|cellspacing="0" border="1"
!style="width:8%"|Features
!style="width:23%"|ActiveRecord
!style="width:23%"|Sequel
!style="width:23%"|DataMapper
!style="width:23%"|MyBatis
|-
! Databases 
| MySQL, PostgreSQL, SQLite, Oracle, SQLServer, and DB2
| ADO, DataObjects, DB2, DBI, Firebird, Informix, JDBC, MySQL, ODBC, OpenBase, Oracle, PostgreSQL and SQLite3
| SQLite, MySQL, PostgreSQL, Oracle, MongoDB, SimpleDB, many others, including CouchDB, Apache Solr, Google Data API
| MySQL, PostgreSQL, SQLite, Oracle, SQLServer, and DB2
|-
! Migrations 
| Yes
| Yes
| Yes, but optional
| Yes, provides migration by Mybatis schema migration system.
|-
! EagerLoading 
| Supported by scanning the SQL fragments
| Supported using eager (preloading) and eager_graph (joins)
| Strategic Eager Loading and by using :summary
| Yes.this can be enabled or disabled by setting the lazyLoadingEnabled flag
|-
! Flexible Overriding 
| No. Overriding is done using alias methods.
| Using methods and by calling 'super'
| Using methods
| No
|-
! Dynamic Finders 
| Yes. Uses 'Method Missing'
| No. Alternative is to use <Model>.FindOrCreate(:name=>"John")
| Yes. Using the dm_ar_finders plugin
| Similar feature is supported in the form of Dynamic SQL
|}

=Further Reading=
To get more information on ORM and the different type of ORM's available for Ruby , please look into the [http://wiki.expertiza.ncsu.edu/index.php/CSC/ECE_517_Spring_2013/ch1_1d_zk CSC/ECE 517 Spring 2013/ch1 1d zk] and [http://wiki.expertiza.ncsu.edu/index.php/CSC/ECE_517_Fall_2010/ch3_3f_ac Fall 2010 detailed ORM explanation] wiki pages.
# [http://www.cs.colorado.edu/~kena/classes/5448/f11/lectures/29-orm.pdf ORM - University of Colorado]
# [http://www.lynda.com/Ruby-Rails-tutorials/Understanding-ActiveRecord-ActiveRelation/139989/159093-4.html Active Record Tutorial]
# [http://digitalcommons.macalester.edu/context/mathcs_honors/article/1006/type/native/viewcontent/ Research papers on object relational mapping]
# [http://www.sitepoint.com/top-ruby-frameworks-rails-and-merb-join-forces/ Merb and Rails]

=Future Work=
More work can be done in the area of comparison between the different ORMs available for Ruby, especially a more detailed feature-by-feature comparison that includes performance differences between the ORMs.

=References =
# [http://en.wikipedia.org/wiki/Object-relational_mapping Object Relational Mapping]
# [http://en.wikipedia.org/wiki/Object-oriented_programming object-oriented programming]
# [http://en.wikipedia.org/wiki/Data_access data access]
# [http://en.wikipedia.org/wiki/Metaprogramming metaprogramming]
# [http://guides.rubyonrails.org/active_record_basics.html Active Record]
# [http://guides.rubyonrails.org/getting_started.html#the-mvc-architecture MVC]
# [http://sequel.jeremyevans.net/documentation.html Sequel]
# [http://datamapper.org/ DataMapper]
# [http://sequel.jeremyevans.net/rdoc/classes/Sequel/ThreadedConnectionPool.html Connection Pooling]
# [http://guides.rubyonrails.org/active_record_querying.html#eager-loading-associations Eager Loading]
# [http://rubydoc.info/gems/squeel/1.1.1/frames Squeel]
# [http://www.techopedia.com/definition/24200/object-relational-mapping--orm ORM]
# [http://en.wikipedia.org/wiki/Merb Merb]
# [http://www.merbivore.com/ Merb Website]
# [http://wiki.expertiza.ncsu.edu/index.php/CSC/ECE_517_Spring_2013/ch1_1d_zk Object Relational Mapping Spring 2013]

=Citations=
<references/>

CSC/ECE 517 Fall 2014/ch1a 25 ks

2014-09-24T23:27:15Z

Knimgao: /* Disadvantageshttp://www.techopedia.com/definition/24200/object-relational-mapping--orm */

__TOC__

=Object Relational Mapping=
==Introduction<ref>http://en.wikipedia.org/wiki/Object-relational_mapping Object Relational Mapping</ref>==
Object Relation Mapping(ORM, O/RM, and O/R mapping) in computer science is a programming technique for converting data between incompatible type systems in object-oriented programming languages. This creates, in effect, a "virtual object database" that can be used from within the programming language. There are both free and commercial packages available that perform object-relational mapping, although some programmers opt to create their own ORM tools.

==Overview==
Object Relational Mapping is a programming technique in which a metadata descriptor is used to connect object code to a relational database. ORM converts data between type systems that are unable to coexist within relational databases and OOP languages.

In [http://en.wikipedia.org/wiki/Object-oriented_programming object-oriented programming], data management tasks act on object-oriented (OO) objects that are almost always non-scalar values. For example, consider an address book entry that represents a single person along with zero or more phone numbers and zero or more addresses. This could be modeled in an object-oriented implementation by a "Person object" with attributes/fields to hold each data item that the entry comprises: the person's name, a list of phone numbers, and a list of addresses. The list of phone numbers would itself contain "PhoneNumber objects" and so on. The address book entry is treated as a single object by the programming language (it can be referenced by a single variable containing a pointer to the object, for instance). Various methods can be associated with the object, such as a method to return the preferred phone number, the home address, and so on.

The heart of the problem is translating the logical representation of the objects into an atomized form that is capable of being stored in the database, while preserving the properties of the objects and their relationships so that they can be reloaded as objects when needed. If this storage and retrieval functionality is implemented, the objects are said to be persistent.

==Simple Explanation==
A simple answer is that you wrap your tables or stored procedures in classes in your programming language, so that instead of writing SQL statements to interact with your database, you use methods and properties of objects.

In other words, instead of something like this:
<pre>
String sql = "SELECT ... FROM persons WHERE id = 10"
DbCommand cmd = new DbCommand(connection, sql);
Result res = cmd.Execute();
String name = res[0]["FIRST_NAME"];
</pre>
you do something like this:
<pre>
Person p = repository.GetPerson(10);
String name = p.FirstName;
</pre>
or similar code (lots of variations here.) Some frameworks also put a lot of the code in as static methods on the classes themselves, which means you could do something like this instead:
<pre>
Person p = Person.Get(10);
</pre>
Some also implement complex query systems, so you could do this:
<pre>
Person p = Person.Get(Person.Properties.Id == 10);
</pre>
The framework is what makes this code possible.

==Features<ref>http://wiki.expertiza.ncsu.edu/index.php/CSC/ECE_517_Spring_2013/ch1_1d_zk</ref>==
Object-relational Mapping (ORM) frameworks unburden the designer of the complex translation between database and object space.

Typical ORM features:
* Automatic mapping from classes to database tables
** Class instance variables to database columns
** Class instances to table rows
* Aggregation and association relationships between mapped classes are managed
** Example, :has_many, :belongs_to associations in ActiveRecord
** Inheritance cases are mapped to tables
* Validation of data prior to table storage
* Class extensions to enable search, as well as creation, read, update, and deletion (CRUD) of instances/records
* Usually abstracts the database from program space in such a way that alternate database types can be easily chosen (SQLite, Oracle, etc)

The diagram below depicts a simple mapping of an object to a database table….

[[Image:3j_ks_pic1.jpg]]

ORM framework is used to persist model objects to a relational database and retrieve them, and the ORM framework will take care of converting the data between the two otherwise incompatible states. Most ORM tools rely heavily on metadata about both the database and objects, so that the objects need to know nothing about the database and the database doesn’t need to know anything about how the data is structured in the application. ORM provides a clean separation of concerns in a well-designed data application, and the database and application can each work with data in its native form. Database rows map to objects, thus making the program more easily accessible and allowing the usage of information in a way that is internally consistent and easy to understand. The ORM gives the programmer an ability to manipulate data with the programming language, instead of having to manipulate each attribute as its data type as obtained by the database management system.

When applied to Ruby, implementations of ORM often leverage the language’s [http://en.wikipedia.org/wiki/Metaprogramming metaprogramming] strengths to create intuitive application-specific methods and otherwise extend classes to support database functionality. With the addition of Rails, the ORM becomes much more important, as it is necessary to have an ORM to connect the models of the MVC (model-view-controller) stack used by Ruby on Rails with the application's database. Since the models are Ruby objects, the ORM allows modifications to the database to be done through changes to these models, independent of the type of database used.

With the release of Rails 3.0, the platform became ORM independent. With this change, it is much easier to use the ORM most preferred by the programmer, rather than being corralled into using one particular one. To allow this, the ORM needed to be extracted from the model and the database, to be a pure mediator between the two. Then any ORM can be used as long as it can successfully understand the model and the database used.

==Advantages<ref>http://www.techopedia.com/definition/24200/object-relational-mapping--orm</ref>==
In addition to the [http://en.wikipedia.org/wiki/Data_access data access] technique, ORM's benefits also include:
*First of all, you hide the SQL away from your logic code. This has the benefit of allowing you to more easily support more database engines. For instance, MS SQL Server and Oracle has different names on typical functions, and different ways to do calculations with dates, so a query to "get me all persons edited the last 24 hours" might entail different SQL syntax just for those two database engines. This difference can be put away from your logic code.
*Additionally, you can focus on writing the logic, instead of getting all the SQL right. The code will typically be more readable as well, since it doesn't contain all the "plumbing" necessary to talk to the database.
*Simplified development because it automates object-to-table and table-to-object conversion, resulting in lower development and maintenance costs
*Less code compared to embedded SQL and handwritten stored procedures
*Transparent object caching in the application tier, improving system performance
*An optimized solution making an application faster and easier to maintain

==Disadvantages==
*ORM’s emergence in multiple application development has created disagreement among experts. Key concerns are that ORM does not perform well and that stored procedures might be a better solution.
*In addition, ORM dependence may result in poorly-designed databases in certain circumstances.
*Performance – like every "proxy" technology
*Complexity – learning curve
*Difficulty / inability to make complex queries

=ORM Frameworks=

==Active Records==
[http://guides.rubyonrails.org/active_record_basics.html Active Record] was described by Martin Fowler in his book Patterns of Enterprise Application Architecture. Active Record is the M in [http://guides.rubyonrails.org/getting_started.html#the-mvc-architecture MVC]- the model - which is the layer of the system responsible for representing business data and logic. In Active Record, objects carry both persistent data and behavior which operates on that data. A database table or view is wrapped into a class and an object instance is tied to a single row in the table. Each Active Record object has CRUD (Create, Read, Update, and Delete) methods for database access. In addition, Active Record allows you to validate the state of a model before it gets written into the database.

Active Record gives us several mechanisms, the most important being the ability to:
* Represent models and their data.
* Represent associations between these models.
* Represent inheritance hierarchies through related models.
* Validate models before they get persisted to the database.
* Perform database operations in an object-oriented fashion.

The naming conventions used in Active Records are :
* Database Table - Plural with underscores separating words (e.g., book_clubs).
* Model Class - Singular with the first letter of each word capitalized (e.g., BookClub).

To create a table, ActiveRecord makes use of a migration class rather than including table definition in the actual class being modeled. As an example, the following code creates a table ‘’users’’ to store a collection of class ‘’User’’ objects:
<pre>
class CreateUsers < ActiveRecord::Migration
def self.up
create_table :users do |t|
t.string :name
t.string :email
t.string :age
t.references :cheer
t.references :post

t.timestamps # add creation and modification timestamps
end
end

def self.down # undo the table creation
drop_table :users
end
end
</pre>

The ActiveRecord’s migration scheme provides a means for backing out changes via the ‘’self.down’’ method. In addition, a table key ‘’id’’ is added to the new table without an explicit definition and record creation and modification timestamps are included via the ‘’timestamps’’ method provided by ActiveRecord.

ActiveRecord manages associations between table elements and provides the means to define such associations in the model definition. For example, the ‘’User’’ class shown below defines a ‘’has_many’’ (one-to-many) association with both the cheers and posts tables. These associations are represented in the migration class with the references operator. Also note ActiveRecord’s integrated support for validation of table information when attempting an update.

<pre>
class User < ActiveRecord::Base
has_many :cheers
has_many :posts

validates_presence_of :name
validates_presence_of :age
validates_uniqueness_of :name
validates_length_of :name, :within => 3..20
end
</pre>

To access the data in the table one calls the class function related to that column. For example, to find the user who's name is Bob, one would use @user = User.find_by_name('Bob'). Then one could find Bob's e-mail by using @user.email. Users can be searched for by any attribute in this way, as find methods are created for every combination of attributes.
While ActiveRecord provides the flexibility to create more sophisticated table relationships to represent class hierarchy, its base scheme is a single table inheritance, which trades some storage efficiency for simplicity in the database design. The following figure illustrates this concept of simplicity over efficiency.

[[Image:3j_ks_pic2.jpg]]

'''Pros''' -
* Integrated with popular Rails development framework
* Dynamically created database search methods (eg: User.find_by_address) ease db queries and make queries database syntax independent
* DB creation/management using the migrate scheme provides a means for backing out unwanted table changes
'''Cons''' -
* DB creation/management is decoupled from the model, requiring a separate utility (rake/migrate) that must be kept in sync with application.

==ORM Adaptor==
[https://github.com/ianwhite/orm_adapter ORM Adaptors] provide a single point of entry for popular ruby ORMs. Its target audience is gem authors who want to support more than one ORM.
ORM Adapter's goal is to support a minimum API used by most of the plugins that needs agnosticism beyond Active Model.
ORM Adapter will support only basic methods, as get, find_first, create! and so forth. It is not ORM Adapter's goal to support different query constructions, handle table joins, etc.
ORM adapter provides a consistent API for these basic class or 'factory' methods. It does not attempt to unify the behaviour of model instances returned by these methods. This means that unifying the behaviour of methods such as `model.save`, and `model.valid?` is beyond the scope of orm_adapter.
If you need complex queries, it is recommended to subclass ORM Adapters in your plugin and extend it expressing these query conditions as part of your domain logic.
<pre>
Example :
require 'orm_adapter'
User # is it an ActiveRecord, DM Resource, MongoMapper or MongoId Document?
User.to_adapter.find_first :name => 'Fred' # we don't care!
user_model = User.to_adapter
user_model.get!(1) # find a record by id
user_model.find_first(:name => 'fred') # find first fred
user_model.find_first(:level => 'awesome', :id => 23) # find user 23, only if it's level is awesome
user_model.find_all # find all users
user_model.find_all(:name => 'fred') # find all freds
user_model.find_all(:order => :name) # find all freds, ordered by name
user_model.create!(:name => 'fred') # create a fred
user_model.destroy(object) # destroy the user object
</pre>

==Sequel==
[http://sequel.jeremyevans.net/documentation.html Sequel] was originally developed by Sharon Rosner and the first release was in March 2007. It is based on the active record pattern. Sequel and Active Record share a lot of common features , for example association and inheritance. But Sequel handles these features in a much more flexible manner. Currently Sequel is at version 3.44.0. Initially Sequel had three core modules - sequel, sequel_core and sequel_model. Starting from version 1.4 , sequel and sequel_model were merged. Sequel handles validations using a validation plug-in and helpers.

<pre>
class CreateUser < Sequel::Migration
def up
create_table(:user) {
primary_key :id
String :name
String :age
String :email}
end
def down
drop_table(:user)
end
end # CreateUser.apply(DB, :up)
</pre>

Sequel supports associations and validations similar to Active Record. The following example shows how validations and associations can be enforced in the User table that has been created above. It enforces one to many relationships between the user table and the cheers and posts tables. It also validates for the presence , uniqueness and the length of the attribute '''name'''.

<pre>
class User < Sequel::Model
one_to_many :cheers
one_to_many :posts

validates_presence [:name, :age]
validates_unique(:name)
validates_length_range 3..20, :name
end
</pre>

To access the data in Sequel, one can use where clauses. For instance, to find Bob again one would use DB[:items].where(Sequel.like(:name, 'Bob'). While the ability to use SQL-like where clauses is quite flexible, it is not quite as pure an object-oriented approach as Active Record's dynamically created find methods.

Some of the key features of sequel are,
* [http://sequel.jeremyevans.net/rdoc/classes/Sequel/ThreadedConnectionPool.html Connection Pooling]
* Thread Safety
* [http://guides.rubyonrails.org/active_record_querying.html#eager-loading-associations Eager Loading] / Lazy Loading
* Model Caching
* Supports advanced database features such as prepared statements, bound variables, stored procedures, savepoints, two-phase commit, transaction isolation, master/slave configurations, and database sharding.

==Data Mapper==
[http://datamapper.org/ DataMapper] is an Object Relational Mapper written in Ruby developed by Sam Smoot with the goal to create an ORM which is fast, thread-safe and feature rich.
A Data Mapper is a Data Access Layer that performs bidirectional transfer of data between a persistent data store (often a relational database) and an in memory data representation (the domain layer). The goal of the pattern is to keep the in memory representation and the persistent data store independent of each other and the data mapper itself. The layer is composed of one or more mappers (or Data Access Objects), performing the data transfer.
DataMapper comes with the ability to use the same API to talk to a multitude of different datastores. There are adapters for the usual RDBMS suspects, NoSQL stores, various file formats and some web services. With DataMapper, you define your mappings in your model. Your data store can develop independently of your model using Migrations.

Some features of Data Mapper are as follows :
* No need to write structural migrations
* Scoped relations
* Lazy loading on certain attribute types
* Strategic eager loading to avoid (N+1) queries
* Default support for composite and natural keys
* Query chaining, and not evaluating the query until absolutely necessary (using a lazy array implementation)
* An API not too heavily oriented to SQL databases

DataMapper was designed to be a more abstract ORM, not strictly SQL, based on Martin Fowler's enterprise pattern. As a result, DataMapper adapters have been built for other non-SQL databases, such as CouchDB, [http://github.com/lritter/dm-solr-adapter/tree/master Apache Solr], and webservices such as [http://github.com/halorgium/dm-salesforce/tree/master Salesforce].

Example of table definition in the model:
<pre>
class User
include DataMapper::Resource

property :id, Serial # key
property :name, String, :required => true, :unique => true
property :age, String, :required => true, :length => 3..20
property :email, String

has n, :posts # one to many association
has n, :cheers # one to many association
end
</pre>

Notice that in the example above , ":required = true" is an example for Auto Validation. Unlike ActiveRecord and Sequel, DataMapper supports auto validations , i.e. these in turn call the validation helpers to enforce basic validations such as length, uniqueness, format, presence etc.

==MyBatis/iBatis==
[http://en.wikipedia.org/wiki/MyBatis MyBatis/iBatis] was a persistence framework which allowed easy access of the database from a Rails application without being a full ORM. It was created by the Apache Foundation in 2002, and is available for several platforms, including Ruby (the Ruby release is known as RBatis). On 6/16/2010, after releasing iBATIS 3.0, the project team moved from Apache to Google Code, changed the project's name to MyBatis, and stopped supporting Ruby.

The MyBatis data mapper framework makes it easier to use a relational database with object-oriented applications. MyBatis couples objects with stored procedures or SQL statements using a XML descriptor. To use the MyBatis data mapper,we make use of our own objects, XML, and SQL.

SQL statements are stored in XML files or annotations. Following is a MyBatis mapper, that consists of a Java interface with some MyBatis annotations:
<pre>
package org.mybatis.example;

public interface BlogMapper {
@Select("select * from Blog where id = #{id}")
Blog selectBlog(int id);
}
</pre>
The sentence is executed as follows.
<pre>
BlogMapper mapper = session.getMapper(BlogMapper.class);
Blog blog = mapper.selectBlog(101);
</pre>

It can also be executed using MyBatis API.
<pre>
Blog blog = session.selectOne("org.mybatis.example.BlogMapper.selectBlog", 101);
</pre>

SQL statements and mappings can also be externalized to an XML file like this.
<pre>
<?xml version="1.0" encoding="UTF-8" ?>
<!DOCTYPE mapper PUBLIC "-//mybatis.org//DTD Mapper 3.0//EN" "http://mybatis.org/dtd/mybatis-3-mapper.dtd">

<mapper namespace="org.mybatis.example.BlogMapper">
<select id="selectBlog" parameterType="int" resultType="Blog">
select * from Blog where id = #{id}
</select>
</mapper>
</pre>

==Squeel==
[http://rubydoc.info/gems/squeel/1.1.1/frames Squeel]unlocks the power of Arel in Rails applications with a handy block-based syntax. It is supporting in Rails 3 and 4. With Squeel, you can write subqueries, access named functions provided by RDMBS and more without writing SQL strings.
Squeel lets you write your Active Record queries with fewer strings, and more Ruby, by making the Arel awesomeness that lies beneath Active Record more accessible.

Squeel lets you rewrite...

<pre>
Article.where ['created_at >= ?', 2.weeks.ago]
...as...
Article.where{created_at >= 2.weeks.ago}
</pre>

Squeel enhances the normal Active Record query methods by enabling them to accept blocks. Inside a block, the Squeel query DSL can be used. Note the use of curly braces in the above example instead of parentheses. {} denotes a Squeel DSL query.

Stubs and keypaths are the two primary building blocks used in a Squeel DSL query.

Stubs are, for most intents and purposes, just like Symbols in a normal call to Relation#where (note the need for doubling up on the curly braces here, the first ones start the block, the second are the hash braces):
<pre>
Person.where{{name => ‘Ernie’ }}
</pre>

You normally wouldn't bother using the DSL in this case, as a simple hash would suffice. However, stubs serve as a building block for keypaths, and keypaths are very handy.

A Squeel keypath is essentially a more concise and readable alternative to a deeply nested hash. For instance, in standard Active Record, you might join several associations like this to perform a query:
<pre>
Person.joins(:articles => { :comments => :person}).references(:all)
</pre>

With a keypath, this would look like:
<pre>
Person.joins{articles.comments.person}.references(:all)
</pre>

The Squeel DSL works its magic using instance_eval which means that inside a Squeel DSL block, self isn't the same thing that it is outside the block.
This carries with it an important implication: Instance variables and instance methods inside the block won't refer to your object's variables/methods.
Use one of the following methods to get access to the object's methods and variables:
* Assign the variable locally before the DSL block, and access it as you would normally.
* Supply an arity to the DSL block, as in Person.where{|q| q.name == @my_name} Downside: You'll need to prefix stubs, keypaths, and functions with the DSL object.
* Wrap the method or instance variable inside the block with my{}. Person.where{name == my{some_method_to_return_a_name}}

==Merb==
[http://en.wikipedia.org/wiki/Merb Merb], short for "Mongrel+Erb", is a model view controller framework written in Ruby. Merb was merged into Rails web framework on December 23, 2008 as part of the Ruby on Rails 3.0 release.
Merb itself provides only the controller of an MVC model which can be extended to create a full-stack application environment. This effectively means Merb itself is not an ORM but can accommodate other ORMs.
Some features of Merb are as follows :
* Speed - Merb is ORM, JavaScript library and template language agnostic, preferring plugins that add support for features rather than producing a monolithic library with everything in the core.
* Lightweight - Rather than trying to cram every feature into a single code, things are kept bare minimum without sacrificing anything important.
* Powerful and extensible - For any features not covered in Merb’s core, there are plugins.
Some basic Command distinction between Ruby on Rails and Merb :
{| class="comparison" border="1"
! Action
! Ruby on Rails
! Merb
|-
| Create new application 'app1' || rails new app1 || merb-gen app app1
|-
| Start server || rails server || merb
|-
| Start cluster of 3 beginning at port 3000 || N/A || merb -p 3000 -c 3
|-
| Interactive console || rails console || merb -i
|}

=Alternative to ORM=
==NonSQL databases==
Instead of ORM we can also use Object-Oriented Database Management System (OODBMS) or document-oriented database like XML, where in databases are designed to store object oriented values, thus eliminating the need to convert data to and from its SQL form. Document oriented databases also eliminates the need to retrieve objects as data rows. Query languages like XQuery can be used to retrieve data sets.

The only issue is we won't be able to create application independent queries for retrieving data without restrictions to access path. Also OODBMS limits the extent of processing SQL queries.
A Relational database allows concurrent access to data, locking, indexing (fast search), as well as many other features that are not available while using XML files.

Other OODBMS (such as RavenDB) provide replication to SQL databases, as a means of addressing the need for ad-hoc queries, while preserving the increased performance and reduced complexity that may be achieved with an OODBMS for an application that has well-known query patterns.

NonSQL databases don’t provide mechanism to maintain relationship between tables. In real life though, business objects or entities do have relationship among them. ORM solutions may allow you to define these relationships in business objects and handle their storage and retrieval behind the scene

=Comparison of ORM Features=

{|cellspacing="0" border="1"
!style="width:8%"|Features
!style="width:23%"|ActiveRecord
!style="width:23%"|Sequel
!style="width:23%"|DataMapper
!style="width:23%"|MyBatis
|-
! Databases 
| MySQL, PostgreSQL, SQLite, Oracle, SQLServer, and DB2
| ADO, DataObjects, DB2, DBI, Firebird, Informix, JDBC, MySQL, ODBC, OpenBase, Oracle, PostgreSQL and SQLite3
| SQLite, MySQL, PostgreSQL, Oracle, MongoDB, SimpleDB, many others, including CouchDB, Apache Solr, Google Data API
| MySQL, PostgreSQL, SQLite, Oracle, SQLServer, and DB2
|-
! Migrations 
| Yes
| Yes
| Yes, but optional
| Yes, provides migration by Mybatis schema migration system.
|-
! EagerLoading 
| Supported by scanning the SQL fragments
| Supported using eager (preloading) and eager_graph (joins)
| Strategic Eager Loading and by using :summary
| Yes.this can be enabled or disabled by setting the lazyLoadingEnabled flag
|-
! Flexible Overriding 
| No. Overriding is done using alias methods.
| Using methods and by calling 'super'
| Using methods
| No
|-
! Dynamic Finders 
| Yes. Uses 'Method Missing'
| No. Alternative is to use <Model>.FindOrCreate(:name=>"John")
| Yes. Using the dm_ar_finders plugin
| Similar feature is supported in the form of Dynamic SQL
|}

=Further Reading=
To get more information on ORM and the different type of ORM's available for Ruby , please look into the [http://wiki.expertiza.ncsu.edu/index.php/CSC/ECE_517_Spring_2013/ch1_1d_zk CSC/ECE 517 Spring 2013/ch1 1d zk] and [http://wiki.expertiza.ncsu.edu/index.php/CSC/ECE_517_Fall_2010/ch3_3f_ac Fall 2010 detailed ORM explanation] wiki pages.
# [http://www.cs.colorado.edu/~kena/classes/5448/f11/lectures/29-orm.pdf ORM - University of Colorado]
# [http://www.lynda.com/Ruby-Rails-tutorials/Understanding-ActiveRecord-ActiveRelation/139989/159093-4.html Active Record Tutorial]
# [http://digitalcommons.macalester.edu/context/mathcs_honors/article/1006/type/native/viewcontent/ Research papers on object relational mapping]
# [http://www.sitepoint.com/top-ruby-frameworks-rails-and-merb-join-forces/ Merb and Rails]

=Future Work=
More work can be done in the area of comparison between the different ORMs available for Ruby, especially a more detailed feature-by-feature comparison that includes performance differences between the ORMs.

=References =
# [http://en.wikipedia.org/wiki/Object-relational_mapping Object Relational Mapping]
# [http://en.wikipedia.org/wiki/Object-oriented_programming object-oriented programming]
# [http://en.wikipedia.org/wiki/Data_access data access]
# [http://en.wikipedia.org/wiki/Metaprogramming metaprogramming]
# [http://guides.rubyonrails.org/active_record_basics.html Active Record]
# [http://guides.rubyonrails.org/getting_started.html#the-mvc-architecture MVC]
# [http://sequel.jeremyevans.net/documentation.html Sequel]
# [http://datamapper.org/ DataMapper]
# [http://sequel.jeremyevans.net/rdoc/classes/Sequel/ThreadedConnectionPool.html Connection Pooling]
# [http://guides.rubyonrails.org/active_record_querying.html#eager-loading-associations Eager Loading]
# [http://rubydoc.info/gems/squeel/1.1.1/frames Squeel]
# [http://www.techopedia.com/definition/24200/object-relational-mapping--orm ORM]
# [http://en.wikipedia.org/wiki/Merb Merb]
# [http://www.merbivore.com/ Merb Website]
# [http://wiki.expertiza.ncsu.edu/index.php/CSC/ECE_517_Spring_2013/ch1_1d_zk Object Relational Mapping Spring 2013]

=Citations=
<references/>

CSC/ECE 517 Fall 2014/ch1a 25 ks

2014-09-24T23:26:23Z

Knimgao: /* Features */

=Object Relational Mapping=

__TOC__

==Introduction<ref>http://en.wikipedia.org/wiki/Object-relational_mapping Object Relational Mapping</ref>==
Object Relation Mapping(ORM, O/RM, and O/R mapping) in computer science is a programming technique for converting data between incompatible type systems in object-oriented programming languages. This creates, in effect, a "virtual object database" that can be used from within the programming language. There are both free and commercial packages available that perform object-relational mapping, although some programmers opt to create their own ORM tools.

==Overview==
Object Relational Mapping is a programming technique in which a metadata descriptor is used to connect object code to a relational database. ORM converts data between type systems that are unable to coexist within relational databases and OOP languages.

In [http://en.wikipedia.org/wiki/Object-oriented_programming object-oriented programming], data management tasks act on object-oriented (OO) objects that are almost always non-scalar values. For example, consider an address book entry that represents a single person along with zero or more phone numbers and zero or more addresses. This could be modeled in an object-oriented implementation by a "Person object" with attributes/fields to hold each data item that the entry comprises: the person's name, a list of phone numbers, and a list of addresses. The list of phone numbers would itself contain "PhoneNumber objects" and so on. The address book entry is treated as a single object by the programming language (it can be referenced by a single variable containing a pointer to the object, for instance). Various methods can be associated with the object, such as a method to return the preferred phone number, the home address, and so on.

The heart of the problem is translating the logical representation of the objects into an atomized form that is capable of being stored in the database, while preserving the properties of the objects and their relationships so that they can be reloaded as objects when needed. If this storage and retrieval functionality is implemented, the objects are said to be persistent.

==Simple Explanation==
A simple answer is that you wrap your tables or stored procedures in classes in your programming language, so that instead of writing SQL statements to interact with your database, you use methods and properties of objects.

In other words, instead of something like this:
<pre>
String sql = "SELECT ... FROM persons WHERE id = 10"
DbCommand cmd = new DbCommand(connection, sql);
Result res = cmd.Execute();
String name = res[0]["FIRST_NAME"];
</pre>
you do something like this:
<pre>
Person p = repository.GetPerson(10);
String name = p.FirstName;
</pre>
or similar code (lots of variations here.) Some frameworks also put a lot of the code in as static methods on the classes themselves, which means you could do something like this instead:
<pre>
Person p = Person.Get(10);
</pre>
Some also implement complex query systems, so you could do this:
<pre>
Person p = Person.Get(Person.Properties.Id == 10);
</pre>
The framework is what makes this code possible.

==Features<ref>http://wiki.expertiza.ncsu.edu/index.php/CSC/ECE_517_Spring_2013/ch1_1d_zk</ref>==
Object-relational Mapping (ORM) frameworks unburden the designer of the complex translation between database and object space.

Typical ORM features:
* Automatic mapping from classes to database tables
** Class instance variables to database columns
** Class instances to table rows
* Aggregation and association relationships between mapped classes are managed
** Example, :has_many, :belongs_to associations in ActiveRecord
** Inheritance cases are mapped to tables
* Validation of data prior to table storage
* Class extensions to enable search, as well as creation, read, update, and deletion (CRUD) of instances/records
* Usually abstracts the database from program space in such a way that alternate database types can be easily chosen (SQLite, Oracle, etc)

The diagram below depicts a simple mapping of an object to a database table….

[[Image:3j_ks_pic1.jpg]]

ORM framework is used to persist model objects to a relational database and retrieve them, and the ORM framework will take care of converting the data between the two otherwise incompatible states. Most ORM tools rely heavily on metadata about both the database and objects, so that the objects need to know nothing about the database and the database doesn’t need to know anything about how the data is structured in the application. ORM provides a clean separation of concerns in a well-designed data application, and the database and application can each work with data in its native form. Database rows map to objects, thus making the program more easily accessible and allowing the usage of information in a way that is internally consistent and easy to understand. The ORM gives the programmer an ability to manipulate data with the programming language, instead of having to manipulate each attribute as its data type as obtained by the database management system.

When applied to Ruby, implementations of ORM often leverage the language’s [http://en.wikipedia.org/wiki/Metaprogramming metaprogramming] strengths to create intuitive application-specific methods and otherwise extend classes to support database functionality. With the addition of Rails, the ORM becomes much more important, as it is necessary to have an ORM to connect the models of the MVC (model-view-controller) stack used by Ruby on Rails with the application's database. Since the models are Ruby objects, the ORM allows modifications to the database to be done through changes to these models, independent of the type of database used.

With the release of Rails 3.0, the platform became ORM independent. With this change, it is much easier to use the ORM most preferred by the programmer, rather than being corralled into using one particular one. To allow this, the ORM needed to be extracted from the model and the database, to be a pure mediator between the two. Then any ORM can be used as long as it can successfully understand the model and the database used.

==Advantages<ref>http://www.techopedia.com/definition/24200/object-relational-mapping--orm</ref>==
In addition to the [http://en.wikipedia.org/wiki/Data_access data access] technique, ORM's benefits also include:
*First of all, you hide the SQL away from your logic code. This has the benefit of allowing you to more easily support more database engines. For instance, MS SQL Server and Oracle has different names on typical functions, and different ways to do calculations with dates, so a query to "get me all persons edited the last 24 hours" might entail different SQL syntax just for those two database engines. This difference can be put away from your logic code.
*Additionally, you can focus on writing the logic, instead of getting all the SQL right. The code will typically be more readable as well, since it doesn't contain all the "plumbing" necessary to talk to the database.
*Simplified development because it automates object-to-table and table-to-object conversion, resulting in lower development and maintenance costs
*Less code compared to embedded SQL and handwritten stored procedures
*Transparent object caching in the application tier, improving system performance
*An optimized solution making an application faster and easier to maintain

==Disadvantages<ref>http://www.techopedia.com/definition/24200/object-relational-mapping--orm</ref>==
*ORM’s emergence in multiple application development has created disagreement among experts. Key concerns are that ORM does not perform well and that stored procedures might be a better solution.
*In addition, ORM dependence may result in poorly-designed databases in certain circumstances.
*Performance – like every "proxy" technology
*Complexity – learning curve
*Difficulty / inability to make complex queries

=ORM Frameworks=

==Active Records==
[http://guides.rubyonrails.org/active_record_basics.html Active Record] was described by Martin Fowler in his book Patterns of Enterprise Application Architecture. Active Record is the M in [http://guides.rubyonrails.org/getting_started.html#the-mvc-architecture MVC]- the model - which is the layer of the system responsible for representing business data and logic. In Active Record, objects carry both persistent data and behavior which operates on that data. A database table or view is wrapped into a class and an object instance is tied to a single row in the table. Each Active Record object has CRUD (Create, Read, Update, and Delete) methods for database access. In addition, Active Record allows you to validate the state of a model before it gets written into the database.

Active Record gives us several mechanisms, the most important being the ability to:
* Represent models and their data.
* Represent associations between these models.
* Represent inheritance hierarchies through related models.
* Validate models before they get persisted to the database.
* Perform database operations in an object-oriented fashion.

The naming conventions used in Active Records are :
* Database Table - Plural with underscores separating words (e.g., book_clubs).
* Model Class - Singular with the first letter of each word capitalized (e.g., BookClub).

To create a table, ActiveRecord makes use of a migration class rather than including table definition in the actual class being modeled. As an example, the following code creates a table ‘’users’’ to store a collection of class ‘’User’’ objects:
<pre>
class CreateUsers < ActiveRecord::Migration
def self.up
create_table :users do |t|
t.string :name
t.string :email
t.string :age
t.references :cheer
t.references :post

t.timestamps # add creation and modification timestamps
end
end

def self.down # undo the table creation
drop_table :users
end
end
</pre>

The ActiveRecord’s migration scheme provides a means for backing out changes via the ‘’self.down’’ method. In addition, a table key ‘’id’’ is added to the new table without an explicit definition and record creation and modification timestamps are included via the ‘’timestamps’’ method provided by ActiveRecord.

ActiveRecord manages associations between table elements and provides the means to define such associations in the model definition. For example, the ‘’User’’ class shown below defines a ‘’has_many’’ (one-to-many) association with both the cheers and posts tables. These associations are represented in the migration class with the references operator. Also note ActiveRecord’s integrated support for validation of table information when attempting an update.

<pre>
class User < ActiveRecord::Base
has_many :cheers
has_many :posts

validates_presence_of :name
validates_presence_of :age
validates_uniqueness_of :name
validates_length_of :name, :within => 3..20
end
</pre>

To access the data in the table one calls the class function related to that column. For example, to find the user who's name is Bob, one would use @user = User.find_by_name('Bob'). Then one could find Bob's e-mail by using @user.email. Users can be searched for by any attribute in this way, as find methods are created for every combination of attributes.
While ActiveRecord provides the flexibility to create more sophisticated table relationships to represent class hierarchy, its base scheme is a single table inheritance, which trades some storage efficiency for simplicity in the database design. The following figure illustrates this concept of simplicity over efficiency.

[[Image:3j_ks_pic2.jpg]]

'''Pros''' -
* Integrated with popular Rails development framework
* Dynamically created database search methods (eg: User.find_by_address) ease db queries and make queries database syntax independent
* DB creation/management using the migrate scheme provides a means for backing out unwanted table changes
'''Cons''' -
* DB creation/management is decoupled from the model, requiring a separate utility (rake/migrate) that must be kept in sync with application.

==ORM Adaptor==
[https://github.com/ianwhite/orm_adapter ORM Adaptors] provide a single point of entry for popular ruby ORMs. Its target audience is gem authors who want to support more than one ORM.
ORM Adapter's goal is to support a minimum API used by most of the plugins that needs agnosticism beyond Active Model.
ORM Adapter will support only basic methods, as get, find_first, create! and so forth. It is not ORM Adapter's goal to support different query constructions, handle table joins, etc.
ORM adapter provides a consistent API for these basic class or 'factory' methods. It does not attempt to unify the behaviour of model instances returned by these methods. This means that unifying the behaviour of methods such as `model.save`, and `model.valid?` is beyond the scope of orm_adapter.
If you need complex queries, it is recommended to subclass ORM Adapters in your plugin and extend it expressing these query conditions as part of your domain logic.
<pre>
Example :
require 'orm_adapter'
User # is it an ActiveRecord, DM Resource, MongoMapper or MongoId Document?
User.to_adapter.find_first :name => 'Fred' # we don't care!
user_model = User.to_adapter
user_model.get!(1) # find a record by id
user_model.find_first(:name => 'fred') # find first fred
user_model.find_first(:level => 'awesome', :id => 23) # find user 23, only if it's level is awesome
user_model.find_all # find all users
user_model.find_all(:name => 'fred') # find all freds
user_model.find_all(:order => :name) # find all freds, ordered by name
user_model.create!(:name => 'fred') # create a fred
user_model.destroy(object) # destroy the user object
</pre>

==Sequel==
[http://sequel.jeremyevans.net/documentation.html Sequel] was originally developed by Sharon Rosner and the first release was in March 2007. It is based on the active record pattern. Sequel and Active Record share a lot of common features , for example association and inheritance. But Sequel handles these features in a much more flexible manner. Currently Sequel is at version 3.44.0. Initially Sequel had three core modules - sequel, sequel_core and sequel_model. Starting from version 1.4 , sequel and sequel_model were merged. Sequel handles validations using a validation plug-in and helpers.

<pre>
class CreateUser < Sequel::Migration
def up
create_table(:user) {
primary_key :id
String :name
String :age
String :email}
end
def down
drop_table(:user)
end
end # CreateUser.apply(DB, :up)
</pre>

Sequel supports associations and validations similar to Active Record. The following example shows how validations and associations can be enforced in the User table that has been created above. It enforces one to many relationships between the user table and the cheers and posts tables. It also validates for the presence , uniqueness and the length of the attribute '''name'''.

<pre>
class User < Sequel::Model
one_to_many :cheers
one_to_many :posts

validates_presence [:name, :age]
validates_unique(:name)
validates_length_range 3..20, :name
end
</pre>

To access the data in Sequel, one can use where clauses. For instance, to find Bob again one would use DB[:items].where(Sequel.like(:name, 'Bob'). While the ability to use SQL-like where clauses is quite flexible, it is not quite as pure an object-oriented approach as Active Record's dynamically created find methods.

Some of the key features of sequel are,
* [http://sequel.jeremyevans.net/rdoc/classes/Sequel/ThreadedConnectionPool.html Connection Pooling]
* Thread Safety
* [http://guides.rubyonrails.org/active_record_querying.html#eager-loading-associations Eager Loading] / Lazy Loading
* Model Caching
* Supports advanced database features such as prepared statements, bound variables, stored procedures, savepoints, two-phase commit, transaction isolation, master/slave configurations, and database sharding.

==Data Mapper==
[http://datamapper.org/ DataMapper] is an Object Relational Mapper written in Ruby developed by Sam Smoot with the goal to create an ORM which is fast, thread-safe and feature rich.
A Data Mapper is a Data Access Layer that performs bidirectional transfer of data between a persistent data store (often a relational database) and an in memory data representation (the domain layer). The goal of the pattern is to keep the in memory representation and the persistent data store independent of each other and the data mapper itself. The layer is composed of one or more mappers (or Data Access Objects), performing the data transfer.
DataMapper comes with the ability to use the same API to talk to a multitude of different datastores. There are adapters for the usual RDBMS suspects, NoSQL stores, various file formats and some web services. With DataMapper, you define your mappings in your model. Your data store can develop independently of your model using Migrations.

Some features of Data Mapper are as follows :
* No need to write structural migrations
* Scoped relations
* Lazy loading on certain attribute types
* Strategic eager loading to avoid (N+1) queries
* Default support for composite and natural keys
* Query chaining, and not evaluating the query until absolutely necessary (using a lazy array implementation)
* An API not too heavily oriented to SQL databases

DataMapper was designed to be a more abstract ORM, not strictly SQL, based on Martin Fowler's enterprise pattern. As a result, DataMapper adapters have been built for other non-SQL databases, such as CouchDB, [http://github.com/lritter/dm-solr-adapter/tree/master Apache Solr], and webservices such as [http://github.com/halorgium/dm-salesforce/tree/master Salesforce].

Example of table definition in the model:
<pre>
class User
include DataMapper::Resource

property :id, Serial # key
property :name, String, :required => true, :unique => true
property :age, String, :required => true, :length => 3..20
property :email, String

has n, :posts # one to many association
has n, :cheers # one to many association
end
</pre>

Notice that in the example above , ":required = true" is an example for Auto Validation. Unlike ActiveRecord and Sequel, DataMapper supports auto validations , i.e. these in turn call the validation helpers to enforce basic validations such as length, uniqueness, format, presence etc.

==MyBatis/iBatis==
[http://en.wikipedia.org/wiki/MyBatis MyBatis/iBatis] was a persistence framework which allowed easy access of the database from a Rails application without being a full ORM. It was created by the Apache Foundation in 2002, and is available for several platforms, including Ruby (the Ruby release is known as RBatis). On 6/16/2010, after releasing iBATIS 3.0, the project team moved from Apache to Google Code, changed the project's name to MyBatis, and stopped supporting Ruby.

The MyBatis data mapper framework makes it easier to use a relational database with object-oriented applications. MyBatis couples objects with stored procedures or SQL statements using a XML descriptor. To use the MyBatis data mapper,we make use of our own objects, XML, and SQL.

SQL statements are stored in XML files or annotations. Following is a MyBatis mapper, that consists of a Java interface with some MyBatis annotations:
<pre>
package org.mybatis.example;

public interface BlogMapper {
@Select("select * from Blog where id = #{id}")
Blog selectBlog(int id);
}
</pre>
The sentence is executed as follows.
<pre>
BlogMapper mapper = session.getMapper(BlogMapper.class);
Blog blog = mapper.selectBlog(101);
</pre>

It can also be executed using MyBatis API.
<pre>
Blog blog = session.selectOne("org.mybatis.example.BlogMapper.selectBlog", 101);
</pre>

SQL statements and mappings can also be externalized to an XML file like this.
<pre>
<?xml version="1.0" encoding="UTF-8" ?>
<!DOCTYPE mapper PUBLIC "-//mybatis.org//DTD Mapper 3.0//EN" "http://mybatis.org/dtd/mybatis-3-mapper.dtd">

<mapper namespace="org.mybatis.example.BlogMapper">
<select id="selectBlog" parameterType="int" resultType="Blog">
select * from Blog where id = #{id}
</select>
</mapper>
</pre>

==Squeel==
[http://rubydoc.info/gems/squeel/1.1.1/frames Squeel]unlocks the power of Arel in Rails applications with a handy block-based syntax. It is supporting in Rails 3 and 4. With Squeel, you can write subqueries, access named functions provided by RDMBS and more without writing SQL strings.
Squeel lets you write your Active Record queries with fewer strings, and more Ruby, by making the Arel awesomeness that lies beneath Active Record more accessible.

Squeel lets you rewrite...

<pre>
Article.where ['created_at >= ?', 2.weeks.ago]
...as...
Article.where{created_at >= 2.weeks.ago}
</pre>

Squeel enhances the normal Active Record query methods by enabling them to accept blocks. Inside a block, the Squeel query DSL can be used. Note the use of curly braces in the above example instead of parentheses. {} denotes a Squeel DSL query.

Stubs and keypaths are the two primary building blocks used in a Squeel DSL query.

Stubs are, for most intents and purposes, just like Symbols in a normal call to Relation#where (note the need for doubling up on the curly braces here, the first ones start the block, the second are the hash braces):
<pre>
Person.where{{name => ‘Ernie’ }}
</pre>

You normally wouldn't bother using the DSL in this case, as a simple hash would suffice. However, stubs serve as a building block for keypaths, and keypaths are very handy.

A Squeel keypath is essentially a more concise and readable alternative to a deeply nested hash. For instance, in standard Active Record, you might join several associations like this to perform a query:
<pre>
Person.joins(:articles => { :comments => :person}).references(:all)
</pre>

With a keypath, this would look like:
<pre>
Person.joins{articles.comments.person}.references(:all)
</pre>

The Squeel DSL works its magic using instance_eval which means that inside a Squeel DSL block, self isn't the same thing that it is outside the block.
This carries with it an important implication: Instance variables and instance methods inside the block won't refer to your object's variables/methods.
Use one of the following methods to get access to the object's methods and variables:
* Assign the variable locally before the DSL block, and access it as you would normally.
* Supply an arity to the DSL block, as in Person.where{|q| q.name == @my_name} Downside: You'll need to prefix stubs, keypaths, and functions with the DSL object.
* Wrap the method or instance variable inside the block with my{}. Person.where{name == my{some_method_to_return_a_name}}

==Merb==
[http://en.wikipedia.org/wiki/Merb Merb], short for "Mongrel+Erb", is a model view controller framework written in Ruby. Merb was merged into Rails web framework on December 23, 2008 as part of the Ruby on Rails 3.0 release.
Merb itself provides only the controller of an MVC model which can be extended to create a full-stack application environment. This effectively means Merb itself is not an ORM but can accommodate other ORMs.
Some features of Merb are as follows :
* Speed - Merb is ORM, JavaScript library and template language agnostic, preferring plugins that add support for features rather than producing a monolithic library with everything in the core.
* Lightweight - Rather than trying to cram every feature into a single code, things are kept bare minimum without sacrificing anything important.
* Powerful and extensible - For any features not covered in Merb’s core, there are plugins.
Some basic Command distinction between Ruby on Rails and Merb :
{| class="comparison" border="1"
! Action
! Ruby on Rails
! Merb
|-
| Create new application 'app1' || rails new app1 || merb-gen app app1
|-
| Start server || rails server || merb
|-
| Start cluster of 3 beginning at port 3000 || N/A || merb -p 3000 -c 3
|-
| Interactive console || rails console || merb -i
|}

=Alternative to ORM=
==NonSQL databases==
Instead of ORM we can also use Object-Oriented Database Management System (OODBMS) or document-oriented database like XML, where in databases are designed to store object oriented values, thus eliminating the need to convert data to and from its SQL form. Document oriented databases also eliminates the need to retrieve objects as data rows. Query languages like XQuery can be used to retrieve data sets.

The only issue is we won't be able to create application independent queries for retrieving data without restrictions to access path. Also OODBMS limits the extent of processing SQL queries.
A Relational database allows concurrent access to data, locking, indexing (fast search), as well as many other features that are not available while using XML files.

Other OODBMS (such as RavenDB) provide replication to SQL databases, as a means of addressing the need for ad-hoc queries, while preserving the increased performance and reduced complexity that may be achieved with an OODBMS for an application that has well-known query patterns.

NonSQL databases don’t provide mechanism to maintain relationship between tables. In real life though, business objects or entities do have relationship among them. ORM solutions may allow you to define these relationships in business objects and handle their storage and retrieval behind the scene

=Comparison of ORM Features=

{|cellspacing="0" border="1"
!style="width:8%"|Features
!style="width:23%"|ActiveRecord
!style="width:23%"|Sequel
!style="width:23%"|DataMapper
!style="width:23%"|MyBatis
|-
! Databases 
| MySQL, PostgreSQL, SQLite, Oracle, SQLServer, and DB2
| ADO, DataObjects, DB2, DBI, Firebird, Informix, JDBC, MySQL, ODBC, OpenBase, Oracle, PostgreSQL and SQLite3
| SQLite, MySQL, PostgreSQL, Oracle, MongoDB, SimpleDB, many others, including CouchDB, Apache Solr, Google Data API
| MySQL, PostgreSQL, SQLite, Oracle, SQLServer, and DB2
|-
! Migrations 
| Yes
| Yes
| Yes, but optional
| Yes, provides migration by Mybatis schema migration system.
|-
! EagerLoading 
| Supported by scanning the SQL fragments
| Supported using eager (preloading) and eager_graph (joins)
| Strategic Eager Loading and by using :summary
| Yes.this can be enabled or disabled by setting the lazyLoadingEnabled flag
|-
! Flexible Overriding 
| No. Overriding is done using alias methods.
| Using methods and by calling 'super'
| Using methods
| No
|-
! Dynamic Finders 
| Yes. Uses 'Method Missing'
| No. Alternative is to use <Model>.FindOrCreate(:name=>"John")
| Yes. Using the dm_ar_finders plugin
| Similar feature is supported in the form of Dynamic SQL
|}

=Further Reading=
To get more information on ORM and the different type of ORM's available for Ruby , please look into the [http://wiki.expertiza.ncsu.edu/index.php/CSC/ECE_517_Spring_2013/ch1_1d_zk CSC/ECE 517 Spring 2013/ch1 1d zk] and [http://wiki.expertiza.ncsu.edu/index.php/CSC/ECE_517_Fall_2010/ch3_3f_ac Fall 2010 detailed ORM explanation] wiki pages.
# [http://www.cs.colorado.edu/~kena/classes/5448/f11/lectures/29-orm.pdf ORM - University of Colorado]
# [http://www.lynda.com/Ruby-Rails-tutorials/Understanding-ActiveRecord-ActiveRelation/139989/159093-4.html Active Record Tutorial]
# [http://digitalcommons.macalester.edu/context/mathcs_honors/article/1006/type/native/viewcontent/ Research papers on object relational mapping]
# [http://www.sitepoint.com/top-ruby-frameworks-rails-and-merb-join-forces/ Merb and Rails]

=Future Work=
More work can be done in the area of comparison between the different ORMs available for Ruby, especially a more detailed feature-by-feature comparison that includes performance differences between the ORMs.

=References =
# [http://en.wikipedia.org/wiki/Object-relational_mapping Object Relational Mapping]
# [http://en.wikipedia.org/wiki/Object-oriented_programming object-oriented programming]
# [http://en.wikipedia.org/wiki/Data_access data access]
# [http://en.wikipedia.org/wiki/Metaprogramming metaprogramming]
# [http://guides.rubyonrails.org/active_record_basics.html Active Record]
# [http://guides.rubyonrails.org/getting_started.html#the-mvc-architecture MVC]
# [http://sequel.jeremyevans.net/documentation.html Sequel]
# [http://datamapper.org/ DataMapper]
# [http://sequel.jeremyevans.net/rdoc/classes/Sequel/ThreadedConnectionPool.html Connection Pooling]
# [http://guides.rubyonrails.org/active_record_querying.html#eager-loading-associations Eager Loading]
# [http://rubydoc.info/gems/squeel/1.1.1/frames Squeel]
# [http://www.techopedia.com/definition/24200/object-relational-mapping--orm ORM]
# [http://en.wikipedia.org/wiki/Merb Merb]
# [http://www.merbivore.com/ Merb Website]
# [http://wiki.expertiza.ncsu.edu/index.php/CSC/ECE_517_Spring_2013/ch1_1d_zk Object Relational Mapping Spring 2013]

=Citations=
<references/>

CSC/ECE 517 Fall 2014/ch1a 25 ks

2014-09-24T23:23:25Z

Knimgao: /* Object Relational Mapping */

=Object Relational Mapping=

__TOC__

==Introduction<ref>http://en.wikipedia.org/wiki/Object-relational_mapping Object Relational Mapping</ref>==
Object Relation Mapping(ORM, O/RM, and O/R mapping) in computer science is a programming technique for converting data between incompatible type systems in object-oriented programming languages. This creates, in effect, a "virtual object database" that can be used from within the programming language. There are both free and commercial packages available that perform object-relational mapping, although some programmers opt to create their own ORM tools.

==Overview==
Object Relational Mapping is a programming technique in which a metadata descriptor is used to connect object code to a relational database. ORM converts data between type systems that are unable to coexist within relational databases and OOP languages.

In [http://en.wikipedia.org/wiki/Object-oriented_programming object-oriented programming], data management tasks act on object-oriented (OO) objects that are almost always non-scalar values. For example, consider an address book entry that represents a single person along with zero or more phone numbers and zero or more addresses. This could be modeled in an object-oriented implementation by a "Person object" with attributes/fields to hold each data item that the entry comprises: the person's name, a list of phone numbers, and a list of addresses. The list of phone numbers would itself contain "PhoneNumber objects" and so on. The address book entry is treated as a single object by the programming language (it can be referenced by a single variable containing a pointer to the object, for instance). Various methods can be associated with the object, such as a method to return the preferred phone number, the home address, and so on.

The heart of the problem is translating the logical representation of the objects into an atomized form that is capable of being stored in the database, while preserving the properties of the objects and their relationships so that they can be reloaded as objects when needed. If this storage and retrieval functionality is implemented, the objects are said to be persistent.

==Simple Explanation==
A simple answer is that you wrap your tables or stored procedures in classes in your programming language, so that instead of writing SQL statements to interact with your database, you use methods and properties of objects.

In other words, instead of something like this:
<pre>
String sql = "SELECT ... FROM persons WHERE id = 10"
DbCommand cmd = new DbCommand(connection, sql);
Result res = cmd.Execute();
String name = res[0]["FIRST_NAME"];
</pre>
you do something like this:
<pre>
Person p = repository.GetPerson(10);
String name = p.FirstName;
</pre>
or similar code (lots of variations here.) Some frameworks also put a lot of the code in as static methods on the classes themselves, which means you could do something like this instead:
<pre>
Person p = Person.Get(10);
</pre>
Some also implement complex query systems, so you could do this:
<pre>
Person p = Person.Get(Person.Properties.Id == 10);
</pre>
The framework is what makes this code possible.

==Features==
Object-relational Mapping (ORM) frameworks unburden the designer of the complex translation between database and object space.

Typical ORM features:
* Automatic mapping from classes to database tables
** Class instance variables to database columns
** Class instances to table rows
* Aggregation and association relationships between mapped classes are managed
** Example, :has_many, :belongs_to associations in ActiveRecord
** Inheritance cases are mapped to tables
* Validation of data prior to table storage
* Class extensions to enable search, as well as creation, read, update, and deletion (CRUD) of instances/records
* Usually abstracts the database from program space in such a way that alternate database types can be easily chosen (SQLite, Oracle, etc)

The diagram below depicts a simple mapping of an object to a database table….

[[Image:3j_ks_pic1.jpg]]

ORM framework is used to persist model objects to a relational database and retrieve them, and the ORM framework will take care of converting the data between the two otherwise incompatible states. Most ORM tools rely heavily on metadata about both the database and objects, so that the objects need to know nothing about the database and the database doesn’t need to know anything about how the data is structured in the application. ORM provides a clean separation of concerns in a well-designed data application, and the database and application can each work with data in its native form. Database rows map to objects, thus making the program more easily accessible and allowing the usage of information in a way that is internally consistent and easy to understand. The ORM gives the programmer an ability to manipulate data with the programming language, instead of having to manipulate each attribute as its data type as obtained by the database management system.

When applied to Ruby, implementations of ORM often leverage the language’s [http://en.wikipedia.org/wiki/Metaprogramming metaprogramming] strengths to create intuitive application-specific methods and otherwise extend classes to support database functionality. With the addition of Rails, the ORM becomes much more important, as it is necessary to have an ORM to connect the models of the MVC (model-view-controller) stack used by Ruby on Rails with the application's database. Since the models are Ruby objects, the ORM allows modifications to the database to be done through changes to these models, independent of the type of database used.

With the release of Rails 3.0, the platform became ORM independent. With this change, it is much easier to use the ORM most preferred by the programmer, rather than being corralled into using one particular one. To allow this, the ORM needed to be extracted from the model and the database, to be a pure mediator between the two. Then any ORM can be used as long as it can successfully understand the model and the database used.

==Advantages<ref>http://www.techopedia.com/definition/24200/object-relational-mapping--orm</ref>==
In addition to the [http://en.wikipedia.org/wiki/Data_access data access] technique, ORM's benefits also include:
*First of all, you hide the SQL away from your logic code. This has the benefit of allowing you to more easily support more database engines. For instance, MS SQL Server and Oracle has different names on typical functions, and different ways to do calculations with dates, so a query to "get me all persons edited the last 24 hours" might entail different SQL syntax just for those two database engines. This difference can be put away from your logic code.
*Additionally, you can focus on writing the logic, instead of getting all the SQL right. The code will typically be more readable as well, since it doesn't contain all the "plumbing" necessary to talk to the database.
*Simplified development because it automates object-to-table and table-to-object conversion, resulting in lower development and maintenance costs
*Less code compared to embedded SQL and handwritten stored procedures
*Transparent object caching in the application tier, improving system performance
*An optimized solution making an application faster and easier to maintain

==Disadvantages<ref>http://www.techopedia.com/definition/24200/object-relational-mapping--orm</ref>==
*ORM’s emergence in multiple application development has created disagreement among experts. Key concerns are that ORM does not perform well and that stored procedures might be a better solution.
*In addition, ORM dependence may result in poorly-designed databases in certain circumstances.
*Performance – like every "proxy" technology
*Complexity – learning curve
*Difficulty / inability to make complex queries

=ORM Frameworks=

==Active Records==
[http://guides.rubyonrails.org/active_record_basics.html Active Record] was described by Martin Fowler in his book Patterns of Enterprise Application Architecture. Active Record is the M in [http://guides.rubyonrails.org/getting_started.html#the-mvc-architecture MVC]- the model - which is the layer of the system responsible for representing business data and logic. In Active Record, objects carry both persistent data and behavior which operates on that data. A database table or view is wrapped into a class and an object instance is tied to a single row in the table. Each Active Record object has CRUD (Create, Read, Update, and Delete) methods for database access. In addition, Active Record allows you to validate the state of a model before it gets written into the database.

Active Record gives us several mechanisms, the most important being the ability to:
* Represent models and their data.
* Represent associations between these models.
* Represent inheritance hierarchies through related models.
* Validate models before they get persisted to the database.
* Perform database operations in an object-oriented fashion.

The naming conventions used in Active Records are :
* Database Table - Plural with underscores separating words (e.g., book_clubs).
* Model Class - Singular with the first letter of each word capitalized (e.g., BookClub).

To create a table, ActiveRecord makes use of a migration class rather than including table definition in the actual class being modeled. As an example, the following code creates a table ‘’users’’ to store a collection of class ‘’User’’ objects:
<pre>
class CreateUsers < ActiveRecord::Migration
def self.up
create_table :users do |t|
t.string :name
t.string :email
t.string :age
t.references :cheer
t.references :post

t.timestamps # add creation and modification timestamps
end
end

def self.down # undo the table creation
drop_table :users
end
end
</pre>

The ActiveRecord’s migration scheme provides a means for backing out changes via the ‘’self.down’’ method. In addition, a table key ‘’id’’ is added to the new table without an explicit definition and record creation and modification timestamps are included via the ‘’timestamps’’ method provided by ActiveRecord.

ActiveRecord manages associations between table elements and provides the means to define such associations in the model definition. For example, the ‘’User’’ class shown below defines a ‘’has_many’’ (one-to-many) association with both the cheers and posts tables. These associations are represented in the migration class with the references operator. Also note ActiveRecord’s integrated support for validation of table information when attempting an update.

<pre>
class User < ActiveRecord::Base
has_many :cheers
has_many :posts

validates_presence_of :name
validates_presence_of :age
validates_uniqueness_of :name
validates_length_of :name, :within => 3..20
end
</pre>

To access the data in the table one calls the class function related to that column. For example, to find the user who's name is Bob, one would use @user = User.find_by_name('Bob'). Then one could find Bob's e-mail by using @user.email. Users can be searched for by any attribute in this way, as find methods are created for every combination of attributes.
While ActiveRecord provides the flexibility to create more sophisticated table relationships to represent class hierarchy, its base scheme is a single table inheritance, which trades some storage efficiency for simplicity in the database design. The following figure illustrates this concept of simplicity over efficiency.

[[Image:3j_ks_pic2.jpg]]

'''Pros''' -
* Integrated with popular Rails development framework
* Dynamically created database search methods (eg: User.find_by_address) ease db queries and make queries database syntax independent
* DB creation/management using the migrate scheme provides a means for backing out unwanted table changes
'''Cons''' -
* DB creation/management is decoupled from the model, requiring a separate utility (rake/migrate) that must be kept in sync with application.

==ORM Adaptor==
[https://github.com/ianwhite/orm_adapter ORM Adaptors] provide a single point of entry for popular ruby ORMs. Its target audience is gem authors who want to support more than one ORM.
ORM Adapter's goal is to support a minimum API used by most of the plugins that needs agnosticism beyond Active Model.
ORM Adapter will support only basic methods, as get, find_first, create! and so forth. It is not ORM Adapter's goal to support different query constructions, handle table joins, etc.
ORM adapter provides a consistent API for these basic class or 'factory' methods. It does not attempt to unify the behaviour of model instances returned by these methods. This means that unifying the behaviour of methods such as `model.save`, and `model.valid?` is beyond the scope of orm_adapter.
If you need complex queries, it is recommended to subclass ORM Adapters in your plugin and extend it expressing these query conditions as part of your domain logic.
<pre>
Example :
require 'orm_adapter'
User # is it an ActiveRecord, DM Resource, MongoMapper or MongoId Document?
User.to_adapter.find_first :name => 'Fred' # we don't care!
user_model = User.to_adapter
user_model.get!(1) # find a record by id
user_model.find_first(:name => 'fred') # find first fred
user_model.find_first(:level => 'awesome', :id => 23) # find user 23, only if it's level is awesome
user_model.find_all # find all users
user_model.find_all(:name => 'fred') # find all freds
user_model.find_all(:order => :name) # find all freds, ordered by name
user_model.create!(:name => 'fred') # create a fred
user_model.destroy(object) # destroy the user object
</pre>

==Sequel==
[http://sequel.jeremyevans.net/documentation.html Sequel] was originally developed by Sharon Rosner and the first release was in March 2007. It is based on the active record pattern. Sequel and Active Record share a lot of common features , for example association and inheritance. But Sequel handles these features in a much more flexible manner. Currently Sequel is at version 3.44.0. Initially Sequel had three core modules - sequel, sequel_core and sequel_model. Starting from version 1.4 , sequel and sequel_model were merged. Sequel handles validations using a validation plug-in and helpers.

<pre>
class CreateUser < Sequel::Migration
def up
create_table(:user) {
primary_key :id
String :name
String :age
String :email}
end
def down
drop_table(:user)
end
end # CreateUser.apply(DB, :up)
</pre>

Sequel supports associations and validations similar to Active Record. The following example shows how validations and associations can be enforced in the User table that has been created above. It enforces one to many relationships between the user table and the cheers and posts tables. It also validates for the presence , uniqueness and the length of the attribute '''name'''.

<pre>
class User < Sequel::Model
one_to_many :cheers
one_to_many :posts

validates_presence [:name, :age]
validates_unique(:name)
validates_length_range 3..20, :name
end
</pre>

To access the data in Sequel, one can use where clauses. For instance, to find Bob again one would use DB[:items].where(Sequel.like(:name, 'Bob'). While the ability to use SQL-like where clauses is quite flexible, it is not quite as pure an object-oriented approach as Active Record's dynamically created find methods.

Some of the key features of sequel are,
* [http://sequel.jeremyevans.net/rdoc/classes/Sequel/ThreadedConnectionPool.html Connection Pooling]
* Thread Safety
* [http://guides.rubyonrails.org/active_record_querying.html#eager-loading-associations Eager Loading] / Lazy Loading
* Model Caching
* Supports advanced database features such as prepared statements, bound variables, stored procedures, savepoints, two-phase commit, transaction isolation, master/slave configurations, and database sharding.

==Data Mapper==
[http://datamapper.org/ DataMapper] is an Object Relational Mapper written in Ruby developed by Sam Smoot with the goal to create an ORM which is fast, thread-safe and feature rich.
A Data Mapper is a Data Access Layer that performs bidirectional transfer of data between a persistent data store (often a relational database) and an in memory data representation (the domain layer). The goal of the pattern is to keep the in memory representation and the persistent data store independent of each other and the data mapper itself. The layer is composed of one or more mappers (or Data Access Objects), performing the data transfer.
DataMapper comes with the ability to use the same API to talk to a multitude of different datastores. There are adapters for the usual RDBMS suspects, NoSQL stores, various file formats and some web services. With DataMapper, you define your mappings in your model. Your data store can develop independently of your model using Migrations.

Some features of Data Mapper are as follows :
* No need to write structural migrations
* Scoped relations
* Lazy loading on certain attribute types
* Strategic eager loading to avoid (N+1) queries
* Default support for composite and natural keys
* Query chaining, and not evaluating the query until absolutely necessary (using a lazy array implementation)
* An API not too heavily oriented to SQL databases

DataMapper was designed to be a more abstract ORM, not strictly SQL, based on Martin Fowler's enterprise pattern. As a result, DataMapper adapters have been built for other non-SQL databases, such as CouchDB, [http://github.com/lritter/dm-solr-adapter/tree/master Apache Solr], and webservices such as [http://github.com/halorgium/dm-salesforce/tree/master Salesforce].

Example of table definition in the model:
<pre>
class User
include DataMapper::Resource

property :id, Serial # key
property :name, String, :required => true, :unique => true
property :age, String, :required => true, :length => 3..20
property :email, String

has n, :posts # one to many association
has n, :cheers # one to many association
end
</pre>

Notice that in the example above , ":required = true" is an example for Auto Validation. Unlike ActiveRecord and Sequel, DataMapper supports auto validations , i.e. these in turn call the validation helpers to enforce basic validations such as length, uniqueness, format, presence etc.

==MyBatis/iBatis==
[http://en.wikipedia.org/wiki/MyBatis MyBatis/iBatis] was a persistence framework which allowed easy access of the database from a Rails application without being a full ORM. It was created by the Apache Foundation in 2002, and is available for several platforms, including Ruby (the Ruby release is known as RBatis). On 6/16/2010, after releasing iBATIS 3.0, the project team moved from Apache to Google Code, changed the project's name to MyBatis, and stopped supporting Ruby.

The MyBatis data mapper framework makes it easier to use a relational database with object-oriented applications. MyBatis couples objects with stored procedures or SQL statements using a XML descriptor. To use the MyBatis data mapper,we make use of our own objects, XML, and SQL.

SQL statements are stored in XML files or annotations. Following is a MyBatis mapper, that consists of a Java interface with some MyBatis annotations:
<pre>
package org.mybatis.example;

public interface BlogMapper {
@Select("select * from Blog where id = #{id}")
Blog selectBlog(int id);
}
</pre>
The sentence is executed as follows.
<pre>
BlogMapper mapper = session.getMapper(BlogMapper.class);
Blog blog = mapper.selectBlog(101);
</pre>

It can also be executed using MyBatis API.
<pre>
Blog blog = session.selectOne("org.mybatis.example.BlogMapper.selectBlog", 101);
</pre>

SQL statements and mappings can also be externalized to an XML file like this.
<pre>
<?xml version="1.0" encoding="UTF-8" ?>
<!DOCTYPE mapper PUBLIC "-//mybatis.org//DTD Mapper 3.0//EN" "http://mybatis.org/dtd/mybatis-3-mapper.dtd">

<mapper namespace="org.mybatis.example.BlogMapper">
<select id="selectBlog" parameterType="int" resultType="Blog">
select * from Blog where id = #{id}
</select>
</mapper>
</pre>

==Squeel==
[http://rubydoc.info/gems/squeel/1.1.1/frames Squeel]unlocks the power of Arel in Rails applications with a handy block-based syntax. It is supporting in Rails 3 and 4. With Squeel, you can write subqueries, access named functions provided by RDMBS and more without writing SQL strings.
Squeel lets you write your Active Record queries with fewer strings, and more Ruby, by making the Arel awesomeness that lies beneath Active Record more accessible.

Squeel lets you rewrite...

<pre>
Article.where ['created_at >= ?', 2.weeks.ago]
...as...
Article.where{created_at >= 2.weeks.ago}
</pre>

Squeel enhances the normal Active Record query methods by enabling them to accept blocks. Inside a block, the Squeel query DSL can be used. Note the use of curly braces in the above example instead of parentheses. {} denotes a Squeel DSL query.

Stubs and keypaths are the two primary building blocks used in a Squeel DSL query.

Stubs are, for most intents and purposes, just like Symbols in a normal call to Relation#where (note the need for doubling up on the curly braces here, the first ones start the block, the second are the hash braces):
<pre>
Person.where{{name => ‘Ernie’ }}
</pre>

You normally wouldn't bother using the DSL in this case, as a simple hash would suffice. However, stubs serve as a building block for keypaths, and keypaths are very handy.

A Squeel keypath is essentially a more concise and readable alternative to a deeply nested hash. For instance, in standard Active Record, you might join several associations like this to perform a query:
<pre>
Person.joins(:articles => { :comments => :person}).references(:all)
</pre>

With a keypath, this would look like:
<pre>
Person.joins{articles.comments.person}.references(:all)
</pre>

The Squeel DSL works its magic using instance_eval which means that inside a Squeel DSL block, self isn't the same thing that it is outside the block.
This carries with it an important implication: Instance variables and instance methods inside the block won't refer to your object's variables/methods.
Use one of the following methods to get access to the object's methods and variables:
* Assign the variable locally before the DSL block, and access it as you would normally.
* Supply an arity to the DSL block, as in Person.where{|q| q.name == @my_name} Downside: You'll need to prefix stubs, keypaths, and functions with the DSL object.
* Wrap the method or instance variable inside the block with my{}. Person.where{name == my{some_method_to_return_a_name}}

==Merb==
[http://en.wikipedia.org/wiki/Merb Merb], short for "Mongrel+Erb", is a model view controller framework written in Ruby. Merb was merged into Rails web framework on December 23, 2008 as part of the Ruby on Rails 3.0 release.
Merb itself provides only the controller of an MVC model which can be extended to create a full-stack application environment. This effectively means Merb itself is not an ORM but can accommodate other ORMs.
Some features of Merb are as follows :
* Speed - Merb is ORM, JavaScript library and template language agnostic, preferring plugins that add support for features rather than producing a monolithic library with everything in the core.
* Lightweight - Rather than trying to cram every feature into a single code, things are kept bare minimum without sacrificing anything important.
* Powerful and extensible - For any features not covered in Merb’s core, there are plugins.
Some basic Command distinction between Ruby on Rails and Merb :
{| class="comparison" border="1"
! Action
! Ruby on Rails
! Merb
|-
| Create new application 'app1' || rails new app1 || merb-gen app app1
|-
| Start server || rails server || merb
|-
| Start cluster of 3 beginning at port 3000 || N/A || merb -p 3000 -c 3
|-
| Interactive console || rails console || merb -i
|}

=Alternative to ORM=
==NonSQL databases==
Instead of ORM we can also use Object-Oriented Database Management System (OODBMS) or document-oriented database like XML, where in databases are designed to store object oriented values, thus eliminating the need to convert data to and from its SQL form. Document oriented databases also eliminates the need to retrieve objects as data rows. Query languages like XQuery can be used to retrieve data sets.

The only issue is we won't be able to create application independent queries for retrieving data without restrictions to access path. Also OODBMS limits the extent of processing SQL queries.
A Relational database allows concurrent access to data, locking, indexing (fast search), as well as many other features that are not available while using XML files.

Other OODBMS (such as RavenDB) provide replication to SQL databases, as a means of addressing the need for ad-hoc queries, while preserving the increased performance and reduced complexity that may be achieved with an OODBMS for an application that has well-known query patterns.

NonSQL databases don’t provide mechanism to maintain relationship between tables. In real life though, business objects or entities do have relationship among them. ORM solutions may allow you to define these relationships in business objects and handle their storage and retrieval behind the scene

=Comparison of ORM Features=

{|cellspacing="0" border="1"
!style="width:8%"|Features
!style="width:23%"|ActiveRecord
!style="width:23%"|Sequel
!style="width:23%"|DataMapper
!style="width:23%"|MyBatis
|-
! Databases 
| MySQL, PostgreSQL, SQLite, Oracle, SQLServer, and DB2
| ADO, DataObjects, DB2, DBI, Firebird, Informix, JDBC, MySQL, ODBC, OpenBase, Oracle, PostgreSQL and SQLite3
| SQLite, MySQL, PostgreSQL, Oracle, MongoDB, SimpleDB, many others, including CouchDB, Apache Solr, Google Data API
| MySQL, PostgreSQL, SQLite, Oracle, SQLServer, and DB2
|-
! Migrations 
| Yes
| Yes
| Yes, but optional
| Yes, provides migration by Mybatis schema migration system.
|-
! EagerLoading 
| Supported by scanning the SQL fragments
| Supported using eager (preloading) and eager_graph (joins)
| Strategic Eager Loading and by using :summary
| Yes.this can be enabled or disabled by setting the lazyLoadingEnabled flag
|-
! Flexible Overriding 
| No. Overriding is done using alias methods.
| Using methods and by calling 'super'
| Using methods
| No
|-
! Dynamic Finders 
| Yes. Uses 'Method Missing'
| No. Alternative is to use <Model>.FindOrCreate(:name=>"John")
| Yes. Using the dm_ar_finders plugin
| Similar feature is supported in the form of Dynamic SQL
|}

=Further Reading=
To get more information on ORM and the different type of ORM's available for Ruby , please look into the [http://wiki.expertiza.ncsu.edu/index.php/CSC/ECE_517_Spring_2013/ch1_1d_zk CSC/ECE 517 Spring 2013/ch1 1d zk] and [http://wiki.expertiza.ncsu.edu/index.php/CSC/ECE_517_Fall_2010/ch3_3f_ac Fall 2010 detailed ORM explanation] wiki pages.
# [http://www.cs.colorado.edu/~kena/classes/5448/f11/lectures/29-orm.pdf ORM - University of Colorado]
# [http://www.lynda.com/Ruby-Rails-tutorials/Understanding-ActiveRecord-ActiveRelation/139989/159093-4.html Active Record Tutorial]
# [http://digitalcommons.macalester.edu/context/mathcs_honors/article/1006/type/native/viewcontent/ Research papers on object relational mapping]
# [http://www.sitepoint.com/top-ruby-frameworks-rails-and-merb-join-forces/ Merb and Rails]

=Future Work=
More work can be done in the area of comparison between the different ORMs available for Ruby, especially a more detailed feature-by-feature comparison that includes performance differences between the ORMs.

=References =
# [http://en.wikipedia.org/wiki/Object-relational_mapping Object Relational Mapping]
# [http://en.wikipedia.org/wiki/Object-oriented_programming object-oriented programming]
# [http://en.wikipedia.org/wiki/Data_access data access]
# [http://en.wikipedia.org/wiki/Metaprogramming metaprogramming]
# [http://guides.rubyonrails.org/active_record_basics.html Active Record]
# [http://guides.rubyonrails.org/getting_started.html#the-mvc-architecture MVC]
# [http://sequel.jeremyevans.net/documentation.html Sequel]
# [http://datamapper.org/ DataMapper]
# [http://sequel.jeremyevans.net/rdoc/classes/Sequel/ThreadedConnectionPool.html Connection Pooling]
# [http://guides.rubyonrails.org/active_record_querying.html#eager-loading-associations Eager Loading]
# [http://rubydoc.info/gems/squeel/1.1.1/frames Squeel]
# [http://www.techopedia.com/definition/24200/object-relational-mapping--orm ORM]
# [http://en.wikipedia.org/wiki/Merb Merb]
# [http://www.merbivore.com/ Merb Website]
# [http://wiki.expertiza.ncsu.edu/index.php/CSC/ECE_517_Spring_2013/ch1_1d_zk Object Relational Mapping Spring 2013]

=Citations=
<references/>

CSC/ECE 517 Fall 2014/ch1a 25 ks

2014-09-24T23:23:03Z

Knimgao:

=Object Relational Mapping=

__TOC__

==Introduction<ref>http://en.wikipedia.org/wiki/Object-relational_mapping Object Relational Mapping</ref>(ORM, O/RM, and O/R mapping) in computer science is a programming technique for converting data between incompatible type systems in object-oriented programming languages. This creates, in effect, a "virtual object database" that can be used from within the programming language. There are both free and commercial packages available that perform object-relational mapping, although some programmers opt to create their own ORM tools.

==Overview==
Object Relational Mapping is a programming technique in which a metadata descriptor is used to connect object code to a relational database. ORM converts data between type systems that are unable to coexist within relational databases and OOP languages.

In [http://en.wikipedia.org/wiki/Object-oriented_programming object-oriented programming], data management tasks act on object-oriented (OO) objects that are almost always non-scalar values. For example, consider an address book entry that represents a single person along with zero or more phone numbers and zero or more addresses. This could be modeled in an object-oriented implementation by a "Person object" with attributes/fields to hold each data item that the entry comprises: the person's name, a list of phone numbers, and a list of addresses. The list of phone numbers would itself contain "PhoneNumber objects" and so on. The address book entry is treated as a single object by the programming language (it can be referenced by a single variable containing a pointer to the object, for instance). Various methods can be associated with the object, such as a method to return the preferred phone number, the home address, and so on.

The heart of the problem is translating the logical representation of the objects into an atomized form that is capable of being stored in the database, while preserving the properties of the objects and their relationships so that they can be reloaded as objects when needed. If this storage and retrieval functionality is implemented, the objects are said to be persistent.

==Simple Explanation==
A simple answer is that you wrap your tables or stored procedures in classes in your programming language, so that instead of writing SQL statements to interact with your database, you use methods and properties of objects.

In other words, instead of something like this:
<pre>
String sql = "SELECT ... FROM persons WHERE id = 10"
DbCommand cmd = new DbCommand(connection, sql);
Result res = cmd.Execute();
String name = res[0]["FIRST_NAME"];
</pre>
you do something like this:
<pre>
Person p = repository.GetPerson(10);
String name = p.FirstName;
</pre>
or similar code (lots of variations here.) Some frameworks also put a lot of the code in as static methods on the classes themselves, which means you could do something like this instead:
<pre>
Person p = Person.Get(10);
</pre>
Some also implement complex query systems, so you could do this:
<pre>
Person p = Person.Get(Person.Properties.Id == 10);
</pre>
The framework is what makes this code possible.

==Features==
Object-relational Mapping (ORM) frameworks unburden the designer of the complex translation between database and object space.

Typical ORM features:
* Automatic mapping from classes to database tables
** Class instance variables to database columns
** Class instances to table rows
* Aggregation and association relationships between mapped classes are managed
** Example, :has_many, :belongs_to associations in ActiveRecord
** Inheritance cases are mapped to tables
* Validation of data prior to table storage
* Class extensions to enable search, as well as creation, read, update, and deletion (CRUD) of instances/records
* Usually abstracts the database from program space in such a way that alternate database types can be easily chosen (SQLite, Oracle, etc)

The diagram below depicts a simple mapping of an object to a database table….

[[Image:3j_ks_pic1.jpg]]

ORM framework is used to persist model objects to a relational database and retrieve them, and the ORM framework will take care of converting the data between the two otherwise incompatible states. Most ORM tools rely heavily on metadata about both the database and objects, so that the objects need to know nothing about the database and the database doesn’t need to know anything about how the data is structured in the application. ORM provides a clean separation of concerns in a well-designed data application, and the database and application can each work with data in its native form. Database rows map to objects, thus making the program more easily accessible and allowing the usage of information in a way that is internally consistent and easy to understand. The ORM gives the programmer an ability to manipulate data with the programming language, instead of having to manipulate each attribute as its data type as obtained by the database management system.

When applied to Ruby, implementations of ORM often leverage the language’s [http://en.wikipedia.org/wiki/Metaprogramming metaprogramming] strengths to create intuitive application-specific methods and otherwise extend classes to support database functionality. With the addition of Rails, the ORM becomes much more important, as it is necessary to have an ORM to connect the models of the MVC (model-view-controller) stack used by Ruby on Rails with the application's database. Since the models are Ruby objects, the ORM allows modifications to the database to be done through changes to these models, independent of the type of database used.

With the release of Rails 3.0, the platform became ORM independent. With this change, it is much easier to use the ORM most preferred by the programmer, rather than being corralled into using one particular one. To allow this, the ORM needed to be extracted from the model and the database, to be a pure mediator between the two. Then any ORM can be used as long as it can successfully understand the model and the database used.

==Advantages<ref>http://www.techopedia.com/definition/24200/object-relational-mapping--orm</ref>==
In addition to the [http://en.wikipedia.org/wiki/Data_access data access] technique, ORM's benefits also include:
*First of all, you hide the SQL away from your logic code. This has the benefit of allowing you to more easily support more database engines. For instance, MS SQL Server and Oracle has different names on typical functions, and different ways to do calculations with dates, so a query to "get me all persons edited the last 24 hours" might entail different SQL syntax just for those two database engines. This difference can be put away from your logic code.
*Additionally, you can focus on writing the logic, instead of getting all the SQL right. The code will typically be more readable as well, since it doesn't contain all the "plumbing" necessary to talk to the database.
*Simplified development because it automates object-to-table and table-to-object conversion, resulting in lower development and maintenance costs
*Less code compared to embedded SQL and handwritten stored procedures
*Transparent object caching in the application tier, improving system performance
*An optimized solution making an application faster and easier to maintain

==Disadvantages<ref>http://www.techopedia.com/definition/24200/object-relational-mapping--orm</ref>==
*ORM’s emergence in multiple application development has created disagreement among experts. Key concerns are that ORM does not perform well and that stored procedures might be a better solution.
*In addition, ORM dependence may result in poorly-designed databases in certain circumstances.
*Performance – like every "proxy" technology
*Complexity – learning curve
*Difficulty / inability to make complex queries

=ORM Frameworks=

==Active Records==
[http://guides.rubyonrails.org/active_record_basics.html Active Record] was described by Martin Fowler in his book Patterns of Enterprise Application Architecture. Active Record is the M in [http://guides.rubyonrails.org/getting_started.html#the-mvc-architecture MVC]- the model - which is the layer of the system responsible for representing business data and logic. In Active Record, objects carry both persistent data and behavior which operates on that data. A database table or view is wrapped into a class and an object instance is tied to a single row in the table. Each Active Record object has CRUD (Create, Read, Update, and Delete) methods for database access. In addition, Active Record allows you to validate the state of a model before it gets written into the database.

Active Record gives us several mechanisms, the most important being the ability to:
* Represent models and their data.
* Represent associations between these models.
* Represent inheritance hierarchies through related models.
* Validate models before they get persisted to the database.
* Perform database operations in an object-oriented fashion.

The naming conventions used in Active Records are :
* Database Table - Plural with underscores separating words (e.g., book_clubs).
* Model Class - Singular with the first letter of each word capitalized (e.g., BookClub).

To create a table, ActiveRecord makes use of a migration class rather than including table definition in the actual class being modeled. As an example, the following code creates a table ‘’users’’ to store a collection of class ‘’User’’ objects:
<pre>
class CreateUsers < ActiveRecord::Migration
def self.up
create_table :users do |t|
t.string :name
t.string :email
t.string :age
t.references :cheer
t.references :post

t.timestamps # add creation and modification timestamps
end
end

def self.down # undo the table creation
drop_table :users
end
end
</pre>

The ActiveRecord’s migration scheme provides a means for backing out changes via the ‘’self.down’’ method. In addition, a table key ‘’id’’ is added to the new table without an explicit definition and record creation and modification timestamps are included via the ‘’timestamps’’ method provided by ActiveRecord.

ActiveRecord manages associations between table elements and provides the means to define such associations in the model definition. For example, the ‘’User’’ class shown below defines a ‘’has_many’’ (one-to-many) association with both the cheers and posts tables. These associations are represented in the migration class with the references operator. Also note ActiveRecord’s integrated support for validation of table information when attempting an update.

<pre>
class User < ActiveRecord::Base
has_many :cheers
has_many :posts

validates_presence_of :name
validates_presence_of :age
validates_uniqueness_of :name
validates_length_of :name, :within => 3..20
end
</pre>

To access the data in the table one calls the class function related to that column. For example, to find the user who's name is Bob, one would use @user = User.find_by_name('Bob'). Then one could find Bob's e-mail by using @user.email. Users can be searched for by any attribute in this way, as find methods are created for every combination of attributes.
While ActiveRecord provides the flexibility to create more sophisticated table relationships to represent class hierarchy, its base scheme is a single table inheritance, which trades some storage efficiency for simplicity in the database design. The following figure illustrates this concept of simplicity over efficiency.

[[Image:3j_ks_pic2.jpg]]

'''Pros''' -
* Integrated with popular Rails development framework
* Dynamically created database search methods (eg: User.find_by_address) ease db queries and make queries database syntax independent
* DB creation/management using the migrate scheme provides a means for backing out unwanted table changes
'''Cons''' -
* DB creation/management is decoupled from the model, requiring a separate utility (rake/migrate) that must be kept in sync with application.

==ORM Adaptor==
[https://github.com/ianwhite/orm_adapter ORM Adaptors] provide a single point of entry for popular ruby ORMs. Its target audience is gem authors who want to support more than one ORM.
ORM Adapter's goal is to support a minimum API used by most of the plugins that needs agnosticism beyond Active Model.
ORM Adapter will support only basic methods, as get, find_first, create! and so forth. It is not ORM Adapter's goal to support different query constructions, handle table joins, etc.
ORM adapter provides a consistent API for these basic class or 'factory' methods. It does not attempt to unify the behaviour of model instances returned by these methods. This means that unifying the behaviour of methods such as `model.save`, and `model.valid?` is beyond the scope of orm_adapter.
If you need complex queries, it is recommended to subclass ORM Adapters in your plugin and extend it expressing these query conditions as part of your domain logic.
<pre>
Example :
require 'orm_adapter'
User # is it an ActiveRecord, DM Resource, MongoMapper or MongoId Document?
User.to_adapter.find_first :name => 'Fred' # we don't care!
user_model = User.to_adapter
user_model.get!(1) # find a record by id
user_model.find_first(:name => 'fred') # find first fred
user_model.find_first(:level => 'awesome', :id => 23) # find user 23, only if it's level is awesome
user_model.find_all # find all users
user_model.find_all(:name => 'fred') # find all freds
user_model.find_all(:order => :name) # find all freds, ordered by name
user_model.create!(:name => 'fred') # create a fred
user_model.destroy(object) # destroy the user object
</pre>

==Sequel==
[http://sequel.jeremyevans.net/documentation.html Sequel] was originally developed by Sharon Rosner and the first release was in March 2007. It is based on the active record pattern. Sequel and Active Record share a lot of common features , for example association and inheritance. But Sequel handles these features in a much more flexible manner. Currently Sequel is at version 3.44.0. Initially Sequel had three core modules - sequel, sequel_core and sequel_model. Starting from version 1.4 , sequel and sequel_model were merged. Sequel handles validations using a validation plug-in and helpers.

<pre>
class CreateUser < Sequel::Migration
def up
create_table(:user) {
primary_key :id
String :name
String :age
String :email}
end
def down
drop_table(:user)
end
end # CreateUser.apply(DB, :up)
</pre>

Sequel supports associations and validations similar to Active Record. The following example shows how validations and associations can be enforced in the User table that has been created above. It enforces one to many relationships between the user table and the cheers and posts tables. It also validates for the presence , uniqueness and the length of the attribute '''name'''.

<pre>
class User < Sequel::Model
one_to_many :cheers
one_to_many :posts

validates_presence [:name, :age]
validates_unique(:name)
validates_length_range 3..20, :name
end
</pre>

To access the data in Sequel, one can use where clauses. For instance, to find Bob again one would use DB[:items].where(Sequel.like(:name, 'Bob'). While the ability to use SQL-like where clauses is quite flexible, it is not quite as pure an object-oriented approach as Active Record's dynamically created find methods.

Some of the key features of sequel are,
* [http://sequel.jeremyevans.net/rdoc/classes/Sequel/ThreadedConnectionPool.html Connection Pooling]
* Thread Safety
* [http://guides.rubyonrails.org/active_record_querying.html#eager-loading-associations Eager Loading] / Lazy Loading
* Model Caching
* Supports advanced database features such as prepared statements, bound variables, stored procedures, savepoints, two-phase commit, transaction isolation, master/slave configurations, and database sharding.

==Data Mapper==
[http://datamapper.org/ DataMapper] is an Object Relational Mapper written in Ruby developed by Sam Smoot with the goal to create an ORM which is fast, thread-safe and feature rich.
A Data Mapper is a Data Access Layer that performs bidirectional transfer of data between a persistent data store (often a relational database) and an in memory data representation (the domain layer). The goal of the pattern is to keep the in memory representation and the persistent data store independent of each other and the data mapper itself. The layer is composed of one or more mappers (or Data Access Objects), performing the data transfer.
DataMapper comes with the ability to use the same API to talk to a multitude of different datastores. There are adapters for the usual RDBMS suspects, NoSQL stores, various file formats and some web services. With DataMapper, you define your mappings in your model. Your data store can develop independently of your model using Migrations.

Some features of Data Mapper are as follows :
* No need to write structural migrations
* Scoped relations
* Lazy loading on certain attribute types
* Strategic eager loading to avoid (N+1) queries
* Default support for composite and natural keys
* Query chaining, and not evaluating the query until absolutely necessary (using a lazy array implementation)
* An API not too heavily oriented to SQL databases

DataMapper was designed to be a more abstract ORM, not strictly SQL, based on Martin Fowler's enterprise pattern. As a result, DataMapper adapters have been built for other non-SQL databases, such as CouchDB, [http://github.com/lritter/dm-solr-adapter/tree/master Apache Solr], and webservices such as [http://github.com/halorgium/dm-salesforce/tree/master Salesforce].

Example of table definition in the model:
<pre>
class User
include DataMapper::Resource

property :id, Serial # key
property :name, String, :required => true, :unique => true
property :age, String, :required => true, :length => 3..20
property :email, String

has n, :posts # one to many association
has n, :cheers # one to many association
end
</pre>

Notice that in the example above , ":required = true" is an example for Auto Validation. Unlike ActiveRecord and Sequel, DataMapper supports auto validations , i.e. these in turn call the validation helpers to enforce basic validations such as length, uniqueness, format, presence etc.

==MyBatis/iBatis==
[http://en.wikipedia.org/wiki/MyBatis MyBatis/iBatis] was a persistence framework which allowed easy access of the database from a Rails application without being a full ORM. It was created by the Apache Foundation in 2002, and is available for several platforms, including Ruby (the Ruby release is known as RBatis). On 6/16/2010, after releasing iBATIS 3.0, the project team moved from Apache to Google Code, changed the project's name to MyBatis, and stopped supporting Ruby.

The MyBatis data mapper framework makes it easier to use a relational database with object-oriented applications. MyBatis couples objects with stored procedures or SQL statements using a XML descriptor. To use the MyBatis data mapper,we make use of our own objects, XML, and SQL.

SQL statements are stored in XML files or annotations. Following is a MyBatis mapper, that consists of a Java interface with some MyBatis annotations:
<pre>
package org.mybatis.example;

public interface BlogMapper {
@Select("select * from Blog where id = #{id}")
Blog selectBlog(int id);
}
</pre>
The sentence is executed as follows.
<pre>
BlogMapper mapper = session.getMapper(BlogMapper.class);
Blog blog = mapper.selectBlog(101);
</pre>

It can also be executed using MyBatis API.
<pre>
Blog blog = session.selectOne("org.mybatis.example.BlogMapper.selectBlog", 101);
</pre>

SQL statements and mappings can also be externalized to an XML file like this.
<pre>
<?xml version="1.0" encoding="UTF-8" ?>
<!DOCTYPE mapper PUBLIC "-//mybatis.org//DTD Mapper 3.0//EN" "http://mybatis.org/dtd/mybatis-3-mapper.dtd">

<mapper namespace="org.mybatis.example.BlogMapper">
<select id="selectBlog" parameterType="int" resultType="Blog">
select * from Blog where id = #{id}
</select>
</mapper>
</pre>

==Squeel==
[http://rubydoc.info/gems/squeel/1.1.1/frames Squeel]unlocks the power of Arel in Rails applications with a handy block-based syntax. It is supporting in Rails 3 and 4. With Squeel, you can write subqueries, access named functions provided by RDMBS and more without writing SQL strings.
Squeel lets you write your Active Record queries with fewer strings, and more Ruby, by making the Arel awesomeness that lies beneath Active Record more accessible.

Squeel lets you rewrite...

<pre>
Article.where ['created_at >= ?', 2.weeks.ago]
...as...
Article.where{created_at >= 2.weeks.ago}
</pre>

Squeel enhances the normal Active Record query methods by enabling them to accept blocks. Inside a block, the Squeel query DSL can be used. Note the use of curly braces in the above example instead of parentheses. {} denotes a Squeel DSL query.

Stubs and keypaths are the two primary building blocks used in a Squeel DSL query.

Stubs are, for most intents and purposes, just like Symbols in a normal call to Relation#where (note the need for doubling up on the curly braces here, the first ones start the block, the second are the hash braces):
<pre>
Person.where{{name => ‘Ernie’ }}
</pre>

You normally wouldn't bother using the DSL in this case, as a simple hash would suffice. However, stubs serve as a building block for keypaths, and keypaths are very handy.

A Squeel keypath is essentially a more concise and readable alternative to a deeply nested hash. For instance, in standard Active Record, you might join several associations like this to perform a query:
<pre>
Person.joins(:articles => { :comments => :person}).references(:all)
</pre>

With a keypath, this would look like:
<pre>
Person.joins{articles.comments.person}.references(:all)
</pre>

The Squeel DSL works its magic using instance_eval which means that inside a Squeel DSL block, self isn't the same thing that it is outside the block.
This carries with it an important implication: Instance variables and instance methods inside the block won't refer to your object's variables/methods.
Use one of the following methods to get access to the object's methods and variables:
* Assign the variable locally before the DSL block, and access it as you would normally.
* Supply an arity to the DSL block, as in Person.where{|q| q.name == @my_name} Downside: You'll need to prefix stubs, keypaths, and functions with the DSL object.
* Wrap the method or instance variable inside the block with my{}. Person.where{name == my{some_method_to_return_a_name}}

==Merb==
[http://en.wikipedia.org/wiki/Merb Merb], short for "Mongrel+Erb", is a model view controller framework written in Ruby. Merb was merged into Rails web framework on December 23, 2008 as part of the Ruby on Rails 3.0 release.
Merb itself provides only the controller of an MVC model which can be extended to create a full-stack application environment. This effectively means Merb itself is not an ORM but can accommodate other ORMs.
Some features of Merb are as follows :
* Speed - Merb is ORM, JavaScript library and template language agnostic, preferring plugins that add support for features rather than producing a monolithic library with everything in the core.
* Lightweight - Rather than trying to cram every feature into a single code, things are kept bare minimum without sacrificing anything important.
* Powerful and extensible - For any features not covered in Merb’s core, there are plugins.
Some basic Command distinction between Ruby on Rails and Merb :
{| class="comparison" border="1"
! Action
! Ruby on Rails
! Merb
|-
| Create new application 'app1' || rails new app1 || merb-gen app app1
|-
| Start server || rails server || merb
|-
| Start cluster of 3 beginning at port 3000 || N/A || merb -p 3000 -c 3
|-
| Interactive console || rails console || merb -i
|}

=Alternative to ORM=
==NonSQL databases==
Instead of ORM we can also use Object-Oriented Database Management System (OODBMS) or document-oriented database like XML, where in databases are designed to store object oriented values, thus eliminating the need to convert data to and from its SQL form. Document oriented databases also eliminates the need to retrieve objects as data rows. Query languages like XQuery can be used to retrieve data sets.

The only issue is we won't be able to create application independent queries for retrieving data without restrictions to access path. Also OODBMS limits the extent of processing SQL queries.
A Relational database allows concurrent access to data, locking, indexing (fast search), as well as many other features that are not available while using XML files.

Other OODBMS (such as RavenDB) provide replication to SQL databases, as a means of addressing the need for ad-hoc queries, while preserving the increased performance and reduced complexity that may be achieved with an OODBMS for an application that has well-known query patterns.

NonSQL databases don’t provide mechanism to maintain relationship between tables. In real life though, business objects or entities do have relationship among them. ORM solutions may allow you to define these relationships in business objects and handle their storage and retrieval behind the scene

=Comparison of ORM Features=

{|cellspacing="0" border="1"
!style="width:8%"|Features
!style="width:23%"|ActiveRecord
!style="width:23%"|Sequel
!style="width:23%"|DataMapper
!style="width:23%"|MyBatis
|-
! Databases 
| MySQL, PostgreSQL, SQLite, Oracle, SQLServer, and DB2
| ADO, DataObjects, DB2, DBI, Firebird, Informix, JDBC, MySQL, ODBC, OpenBase, Oracle, PostgreSQL and SQLite3
| SQLite, MySQL, PostgreSQL, Oracle, MongoDB, SimpleDB, many others, including CouchDB, Apache Solr, Google Data API
| MySQL, PostgreSQL, SQLite, Oracle, SQLServer, and DB2
|-
! Migrations 
| Yes
| Yes
| Yes, but optional
| Yes, provides migration by Mybatis schema migration system.
|-
! EagerLoading 
| Supported by scanning the SQL fragments
| Supported using eager (preloading) and eager_graph (joins)
| Strategic Eager Loading and by using :summary
| Yes.this can be enabled or disabled by setting the lazyLoadingEnabled flag
|-
! Flexible Overriding 
| No. Overriding is done using alias methods.
| Using methods and by calling 'super'
| Using methods
| No
|-
! Dynamic Finders 
| Yes. Uses 'Method Missing'
| No. Alternative is to use <Model>.FindOrCreate(:name=>"John")
| Yes. Using the dm_ar_finders plugin
| Similar feature is supported in the form of Dynamic SQL
|}

=Further Reading=
To get more information on ORM and the different type of ORM's available for Ruby , please look into the [http://wiki.expertiza.ncsu.edu/index.php/CSC/ECE_517_Spring_2013/ch1_1d_zk CSC/ECE 517 Spring 2013/ch1 1d zk] and [http://wiki.expertiza.ncsu.edu/index.php/CSC/ECE_517_Fall_2010/ch3_3f_ac Fall 2010 detailed ORM explanation] wiki pages.
# [http://www.cs.colorado.edu/~kena/classes/5448/f11/lectures/29-orm.pdf ORM - University of Colorado]
# [http://www.lynda.com/Ruby-Rails-tutorials/Understanding-ActiveRecord-ActiveRelation/139989/159093-4.html Active Record Tutorial]
# [http://digitalcommons.macalester.edu/context/mathcs_honors/article/1006/type/native/viewcontent/ Research papers on object relational mapping]
# [http://www.sitepoint.com/top-ruby-frameworks-rails-and-merb-join-forces/ Merb and Rails]

=Future Work=
More work can be done in the area of comparison between the different ORMs available for Ruby, especially a more detailed feature-by-feature comparison that includes performance differences between the ORMs.

=References =
# [http://en.wikipedia.org/wiki/Object-relational_mapping Object Relational Mapping]
# [http://en.wikipedia.org/wiki/Object-oriented_programming object-oriented programming]
# [http://en.wikipedia.org/wiki/Data_access data access]
# [http://en.wikipedia.org/wiki/Metaprogramming metaprogramming]
# [http://guides.rubyonrails.org/active_record_basics.html Active Record]
# [http://guides.rubyonrails.org/getting_started.html#the-mvc-architecture MVC]
# [http://sequel.jeremyevans.net/documentation.html Sequel]
# [http://datamapper.org/ DataMapper]
# [http://sequel.jeremyevans.net/rdoc/classes/Sequel/ThreadedConnectionPool.html Connection Pooling]
# [http://guides.rubyonrails.org/active_record_querying.html#eager-loading-associations Eager Loading]
# [http://rubydoc.info/gems/squeel/1.1.1/frames Squeel]
# [http://www.techopedia.com/definition/24200/object-relational-mapping--orm ORM]
# [http://en.wikipedia.org/wiki/Merb Merb]
# [http://www.merbivore.com/ Merb Website]
# [http://wiki.expertiza.ncsu.edu/index.php/CSC/ECE_517_Spring_2013/ch1_1d_zk Object Relational Mapping Spring 2013]

=Citations=
<references/>

CSC/ECE 517 Fall 2014/ch1a 25 ks

2014-09-24T23:19:54Z

Knimgao: /* References */

=Object Relational Mapping=

__TOC__

==Introduction==
[http://en.wikipedia.org/wiki/Object-relational_mapping Object Relational Mapping] (ORM, O/RM, and O/R mapping) in computer science is a programming technique for converting data between incompatible type systems in object-oriented programming languages. This creates, in effect, a "virtual object database" that can be used from within the programming language. There are both free and commercial packages available that perform object-relational mapping, although some programmers opt to create their own ORM tools.

==Overview==
Object Relational Mapping is a programming technique in which a metadata descriptor is used to connect object code to a relational database. ORM converts data between type systems that are unable to coexist within relational databases and OOP languages.

In [http://en.wikipedia.org/wiki/Object-oriented_programming object-oriented programming], data management tasks act on object-oriented (OO) objects that are almost always non-scalar values. For example, consider an address book entry that represents a single person along with zero or more phone numbers and zero or more addresses. This could be modeled in an object-oriented implementation by a "Person object" with attributes/fields to hold each data item that the entry comprises: the person's name, a list of phone numbers, and a list of addresses. The list of phone numbers would itself contain "PhoneNumber objects" and so on. The address book entry is treated as a single object by the programming language (it can be referenced by a single variable containing a pointer to the object, for instance). Various methods can be associated with the object, such as a method to return the preferred phone number, the home address, and so on.

The heart of the problem is translating the logical representation of the objects into an atomized form that is capable of being stored in the database, while preserving the properties of the objects and their relationships so that they can be reloaded as objects when needed. If this storage and retrieval functionality is implemented, the objects are said to be persistent.

==Simple Explanation==
A simple answer is that you wrap your tables or stored procedures in classes in your programming language, so that instead of writing SQL statements to interact with your database, you use methods and properties of objects.

In other words, instead of something like this:
<pre>
String sql = "SELECT ... FROM persons WHERE id = 10"
DbCommand cmd = new DbCommand(connection, sql);
Result res = cmd.Execute();
String name = res[0]["FIRST_NAME"];
</pre>
you do something like this:
<pre>
Person p = repository.GetPerson(10);
String name = p.FirstName;
</pre>
or similar code (lots of variations here.) Some frameworks also put a lot of the code in as static methods on the classes themselves, which means you could do something like this instead:
<pre>
Person p = Person.Get(10);
</pre>
Some also implement complex query systems, so you could do this:
<pre>
Person p = Person.Get(Person.Properties.Id == 10);
</pre>
The framework is what makes this code possible.

==Features==
Object-relational Mapping (ORM) frameworks unburden the designer of the complex translation between database and object space.

Typical ORM features:
* Automatic mapping from classes to database tables
** Class instance variables to database columns
** Class instances to table rows
* Aggregation and association relationships between mapped classes are managed
** Example, :has_many, :belongs_to associations in ActiveRecord
** Inheritance cases are mapped to tables
* Validation of data prior to table storage
* Class extensions to enable search, as well as creation, read, update, and deletion (CRUD) of instances/records
* Usually abstracts the database from program space in such a way that alternate database types can be easily chosen (SQLite, Oracle, etc)

The diagram below depicts a simple mapping of an object to a database table….

[[Image:3j_ks_pic1.jpg]]

ORM framework is used to persist model objects to a relational database and retrieve them, and the ORM framework will take care of converting the data between the two otherwise incompatible states. Most ORM tools rely heavily on metadata about both the database and objects, so that the objects need to know nothing about the database and the database doesn’t need to know anything about how the data is structured in the application. ORM provides a clean separation of concerns in a well-designed data application, and the database and application can each work with data in its native form. Database rows map to objects, thus making the program more easily accessible and allowing the usage of information in a way that is internally consistent and easy to understand. The ORM gives the programmer an ability to manipulate data with the programming language, instead of having to manipulate each attribute as its data type as obtained by the database management system.

When applied to Ruby, implementations of ORM often leverage the language’s [http://en.wikipedia.org/wiki/Metaprogramming metaprogramming] strengths to create intuitive application-specific methods and otherwise extend classes to support database functionality. With the addition of Rails, the ORM becomes much more important, as it is necessary to have an ORM to connect the models of the MVC (model-view-controller) stack used by Ruby on Rails with the application's database. Since the models are Ruby objects, the ORM allows modifications to the database to be done through changes to these models, independent of the type of database used.

With the release of Rails 3.0, the platform became ORM independent. With this change, it is much easier to use the ORM most preferred by the programmer, rather than being corralled into using one particular one. To allow this, the ORM needed to be extracted from the model and the database, to be a pure mediator between the two. Then any ORM can be used as long as it can successfully understand the model and the database used.

==Advantages<ref>http://www.techopedia.com/definition/24200/object-relational-mapping--orm</ref>==
In addition to the [http://en.wikipedia.org/wiki/Data_access data access] technique, ORM's benefits also include:
*First of all, you hide the SQL away from your logic code. This has the benefit of allowing you to more easily support more database engines. For instance, MS SQL Server and Oracle has different names on typical functions, and different ways to do calculations with dates, so a query to "get me all persons edited the last 24 hours" might entail different SQL syntax just for those two database engines. This difference can be put away from your logic code.
*Additionally, you can focus on writing the logic, instead of getting all the SQL right. The code will typically be more readable as well, since it doesn't contain all the "plumbing" necessary to talk to the database.
*Simplified development because it automates object-to-table and table-to-object conversion, resulting in lower development and maintenance costs
*Less code compared to embedded SQL and handwritten stored procedures
*Transparent object caching in the application tier, improving system performance
*An optimized solution making an application faster and easier to maintain

==Disadvantages<ref>http://www.techopedia.com/definition/24200/object-relational-mapping--orm</ref>==
*ORM’s emergence in multiple application development has created disagreement among experts. Key concerns are that ORM does not perform well and that stored procedures might be a better solution.
*In addition, ORM dependence may result in poorly-designed databases in certain circumstances.
*Performance – like every "proxy" technology
*Complexity – learning curve
*Difficulty / inability to make complex queries

=ORM Frameworks=

==Active Records==
[http://guides.rubyonrails.org/active_record_basics.html Active Record] was described by Martin Fowler in his book Patterns of Enterprise Application Architecture. Active Record is the M in [http://guides.rubyonrails.org/getting_started.html#the-mvc-architecture MVC]- the model - which is the layer of the system responsible for representing business data and logic. In Active Record, objects carry both persistent data and behavior which operates on that data. A database table or view is wrapped into a class and an object instance is tied to a single row in the table. Each Active Record object has CRUD (Create, Read, Update, and Delete) methods for database access. In addition, Active Record allows you to validate the state of a model before it gets written into the database.

Active Record gives us several mechanisms, the most important being the ability to:
* Represent models and their data.
* Represent associations between these models.
* Represent inheritance hierarchies through related models.
* Validate models before they get persisted to the database.
* Perform database operations in an object-oriented fashion.

The naming conventions used in Active Records are :
* Database Table - Plural with underscores separating words (e.g., book_clubs).
* Model Class - Singular with the first letter of each word capitalized (e.g., BookClub).

To create a table, ActiveRecord makes use of a migration class rather than including table definition in the actual class being modeled. As an example, the following code creates a table ‘’users’’ to store a collection of class ‘’User’’ objects:
<pre>
class CreateUsers < ActiveRecord::Migration
def self.up
create_table :users do |t|
t.string :name
t.string :email
t.string :age
t.references :cheer
t.references :post

t.timestamps # add creation and modification timestamps
end
end

def self.down # undo the table creation
drop_table :users
end
end
</pre>

The ActiveRecord’s migration scheme provides a means for backing out changes via the ‘’self.down’’ method. In addition, a table key ‘’id’’ is added to the new table without an explicit definition and record creation and modification timestamps are included via the ‘’timestamps’’ method provided by ActiveRecord.

ActiveRecord manages associations between table elements and provides the means to define such associations in the model definition. For example, the ‘’User’’ class shown below defines a ‘’has_many’’ (one-to-many) association with both the cheers and posts tables. These associations are represented in the migration class with the references operator. Also note ActiveRecord’s integrated support for validation of table information when attempting an update.

<pre>
class User < ActiveRecord::Base
has_many :cheers
has_many :posts

validates_presence_of :name
validates_presence_of :age
validates_uniqueness_of :name
validates_length_of :name, :within => 3..20
end
</pre>

To access the data in the table one calls the class function related to that column. For example, to find the user who's name is Bob, one would use @user = User.find_by_name('Bob'). Then one could find Bob's e-mail by using @user.email. Users can be searched for by any attribute in this way, as find methods are created for every combination of attributes.
While ActiveRecord provides the flexibility to create more sophisticated table relationships to represent class hierarchy, its base scheme is a single table inheritance, which trades some storage efficiency for simplicity in the database design. The following figure illustrates this concept of simplicity over efficiency.

[[Image:3j_ks_pic2.jpg]]

'''Pros''' -
* Integrated with popular Rails development framework
* Dynamically created database search methods (eg: User.find_by_address) ease db queries and make queries database syntax independent
* DB creation/management using the migrate scheme provides a means for backing out unwanted table changes
'''Cons''' -
* DB creation/management is decoupled from the model, requiring a separate utility (rake/migrate) that must be kept in sync with application.

==ORM Adaptor==
[https://github.com/ianwhite/orm_adapter ORM Adaptors] provide a single point of entry for popular ruby ORMs. Its target audience is gem authors who want to support more than one ORM.
ORM Adapter's goal is to support a minimum API used by most of the plugins that needs agnosticism beyond Active Model.
ORM Adapter will support only basic methods, as get, find_first, create! and so forth. It is not ORM Adapter's goal to support different query constructions, handle table joins, etc.
ORM adapter provides a consistent API for these basic class or 'factory' methods. It does not attempt to unify the behaviour of model instances returned by these methods. This means that unifying the behaviour of methods such as `model.save`, and `model.valid?` is beyond the scope of orm_adapter.
If you need complex queries, it is recommended to subclass ORM Adapters in your plugin and extend it expressing these query conditions as part of your domain logic.
<pre>
Example :
require 'orm_adapter'
User # is it an ActiveRecord, DM Resource, MongoMapper or MongoId Document?
User.to_adapter.find_first :name => 'Fred' # we don't care!
user_model = User.to_adapter
user_model.get!(1) # find a record by id
user_model.find_first(:name => 'fred') # find first fred
user_model.find_first(:level => 'awesome', :id => 23) # find user 23, only if it's level is awesome
user_model.find_all # find all users
user_model.find_all(:name => 'fred') # find all freds
user_model.find_all(:order => :name) # find all freds, ordered by name
user_model.create!(:name => 'fred') # create a fred
user_model.destroy(object) # destroy the user object
</pre>

==Sequel==
[http://sequel.jeremyevans.net/documentation.html Sequel] was originally developed by Sharon Rosner and the first release was in March 2007. It is based on the active record pattern. Sequel and Active Record share a lot of common features , for example association and inheritance. But Sequel handles these features in a much more flexible manner. Currently Sequel is at version 3.44.0. Initially Sequel had three core modules - sequel, sequel_core and sequel_model. Starting from version 1.4 , sequel and sequel_model were merged. Sequel handles validations using a validation plug-in and helpers.

<pre>
class CreateUser < Sequel::Migration
def up
create_table(:user) {
primary_key :id
String :name
String :age
String :email}
end
def down
drop_table(:user)
end
end # CreateUser.apply(DB, :up)
</pre>

Sequel supports associations and validations similar to Active Record. The following example shows how validations and associations can be enforced in the User table that has been created above. It enforces one to many relationships between the user table and the cheers and posts tables. It also validates for the presence , uniqueness and the length of the attribute '''name'''.

<pre>
class User < Sequel::Model
one_to_many :cheers
one_to_many :posts

validates_presence [:name, :age]
validates_unique(:name)
validates_length_range 3..20, :name
end
</pre>

To access the data in Sequel, one can use where clauses. For instance, to find Bob again one would use DB[:items].where(Sequel.like(:name, 'Bob'). While the ability to use SQL-like where clauses is quite flexible, it is not quite as pure an object-oriented approach as Active Record's dynamically created find methods.

Some of the key features of sequel are,
* [http://sequel.jeremyevans.net/rdoc/classes/Sequel/ThreadedConnectionPool.html Connection Pooling]
* Thread Safety
* [http://guides.rubyonrails.org/active_record_querying.html#eager-loading-associations Eager Loading] / Lazy Loading
* Model Caching
* Supports advanced database features such as prepared statements, bound variables, stored procedures, savepoints, two-phase commit, transaction isolation, master/slave configurations, and database sharding.

==Data Mapper==
[http://datamapper.org/ DataMapper] is an Object Relational Mapper written in Ruby developed by Sam Smoot with the goal to create an ORM which is fast, thread-safe and feature rich.
A Data Mapper is a Data Access Layer that performs bidirectional transfer of data between a persistent data store (often a relational database) and an in memory data representation (the domain layer). The goal of the pattern is to keep the in memory representation and the persistent data store independent of each other and the data mapper itself. The layer is composed of one or more mappers (or Data Access Objects), performing the data transfer.
DataMapper comes with the ability to use the same API to talk to a multitude of different datastores. There are adapters for the usual RDBMS suspects, NoSQL stores, various file formats and some web services. With DataMapper, you define your mappings in your model. Your data store can develop independently of your model using Migrations.

Some features of Data Mapper are as follows :
* No need to write structural migrations
* Scoped relations
* Lazy loading on certain attribute types
* Strategic eager loading to avoid (N+1) queries
* Default support for composite and natural keys
* Query chaining, and not evaluating the query until absolutely necessary (using a lazy array implementation)
* An API not too heavily oriented to SQL databases

DataMapper was designed to be a more abstract ORM, not strictly SQL, based on Martin Fowler's enterprise pattern. As a result, DataMapper adapters have been built for other non-SQL databases, such as CouchDB, [http://github.com/lritter/dm-solr-adapter/tree/master Apache Solr], and webservices such as [http://github.com/halorgium/dm-salesforce/tree/master Salesforce].

Example of table definition in the model:
<pre>
class User
include DataMapper::Resource

property :id, Serial # key
property :name, String, :required => true, :unique => true
property :age, String, :required => true, :length => 3..20
property :email, String

has n, :posts # one to many association
has n, :cheers # one to many association
end
</pre>

Notice that in the example above , ":required = true" is an example for Auto Validation. Unlike ActiveRecord and Sequel, DataMapper supports auto validations , i.e. these in turn call the validation helpers to enforce basic validations such as length, uniqueness, format, presence etc.

==MyBatis/iBatis==
[http://en.wikipedia.org/wiki/MyBatis MyBatis/iBatis] was a persistence framework which allowed easy access of the database from a Rails application without being a full ORM. It was created by the Apache Foundation in 2002, and is available for several platforms, including Ruby (the Ruby release is known as RBatis). On 6/16/2010, after releasing iBATIS 3.0, the project team moved from Apache to Google Code, changed the project's name to MyBatis, and stopped supporting Ruby.

The MyBatis data mapper framework makes it easier to use a relational database with object-oriented applications. MyBatis couples objects with stored procedures or SQL statements using a XML descriptor. To use the MyBatis data mapper,we make use of our own objects, XML, and SQL.

SQL statements are stored in XML files or annotations. Following is a MyBatis mapper, that consists of a Java interface with some MyBatis annotations:
<pre>
package org.mybatis.example;

public interface BlogMapper {
@Select("select * from Blog where id = #{id}")
Blog selectBlog(int id);
}
</pre>
The sentence is executed as follows.
<pre>
BlogMapper mapper = session.getMapper(BlogMapper.class);
Blog blog = mapper.selectBlog(101);
</pre>

It can also be executed using MyBatis API.
<pre>
Blog blog = session.selectOne("org.mybatis.example.BlogMapper.selectBlog", 101);
</pre>

SQL statements and mappings can also be externalized to an XML file like this.
<pre>
<?xml version="1.0" encoding="UTF-8" ?>
<!DOCTYPE mapper PUBLIC "-//mybatis.org//DTD Mapper 3.0//EN" "http://mybatis.org/dtd/mybatis-3-mapper.dtd">

<mapper namespace="org.mybatis.example.BlogMapper">
<select id="selectBlog" parameterType="int" resultType="Blog">
select * from Blog where id = #{id}
</select>
</mapper>
</pre>

==Squeel==
[http://rubydoc.info/gems/squeel/1.1.1/frames Squeel]unlocks the power of Arel in Rails applications with a handy block-based syntax. It is supporting in Rails 3 and 4. With Squeel, you can write subqueries, access named functions provided by RDMBS and more without writing SQL strings.
Squeel lets you write your Active Record queries with fewer strings, and more Ruby, by making the Arel awesomeness that lies beneath Active Record more accessible.

Squeel lets you rewrite...

<pre>
Article.where ['created_at >= ?', 2.weeks.ago]
...as...
Article.where{created_at >= 2.weeks.ago}
</pre>

Squeel enhances the normal Active Record query methods by enabling them to accept blocks. Inside a block, the Squeel query DSL can be used. Note the use of curly braces in the above example instead of parentheses. {} denotes a Squeel DSL query.

Stubs and keypaths are the two primary building blocks used in a Squeel DSL query.

Stubs are, for most intents and purposes, just like Symbols in a normal call to Relation#where (note the need for doubling up on the curly braces here, the first ones start the block, the second are the hash braces):
<pre>
Person.where{{name => ‘Ernie’ }}
</pre>

You normally wouldn't bother using the DSL in this case, as a simple hash would suffice. However, stubs serve as a building block for keypaths, and keypaths are very handy.

A Squeel keypath is essentially a more concise and readable alternative to a deeply nested hash. For instance, in standard Active Record, you might join several associations like this to perform a query:
<pre>
Person.joins(:articles => { :comments => :person}).references(:all)
</pre>

With a keypath, this would look like:
<pre>
Person.joins{articles.comments.person}.references(:all)
</pre>

The Squeel DSL works its magic using instance_eval which means that inside a Squeel DSL block, self isn't the same thing that it is outside the block.
This carries with it an important implication: Instance variables and instance methods inside the block won't refer to your object's variables/methods.
Use one of the following methods to get access to the object's methods and variables:
* Assign the variable locally before the DSL block, and access it as you would normally.
* Supply an arity to the DSL block, as in Person.where{|q| q.name == @my_name} Downside: You'll need to prefix stubs, keypaths, and functions with the DSL object.
* Wrap the method or instance variable inside the block with my{}. Person.where{name == my{some_method_to_return_a_name}}

==Merb==
[http://en.wikipedia.org/wiki/Merb Merb], short for "Mongrel+Erb", is a model view controller framework written in Ruby. Merb was merged into Rails web framework on December 23, 2008 as part of the Ruby on Rails 3.0 release.
Merb itself provides only the controller of an MVC model which can be extended to create a full-stack application environment. This effectively means Merb itself is not an ORM but can accommodate other ORMs.
Some features of Merb are as follows :
* Speed - Merb is ORM, JavaScript library and template language agnostic, preferring plugins that add support for features rather than producing a monolithic library with everything in the core.
* Lightweight - Rather than trying to cram every feature into a single code, things are kept bare minimum without sacrificing anything important.
* Powerful and extensible - For any features not covered in Merb’s core, there are plugins.
Some basic Command distinction between Ruby on Rails and Merb :
{| class="comparison" border="1"
! Action
! Ruby on Rails
! Merb
|-
| Create new application 'app1' || rails new app1 || merb-gen app app1
|-
| Start server || rails server || merb
|-
| Start cluster of 3 beginning at port 3000 || N/A || merb -p 3000 -c 3
|-
| Interactive console || rails console || merb -i
|}

=Alternative to ORM=
==NonSQL databases==
Instead of ORM we can also use Object-Oriented Database Management System (OODBMS) or document-oriented database like XML, where in databases are designed to store object oriented values, thus eliminating the need to convert data to and from its SQL form. Document oriented databases also eliminates the need to retrieve objects as data rows. Query languages like XQuery can be used to retrieve data sets.

The only issue is we won't be able to create application independent queries for retrieving data without restrictions to access path. Also OODBMS limits the extent of processing SQL queries.
A Relational database allows concurrent access to data, locking, indexing (fast search), as well as many other features that are not available while using XML files.

Other OODBMS (such as RavenDB) provide replication to SQL databases, as a means of addressing the need for ad-hoc queries, while preserving the increased performance and reduced complexity that may be achieved with an OODBMS for an application that has well-known query patterns.

NonSQL databases don’t provide mechanism to maintain relationship between tables. In real life though, business objects or entities do have relationship among them. ORM solutions may allow you to define these relationships in business objects and handle their storage and retrieval behind the scene

=Comparison of ORM Features=

{|cellspacing="0" border="1"
!style="width:8%"|Features
!style="width:23%"|ActiveRecord
!style="width:23%"|Sequel
!style="width:23%"|DataMapper
!style="width:23%"|MyBatis
|-
! Databases 
| MySQL, PostgreSQL, SQLite, Oracle, SQLServer, and DB2
| ADO, DataObjects, DB2, DBI, Firebird, Informix, JDBC, MySQL, ODBC, OpenBase, Oracle, PostgreSQL and SQLite3
| SQLite, MySQL, PostgreSQL, Oracle, MongoDB, SimpleDB, many others, including CouchDB, Apache Solr, Google Data API
| MySQL, PostgreSQL, SQLite, Oracle, SQLServer, and DB2
|-
! Migrations 
| Yes
| Yes
| Yes, but optional
| Yes, provides migration by Mybatis schema migration system.
|-
! EagerLoading 
| Supported by scanning the SQL fragments
| Supported using eager (preloading) and eager_graph (joins)
| Strategic Eager Loading and by using :summary
| Yes.this can be enabled or disabled by setting the lazyLoadingEnabled flag
|-
! Flexible Overriding 
| No. Overriding is done using alias methods.
| Using methods and by calling 'super'
| Using methods
| No
|-
! Dynamic Finders 
| Yes. Uses 'Method Missing'
| No. Alternative is to use <Model>.FindOrCreate(:name=>"John")
| Yes. Using the dm_ar_finders plugin
| Similar feature is supported in the form of Dynamic SQL
|}

=Further Reading=
To get more information on ORM and the different type of ORM's available for Ruby , please look into the [http://wiki.expertiza.ncsu.edu/index.php/CSC/ECE_517_Spring_2013/ch1_1d_zk CSC/ECE 517 Spring 2013/ch1 1d zk] and [http://wiki.expertiza.ncsu.edu/index.php/CSC/ECE_517_Fall_2010/ch3_3f_ac Fall 2010 detailed ORM explanation] wiki pages.
# [http://www.cs.colorado.edu/~kena/classes/5448/f11/lectures/29-orm.pdf ORM - University of Colorado]
# [http://www.lynda.com/Ruby-Rails-tutorials/Understanding-ActiveRecord-ActiveRelation/139989/159093-4.html Active Record Tutorial]
# [http://digitalcommons.macalester.edu/context/mathcs_honors/article/1006/type/native/viewcontent/ Research papers on object relational mapping]
# [http://www.sitepoint.com/top-ruby-frameworks-rails-and-merb-join-forces/ Merb and Rails]

=Future Work=
More work can be done in the area of comparison between the different ORMs available for Ruby, especially a more detailed feature-by-feature comparison that includes performance differences between the ORMs.

=References =
# [http://en.wikipedia.org/wiki/Object-relational_mapping Object Relational Mapping]
# [http://en.wikipedia.org/wiki/Object-oriented_programming object-oriented programming]
# [http://en.wikipedia.org/wiki/Data_access data access]
# [http://en.wikipedia.org/wiki/Metaprogramming metaprogramming]
# [http://guides.rubyonrails.org/active_record_basics.html Active Record]
# [http://guides.rubyonrails.org/getting_started.html#the-mvc-architecture MVC]
# [http://sequel.jeremyevans.net/documentation.html Sequel]
# [http://datamapper.org/ DataMapper]
# [http://sequel.jeremyevans.net/rdoc/classes/Sequel/ThreadedConnectionPool.html Connection Pooling]
# [http://guides.rubyonrails.org/active_record_querying.html#eager-loading-associations Eager Loading]
# [http://rubydoc.info/gems/squeel/1.1.1/frames Squeel]
# [http://www.techopedia.com/definition/24200/object-relational-mapping--orm ORM]
# [http://en.wikipedia.org/wiki/Merb Merb]
# [http://www.merbivore.com/ Merb Website]
# [http://wiki.expertiza.ncsu.edu/index.php/CSC/ECE_517_Spring_2013/ch1_1d_zk Object Relational Mapping Spring 2013]
<references/>

CSC/ECE 517 Fall 2014/ch1a 25 ks

2014-09-24T23:17:58Z

Knimgao: /* Disadvantageshttp://www.techopedia.com/definition/24200/object-relational-mapping--orm */

CSC/ECE 517 Fall 2014/ch1a 25 ks

2014-09-24T23:17:41Z

Knimgao: /* Disadvantages */

=Object Relational Mapping=

__TOC__

==Introduction==
[http://en.wikipedia.org/wiki/Object-relational_mapping Object Relational Mapping] (ORM, O/RM, and O/R mapping) in computer science is a programming technique for converting data between incompatible type systems in object-oriented programming languages. This creates, in effect, a "virtual object database" that can be used from within the programming language. There are both free and commercial packages available that perform object-relational mapping, although some programmers opt to create their own ORM tools.

==Overview==
Object Relational Mapping is a programming technique in which a metadata descriptor is used to connect object code to a relational database. ORM converts data between type systems that are unable to coexist within relational databases and OOP languages.

In [http://en.wikipedia.org/wiki/Object-oriented_programming object-oriented programming], data management tasks act on object-oriented (OO) objects that are almost always non-scalar values. For example, consider an address book entry that represents a single person along with zero or more phone numbers and zero or more addresses. This could be modeled in an object-oriented implementation by a "Person object" with attributes/fields to hold each data item that the entry comprises: the person's name, a list of phone numbers, and a list of addresses. The list of phone numbers would itself contain "PhoneNumber objects" and so on. The address book entry is treated as a single object by the programming language (it can be referenced by a single variable containing a pointer to the object, for instance). Various methods can be associated with the object, such as a method to return the preferred phone number, the home address, and so on.

The heart of the problem is translating the logical representation of the objects into an atomized form that is capable of being stored in the database, while preserving the properties of the objects and their relationships so that they can be reloaded as objects when needed. If this storage and retrieval functionality is implemented, the objects are said to be persistent.

==Simple Explanation==
A simple answer is that you wrap your tables or stored procedures in classes in your programming language, so that instead of writing SQL statements to interact with your database, you use methods and properties of objects.

In other words, instead of something like this:
<pre>
String sql = "SELECT ... FROM persons WHERE id = 10"
DbCommand cmd = new DbCommand(connection, sql);
Result res = cmd.Execute();
String name = res[0]["FIRST_NAME"];
</pre>
you do something like this:
<pre>
Person p = repository.GetPerson(10);
String name = p.FirstName;
</pre>
or similar code (lots of variations here.) Some frameworks also put a lot of the code in as static methods on the classes themselves, which means you could do something like this instead:
<pre>
Person p = Person.Get(10);
</pre>
Some also implement complex query systems, so you could do this:
<pre>
Person p = Person.Get(Person.Properties.Id == 10);
</pre>
The framework is what makes this code possible.

==Features==
Object-relational Mapping (ORM) frameworks unburden the designer of the complex translation between database and object space.

Typical ORM features:
* Automatic mapping from classes to database tables
** Class instance variables to database columns
** Class instances to table rows
* Aggregation and association relationships between mapped classes are managed
** Example, :has_many, :belongs_to associations in ActiveRecord
** Inheritance cases are mapped to tables
* Validation of data prior to table storage
* Class extensions to enable search, as well as creation, read, update, and deletion (CRUD) of instances/records
* Usually abstracts the database from program space in such a way that alternate database types can be easily chosen (SQLite, Oracle, etc)

The diagram below depicts a simple mapping of an object to a database table….

[[Image:3j_ks_pic1.jpg]]

ORM framework is used to persist model objects to a relational database and retrieve them, and the ORM framework will take care of converting the data between the two otherwise incompatible states. Most ORM tools rely heavily on metadata about both the database and objects, so that the objects need to know nothing about the database and the database doesn’t need to know anything about how the data is structured in the application. ORM provides a clean separation of concerns in a well-designed data application, and the database and application can each work with data in its native form. Database rows map to objects, thus making the program more easily accessible and allowing the usage of information in a way that is internally consistent and easy to understand. The ORM gives the programmer an ability to manipulate data with the programming language, instead of having to manipulate each attribute as its data type as obtained by the database management system.

When applied to Ruby, implementations of ORM often leverage the language’s [http://en.wikipedia.org/wiki/Metaprogramming metaprogramming] strengths to create intuitive application-specific methods and otherwise extend classes to support database functionality. With the addition of Rails, the ORM becomes much more important, as it is necessary to have an ORM to connect the models of the MVC (model-view-controller) stack used by Ruby on Rails with the application's database. Since the models are Ruby objects, the ORM allows modifications to the database to be done through changes to these models, independent of the type of database used.

With the release of Rails 3.0, the platform became ORM independent. With this change, it is much easier to use the ORM most preferred by the programmer, rather than being corralled into using one particular one. To allow this, the ORM needed to be extracted from the model and the database, to be a pure mediator between the two. Then any ORM can be used as long as it can successfully understand the model and the database used.

==Advantages<ref>http://www.techopedia.com/definition/24200/object-relational-mapping--orm</ref>==
In addition to the [http://en.wikipedia.org/wiki/Data_access data access] technique, ORM's benefits also include:
*First of all, you hide the SQL away from your logic code. This has the benefit of allowing you to more easily support more database engines. For instance, MS SQL Server and Oracle has different names on typical functions, and different ways to do calculations with dates, so a query to "get me all persons edited the last 24 hours" might entail different SQL syntax just for those two database engines. This difference can be put away from your logic code.
*Additionally, you can focus on writing the logic, instead of getting all the SQL right. The code will typically be more readable as well, since it doesn't contain all the "plumbing" necessary to talk to the database.
*Simplified development because it automates object-to-table and table-to-object conversion, resulting in lower development and maintenance costs
*Less code compared to embedded SQL and handwritten stored procedures
*Transparent object caching in the application tier, improving system performance
*An optimized solution making an application faster and easier to maintain

==Disadvantages<ref><ref>http://www.techopedia.com/definition/24200/object-relational-mapping--orm</ref>==
*ORM’s emergence in multiple application development has created disagreement among experts. Key concerns are that ORM does not perform well and that stored procedures might be a better solution.
*In addition, ORM dependence may result in poorly-designed databases in certain circumstances.
*Performance – like every "proxy" technology
*Complexity – learning curve
*Difficulty / inability to make complex queries

=ORM Frameworks=

==Active Records==
[http://guides.rubyonrails.org/active_record_basics.html Active Record] was described by Martin Fowler in his book Patterns of Enterprise Application Architecture. Active Record is the M in [http://guides.rubyonrails.org/getting_started.html#the-mvc-architecture MVC]- the model - which is the layer of the system responsible for representing business data and logic. In Active Record, objects carry both persistent data and behavior which operates on that data. A database table or view is wrapped into a class and an object instance is tied to a single row in the table. Each Active Record object has CRUD (Create, Read, Update, and Delete) methods for database access. In addition, Active Record allows you to validate the state of a model before it gets written into the database.

Active Record gives us several mechanisms, the most important being the ability to:
* Represent models and their data.
* Represent associations between these models.
* Represent inheritance hierarchies through related models.
* Validate models before they get persisted to the database.
* Perform database operations in an object-oriented fashion.

The naming conventions used in Active Records are :
* Database Table - Plural with underscores separating words (e.g., book_clubs).
* Model Class - Singular with the first letter of each word capitalized (e.g., BookClub).

To create a table, ActiveRecord makes use of a migration class rather than including table definition in the actual class being modeled. As an example, the following code creates a table ‘’users’’ to store a collection of class ‘’User’’ objects:
<pre>
class CreateUsers < ActiveRecord::Migration
def self.up
create_table :users do |t|
t.string :name
t.string :email
t.string :age
t.references :cheer
t.references :post

t.timestamps # add creation and modification timestamps
end
end

def self.down # undo the table creation
drop_table :users
end
end
</pre>

The ActiveRecord’s migration scheme provides a means for backing out changes via the ‘’self.down’’ method. In addition, a table key ‘’id’’ is added to the new table without an explicit definition and record creation and modification timestamps are included via the ‘’timestamps’’ method provided by ActiveRecord.

ActiveRecord manages associations between table elements and provides the means to define such associations in the model definition. For example, the ‘’User’’ class shown below defines a ‘’has_many’’ (one-to-many) association with both the cheers and posts tables. These associations are represented in the migration class with the references operator. Also note ActiveRecord’s integrated support for validation of table information when attempting an update.

<pre>
class User < ActiveRecord::Base
has_many :cheers
has_many :posts

validates_presence_of :name
validates_presence_of :age
validates_uniqueness_of :name
validates_length_of :name, :within => 3..20
end
</pre>

To access the data in the table one calls the class function related to that column. For example, to find the user who's name is Bob, one would use @user = User.find_by_name('Bob'). Then one could find Bob's e-mail by using @user.email. Users can be searched for by any attribute in this way, as find methods are created for every combination of attributes.
While ActiveRecord provides the flexibility to create more sophisticated table relationships to represent class hierarchy, its base scheme is a single table inheritance, which trades some storage efficiency for simplicity in the database design. The following figure illustrates this concept of simplicity over efficiency.

[[Image:3j_ks_pic2.jpg]]

'''Pros''' -
* Integrated with popular Rails development framework
* Dynamically created database search methods (eg: User.find_by_address) ease db queries and make queries database syntax independent
* DB creation/management using the migrate scheme provides a means for backing out unwanted table changes
'''Cons''' -
* DB creation/management is decoupled from the model, requiring a separate utility (rake/migrate) that must be kept in sync with application.

==ORM Adaptor==
[https://github.com/ianwhite/orm_adapter ORM Adaptors] provide a single point of entry for popular ruby ORMs. Its target audience is gem authors who want to support more than one ORM.
ORM Adapter's goal is to support a minimum API used by most of the plugins that needs agnosticism beyond Active Model.
ORM Adapter will support only basic methods, as get, find_first, create! and so forth. It is not ORM Adapter's goal to support different query constructions, handle table joins, etc.
ORM adapter provides a consistent API for these basic class or 'factory' methods. It does not attempt to unify the behaviour of model instances returned by these methods. This means that unifying the behaviour of methods such as `model.save`, and `model.valid?` is beyond the scope of orm_adapter.
If you need complex queries, it is recommended to subclass ORM Adapters in your plugin and extend it expressing these query conditions as part of your domain logic.
<pre>
Example :
require 'orm_adapter'
User # is it an ActiveRecord, DM Resource, MongoMapper or MongoId Document?
User.to_adapter.find_first :name => 'Fred' # we don't care!
user_model = User.to_adapter
user_model.get!(1) # find a record by id
user_model.find_first(:name => 'fred') # find first fred
user_model.find_first(:level => 'awesome', :id => 23) # find user 23, only if it's level is awesome
user_model.find_all # find all users
user_model.find_all(:name => 'fred') # find all freds
user_model.find_all(:order => :name) # find all freds, ordered by name
user_model.create!(:name => 'fred') # create a fred
user_model.destroy(object) # destroy the user object
</pre>

==Sequel==
[http://sequel.jeremyevans.net/documentation.html Sequel] was originally developed by Sharon Rosner and the first release was in March 2007. It is based on the active record pattern. Sequel and Active Record share a lot of common features , for example association and inheritance. But Sequel handles these features in a much more flexible manner. Currently Sequel is at version 3.44.0. Initially Sequel had three core modules - sequel, sequel_core and sequel_model. Starting from version 1.4 , sequel and sequel_model were merged. Sequel handles validations using a validation plug-in and helpers.

<pre>
class CreateUser < Sequel::Migration
def up
create_table(:user) {
primary_key :id
String :name
String :age
String :email}
end
def down
drop_table(:user)
end
end # CreateUser.apply(DB, :up)
</pre>

Sequel supports associations and validations similar to Active Record. The following example shows how validations and associations can be enforced in the User table that has been created above. It enforces one to many relationships between the user table and the cheers and posts tables. It also validates for the presence , uniqueness and the length of the attribute '''name'''.

<pre>
class User < Sequel::Model
one_to_many :cheers
one_to_many :posts

validates_presence [:name, :age]
validates_unique(:name)
validates_length_range 3..20, :name
end
</pre>

To access the data in Sequel, one can use where clauses. For instance, to find Bob again one would use DB[:items].where(Sequel.like(:name, 'Bob'). While the ability to use SQL-like where clauses is quite flexible, it is not quite as pure an object-oriented approach as Active Record's dynamically created find methods.

Some of the key features of sequel are,
* [http://sequel.jeremyevans.net/rdoc/classes/Sequel/ThreadedConnectionPool.html Connection Pooling]
* Thread Safety
* [http://guides.rubyonrails.org/active_record_querying.html#eager-loading-associations Eager Loading] / Lazy Loading
* Model Caching
* Supports advanced database features such as prepared statements, bound variables, stored procedures, savepoints, two-phase commit, transaction isolation, master/slave configurations, and database sharding.

==Data Mapper==
[http://datamapper.org/ DataMapper] is an Object Relational Mapper written in Ruby developed by Sam Smoot with the goal to create an ORM which is fast, thread-safe and feature rich.
A Data Mapper is a Data Access Layer that performs bidirectional transfer of data between a persistent data store (often a relational database) and an in memory data representation (the domain layer). The goal of the pattern is to keep the in memory representation and the persistent data store independent of each other and the data mapper itself. The layer is composed of one or more mappers (or Data Access Objects), performing the data transfer.
DataMapper comes with the ability to use the same API to talk to a multitude of different datastores. There are adapters for the usual RDBMS suspects, NoSQL stores, various file formats and some web services. With DataMapper, you define your mappings in your model. Your data store can develop independently of your model using Migrations.

Some features of Data Mapper are as follows :
* No need to write structural migrations
* Scoped relations
* Lazy loading on certain attribute types
* Strategic eager loading to avoid (N+1) queries
* Default support for composite and natural keys
* Query chaining, and not evaluating the query until absolutely necessary (using a lazy array implementation)
* An API not too heavily oriented to SQL databases

DataMapper was designed to be a more abstract ORM, not strictly SQL, based on Martin Fowler's enterprise pattern. As a result, DataMapper adapters have been built for other non-SQL databases, such as CouchDB, [http://github.com/lritter/dm-solr-adapter/tree/master Apache Solr], and webservices such as [http://github.com/halorgium/dm-salesforce/tree/master Salesforce].

Example of table definition in the model:
<pre>
class User
include DataMapper::Resource

property :id, Serial # key
property :name, String, :required => true, :unique => true
property :age, String, :required => true, :length => 3..20
property :email, String

has n, :posts # one to many association
has n, :cheers # one to many association
end
</pre>

Notice that in the example above , ":required = true" is an example for Auto Validation. Unlike ActiveRecord and Sequel, DataMapper supports auto validations , i.e. these in turn call the validation helpers to enforce basic validations such as length, uniqueness, format, presence etc.

==MyBatis/iBatis==
[http://en.wikipedia.org/wiki/MyBatis MyBatis/iBatis] was a persistence framework which allowed easy access of the database from a Rails application without being a full ORM. It was created by the Apache Foundation in 2002, and is available for several platforms, including Ruby (the Ruby release is known as RBatis). On 6/16/2010, after releasing iBATIS 3.0, the project team moved from Apache to Google Code, changed the project's name to MyBatis, and stopped supporting Ruby.

The MyBatis data mapper framework makes it easier to use a relational database with object-oriented applications. MyBatis couples objects with stored procedures or SQL statements using a XML descriptor. To use the MyBatis data mapper,we make use of our own objects, XML, and SQL.

SQL statements are stored in XML files or annotations. Following is a MyBatis mapper, that consists of a Java interface with some MyBatis annotations:
<pre>
package org.mybatis.example;

public interface BlogMapper {
@Select("select * from Blog where id = #{id}")
Blog selectBlog(int id);
}
</pre>
The sentence is executed as follows.
<pre>
BlogMapper mapper = session.getMapper(BlogMapper.class);
Blog blog = mapper.selectBlog(101);
</pre>

It can also be executed using MyBatis API.
<pre>
Blog blog = session.selectOne("org.mybatis.example.BlogMapper.selectBlog", 101);
</pre>

SQL statements and mappings can also be externalized to an XML file like this.
<pre>
<?xml version="1.0" encoding="UTF-8" ?>
<!DOCTYPE mapper PUBLIC "-//mybatis.org//DTD Mapper 3.0//EN" "http://mybatis.org/dtd/mybatis-3-mapper.dtd">

<mapper namespace="org.mybatis.example.BlogMapper">
<select id="selectBlog" parameterType="int" resultType="Blog">
select * from Blog where id = #{id}
</select>
</mapper>
</pre>

==Squeel==
[http://rubydoc.info/gems/squeel/1.1.1/frames Squeel]unlocks the power of Arel in Rails applications with a handy block-based syntax. It is supporting in Rails 3 and 4. With Squeel, you can write subqueries, access named functions provided by RDMBS and more without writing SQL strings.
Squeel lets you write your Active Record queries with fewer strings, and more Ruby, by making the Arel awesomeness that lies beneath Active Record more accessible.

Squeel lets you rewrite...

<pre>
Article.where ['created_at >= ?', 2.weeks.ago]
...as...
Article.where{created_at >= 2.weeks.ago}
</pre>

Squeel enhances the normal Active Record query methods by enabling them to accept blocks. Inside a block, the Squeel query DSL can be used. Note the use of curly braces in the above example instead of parentheses. {} denotes a Squeel DSL query.

Stubs and keypaths are the two primary building blocks used in a Squeel DSL query.

Stubs are, for most intents and purposes, just like Symbols in a normal call to Relation#where (note the need for doubling up on the curly braces here, the first ones start the block, the second are the hash braces):
<pre>
Person.where{{name => ‘Ernie’ }}
</pre>

You normally wouldn't bother using the DSL in this case, as a simple hash would suffice. However, stubs serve as a building block for keypaths, and keypaths are very handy.

A Squeel keypath is essentially a more concise and readable alternative to a deeply nested hash. For instance, in standard Active Record, you might join several associations like this to perform a query:
<pre>
Person.joins(:articles => { :comments => :person}).references(:all)
</pre>

With a keypath, this would look like:
<pre>
Person.joins{articles.comments.person}.references(:all)
</pre>

The Squeel DSL works its magic using instance_eval which means that inside a Squeel DSL block, self isn't the same thing that it is outside the block.
This carries with it an important implication: Instance variables and instance methods inside the block won't refer to your object's variables/methods.
Use one of the following methods to get access to the object's methods and variables:
* Assign the variable locally before the DSL block, and access it as you would normally.
* Supply an arity to the DSL block, as in Person.where{|q| q.name == @my_name} Downside: You'll need to prefix stubs, keypaths, and functions with the DSL object.
* Wrap the method or instance variable inside the block with my{}. Person.where{name == my{some_method_to_return_a_name}}

==Merb==
[http://en.wikipedia.org/wiki/Merb Merb], short for "Mongrel+Erb", is a model view controller framework written in Ruby. Merb was merged into Rails web framework on December 23, 2008 as part of the Ruby on Rails 3.0 release.
Merb itself provides only the controller of an MVC model which can be extended to create a full-stack application environment. This effectively means Merb itself is not an ORM but can accommodate other ORMs.
Some features of Merb are as follows :
* Speed - Merb is ORM, JavaScript library and template language agnostic, preferring plugins that add support for features rather than producing a monolithic library with everything in the core.
* Lightweight - Rather than trying to cram every feature into a single code, things are kept bare minimum without sacrificing anything important.
* Powerful and extensible - For any features not covered in Merb’s core, there are plugins.
Some basic Command distinction between Ruby on Rails and Merb :
{| class="comparison" border="1"
! Action
! Ruby on Rails
! Merb
|-
| Create new application 'app1' || rails new app1 || merb-gen app app1
|-
| Start server || rails server || merb
|-
| Start cluster of 3 beginning at port 3000 || N/A || merb -p 3000 -c 3
|-
| Interactive console || rails console || merb -i
|}

=Alternative to ORM=
==NonSQL databases==
Instead of ORM we can also use Object-Oriented Database Management System (OODBMS) or document-oriented database like XML, where in databases are designed to store object oriented values, thus eliminating the need to convert data to and from its SQL form. Document oriented databases also eliminates the need to retrieve objects as data rows. Query languages like XQuery can be used to retrieve data sets.

The only issue is we won't be able to create application independent queries for retrieving data without restrictions to access path. Also OODBMS limits the extent of processing SQL queries.
A Relational database allows concurrent access to data, locking, indexing (fast search), as well as many other features that are not available while using XML files.

Other OODBMS (such as RavenDB) provide replication to SQL databases, as a means of addressing the need for ad-hoc queries, while preserving the increased performance and reduced complexity that may be achieved with an OODBMS for an application that has well-known query patterns.

NonSQL databases don’t provide mechanism to maintain relationship between tables. In real life though, business objects or entities do have relationship among them. ORM solutions may allow you to define these relationships in business objects and handle their storage and retrieval behind the scene

=Comparison of ORM Features=

{|cellspacing="0" border="1"
!style="width:8%"|Features
!style="width:23%"|ActiveRecord
!style="width:23%"|Sequel
!style="width:23%"|DataMapper
!style="width:23%"|MyBatis
|-
! Databases 
| MySQL, PostgreSQL, SQLite, Oracle, SQLServer, and DB2
| ADO, DataObjects, DB2, DBI, Firebird, Informix, JDBC, MySQL, ODBC, OpenBase, Oracle, PostgreSQL and SQLite3
| SQLite, MySQL, PostgreSQL, Oracle, MongoDB, SimpleDB, many others, including CouchDB, Apache Solr, Google Data API
| MySQL, PostgreSQL, SQLite, Oracle, SQLServer, and DB2
|-
! Migrations 
| Yes
| Yes
| Yes, but optional
| Yes, provides migration by Mybatis schema migration system.
|-
! EagerLoading 
| Supported by scanning the SQL fragments
| Supported using eager (preloading) and eager_graph (joins)
| Strategic Eager Loading and by using :summary
| Yes.this can be enabled or disabled by setting the lazyLoadingEnabled flag
|-
! Flexible Overriding 
| No. Overriding is done using alias methods.
| Using methods and by calling 'super'
| Using methods
| No
|-
! Dynamic Finders 
| Yes. Uses 'Method Missing'
| No. Alternative is to use <Model>.FindOrCreate(:name=>"John")
| Yes. Using the dm_ar_finders plugin
| Similar feature is supported in the form of Dynamic SQL
|}

=Further Reading=
To get more information on ORM and the different type of ORM's available for Ruby , please look into the [http://wiki.expertiza.ncsu.edu/index.php/CSC/ECE_517_Spring_2013/ch1_1d_zk CSC/ECE 517 Spring 2013/ch1 1d zk] and [http://wiki.expertiza.ncsu.edu/index.php/CSC/ECE_517_Fall_2010/ch3_3f_ac Fall 2010 detailed ORM explanation] wiki pages.
# [http://www.cs.colorado.edu/~kena/classes/5448/f11/lectures/29-orm.pdf ORM - University of Colorado]
# [http://www.lynda.com/Ruby-Rails-tutorials/Understanding-ActiveRecord-ActiveRelation/139989/159093-4.html Active Record Tutorial]
# [http://digitalcommons.macalester.edu/context/mathcs_honors/article/1006/type/native/viewcontent/ Research papers on object relational mapping]
# [http://www.sitepoint.com/top-ruby-frameworks-rails-and-merb-join-forces/ Merb and Rails]

=Future Work=
More work can be done in the area of comparison between the different ORMs available for Ruby, especially a more detailed feature-by-feature comparison that includes performance differences between the ORMs.

=References =
# [http://en.wikipedia.org/wiki/Object-relational_mapping Object Relational Mapping]
# [http://en.wikipedia.org/wiki/Object-oriented_programming object-oriented programming]
# [http://en.wikipedia.org/wiki/Data_access data access]
# [http://en.wikipedia.org/wiki/Metaprogramming metaprogramming]
# [http://guides.rubyonrails.org/active_record_basics.html Active Record]
# [http://guides.rubyonrails.org/getting_started.html#the-mvc-architecture MVC]
# [http://sequel.jeremyevans.net/documentation.html Sequel]
# [http://datamapper.org/ DataMapper]
# [http://sequel.jeremyevans.net/rdoc/classes/Sequel/ThreadedConnectionPool.html Connection Pooling]
# [http://guides.rubyonrails.org/active_record_querying.html#eager-loading-associations Eager Loading]
# [http://rubydoc.info/gems/squeel/1.1.1/frames Squeel]
# [http://www.techopedia.com/definition/24200/object-relational-mapping--orm ORM]
# [http://en.wikipedia.org/wiki/Merb Merb]
# [http://www.merbivore.com/ Merb Website]
# [http://wiki.expertiza.ncsu.edu/index.php/CSC/ECE_517_Spring_2013/ch1_1d_zk Object Relational Mapping Spring 2013]

CSC/ECE 517 Fall 2014/ch1a 25 ks

2014-09-24T23:17:17Z

Knimgao: /* Features */

=Object Relational Mapping=

__TOC__

==Introduction==
[http://en.wikipedia.org/wiki/Object-relational_mapping Object Relational Mapping] (ORM, O/RM, and O/R mapping) in computer science is a programming technique for converting data between incompatible type systems in object-oriented programming languages. This creates, in effect, a "virtual object database" that can be used from within the programming language. There are both free and commercial packages available that perform object-relational mapping, although some programmers opt to create their own ORM tools.

==Overview==
Object Relational Mapping is a programming technique in which a metadata descriptor is used to connect object code to a relational database. ORM converts data between type systems that are unable to coexist within relational databases and OOP languages.

In [http://en.wikipedia.org/wiki/Object-oriented_programming object-oriented programming], data management tasks act on object-oriented (OO) objects that are almost always non-scalar values. For example, consider an address book entry that represents a single person along with zero or more phone numbers and zero or more addresses. This could be modeled in an object-oriented implementation by a "Person object" with attributes/fields to hold each data item that the entry comprises: the person's name, a list of phone numbers, and a list of addresses. The list of phone numbers would itself contain "PhoneNumber objects" and so on. The address book entry is treated as a single object by the programming language (it can be referenced by a single variable containing a pointer to the object, for instance). Various methods can be associated with the object, such as a method to return the preferred phone number, the home address, and so on.

The heart of the problem is translating the logical representation of the objects into an atomized form that is capable of being stored in the database, while preserving the properties of the objects and their relationships so that they can be reloaded as objects when needed. If this storage and retrieval functionality is implemented, the objects are said to be persistent.

==Simple Explanation==
A simple answer is that you wrap your tables or stored procedures in classes in your programming language, so that instead of writing SQL statements to interact with your database, you use methods and properties of objects.

In other words, instead of something like this:
<pre>
String sql = "SELECT ... FROM persons WHERE id = 10"
DbCommand cmd = new DbCommand(connection, sql);
Result res = cmd.Execute();
String name = res[0]["FIRST_NAME"];
</pre>
you do something like this:
<pre>
Person p = repository.GetPerson(10);
String name = p.FirstName;
</pre>
or similar code (lots of variations here.) Some frameworks also put a lot of the code in as static methods on the classes themselves, which means you could do something like this instead:
<pre>
Person p = Person.Get(10);
</pre>
Some also implement complex query systems, so you could do this:
<pre>
Person p = Person.Get(Person.Properties.Id == 10);
</pre>
The framework is what makes this code possible.

==Features==
Object-relational Mapping (ORM) frameworks unburden the designer of the complex translation between database and object space.

Typical ORM features:
* Automatic mapping from classes to database tables
** Class instance variables to database columns
** Class instances to table rows
* Aggregation and association relationships between mapped classes are managed
** Example, :has_many, :belongs_to associations in ActiveRecord
** Inheritance cases are mapped to tables
* Validation of data prior to table storage
* Class extensions to enable search, as well as creation, read, update, and deletion (CRUD) of instances/records
* Usually abstracts the database from program space in such a way that alternate database types can be easily chosen (SQLite, Oracle, etc)

The diagram below depicts a simple mapping of an object to a database table….

[[Image:3j_ks_pic1.jpg]]

ORM framework is used to persist model objects to a relational database and retrieve them, and the ORM framework will take care of converting the data between the two otherwise incompatible states. Most ORM tools rely heavily on metadata about both the database and objects, so that the objects need to know nothing about the database and the database doesn’t need to know anything about how the data is structured in the application. ORM provides a clean separation of concerns in a well-designed data application, and the database and application can each work with data in its native form. Database rows map to objects, thus making the program more easily accessible and allowing the usage of information in a way that is internally consistent and easy to understand. The ORM gives the programmer an ability to manipulate data with the programming language, instead of having to manipulate each attribute as its data type as obtained by the database management system.

When applied to Ruby, implementations of ORM often leverage the language’s [http://en.wikipedia.org/wiki/Metaprogramming metaprogramming] strengths to create intuitive application-specific methods and otherwise extend classes to support database functionality. With the addition of Rails, the ORM becomes much more important, as it is necessary to have an ORM to connect the models of the MVC (model-view-controller) stack used by Ruby on Rails with the application's database. Since the models are Ruby objects, the ORM allows modifications to the database to be done through changes to these models, independent of the type of database used.

With the release of Rails 3.0, the platform became ORM independent. With this change, it is much easier to use the ORM most preferred by the programmer, rather than being corralled into using one particular one. To allow this, the ORM needed to be extracted from the model and the database, to be a pure mediator between the two. Then any ORM can be used as long as it can successfully understand the model and the database used.

==Advantages<ref>http://www.techopedia.com/definition/24200/object-relational-mapping--orm</ref>==
In addition to the [http://en.wikipedia.org/wiki/Data_access data access] technique, ORM's benefits also include:
*First of all, you hide the SQL away from your logic code. This has the benefit of allowing you to more easily support more database engines. For instance, MS SQL Server and Oracle has different names on typical functions, and different ways to do calculations with dates, so a query to "get me all persons edited the last 24 hours" might entail different SQL syntax just for those two database engines. This difference can be put away from your logic code.
*Additionally, you can focus on writing the logic, instead of getting all the SQL right. The code will typically be more readable as well, since it doesn't contain all the "plumbing" necessary to talk to the database.
*Simplified development because it automates object-to-table and table-to-object conversion, resulting in lower development and maintenance costs
*Less code compared to embedded SQL and handwritten stored procedures
*Transparent object caching in the application tier, improving system performance
*An optimized solution making an application faster and easier to maintain

==Disadvantages ==
*ORM’s emergence in multiple application development has created disagreement among experts. Key concerns are that ORM does not perform well and that stored procedures might be a better solution.
*In addition, ORM dependence may result in poorly-designed databases in certain circumstances.
*Performance – like every "proxy" technology
*Complexity – learning curve
*Difficulty / inability to make complex queries

=ORM Frameworks=

==Active Records==
[http://guides.rubyonrails.org/active_record_basics.html Active Record] was described by Martin Fowler in his book Patterns of Enterprise Application Architecture. Active Record is the M in [http://guides.rubyonrails.org/getting_started.html#the-mvc-architecture MVC]- the model - which is the layer of the system responsible for representing business data and logic. In Active Record, objects carry both persistent data and behavior which operates on that data. A database table or view is wrapped into a class and an object instance is tied to a single row in the table. Each Active Record object has CRUD (Create, Read, Update, and Delete) methods for database access. In addition, Active Record allows you to validate the state of a model before it gets written into the database.

Active Record gives us several mechanisms, the most important being the ability to:
* Represent models and their data.
* Represent associations between these models.
* Represent inheritance hierarchies through related models.
* Validate models before they get persisted to the database.
* Perform database operations in an object-oriented fashion.

The naming conventions used in Active Records are :
* Database Table - Plural with underscores separating words (e.g., book_clubs).
* Model Class - Singular with the first letter of each word capitalized (e.g., BookClub).

To create a table, ActiveRecord makes use of a migration class rather than including table definition in the actual class being modeled. As an example, the following code creates a table ‘’users’’ to store a collection of class ‘’User’’ objects:
<pre>
class CreateUsers < ActiveRecord::Migration
def self.up
create_table :users do |t|
t.string :name
t.string :email
t.string :age
t.references :cheer
t.references :post

t.timestamps # add creation and modification timestamps
end
end

def self.down # undo the table creation
drop_table :users
end
end
</pre>

The ActiveRecord’s migration scheme provides a means for backing out changes via the ‘’self.down’’ method. In addition, a table key ‘’id’’ is added to the new table without an explicit definition and record creation and modification timestamps are included via the ‘’timestamps’’ method provided by ActiveRecord.

ActiveRecord manages associations between table elements and provides the means to define such associations in the model definition. For example, the ‘’User’’ class shown below defines a ‘’has_many’’ (one-to-many) association with both the cheers and posts tables. These associations are represented in the migration class with the references operator. Also note ActiveRecord’s integrated support for validation of table information when attempting an update.

<pre>
class User < ActiveRecord::Base
has_many :cheers
has_many :posts

validates_presence_of :name
validates_presence_of :age
validates_uniqueness_of :name
validates_length_of :name, :within => 3..20
end
</pre>

To access the data in the table one calls the class function related to that column. For example, to find the user who's name is Bob, one would use @user = User.find_by_name('Bob'). Then one could find Bob's e-mail by using @user.email. Users can be searched for by any attribute in this way, as find methods are created for every combination of attributes.
While ActiveRecord provides the flexibility to create more sophisticated table relationships to represent class hierarchy, its base scheme is a single table inheritance, which trades some storage efficiency for simplicity in the database design. The following figure illustrates this concept of simplicity over efficiency.

[[Image:3j_ks_pic2.jpg]]

'''Pros''' -
* Integrated with popular Rails development framework
* Dynamically created database search methods (eg: User.find_by_address) ease db queries and make queries database syntax independent
* DB creation/management using the migrate scheme provides a means for backing out unwanted table changes
'''Cons''' -
* DB creation/management is decoupled from the model, requiring a separate utility (rake/migrate) that must be kept in sync with application.

==ORM Adaptor==
[https://github.com/ianwhite/orm_adapter ORM Adaptors] provide a single point of entry for popular ruby ORMs. Its target audience is gem authors who want to support more than one ORM.
ORM Adapter's goal is to support a minimum API used by most of the plugins that needs agnosticism beyond Active Model.
ORM Adapter will support only basic methods, as get, find_first, create! and so forth. It is not ORM Adapter's goal to support different query constructions, handle table joins, etc.
ORM adapter provides a consistent API for these basic class or 'factory' methods. It does not attempt to unify the behaviour of model instances returned by these methods. This means that unifying the behaviour of methods such as `model.save`, and `model.valid?` is beyond the scope of orm_adapter.
If you need complex queries, it is recommended to subclass ORM Adapters in your plugin and extend it expressing these query conditions as part of your domain logic.
<pre>
Example :
require 'orm_adapter'
User # is it an ActiveRecord, DM Resource, MongoMapper or MongoId Document?
User.to_adapter.find_first :name => 'Fred' # we don't care!
user_model = User.to_adapter
user_model.get!(1) # find a record by id
user_model.find_first(:name => 'fred') # find first fred
user_model.find_first(:level => 'awesome', :id => 23) # find user 23, only if it's level is awesome
user_model.find_all # find all users
user_model.find_all(:name => 'fred') # find all freds
user_model.find_all(:order => :name) # find all freds, ordered by name
user_model.create!(:name => 'fred') # create a fred
user_model.destroy(object) # destroy the user object
</pre>

==Sequel==
[http://sequel.jeremyevans.net/documentation.html Sequel] was originally developed by Sharon Rosner and the first release was in March 2007. It is based on the active record pattern. Sequel and Active Record share a lot of common features , for example association and inheritance. But Sequel handles these features in a much more flexible manner. Currently Sequel is at version 3.44.0. Initially Sequel had three core modules - sequel, sequel_core and sequel_model. Starting from version 1.4 , sequel and sequel_model were merged. Sequel handles validations using a validation plug-in and helpers.

<pre>
class CreateUser < Sequel::Migration
def up
create_table(:user) {
primary_key :id
String :name
String :age
String :email}
end
def down
drop_table(:user)
end
end # CreateUser.apply(DB, :up)
</pre>

Sequel supports associations and validations similar to Active Record. The following example shows how validations and associations can be enforced in the User table that has been created above. It enforces one to many relationships between the user table and the cheers and posts tables. It also validates for the presence , uniqueness and the length of the attribute '''name'''.

<pre>
class User < Sequel::Model
one_to_many :cheers
one_to_many :posts

validates_presence [:name, :age]
validates_unique(:name)
validates_length_range 3..20, :name
end
</pre>

To access the data in Sequel, one can use where clauses. For instance, to find Bob again one would use DB[:items].where(Sequel.like(:name, 'Bob'). While the ability to use SQL-like where clauses is quite flexible, it is not quite as pure an object-oriented approach as Active Record's dynamically created find methods.

Some of the key features of sequel are,
* [http://sequel.jeremyevans.net/rdoc/classes/Sequel/ThreadedConnectionPool.html Connection Pooling]
* Thread Safety
* [http://guides.rubyonrails.org/active_record_querying.html#eager-loading-associations Eager Loading] / Lazy Loading
* Model Caching
* Supports advanced database features such as prepared statements, bound variables, stored procedures, savepoints, two-phase commit, transaction isolation, master/slave configurations, and database sharding.

==Data Mapper==
[http://datamapper.org/ DataMapper] is an Object Relational Mapper written in Ruby developed by Sam Smoot with the goal to create an ORM which is fast, thread-safe and feature rich.
A Data Mapper is a Data Access Layer that performs bidirectional transfer of data between a persistent data store (often a relational database) and an in memory data representation (the domain layer). The goal of the pattern is to keep the in memory representation and the persistent data store independent of each other and the data mapper itself. The layer is composed of one or more mappers (or Data Access Objects), performing the data transfer.
DataMapper comes with the ability to use the same API to talk to a multitude of different datastores. There are adapters for the usual RDBMS suspects, NoSQL stores, various file formats and some web services. With DataMapper, you define your mappings in your model. Your data store can develop independently of your model using Migrations.

Some features of Data Mapper are as follows :
* No need to write structural migrations
* Scoped relations
* Lazy loading on certain attribute types
* Strategic eager loading to avoid (N+1) queries
* Default support for composite and natural keys
* Query chaining, and not evaluating the query until absolutely necessary (using a lazy array implementation)
* An API not too heavily oriented to SQL databases

DataMapper was designed to be a more abstract ORM, not strictly SQL, based on Martin Fowler's enterprise pattern. As a result, DataMapper adapters have been built for other non-SQL databases, such as CouchDB, [http://github.com/lritter/dm-solr-adapter/tree/master Apache Solr], and webservices such as [http://github.com/halorgium/dm-salesforce/tree/master Salesforce].

Example of table definition in the model:
<pre>
class User
include DataMapper::Resource

property :id, Serial # key
property :name, String, :required => true, :unique => true
property :age, String, :required => true, :length => 3..20
property :email, String

has n, :posts # one to many association
has n, :cheers # one to many association
end
</pre>

Notice that in the example above , ":required = true" is an example for Auto Validation. Unlike ActiveRecord and Sequel, DataMapper supports auto validations , i.e. these in turn call the validation helpers to enforce basic validations such as length, uniqueness, format, presence etc.

==MyBatis/iBatis==
[http://en.wikipedia.org/wiki/MyBatis MyBatis/iBatis] was a persistence framework which allowed easy access of the database from a Rails application without being a full ORM. It was created by the Apache Foundation in 2002, and is available for several platforms, including Ruby (the Ruby release is known as RBatis). On 6/16/2010, after releasing iBATIS 3.0, the project team moved from Apache to Google Code, changed the project's name to MyBatis, and stopped supporting Ruby.

The MyBatis data mapper framework makes it easier to use a relational database with object-oriented applications. MyBatis couples objects with stored procedures or SQL statements using a XML descriptor. To use the MyBatis data mapper,we make use of our own objects, XML, and SQL.

SQL statements are stored in XML files or annotations. Following is a MyBatis mapper, that consists of a Java interface with some MyBatis annotations:
<pre>
package org.mybatis.example;

public interface BlogMapper {
@Select("select * from Blog where id = #{id}")
Blog selectBlog(int id);
}
</pre>
The sentence is executed as follows.
<pre>
BlogMapper mapper = session.getMapper(BlogMapper.class);
Blog blog = mapper.selectBlog(101);
</pre>

It can also be executed using MyBatis API.
<pre>
Blog blog = session.selectOne("org.mybatis.example.BlogMapper.selectBlog", 101);
</pre>

SQL statements and mappings can also be externalized to an XML file like this.
<pre>
<?xml version="1.0" encoding="UTF-8" ?>
<!DOCTYPE mapper PUBLIC "-//mybatis.org//DTD Mapper 3.0//EN" "http://mybatis.org/dtd/mybatis-3-mapper.dtd">

<mapper namespace="org.mybatis.example.BlogMapper">
<select id="selectBlog" parameterType="int" resultType="Blog">
select * from Blog where id = #{id}
</select>
</mapper>
</pre>

==Squeel==
[http://rubydoc.info/gems/squeel/1.1.1/frames Squeel]unlocks the power of Arel in Rails applications with a handy block-based syntax. It is supporting in Rails 3 and 4. With Squeel, you can write subqueries, access named functions provided by RDMBS and more without writing SQL strings.
Squeel lets you write your Active Record queries with fewer strings, and more Ruby, by making the Arel awesomeness that lies beneath Active Record more accessible.

Squeel lets you rewrite...

<pre>
Article.where ['created_at >= ?', 2.weeks.ago]
...as...
Article.where{created_at >= 2.weeks.ago}
</pre>

Squeel enhances the normal Active Record query methods by enabling them to accept blocks. Inside a block, the Squeel query DSL can be used. Note the use of curly braces in the above example instead of parentheses. {} denotes a Squeel DSL query.

Stubs and keypaths are the two primary building blocks used in a Squeel DSL query.

Stubs are, for most intents and purposes, just like Symbols in a normal call to Relation#where (note the need for doubling up on the curly braces here, the first ones start the block, the second are the hash braces):
<pre>
Person.where{{name => ‘Ernie’ }}
</pre>

You normally wouldn't bother using the DSL in this case, as a simple hash would suffice. However, stubs serve as a building block for keypaths, and keypaths are very handy.

A Squeel keypath is essentially a more concise and readable alternative to a deeply nested hash. For instance, in standard Active Record, you might join several associations like this to perform a query:
<pre>
Person.joins(:articles => { :comments => :person}).references(:all)
</pre>

With a keypath, this would look like:
<pre>
Person.joins{articles.comments.person}.references(:all)
</pre>

The Squeel DSL works its magic using instance_eval which means that inside a Squeel DSL block, self isn't the same thing that it is outside the block.
This carries with it an important implication: Instance variables and instance methods inside the block won't refer to your object's variables/methods.
Use one of the following methods to get access to the object's methods and variables:
* Assign the variable locally before the DSL block, and access it as you would normally.
* Supply an arity to the DSL block, as in Person.where{|q| q.name == @my_name} Downside: You'll need to prefix stubs, keypaths, and functions with the DSL object.
* Wrap the method or instance variable inside the block with my{}. Person.where{name == my{some_method_to_return_a_name}}

==Merb==
[http://en.wikipedia.org/wiki/Merb Merb], short for "Mongrel+Erb", is a model view controller framework written in Ruby. Merb was merged into Rails web framework on December 23, 2008 as part of the Ruby on Rails 3.0 release.
Merb itself provides only the controller of an MVC model which can be extended to create a full-stack application environment. This effectively means Merb itself is not an ORM but can accommodate other ORMs.
Some features of Merb are as follows :
* Speed - Merb is ORM, JavaScript library and template language agnostic, preferring plugins that add support for features rather than producing a monolithic library with everything in the core.
* Lightweight - Rather than trying to cram every feature into a single code, things are kept bare minimum without sacrificing anything important.
* Powerful and extensible - For any features not covered in Merb’s core, there are plugins.
Some basic Command distinction between Ruby on Rails and Merb :
{| class="comparison" border="1"
! Action
! Ruby on Rails
! Merb
|-
| Create new application 'app1' || rails new app1 || merb-gen app app1
|-
| Start server || rails server || merb
|-
| Start cluster of 3 beginning at port 3000 || N/A || merb -p 3000 -c 3
|-
| Interactive console || rails console || merb -i
|}

=Alternative to ORM=
==NonSQL databases==
Instead of ORM we can also use Object-Oriented Database Management System (OODBMS) or document-oriented database like XML, where in databases are designed to store object oriented values, thus eliminating the need to convert data to and from its SQL form. Document oriented databases also eliminates the need to retrieve objects as data rows. Query languages like XQuery can be used to retrieve data sets.

The only issue is we won't be able to create application independent queries for retrieving data without restrictions to access path. Also OODBMS limits the extent of processing SQL queries.
A Relational database allows concurrent access to data, locking, indexing (fast search), as well as many other features that are not available while using XML files.

Other OODBMS (such as RavenDB) provide replication to SQL databases, as a means of addressing the need for ad-hoc queries, while preserving the increased performance and reduced complexity that may be achieved with an OODBMS for an application that has well-known query patterns.

NonSQL databases don’t provide mechanism to maintain relationship between tables. In real life though, business objects or entities do have relationship among them. ORM solutions may allow you to define these relationships in business objects and handle their storage and retrieval behind the scene

=Comparison of ORM Features=

{|cellspacing="0" border="1"
!style="width:8%"|Features
!style="width:23%"|ActiveRecord
!style="width:23%"|Sequel
!style="width:23%"|DataMapper
!style="width:23%"|MyBatis
|-
! Databases 
| MySQL, PostgreSQL, SQLite, Oracle, SQLServer, and DB2
| ADO, DataObjects, DB2, DBI, Firebird, Informix, JDBC, MySQL, ODBC, OpenBase, Oracle, PostgreSQL and SQLite3
| SQLite, MySQL, PostgreSQL, Oracle, MongoDB, SimpleDB, many others, including CouchDB, Apache Solr, Google Data API
| MySQL, PostgreSQL, SQLite, Oracle, SQLServer, and DB2
|-
! Migrations 
| Yes
| Yes
| Yes, but optional
| Yes, provides migration by Mybatis schema migration system.
|-
! EagerLoading 
| Supported by scanning the SQL fragments
| Supported using eager (preloading) and eager_graph (joins)
| Strategic Eager Loading and by using :summary
| Yes.this can be enabled or disabled by setting the lazyLoadingEnabled flag
|-
! Flexible Overriding 
| No. Overriding is done using alias methods.
| Using methods and by calling 'super'
| Using methods
| No
|-
! Dynamic Finders 
| Yes. Uses 'Method Missing'
| No. Alternative is to use <Model>.FindOrCreate(:name=>"John")
| Yes. Using the dm_ar_finders plugin
| Similar feature is supported in the form of Dynamic SQL
|}

=Further Reading=
To get more information on ORM and the different type of ORM's available for Ruby , please look into the [http://wiki.expertiza.ncsu.edu/index.php/CSC/ECE_517_Spring_2013/ch1_1d_zk CSC/ECE 517 Spring 2013/ch1 1d zk] and [http://wiki.expertiza.ncsu.edu/index.php/CSC/ECE_517_Fall_2010/ch3_3f_ac Fall 2010 detailed ORM explanation] wiki pages.
# [http://www.cs.colorado.edu/~kena/classes/5448/f11/lectures/29-orm.pdf ORM - University of Colorado]
# [http://www.lynda.com/Ruby-Rails-tutorials/Understanding-ActiveRecord-ActiveRelation/139989/159093-4.html Active Record Tutorial]
# [http://digitalcommons.macalester.edu/context/mathcs_honors/article/1006/type/native/viewcontent/ Research papers on object relational mapping]
# [http://www.sitepoint.com/top-ruby-frameworks-rails-and-merb-join-forces/ Merb and Rails]

=Future Work=
More work can be done in the area of comparison between the different ORMs available for Ruby, especially a more detailed feature-by-feature comparison that includes performance differences between the ORMs.

=References =
# [http://en.wikipedia.org/wiki/Object-relational_mapping Object Relational Mapping]
# [http://en.wikipedia.org/wiki/Object-oriented_programming object-oriented programming]
# [http://en.wikipedia.org/wiki/Data_access data access]
# [http://en.wikipedia.org/wiki/Metaprogramming metaprogramming]
# [http://guides.rubyonrails.org/active_record_basics.html Active Record]
# [http://guides.rubyonrails.org/getting_started.html#the-mvc-architecture MVC]
# [http://sequel.jeremyevans.net/documentation.html Sequel]
# [http://datamapper.org/ DataMapper]
# [http://sequel.jeremyevans.net/rdoc/classes/Sequel/ThreadedConnectionPool.html Connection Pooling]
# [http://guides.rubyonrails.org/active_record_querying.html#eager-loading-associations Eager Loading]
# [http://rubydoc.info/gems/squeel/1.1.1/frames Squeel]
# [http://www.techopedia.com/definition/24200/object-relational-mapping--orm ORM]
# [http://en.wikipedia.org/wiki/Merb Merb]
# [http://www.merbivore.com/ Merb Website]
# [http://wiki.expertiza.ncsu.edu/index.php/CSC/ECE_517_Spring_2013/ch1_1d_zk Object Relational Mapping Spring 2013]

CSC/ECE 517 Fall 2014/ch1a 25 ks

2014-09-24T23:16:47Z

Knimgao:

=Object Relational Mapping=

__TOC__

==Introduction==
[http://en.wikipedia.org/wiki/Object-relational_mapping Object Relational Mapping] (ORM, O/RM, and O/R mapping) in computer science is a programming technique for converting data between incompatible type systems in object-oriented programming languages. This creates, in effect, a "virtual object database" that can be used from within the programming language. There are both free and commercial packages available that perform object-relational mapping, although some programmers opt to create their own ORM tools.

==Overview==
Object Relational Mapping is a programming technique in which a metadata descriptor is used to connect object code to a relational database. ORM converts data between type systems that are unable to coexist within relational databases and OOP languages.

In [http://en.wikipedia.org/wiki/Object-oriented_programming object-oriented programming], data management tasks act on object-oriented (OO) objects that are almost always non-scalar values. For example, consider an address book entry that represents a single person along with zero or more phone numbers and zero or more addresses. This could be modeled in an object-oriented implementation by a "Person object" with attributes/fields to hold each data item that the entry comprises: the person's name, a list of phone numbers, and a list of addresses. The list of phone numbers would itself contain "PhoneNumber objects" and so on. The address book entry is treated as a single object by the programming language (it can be referenced by a single variable containing a pointer to the object, for instance). Various methods can be associated with the object, such as a method to return the preferred phone number, the home address, and so on.

The heart of the problem is translating the logical representation of the objects into an atomized form that is capable of being stored in the database, while preserving the properties of the objects and their relationships so that they can be reloaded as objects when needed. If this storage and retrieval functionality is implemented, the objects are said to be persistent.

==Simple Explanation==
A simple answer is that you wrap your tables or stored procedures in classes in your programming language, so that instead of writing SQL statements to interact with your database, you use methods and properties of objects.

In other words, instead of something like this:
<pre>
String sql = "SELECT ... FROM persons WHERE id = 10"
DbCommand cmd = new DbCommand(connection, sql);
Result res = cmd.Execute();
String name = res[0]["FIRST_NAME"];
</pre>
you do something like this:
<pre>
Person p = repository.GetPerson(10);
String name = p.FirstName;
</pre>
or similar code (lots of variations here.) Some frameworks also put a lot of the code in as static methods on the classes themselves, which means you could do something like this instead:
<pre>
Person p = Person.Get(10);
</pre>
Some also implement complex query systems, so you could do this:
<pre>
Person p = Person.Get(Person.Properties.Id == 10);
</pre>
The framework is what makes this code possible.

==Features==
Object-relational Mapping (ORM) frameworks unburden the designer of the complex translation between database and object space.

Typical ORM features:
* Automatic mapping from classes to database tables
** Class instance variables to database columns
** Class instances to table rows
* Aggregation and association relationships between mapped classes are managed
** Example, :has_many, :belongs_to associations in ActiveRecord
** Inheritance cases are mapped to tables
* Validation of data prior to table storage
* Class extensions to enable search, as well as creation, read, update, and deletion (CRUD) of instances/records
* Usually abstracts the database from program space in such a way that alternate database types can be easily chosen (SQLite, Oracle, etc)

The diagram below depicts a simple mapping of an object to a database table….

[[Image:3j_ks_pic1.jpg]]

ORM framework is used to persist model objects to a relational database and retrieve them, and the ORM framework will take care of converting the data between the two otherwise incompatible states. Most ORM tools rely heavily on metadata about both the database and objects, so that the objects need to know nothing about the database and the database doesn’t need to know anything about how the data is structured in the application. ORM provides a clean separation of concerns in a well-designed data application, and the database and application can each work with data in its native form. Database rows map to objects, thus making the program more easily accessible and allowing the usage of information in a way that is internally consistent and easy to understand. The ORM gives the programmer an ability to manipulate data with the programming language, instead of having to manipulate each attribute as its data type as obtained by the database management system.

When applied to Ruby, implementations of ORM often leverage the language’s [http://en.wikipedia.org/wiki/Metaprogramming metaprogramming] strengths to create intuitive application-specific methods and otherwise extend classes to support database functionality. With the addition of Rails, the ORM becomes much more important, as it is necessary to have an ORM to connect the models of the MVC (model-view-controller) stack used by Ruby on Rails with the application's database. Since the models are Ruby objects, the ORM allows modifications to the database to be done through changes to these models, independent of the type of database used.

With the release of Rails 3.0, the platform became ORM independent. With this change, it is much easier to use the ORM most preferred by the programmer, rather than being corralled into using one particular one. To allow this, the ORM needed to be extracted from the model and the database, to be a pure mediator between the two. Then any ORM can be used as long as it can successfully understand the model and the database used.

==Advantages== <ref>http://www.techopedia.com/definition/24200/object-relational-mapping--orm</ref>
In addition to the [http://en.wikipedia.org/wiki/Data_access data access] technique, ORM's benefits also include:
*First of all, you hide the SQL away from your logic code. This has the benefit of allowing you to more easily support more database engines. For instance, MS SQL Server and Oracle has different names on typical functions, and different ways to do calculations with dates, so a query to "get me all persons edited the last 24 hours" might entail different SQL syntax just for those two database engines. This difference can be put away from your logic code.
*Additionally, you can focus on writing the logic, instead of getting all the SQL right. The code will typically be more readable as well, since it doesn't contain all the "plumbing" necessary to talk to the database.
*Simplified development because it automates object-to-table and table-to-object conversion, resulting in lower development and maintenance costs
*Less code compared to embedded SQL and handwritten stored procedures
*Transparent object caching in the application tier, improving system performance
*An optimized solution making an application faster and easier to maintain

==Disadvantages ==
*ORM’s emergence in multiple application development has created disagreement among experts. Key concerns are that ORM does not perform well and that stored procedures might be a better solution.
*In addition, ORM dependence may result in poorly-designed databases in certain circumstances.
*Performance – like every "proxy" technology
*Complexity – learning curve
*Difficulty / inability to make complex queries

=ORM Frameworks=

==Active Records==
[http://guides.rubyonrails.org/active_record_basics.html Active Record] was described by Martin Fowler in his book Patterns of Enterprise Application Architecture. Active Record is the M in [http://guides.rubyonrails.org/getting_started.html#the-mvc-architecture MVC]- the model - which is the layer of the system responsible for representing business data and logic. In Active Record, objects carry both persistent data and behavior which operates on that data. A database table or view is wrapped into a class and an object instance is tied to a single row in the table. Each Active Record object has CRUD (Create, Read, Update, and Delete) methods for database access. In addition, Active Record allows you to validate the state of a model before it gets written into the database.

Active Record gives us several mechanisms, the most important being the ability to:
* Represent models and their data.
* Represent associations between these models.
* Represent inheritance hierarchies through related models.
* Validate models before they get persisted to the database.
* Perform database operations in an object-oriented fashion.

The naming conventions used in Active Records are :
* Database Table - Plural with underscores separating words (e.g., book_clubs).
* Model Class - Singular with the first letter of each word capitalized (e.g., BookClub).

To create a table, ActiveRecord makes use of a migration class rather than including table definition in the actual class being modeled. As an example, the following code creates a table ‘’users’’ to store a collection of class ‘’User’’ objects:
<pre>
class CreateUsers < ActiveRecord::Migration
def self.up
create_table :users do |t|
t.string :name
t.string :email
t.string :age
t.references :cheer
t.references :post

t.timestamps # add creation and modification timestamps
end
end

def self.down # undo the table creation
drop_table :users
end
end
</pre>

The ActiveRecord’s migration scheme provides a means for backing out changes via the ‘’self.down’’ method. In addition, a table key ‘’id’’ is added to the new table without an explicit definition and record creation and modification timestamps are included via the ‘’timestamps’’ method provided by ActiveRecord.

ActiveRecord manages associations between table elements and provides the means to define such associations in the model definition. For example, the ‘’User’’ class shown below defines a ‘’has_many’’ (one-to-many) association with both the cheers and posts tables. These associations are represented in the migration class with the references operator. Also note ActiveRecord’s integrated support for validation of table information when attempting an update.

<pre>
class User < ActiveRecord::Base
has_many :cheers
has_many :posts

validates_presence_of :name
validates_presence_of :age
validates_uniqueness_of :name
validates_length_of :name, :within => 3..20
end
</pre>

To access the data in the table one calls the class function related to that column. For example, to find the user who's name is Bob, one would use @user = User.find_by_name('Bob'). Then one could find Bob's e-mail by using @user.email. Users can be searched for by any attribute in this way, as find methods are created for every combination of attributes.
While ActiveRecord provides the flexibility to create more sophisticated table relationships to represent class hierarchy, its base scheme is a single table inheritance, which trades some storage efficiency for simplicity in the database design. The following figure illustrates this concept of simplicity over efficiency.

[[Image:3j_ks_pic2.jpg]]

'''Pros''' -
* Integrated with popular Rails development framework
* Dynamically created database search methods (eg: User.find_by_address) ease db queries and make queries database syntax independent
* DB creation/management using the migrate scheme provides a means for backing out unwanted table changes
'''Cons''' -
* DB creation/management is decoupled from the model, requiring a separate utility (rake/migrate) that must be kept in sync with application.

==ORM Adaptor==
[https://github.com/ianwhite/orm_adapter ORM Adaptors] provide a single point of entry for popular ruby ORMs. Its target audience is gem authors who want to support more than one ORM.
ORM Adapter's goal is to support a minimum API used by most of the plugins that needs agnosticism beyond Active Model.
ORM Adapter will support only basic methods, as get, find_first, create! and so forth. It is not ORM Adapter's goal to support different query constructions, handle table joins, etc.
ORM adapter provides a consistent API for these basic class or 'factory' methods. It does not attempt to unify the behaviour of model instances returned by these methods. This means that unifying the behaviour of methods such as `model.save`, and `model.valid?` is beyond the scope of orm_adapter.
If you need complex queries, it is recommended to subclass ORM Adapters in your plugin and extend it expressing these query conditions as part of your domain logic.
<pre>
Example :
require 'orm_adapter'
User # is it an ActiveRecord, DM Resource, MongoMapper or MongoId Document?
User.to_adapter.find_first :name => 'Fred' # we don't care!
user_model = User.to_adapter
user_model.get!(1) # find a record by id
user_model.find_first(:name => 'fred') # find first fred
user_model.find_first(:level => 'awesome', :id => 23) # find user 23, only if it's level is awesome
user_model.find_all # find all users
user_model.find_all(:name => 'fred') # find all freds
user_model.find_all(:order => :name) # find all freds, ordered by name
user_model.create!(:name => 'fred') # create a fred
user_model.destroy(object) # destroy the user object
</pre>

==Sequel==
[http://sequel.jeremyevans.net/documentation.html Sequel] was originally developed by Sharon Rosner and the first release was in March 2007. It is based on the active record pattern. Sequel and Active Record share a lot of common features , for example association and inheritance. But Sequel handles these features in a much more flexible manner. Currently Sequel is at version 3.44.0. Initially Sequel had three core modules - sequel, sequel_core and sequel_model. Starting from version 1.4 , sequel and sequel_model were merged. Sequel handles validations using a validation plug-in and helpers.

<pre>
class CreateUser < Sequel::Migration
def up
create_table(:user) {
primary_key :id
String :name
String :age
String :email}
end
def down
drop_table(:user)
end
end # CreateUser.apply(DB, :up)
</pre>

Sequel supports associations and validations similar to Active Record. The following example shows how validations and associations can be enforced in the User table that has been created above. It enforces one to many relationships between the user table and the cheers and posts tables. It also validates for the presence , uniqueness and the length of the attribute '''name'''.

<pre>
class User < Sequel::Model
one_to_many :cheers
one_to_many :posts

validates_presence [:name, :age]
validates_unique(:name)
validates_length_range 3..20, :name
end
</pre>

To access the data in Sequel, one can use where clauses. For instance, to find Bob again one would use DB[:items].where(Sequel.like(:name, 'Bob'). While the ability to use SQL-like where clauses is quite flexible, it is not quite as pure an object-oriented approach as Active Record's dynamically created find methods.

Some of the key features of sequel are,
* [http://sequel.jeremyevans.net/rdoc/classes/Sequel/ThreadedConnectionPool.html Connection Pooling]
* Thread Safety
* [http://guides.rubyonrails.org/active_record_querying.html#eager-loading-associations Eager Loading] / Lazy Loading
* Model Caching
* Supports advanced database features such as prepared statements, bound variables, stored procedures, savepoints, two-phase commit, transaction isolation, master/slave configurations, and database sharding.

==Data Mapper==
[http://datamapper.org/ DataMapper] is an Object Relational Mapper written in Ruby developed by Sam Smoot with the goal to create an ORM which is fast, thread-safe and feature rich.
A Data Mapper is a Data Access Layer that performs bidirectional transfer of data between a persistent data store (often a relational database) and an in memory data representation (the domain layer). The goal of the pattern is to keep the in memory representation and the persistent data store independent of each other and the data mapper itself. The layer is composed of one or more mappers (or Data Access Objects), performing the data transfer.
DataMapper comes with the ability to use the same API to talk to a multitude of different datastores. There are adapters for the usual RDBMS suspects, NoSQL stores, various file formats and some web services. With DataMapper, you define your mappings in your model. Your data store can develop independently of your model using Migrations.

Some features of Data Mapper are as follows :
* No need to write structural migrations
* Scoped relations
* Lazy loading on certain attribute types
* Strategic eager loading to avoid (N+1) queries
* Default support for composite and natural keys
* Query chaining, and not evaluating the query until absolutely necessary (using a lazy array implementation)
* An API not too heavily oriented to SQL databases

DataMapper was designed to be a more abstract ORM, not strictly SQL, based on Martin Fowler's enterprise pattern. As a result, DataMapper adapters have been built for other non-SQL databases, such as CouchDB, [http://github.com/lritter/dm-solr-adapter/tree/master Apache Solr], and webservices such as [http://github.com/halorgium/dm-salesforce/tree/master Salesforce].

Example of table definition in the model:
<pre>
class User
include DataMapper::Resource

property :id, Serial # key
property :name, String, :required => true, :unique => true
property :age, String, :required => true, :length => 3..20
property :email, String

has n, :posts # one to many association
has n, :cheers # one to many association
end
</pre>

Notice that in the example above , ":required = true" is an example for Auto Validation. Unlike ActiveRecord and Sequel, DataMapper supports auto validations , i.e. these in turn call the validation helpers to enforce basic validations such as length, uniqueness, format, presence etc.

==MyBatis/iBatis==
[http://en.wikipedia.org/wiki/MyBatis MyBatis/iBatis] was a persistence framework which allowed easy access of the database from a Rails application without being a full ORM. It was created by the Apache Foundation in 2002, and is available for several platforms, including Ruby (the Ruby release is known as RBatis). On 6/16/2010, after releasing iBATIS 3.0, the project team moved from Apache to Google Code, changed the project's name to MyBatis, and stopped supporting Ruby.

The MyBatis data mapper framework makes it easier to use a relational database with object-oriented applications. MyBatis couples objects with stored procedures or SQL statements using a XML descriptor. To use the MyBatis data mapper,we make use of our own objects, XML, and SQL.

SQL statements are stored in XML files or annotations. Following is a MyBatis mapper, that consists of a Java interface with some MyBatis annotations:
<pre>
package org.mybatis.example;

public interface BlogMapper {
@Select("select * from Blog where id = #{id}")
Blog selectBlog(int id);
}
</pre>
The sentence is executed as follows.
<pre>
BlogMapper mapper = session.getMapper(BlogMapper.class);
Blog blog = mapper.selectBlog(101);
</pre>

It can also be executed using MyBatis API.
<pre>
Blog blog = session.selectOne("org.mybatis.example.BlogMapper.selectBlog", 101);
</pre>

SQL statements and mappings can also be externalized to an XML file like this.
<pre>
<?xml version="1.0" encoding="UTF-8" ?>
<!DOCTYPE mapper PUBLIC "-//mybatis.org//DTD Mapper 3.0//EN" "http://mybatis.org/dtd/mybatis-3-mapper.dtd">

<mapper namespace="org.mybatis.example.BlogMapper">
<select id="selectBlog" parameterType="int" resultType="Blog">
select * from Blog where id = #{id}
</select>
</mapper>
</pre>

==Squeel==
[http://rubydoc.info/gems/squeel/1.1.1/frames Squeel]unlocks the power of Arel in Rails applications with a handy block-based syntax. It is supporting in Rails 3 and 4. With Squeel, you can write subqueries, access named functions provided by RDMBS and more without writing SQL strings.
Squeel lets you write your Active Record queries with fewer strings, and more Ruby, by making the Arel awesomeness that lies beneath Active Record more accessible.

Squeel lets you rewrite...

<pre>
Article.where ['created_at >= ?', 2.weeks.ago]
...as...
Article.where{created_at >= 2.weeks.ago}
</pre>

Squeel enhances the normal Active Record query methods by enabling them to accept blocks. Inside a block, the Squeel query DSL can be used. Note the use of curly braces in the above example instead of parentheses. {} denotes a Squeel DSL query.

Stubs and keypaths are the two primary building blocks used in a Squeel DSL query.

Stubs are, for most intents and purposes, just like Symbols in a normal call to Relation#where (note the need for doubling up on the curly braces here, the first ones start the block, the second are the hash braces):
<pre>
Person.where{{name => ‘Ernie’ }}
</pre>

You normally wouldn't bother using the DSL in this case, as a simple hash would suffice. However, stubs serve as a building block for keypaths, and keypaths are very handy.

A Squeel keypath is essentially a more concise and readable alternative to a deeply nested hash. For instance, in standard Active Record, you might join several associations like this to perform a query:
<pre>
Person.joins(:articles => { :comments => :person}).references(:all)
</pre>

With a keypath, this would look like:
<pre>
Person.joins{articles.comments.person}.references(:all)
</pre>

The Squeel DSL works its magic using instance_eval which means that inside a Squeel DSL block, self isn't the same thing that it is outside the block.
This carries with it an important implication: Instance variables and instance methods inside the block won't refer to your object's variables/methods.
Use one of the following methods to get access to the object's methods and variables:
* Assign the variable locally before the DSL block, and access it as you would normally.
* Supply an arity to the DSL block, as in Person.where{|q| q.name == @my_name} Downside: You'll need to prefix stubs, keypaths, and functions with the DSL object.
* Wrap the method or instance variable inside the block with my{}. Person.where{name == my{some_method_to_return_a_name}}

==Merb==
[http://en.wikipedia.org/wiki/Merb Merb], short for "Mongrel+Erb", is a model view controller framework written in Ruby. Merb was merged into Rails web framework on December 23, 2008 as part of the Ruby on Rails 3.0 release.
Merb itself provides only the controller of an MVC model which can be extended to create a full-stack application environment. This effectively means Merb itself is not an ORM but can accommodate other ORMs.
Some features of Merb are as follows :
* Speed - Merb is ORM, JavaScript library and template language agnostic, preferring plugins that add support for features rather than producing a monolithic library with everything in the core.
* Lightweight - Rather than trying to cram every feature into a single code, things are kept bare minimum without sacrificing anything important.
* Powerful and extensible - For any features not covered in Merb’s core, there are plugins.
Some basic Command distinction between Ruby on Rails and Merb :
{| class="comparison" border="1"
! Action
! Ruby on Rails
! Merb
|-
| Create new application 'app1' || rails new app1 || merb-gen app app1
|-
| Start server || rails server || merb
|-
| Start cluster of 3 beginning at port 3000 || N/A || merb -p 3000 -c 3
|-
| Interactive console || rails console || merb -i
|}

=Alternative to ORM=
==NonSQL databases==
Instead of ORM we can also use Object-Oriented Database Management System (OODBMS) or document-oriented database like XML, where in databases are designed to store object oriented values, thus eliminating the need to convert data to and from its SQL form. Document oriented databases also eliminates the need to retrieve objects as data rows. Query languages like XQuery can be used to retrieve data sets.

The only issue is we won't be able to create application independent queries for retrieving data without restrictions to access path. Also OODBMS limits the extent of processing SQL queries.
A Relational database allows concurrent access to data, locking, indexing (fast search), as well as many other features that are not available while using XML files.

Other OODBMS (such as RavenDB) provide replication to SQL databases, as a means of addressing the need for ad-hoc queries, while preserving the increased performance and reduced complexity that may be achieved with an OODBMS for an application that has well-known query patterns.

NonSQL databases don’t provide mechanism to maintain relationship between tables. In real life though, business objects or entities do have relationship among them. ORM solutions may allow you to define these relationships in business objects and handle their storage and retrieval behind the scene

=Comparison of ORM Features=

{|cellspacing="0" border="1"
!style="width:8%"|Features
!style="width:23%"|ActiveRecord
!style="width:23%"|Sequel
!style="width:23%"|DataMapper
!style="width:23%"|MyBatis
|-
! Databases 
| MySQL, PostgreSQL, SQLite, Oracle, SQLServer, and DB2
| ADO, DataObjects, DB2, DBI, Firebird, Informix, JDBC, MySQL, ODBC, OpenBase, Oracle, PostgreSQL and SQLite3
| SQLite, MySQL, PostgreSQL, Oracle, MongoDB, SimpleDB, many others, including CouchDB, Apache Solr, Google Data API
| MySQL, PostgreSQL, SQLite, Oracle, SQLServer, and DB2
|-
! Migrations 
| Yes
| Yes
| Yes, but optional
| Yes, provides migration by Mybatis schema migration system.
|-
! EagerLoading 
| Supported by scanning the SQL fragments
| Supported using eager (preloading) and eager_graph (joins)
| Strategic Eager Loading and by using :summary
| Yes.this can be enabled or disabled by setting the lazyLoadingEnabled flag
|-
! Flexible Overriding 
| No. Overriding is done using alias methods.
| Using methods and by calling 'super'
| Using methods
| No
|-
! Dynamic Finders 
| Yes. Uses 'Method Missing'
| No. Alternative is to use <Model>.FindOrCreate(:name=>"John")
| Yes. Using the dm_ar_finders plugin
| Similar feature is supported in the form of Dynamic SQL
|}

=Further Reading=
To get more information on ORM and the different type of ORM's available for Ruby , please look into the [http://wiki.expertiza.ncsu.edu/index.php/CSC/ECE_517_Spring_2013/ch1_1d_zk CSC/ECE 517 Spring 2013/ch1 1d zk] and [http://wiki.expertiza.ncsu.edu/index.php/CSC/ECE_517_Fall_2010/ch3_3f_ac Fall 2010 detailed ORM explanation] wiki pages.
# [http://www.cs.colorado.edu/~kena/classes/5448/f11/lectures/29-orm.pdf ORM - University of Colorado]
# [http://www.lynda.com/Ruby-Rails-tutorials/Understanding-ActiveRecord-ActiveRelation/139989/159093-4.html Active Record Tutorial]
# [http://digitalcommons.macalester.edu/context/mathcs_honors/article/1006/type/native/viewcontent/ Research papers on object relational mapping]
# [http://www.sitepoint.com/top-ruby-frameworks-rails-and-merb-join-forces/ Merb and Rails]

=Future Work=
More work can be done in the area of comparison between the different ORMs available for Ruby, especially a more detailed feature-by-feature comparison that includes performance differences between the ORMs.

=References =
# [http://en.wikipedia.org/wiki/Object-relational_mapping Object Relational Mapping]
# [http://en.wikipedia.org/wiki/Object-oriented_programming object-oriented programming]
# [http://en.wikipedia.org/wiki/Data_access data access]
# [http://en.wikipedia.org/wiki/Metaprogramming metaprogramming]
# [http://guides.rubyonrails.org/active_record_basics.html Active Record]
# [http://guides.rubyonrails.org/getting_started.html#the-mvc-architecture MVC]
# [http://sequel.jeremyevans.net/documentation.html Sequel]
# [http://datamapper.org/ DataMapper]
# [http://sequel.jeremyevans.net/rdoc/classes/Sequel/ThreadedConnectionPool.html Connection Pooling]
# [http://guides.rubyonrails.org/active_record_querying.html#eager-loading-associations Eager Loading]
# [http://rubydoc.info/gems/squeel/1.1.1/frames Squeel]
# [http://www.techopedia.com/definition/24200/object-relational-mapping--orm ORM]
# [http://en.wikipedia.org/wiki/Merb Merb]
# [http://www.merbivore.com/ Merb Website]
# [http://wiki.expertiza.ncsu.edu/index.php/CSC/ECE_517_Spring_2013/ch1_1d_zk Object Relational Mapping Spring 2013]

CSC/ECE 517 Fall 2014/ch1a 25 ks

2014-09-24T23:15:18Z

Knimgao: /* Advantages */

=Object Relational Mapping=

__TOC__

==Introduction==
[http://en.wikipedia.org/wiki/Object-relational_mapping Object Relational Mapping] (ORM, O/RM, and O/R mapping) in computer science is a programming technique for converting data between incompatible type systems in object-oriented programming languages. This creates, in effect, a "virtual object database" that can be used from within the programming language. There are both free and commercial packages available that perform object-relational mapping, although some programmers opt to create their own ORM tools.

==Overview==
Object Relational Mapping is a programming technique in which a metadata descriptor is used to connect object code to a relational database. ORM converts data between type systems that are unable to coexist within relational databases and OOP languages.

In [http://en.wikipedia.org/wiki/Object-oriented_programming object-oriented programming], data management tasks act on object-oriented (OO) objects that are almost always non-scalar values. For example, consider an address book entry that represents a single person along with zero or more phone numbers and zero or more addresses. This could be modeled in an object-oriented implementation by a "Person object" with attributes/fields to hold each data item that the entry comprises: the person's name, a list of phone numbers, and a list of addresses. The list of phone numbers would itself contain "PhoneNumber objects" and so on. The address book entry is treated as a single object by the programming language (it can be referenced by a single variable containing a pointer to the object, for instance). Various methods can be associated with the object, such as a method to return the preferred phone number, the home address, and so on.

The heart of the problem is translating the logical representation of the objects into an atomized form that is capable of being stored in the database, while preserving the properties of the objects and their relationships so that they can be reloaded as objects when needed. If this storage and retrieval functionality is implemented, the objects are said to be persistent.

==Simple Explanation==
A simple answer is that you wrap your tables or stored procedures in classes in your programming language, so that instead of writing SQL statements to interact with your database, you use methods and properties of objects.

In other words, instead of something like this:
<pre>
String sql = "SELECT ... FROM persons WHERE id = 10"
DbCommand cmd = new DbCommand(connection, sql);
Result res = cmd.Execute();
String name = res[0]["FIRST_NAME"];
</pre>
you do something like this:
<pre>
Person p = repository.GetPerson(10);
String name = p.FirstName;
</pre>
or similar code (lots of variations here.) Some frameworks also put a lot of the code in as static methods on the classes themselves, which means you could do something like this instead:
<pre>
Person p = Person.Get(10);
</pre>
Some also implement complex query systems, so you could do this:
<pre>
Person p = Person.Get(Person.Properties.Id == 10);
</pre>
The framework is what makes this code possible.

==Features==
Object-relational Mapping (ORM) frameworks unburden the designer of the complex translation between database and object space.

Typical ORM features:
* Automatic mapping from classes to database tables
** Class instance variables to database columns
** Class instances to table rows
* Aggregation and association relationships between mapped classes are managed
** Example, :has_many, :belongs_to associations in ActiveRecord
** Inheritance cases are mapped to tables
* Validation of data prior to table storage
* Class extensions to enable search, as well as creation, read, update, and deletion (CRUD) of instances/records
* Usually abstracts the database from program space in such a way that alternate database types can be easily chosen (SQLite, Oracle, etc)

The diagram below depicts a simple mapping of an object to a database table….

[[Image:3j_ks_pic1.jpg]]

ORM framework is used to persist model objects to a relational database and retrieve them, and the ORM framework will take care of converting the data between the two otherwise incompatible states. Most ORM tools rely heavily on metadata about both the database and objects, so that the objects need to know nothing about the database and the database doesn’t need to know anything about how the data is structured in the application. ORM provides a clean separation of concerns in a well-designed data application, and the database and application can each work with data in its native form. Database rows map to objects, thus making the program more easily accessible and allowing the usage of information in a way that is internally consistent and easy to understand. The ORM gives the programmer an ability to manipulate data with the programming language, instead of having to manipulate each attribute as its data type as obtained by the database management system.

When applied to Ruby, implementations of ORM often leverage the language’s [http://en.wikipedia.org/wiki/Metaprogramming metaprogramming] strengths to create intuitive application-specific methods and otherwise extend classes to support database functionality. With the addition of Rails, the ORM becomes much more important, as it is necessary to have an ORM to connect the models of the MVC (model-view-controller) stack used by Ruby on Rails with the application's database. Since the models are Ruby objects, the ORM allows modifications to the database to be done through changes to these models, independent of the type of database used.

With the release of Rails 3.0, the platform became ORM independent. With this change, it is much easier to use the ORM most preferred by the programmer, rather than being corralled into using one particular one. To allow this, the ORM needed to be extracted from the model and the database, to be a pure mediator between the two. Then any ORM can be used as long as it can successfully understand the model and the database used.

<ref>http://www.techopedia.com/definition/24200/object-relational-mapping--orm</ref>==Advantages ==
In addition to the [http://en.wikipedia.org/wiki/Data_access data access] technique, ORM's benefits also include:
*First of all, you hide the SQL away from your logic code. This has the benefit of allowing you to more easily support more database engines. For instance, MS SQL Server and Oracle has different names on typical functions, and different ways to do calculations with dates, so a query to "get me all persons edited the last 24 hours" might entail different SQL syntax just for those two database engines. This difference can be put away from your logic code.
*Additionally, you can focus on writing the logic, instead of getting all the SQL right. The code will typically be more readable as well, since it doesn't contain all the "plumbing" necessary to talk to the database.
*Simplified development because it automates object-to-table and table-to-object conversion, resulting in lower development and maintenance costs
*Less code compared to embedded SQL and handwritten stored procedures
*Transparent object caching in the application tier, improving system performance
*An optimized solution making an application faster and easier to maintain

==Disadvantages ==
*ORM’s emergence in multiple application development has created disagreement among experts. Key concerns are that ORM does not perform well and that stored procedures might be a better solution.
*In addition, ORM dependence may result in poorly-designed databases in certain circumstances.
*Performance – like every "proxy" technology
*Complexity – learning curve
*Difficulty / inability to make complex queries

=ORM Frameworks=

==Active Records==
[http://guides.rubyonrails.org/active_record_basics.html Active Record] was described by Martin Fowler in his book Patterns of Enterprise Application Architecture. Active Record is the M in [http://guides.rubyonrails.org/getting_started.html#the-mvc-architecture MVC]- the model - which is the layer of the system responsible for representing business data and logic. In Active Record, objects carry both persistent data and behavior which operates on that data. A database table or view is wrapped into a class and an object instance is tied to a single row in the table. Each Active Record object has CRUD (Create, Read, Update, and Delete) methods for database access. In addition, Active Record allows you to validate the state of a model before it gets written into the database.

Active Record gives us several mechanisms, the most important being the ability to:
* Represent models and their data.
* Represent associations between these models.
* Represent inheritance hierarchies through related models.
* Validate models before they get persisted to the database.
* Perform database operations in an object-oriented fashion.

The naming conventions used in Active Records are :
* Database Table - Plural with underscores separating words (e.g., book_clubs).
* Model Class - Singular with the first letter of each word capitalized (e.g., BookClub).

To create a table, ActiveRecord makes use of a migration class rather than including table definition in the actual class being modeled. As an example, the following code creates a table ‘’users’’ to store a collection of class ‘’User’’ objects:
<pre>
class CreateUsers < ActiveRecord::Migration
def self.up
create_table :users do |t|
t.string :name
t.string :email
t.string :age
t.references :cheer
t.references :post

t.timestamps # add creation and modification timestamps
end
end

def self.down # undo the table creation
drop_table :users
end
end
</pre>

The ActiveRecord’s migration scheme provides a means for backing out changes via the ‘’self.down’’ method. In addition, a table key ‘’id’’ is added to the new table without an explicit definition and record creation and modification timestamps are included via the ‘’timestamps’’ method provided by ActiveRecord.

ActiveRecord manages associations between table elements and provides the means to define such associations in the model definition. For example, the ‘’User’’ class shown below defines a ‘’has_many’’ (one-to-many) association with both the cheers and posts tables. These associations are represented in the migration class with the references operator. Also note ActiveRecord’s integrated support for validation of table information when attempting an update.

<pre>
class User < ActiveRecord::Base
has_many :cheers
has_many :posts

validates_presence_of :name
validates_presence_of :age
validates_uniqueness_of :name
validates_length_of :name, :within => 3..20
end
</pre>

To access the data in the table one calls the class function related to that column. For example, to find the user who's name is Bob, one would use @user = User.find_by_name('Bob'). Then one could find Bob's e-mail by using @user.email. Users can be searched for by any attribute in this way, as find methods are created for every combination of attributes.
While ActiveRecord provides the flexibility to create more sophisticated table relationships to represent class hierarchy, its base scheme is a single table inheritance, which trades some storage efficiency for simplicity in the database design. The following figure illustrates this concept of simplicity over efficiency.

[[Image:3j_ks_pic2.jpg]]

'''Pros''' -
* Integrated with popular Rails development framework
* Dynamically created database search methods (eg: User.find_by_address) ease db queries and make queries database syntax independent
* DB creation/management using the migrate scheme provides a means for backing out unwanted table changes
'''Cons''' -
* DB creation/management is decoupled from the model, requiring a separate utility (rake/migrate) that must be kept in sync with application.

==ORM Adaptor==
[https://github.com/ianwhite/orm_adapter ORM Adaptors] provide a single point of entry for popular ruby ORMs. Its target audience is gem authors who want to support more than one ORM.
ORM Adapter's goal is to support a minimum API used by most of the plugins that needs agnosticism beyond Active Model.
ORM Adapter will support only basic methods, as get, find_first, create! and so forth. It is not ORM Adapter's goal to support different query constructions, handle table joins, etc.
ORM adapter provides a consistent API for these basic class or 'factory' methods. It does not attempt to unify the behaviour of model instances returned by these methods. This means that unifying the behaviour of methods such as `model.save`, and `model.valid?` is beyond the scope of orm_adapter.
If you need complex queries, it is recommended to subclass ORM Adapters in your plugin and extend it expressing these query conditions as part of your domain logic.
<pre>
Example :
require 'orm_adapter'
User # is it an ActiveRecord, DM Resource, MongoMapper or MongoId Document?
User.to_adapter.find_first :name => 'Fred' # we don't care!
user_model = User.to_adapter
user_model.get!(1) # find a record by id
user_model.find_first(:name => 'fred') # find first fred
user_model.find_first(:level => 'awesome', :id => 23) # find user 23, only if it's level is awesome
user_model.find_all # find all users
user_model.find_all(:name => 'fred') # find all freds
user_model.find_all(:order => :name) # find all freds, ordered by name
user_model.create!(:name => 'fred') # create a fred
user_model.destroy(object) # destroy the user object
</pre>

==Sequel==
[http://sequel.jeremyevans.net/documentation.html Sequel] was originally developed by Sharon Rosner and the first release was in March 2007. It is based on the active record pattern. Sequel and Active Record share a lot of common features , for example association and inheritance. But Sequel handles these features in a much more flexible manner. Currently Sequel is at version 3.44.0. Initially Sequel had three core modules - sequel, sequel_core and sequel_model. Starting from version 1.4 , sequel and sequel_model were merged. Sequel handles validations using a validation plug-in and helpers.

<pre>
class CreateUser < Sequel::Migration
def up
create_table(:user) {
primary_key :id
String :name
String :age
String :email}
end
def down
drop_table(:user)
end
end # CreateUser.apply(DB, :up)
</pre>

Sequel supports associations and validations similar to Active Record. The following example shows how validations and associations can be enforced in the User table that has been created above. It enforces one to many relationships between the user table and the cheers and posts tables. It also validates for the presence , uniqueness and the length of the attribute '''name'''.

<pre>
class User < Sequel::Model
one_to_many :cheers
one_to_many :posts

validates_presence [:name, :age]
validates_unique(:name)
validates_length_range 3..20, :name
end
</pre>

To access the data in Sequel, one can use where clauses. For instance, to find Bob again one would use DB[:items].where(Sequel.like(:name, 'Bob'). While the ability to use SQL-like where clauses is quite flexible, it is not quite as pure an object-oriented approach as Active Record's dynamically created find methods.

Some of the key features of sequel are,
* [http://sequel.jeremyevans.net/rdoc/classes/Sequel/ThreadedConnectionPool.html Connection Pooling]
* Thread Safety
* [http://guides.rubyonrails.org/active_record_querying.html#eager-loading-associations Eager Loading] / Lazy Loading
* Model Caching
* Supports advanced database features such as prepared statements, bound variables, stored procedures, savepoints, two-phase commit, transaction isolation, master/slave configurations, and database sharding.

==Data Mapper==
[http://datamapper.org/ DataMapper] is an Object Relational Mapper written in Ruby developed by Sam Smoot with the goal to create an ORM which is fast, thread-safe and feature rich.
A Data Mapper is a Data Access Layer that performs bidirectional transfer of data between a persistent data store (often a relational database) and an in memory data representation (the domain layer). The goal of the pattern is to keep the in memory representation and the persistent data store independent of each other and the data mapper itself. The layer is composed of one or more mappers (or Data Access Objects), performing the data transfer.
DataMapper comes with the ability to use the same API to talk to a multitude of different datastores. There are adapters for the usual RDBMS suspects, NoSQL stores, various file formats and some web services. With DataMapper, you define your mappings in your model. Your data store can develop independently of your model using Migrations.

Some features of Data Mapper are as follows :
* No need to write structural migrations
* Scoped relations
* Lazy loading on certain attribute types
* Strategic eager loading to avoid (N+1) queries
* Default support for composite and natural keys
* Query chaining, and not evaluating the query until absolutely necessary (using a lazy array implementation)
* An API not too heavily oriented to SQL databases

DataMapper was designed to be a more abstract ORM, not strictly SQL, based on Martin Fowler's enterprise pattern. As a result, DataMapper adapters have been built for other non-SQL databases, such as CouchDB, [http://github.com/lritter/dm-solr-adapter/tree/master Apache Solr], and webservices such as [http://github.com/halorgium/dm-salesforce/tree/master Salesforce].

Example of table definition in the model:
<pre>
class User
include DataMapper::Resource

property :id, Serial # key
property :name, String, :required => true, :unique => true
property :age, String, :required => true, :length => 3..20
property :email, String

has n, :posts # one to many association
has n, :cheers # one to many association
end
</pre>

Notice that in the example above , ":required = true" is an example for Auto Validation. Unlike ActiveRecord and Sequel, DataMapper supports auto validations , i.e. these in turn call the validation helpers to enforce basic validations such as length, uniqueness, format, presence etc.

==MyBatis/iBatis==
[http://en.wikipedia.org/wiki/MyBatis MyBatis/iBatis] was a persistence framework which allowed easy access of the database from a Rails application without being a full ORM. It was created by the Apache Foundation in 2002, and is available for several platforms, including Ruby (the Ruby release is known as RBatis). On 6/16/2010, after releasing iBATIS 3.0, the project team moved from Apache to Google Code, changed the project's name to MyBatis, and stopped supporting Ruby.

The MyBatis data mapper framework makes it easier to use a relational database with object-oriented applications. MyBatis couples objects with stored procedures or SQL statements using a XML descriptor. To use the MyBatis data mapper,we make use of our own objects, XML, and SQL.

SQL statements are stored in XML files or annotations. Following is a MyBatis mapper, that consists of a Java interface with some MyBatis annotations:
<pre>
package org.mybatis.example;

public interface BlogMapper {
@Select("select * from Blog where id = #{id}")
Blog selectBlog(int id);
}
</pre>
The sentence is executed as follows.
<pre>
BlogMapper mapper = session.getMapper(BlogMapper.class);
Blog blog = mapper.selectBlog(101);
</pre>

It can also be executed using MyBatis API.
<pre>
Blog blog = session.selectOne("org.mybatis.example.BlogMapper.selectBlog", 101);
</pre>

SQL statements and mappings can also be externalized to an XML file like this.
<pre>
<?xml version="1.0" encoding="UTF-8" ?>
<!DOCTYPE mapper PUBLIC "-//mybatis.org//DTD Mapper 3.0//EN" "http://mybatis.org/dtd/mybatis-3-mapper.dtd">

<mapper namespace="org.mybatis.example.BlogMapper">
<select id="selectBlog" parameterType="int" resultType="Blog">
select * from Blog where id = #{id}
</select>
</mapper>
</pre>

==Squeel==
[http://rubydoc.info/gems/squeel/1.1.1/frames Squeel]unlocks the power of Arel in Rails applications with a handy block-based syntax. It is supporting in Rails 3 and 4. With Squeel, you can write subqueries, access named functions provided by RDMBS and more without writing SQL strings.
Squeel lets you write your Active Record queries with fewer strings, and more Ruby, by making the Arel awesomeness that lies beneath Active Record more accessible.

Squeel lets you rewrite...

<pre>
Article.where ['created_at >= ?', 2.weeks.ago]
...as...
Article.where{created_at >= 2.weeks.ago}
</pre>

Squeel enhances the normal Active Record query methods by enabling them to accept blocks. Inside a block, the Squeel query DSL can be used. Note the use of curly braces in the above example instead of parentheses. {} denotes a Squeel DSL query.

Stubs and keypaths are the two primary building blocks used in a Squeel DSL query.

Stubs are, for most intents and purposes, just like Symbols in a normal call to Relation#where (note the need for doubling up on the curly braces here, the first ones start the block, the second are the hash braces):
<pre>
Person.where{{name => ‘Ernie’ }}
</pre>

You normally wouldn't bother using the DSL in this case, as a simple hash would suffice. However, stubs serve as a building block for keypaths, and keypaths are very handy.

A Squeel keypath is essentially a more concise and readable alternative to a deeply nested hash. For instance, in standard Active Record, you might join several associations like this to perform a query:
<pre>
Person.joins(:articles => { :comments => :person}).references(:all)
</pre>

With a keypath, this would look like:
<pre>
Person.joins{articles.comments.person}.references(:all)
</pre>

The Squeel DSL works its magic using instance_eval which means that inside a Squeel DSL block, self isn't the same thing that it is outside the block.
This carries with it an important implication: Instance variables and instance methods inside the block won't refer to your object's variables/methods.
Use one of the following methods to get access to the object's methods and variables:
* Assign the variable locally before the DSL block, and access it as you would normally.
* Supply an arity to the DSL block, as in Person.where{|q| q.name == @my_name} Downside: You'll need to prefix stubs, keypaths, and functions with the DSL object.
* Wrap the method or instance variable inside the block with my{}. Person.where{name == my{some_method_to_return_a_name}}

==Merb==
[http://en.wikipedia.org/wiki/Merb Merb], short for "Mongrel+Erb", is a model view controller framework written in Ruby. Merb was merged into Rails web framework on December 23, 2008 as part of the Ruby on Rails 3.0 release.
Merb itself provides only the controller of an MVC model which can be extended to create a full-stack application environment. This effectively means Merb itself is not an ORM but can accommodate other ORMs.
Some features of Merb are as follows :
* Speed - Merb is ORM, JavaScript library and template language agnostic, preferring plugins that add support for features rather than producing a monolithic library with everything in the core.
* Lightweight - Rather than trying to cram every feature into a single code, things are kept bare minimum without sacrificing anything important.
* Powerful and extensible - For any features not covered in Merb’s core, there are plugins.
Some basic Command distinction between Ruby on Rails and Merb :
{| class="comparison" border="1"
! Action
! Ruby on Rails
! Merb
|-
| Create new application 'app1' || rails new app1 || merb-gen app app1
|-
| Start server || rails server || merb
|-
| Start cluster of 3 beginning at port 3000 || N/A || merb -p 3000 -c 3
|-
| Interactive console || rails console || merb -i
|}

=Alternative to ORM=
==NonSQL databases==
Instead of ORM we can also use Object-Oriented Database Management System (OODBMS) or document-oriented database like XML, where in databases are designed to store object oriented values, thus eliminating the need to convert data to and from its SQL form. Document oriented databases also eliminates the need to retrieve objects as data rows. Query languages like XQuery can be used to retrieve data sets.

The only issue is we won't be able to create application independent queries for retrieving data without restrictions to access path. Also OODBMS limits the extent of processing SQL queries.
A Relational database allows concurrent access to data, locking, indexing (fast search), as well as many other features that are not available while using XML files.

Other OODBMS (such as RavenDB) provide replication to SQL databases, as a means of addressing the need for ad-hoc queries, while preserving the increased performance and reduced complexity that may be achieved with an OODBMS for an application that has well-known query patterns.

NonSQL databases don’t provide mechanism to maintain relationship between tables. In real life though, business objects or entities do have relationship among them. ORM solutions may allow you to define these relationships in business objects and handle their storage and retrieval behind the scene

=Comparison of ORM Features=

{|cellspacing="0" border="1"
!style="width:8%"|Features
!style="width:23%"|ActiveRecord
!style="width:23%"|Sequel
!style="width:23%"|DataMapper
!style="width:23%"|MyBatis
|-
! Databases 
| MySQL, PostgreSQL, SQLite, Oracle, SQLServer, and DB2
| ADO, DataObjects, DB2, DBI, Firebird, Informix, JDBC, MySQL, ODBC, OpenBase, Oracle, PostgreSQL and SQLite3
| SQLite, MySQL, PostgreSQL, Oracle, MongoDB, SimpleDB, many others, including CouchDB, Apache Solr, Google Data API
| MySQL, PostgreSQL, SQLite, Oracle, SQLServer, and DB2
|-
! Migrations 
| Yes
| Yes
| Yes, but optional
| Yes, provides migration by Mybatis schema migration system.
|-
! EagerLoading 
| Supported by scanning the SQL fragments
| Supported using eager (preloading) and eager_graph (joins)
| Strategic Eager Loading and by using :summary
| Yes.this can be enabled or disabled by setting the lazyLoadingEnabled flag
|-
! Flexible Overriding 
| No. Overriding is done using alias methods.
| Using methods and by calling 'super'
| Using methods
| No
|-
! Dynamic Finders 
| Yes. Uses 'Method Missing'
| No. Alternative is to use <Model>.FindOrCreate(:name=>"John")
| Yes. Using the dm_ar_finders plugin
| Similar feature is supported in the form of Dynamic SQL
|}

=Further Reading=
To get more information on ORM and the different type of ORM's available for Ruby , please look into the [http://wiki.expertiza.ncsu.edu/index.php/CSC/ECE_517_Spring_2013/ch1_1d_zk CSC/ECE 517 Spring 2013/ch1 1d zk] and [http://wiki.expertiza.ncsu.edu/index.php/CSC/ECE_517_Fall_2010/ch3_3f_ac Fall 2010 detailed ORM explanation] wiki pages.
# [http://www.cs.colorado.edu/~kena/classes/5448/f11/lectures/29-orm.pdf ORM - University of Colorado]
# [http://www.lynda.com/Ruby-Rails-tutorials/Understanding-ActiveRecord-ActiveRelation/139989/159093-4.html Active Record Tutorial]
# [http://digitalcommons.macalester.edu/context/mathcs_honors/article/1006/type/native/viewcontent/ Research papers on object relational mapping]
# [http://www.sitepoint.com/top-ruby-frameworks-rails-and-merb-join-forces/ Merb and Rails]

=Future Work=
More work can be done in the area of comparison between the different ORMs available for Ruby, especially a more detailed feature-by-feature comparison that includes performance differences between the ORMs.

=References =
# [http://en.wikipedia.org/wiki/Object-relational_mapping Object Relational Mapping]
# [http://en.wikipedia.org/wiki/Object-oriented_programming object-oriented programming]
# [http://en.wikipedia.org/wiki/Data_access data access]
# [http://en.wikipedia.org/wiki/Metaprogramming metaprogramming]
# [http://guides.rubyonrails.org/active_record_basics.html Active Record]
# [http://guides.rubyonrails.org/getting_started.html#the-mvc-architecture MVC]
# [http://sequel.jeremyevans.net/documentation.html Sequel]
# [http://datamapper.org/ DataMapper]
# [http://sequel.jeremyevans.net/rdoc/classes/Sequel/ThreadedConnectionPool.html Connection Pooling]
# [http://guides.rubyonrails.org/active_record_querying.html#eager-loading-associations Eager Loading]
# [http://rubydoc.info/gems/squeel/1.1.1/frames Squeel]
# [http://www.techopedia.com/definition/24200/object-relational-mapping--orm ORM]
# [http://en.wikipedia.org/wiki/Merb Merb]
# [http://www.merbivore.com/ Merb Website]
# [http://wiki.expertiza.ncsu.edu/index.php/CSC/ECE_517_Spring_2013/ch1_1d_zk Object Relational Mapping Spring 2013]

CSC/ECE 517 Fall 2014/ch1a 25 ks

2014-09-24T23:05:30Z

Knimgao: /* Further Reading */

=Object Relational Mapping=

__TOC__

==Introduction==
[http://en.wikipedia.org/wiki/Object-relational_mapping Object Relational Mapping] (ORM, O/RM, and O/R mapping) in computer science is a programming technique for converting data between incompatible type systems in object-oriented programming languages. This creates, in effect, a "virtual object database" that can be used from within the programming language. There are both free and commercial packages available that perform object-relational mapping, although some programmers opt to create their own ORM tools.

==Overview==
Object Relational Mapping is a programming technique in which a metadata descriptor is used to connect object code to a relational database. ORM converts data between type systems that are unable to coexist within relational databases and OOP languages.

In [http://en.wikipedia.org/wiki/Object-oriented_programming object-oriented programming], data management tasks act on object-oriented (OO) objects that are almost always non-scalar values. For example, consider an address book entry that represents a single person along with zero or more phone numbers and zero or more addresses. This could be modeled in an object-oriented implementation by a "Person object" with attributes/fields to hold each data item that the entry comprises: the person's name, a list of phone numbers, and a list of addresses. The list of phone numbers would itself contain "PhoneNumber objects" and so on. The address book entry is treated as a single object by the programming language (it can be referenced by a single variable containing a pointer to the object, for instance). Various methods can be associated with the object, such as a method to return the preferred phone number, the home address, and so on.

The heart of the problem is translating the logical representation of the objects into an atomized form that is capable of being stored in the database, while preserving the properties of the objects and their relationships so that they can be reloaded as objects when needed. If this storage and retrieval functionality is implemented, the objects are said to be persistent.

==Simple Explanation==
A simple answer is that you wrap your tables or stored procedures in classes in your programming language, so that instead of writing SQL statements to interact with your database, you use methods and properties of objects.

In other words, instead of something like this:
<pre>
String sql = "SELECT ... FROM persons WHERE id = 10"
DbCommand cmd = new DbCommand(connection, sql);
Result res = cmd.Execute();
String name = res[0]["FIRST_NAME"];
</pre>
you do something like this:
<pre>
Person p = repository.GetPerson(10);
String name = p.FirstName;
</pre>
or similar code (lots of variations here.) Some frameworks also put a lot of the code in as static methods on the classes themselves, which means you could do something like this instead:
<pre>
Person p = Person.Get(10);
</pre>
Some also implement complex query systems, so you could do this:
<pre>
Person p = Person.Get(Person.Properties.Id == 10);
</pre>
The framework is what makes this code possible.

==Features==
Object-relational Mapping (ORM) frameworks unburden the designer of the complex translation between database and object space.

Typical ORM features:
* Automatic mapping from classes to database tables
** Class instance variables to database columns
** Class instances to table rows
* Aggregation and association relationships between mapped classes are managed
** Example, :has_many, :belongs_to associations in ActiveRecord
** Inheritance cases are mapped to tables
* Validation of data prior to table storage
* Class extensions to enable search, as well as creation, read, update, and deletion (CRUD) of instances/records
* Usually abstracts the database from program space in such a way that alternate database types can be easily chosen (SQLite, Oracle, etc)

The diagram below depicts a simple mapping of an object to a database table….

[[Image:3j_ks_pic1.jpg]]

ORM framework is used to persist model objects to a relational database and retrieve them, and the ORM framework will take care of converting the data between the two otherwise incompatible states. Most ORM tools rely heavily on metadata about both the database and objects, so that the objects need to know nothing about the database and the database doesn’t need to know anything about how the data is structured in the application. ORM provides a clean separation of concerns in a well-designed data application, and the database and application can each work with data in its native form. Database rows map to objects, thus making the program more easily accessible and allowing the usage of information in a way that is internally consistent and easy to understand. The ORM gives the programmer an ability to manipulate data with the programming language, instead of having to manipulate each attribute as its data type as obtained by the database management system.

When applied to Ruby, implementations of ORM often leverage the language’s [http://en.wikipedia.org/wiki/Metaprogramming metaprogramming] strengths to create intuitive application-specific methods and otherwise extend classes to support database functionality. With the addition of Rails, the ORM becomes much more important, as it is necessary to have an ORM to connect the models of the MVC (model-view-controller) stack used by Ruby on Rails with the application's database. Since the models are Ruby objects, the ORM allows modifications to the database to be done through changes to these models, independent of the type of database used.

With the release of Rails 3.0, the platform became ORM independent. With this change, it is much easier to use the ORM most preferred by the programmer, rather than being corralled into using one particular one. To allow this, the ORM needed to be extracted from the model and the database, to be a pure mediator between the two. Then any ORM can be used as long as it can successfully understand the model and the database used.

==Advantages ==
In addition to the [http://en.wikipedia.org/wiki/Data_access data access] technique, ORM's benefits also include:
*First of all, you hide the SQL away from your logic code. This has the benefit of allowing you to more easily support more database engines. For instance, MS SQL Server and Oracle has different names on typical functions, and different ways to do calculations with dates, so a query to "get me all persons edited the last 24 hours" might entail different SQL syntax just for those two database engines. This difference can be put away from your logic code.
*Additionally, you can focus on writing the logic, instead of getting all the SQL right. The code will typically be more readable as well, since it doesn't contain all the "plumbing" necessary to talk to the database.
*Simplified development because it automates object-to-table and table-to-object conversion, resulting in lower development and maintenance costs
*Less code compared to embedded SQL and handwritten stored procedures
*Transparent object caching in the application tier, improving system performance
*An optimized solution making an application faster and easier to maintain

==Disadvantages ==
*ORM’s emergence in multiple application development has created disagreement among experts. Key concerns are that ORM does not perform well and that stored procedures might be a better solution.
*In addition, ORM dependence may result in poorly-designed databases in certain circumstances.
*Performance – like every "proxy" technology
*Complexity – learning curve
*Difficulty / inability to make complex queries

=ORM Frameworks=

==Active Records==
[http://guides.rubyonrails.org/active_record_basics.html Active Record] was described by Martin Fowler in his book Patterns of Enterprise Application Architecture. Active Record is the M in [http://guides.rubyonrails.org/getting_started.html#the-mvc-architecture MVC]- the model - which is the layer of the system responsible for representing business data and logic. In Active Record, objects carry both persistent data and behavior which operates on that data. A database table or view is wrapped into a class and an object instance is tied to a single row in the table. Each Active Record object has CRUD (Create, Read, Update, and Delete) methods for database access. In addition, Active Record allows you to validate the state of a model before it gets written into the database.

Active Record gives us several mechanisms, the most important being the ability to:
* Represent models and their data.
* Represent associations between these models.
* Represent inheritance hierarchies through related models.
* Validate models before they get persisted to the database.
* Perform database operations in an object-oriented fashion.

The naming conventions used in Active Records are :
* Database Table - Plural with underscores separating words (e.g., book_clubs).
* Model Class - Singular with the first letter of each word capitalized (e.g., BookClub).

To create a table, ActiveRecord makes use of a migration class rather than including table definition in the actual class being modeled. As an example, the following code creates a table ‘’users’’ to store a collection of class ‘’User’’ objects:
<pre>
class CreateUsers < ActiveRecord::Migration
def self.up
create_table :users do |t|
t.string :name
t.string :email
t.string :age
t.references :cheer
t.references :post

t.timestamps # add creation and modification timestamps
end
end

def self.down # undo the table creation
drop_table :users
end
end
</pre>

The ActiveRecord’s migration scheme provides a means for backing out changes via the ‘’self.down’’ method. In addition, a table key ‘’id’’ is added to the new table without an explicit definition and record creation and modification timestamps are included via the ‘’timestamps’’ method provided by ActiveRecord.

ActiveRecord manages associations between table elements and provides the means to define such associations in the model definition. For example, the ‘’User’’ class shown below defines a ‘’has_many’’ (one-to-many) association with both the cheers and posts tables. These associations are represented in the migration class with the references operator. Also note ActiveRecord’s integrated support for validation of table information when attempting an update.

<pre>
class User < ActiveRecord::Base
has_many :cheers
has_many :posts

validates_presence_of :name
validates_presence_of :age
validates_uniqueness_of :name
validates_length_of :name, :within => 3..20
end
</pre>

To access the data in the table one calls the class function related to that column. For example, to find the user who's name is Bob, one would use @user = User.find_by_name('Bob'). Then one could find Bob's e-mail by using @user.email. Users can be searched for by any attribute in this way, as find methods are created for every combination of attributes.
While ActiveRecord provides the flexibility to create more sophisticated table relationships to represent class hierarchy, its base scheme is a single table inheritance, which trades some storage efficiency for simplicity in the database design. The following figure illustrates this concept of simplicity over efficiency.

[[Image:3j_ks_pic2.jpg]]

'''Pros''' -
* Integrated with popular Rails development framework
* Dynamically created database search methods (eg: User.find_by_address) ease db queries and make queries database syntax independent
* DB creation/management using the migrate scheme provides a means for backing out unwanted table changes
'''Cons''' -
* DB creation/management is decoupled from the model, requiring a separate utility (rake/migrate) that must be kept in sync with application.

==ORM Adaptor==
[https://github.com/ianwhite/orm_adapter ORM Adaptors] provide a single point of entry for popular ruby ORMs. Its target audience is gem authors who want to support more than one ORM.
ORM Adapter's goal is to support a minimum API used by most of the plugins that needs agnosticism beyond Active Model.
ORM Adapter will support only basic methods, as get, find_first, create! and so forth. It is not ORM Adapter's goal to support different query constructions, handle table joins, etc.
ORM adapter provides a consistent API for these basic class or 'factory' methods. It does not attempt to unify the behaviour of model instances returned by these methods. This means that unifying the behaviour of methods such as `model.save`, and `model.valid?` is beyond the scope of orm_adapter.
If you need complex queries, it is recommended to subclass ORM Adapters in your plugin and extend it expressing these query conditions as part of your domain logic.
<pre>
Example :
require 'orm_adapter'
User # is it an ActiveRecord, DM Resource, MongoMapper or MongoId Document?
User.to_adapter.find_first :name => 'Fred' # we don't care!
user_model = User.to_adapter
user_model.get!(1) # find a record by id
user_model.find_first(:name => 'fred') # find first fred
user_model.find_first(:level => 'awesome', :id => 23) # find user 23, only if it's level is awesome
user_model.find_all # find all users
user_model.find_all(:name => 'fred') # find all freds
user_model.find_all(:order => :name) # find all freds, ordered by name
user_model.create!(:name => 'fred') # create a fred
user_model.destroy(object) # destroy the user object
</pre>

==Sequel==
[http://sequel.jeremyevans.net/documentation.html Sequel] was originally developed by Sharon Rosner and the first release was in March 2007. It is based on the active record pattern. Sequel and Active Record share a lot of common features , for example association and inheritance. But Sequel handles these features in a much more flexible manner. Currently Sequel is at version 3.44.0. Initially Sequel had three core modules - sequel, sequel_core and sequel_model. Starting from version 1.4 , sequel and sequel_model were merged. Sequel handles validations using a validation plug-in and helpers.

<pre>
class CreateUser < Sequel::Migration
def up
create_table(:user) {
primary_key :id
String :name
String :age
String :email}
end
def down
drop_table(:user)
end
end # CreateUser.apply(DB, :up)
</pre>

Sequel supports associations and validations similar to Active Record. The following example shows how validations and associations can be enforced in the User table that has been created above. It enforces one to many relationships between the user table and the cheers and posts tables. It also validates for the presence , uniqueness and the length of the attribute '''name'''.

<pre>
class User < Sequel::Model
one_to_many :cheers
one_to_many :posts

validates_presence [:name, :age]
validates_unique(:name)
validates_length_range 3..20, :name
end
</pre>

To access the data in Sequel, one can use where clauses. For instance, to find Bob again one would use DB[:items].where(Sequel.like(:name, 'Bob'). While the ability to use SQL-like where clauses is quite flexible, it is not quite as pure an object-oriented approach as Active Record's dynamically created find methods.

Some of the key features of sequel are,
* [http://sequel.jeremyevans.net/rdoc/classes/Sequel/ThreadedConnectionPool.html Connection Pooling]
* Thread Safety
* [http://guides.rubyonrails.org/active_record_querying.html#eager-loading-associations Eager Loading] / Lazy Loading
* Model Caching
* Supports advanced database features such as prepared statements, bound variables, stored procedures, savepoints, two-phase commit, transaction isolation, master/slave configurations, and database sharding.

==Data Mapper==
[http://datamapper.org/ DataMapper] is an Object Relational Mapper written in Ruby developed by Sam Smoot with the goal to create an ORM which is fast, thread-safe and feature rich.
A Data Mapper is a Data Access Layer that performs bidirectional transfer of data between a persistent data store (often a relational database) and an in memory data representation (the domain layer). The goal of the pattern is to keep the in memory representation and the persistent data store independent of each other and the data mapper itself. The layer is composed of one or more mappers (or Data Access Objects), performing the data transfer.
DataMapper comes with the ability to use the same API to talk to a multitude of different datastores. There are adapters for the usual RDBMS suspects, NoSQL stores, various file formats and some web services. With DataMapper, you define your mappings in your model. Your data store can develop independently of your model using Migrations.

Some features of Data Mapper are as follows :
* No need to write structural migrations
* Scoped relations
* Lazy loading on certain attribute types
* Strategic eager loading to avoid (N+1) queries
* Default support for composite and natural keys
* Query chaining, and not evaluating the query until absolutely necessary (using a lazy array implementation)
* An API not too heavily oriented to SQL databases

DataMapper was designed to be a more abstract ORM, not strictly SQL, based on Martin Fowler's enterprise pattern. As a result, DataMapper adapters have been built for other non-SQL databases, such as CouchDB, [http://github.com/lritter/dm-solr-adapter/tree/master Apache Solr], and webservices such as [http://github.com/halorgium/dm-salesforce/tree/master Salesforce].

Example of table definition in the model:
<pre>
class User
include DataMapper::Resource

property :id, Serial # key
property :name, String, :required => true, :unique => true
property :age, String, :required => true, :length => 3..20
property :email, String

has n, :posts # one to many association
has n, :cheers # one to many association
end
</pre>

Notice that in the example above , ":required = true" is an example for Auto Validation. Unlike ActiveRecord and Sequel, DataMapper supports auto validations , i.e. these in turn call the validation helpers to enforce basic validations such as length, uniqueness, format, presence etc.

==MyBatis/iBatis==
[http://en.wikipedia.org/wiki/MyBatis MyBatis/iBatis] was a persistence framework which allowed easy access of the database from a Rails application without being a full ORM. It was created by the Apache Foundation in 2002, and is available for several platforms, including Ruby (the Ruby release is known as RBatis). On 6/16/2010, after releasing iBATIS 3.0, the project team moved from Apache to Google Code, changed the project's name to MyBatis, and stopped supporting Ruby.

The MyBatis data mapper framework makes it easier to use a relational database with object-oriented applications. MyBatis couples objects with stored procedures or SQL statements using a XML descriptor. To use the MyBatis data mapper,we make use of our own objects, XML, and SQL.

SQL statements are stored in XML files or annotations. Following is a MyBatis mapper, that consists of a Java interface with some MyBatis annotations:
<pre>
package org.mybatis.example;

public interface BlogMapper {
@Select("select * from Blog where id = #{id}")
Blog selectBlog(int id);
}
</pre>
The sentence is executed as follows.
<pre>
BlogMapper mapper = session.getMapper(BlogMapper.class);
Blog blog = mapper.selectBlog(101);
</pre>

It can also be executed using MyBatis API.
<pre>
Blog blog = session.selectOne("org.mybatis.example.BlogMapper.selectBlog", 101);
</pre>

SQL statements and mappings can also be externalized to an XML file like this.
<pre>
<?xml version="1.0" encoding="UTF-8" ?>
<!DOCTYPE mapper PUBLIC "-//mybatis.org//DTD Mapper 3.0//EN" "http://mybatis.org/dtd/mybatis-3-mapper.dtd">

<mapper namespace="org.mybatis.example.BlogMapper">
<select id="selectBlog" parameterType="int" resultType="Blog">
select * from Blog where id = #{id}
</select>
</mapper>
</pre>

==Squeel==
[http://rubydoc.info/gems/squeel/1.1.1/frames Squeel]unlocks the power of Arel in Rails applications with a handy block-based syntax. It is supporting in Rails 3 and 4. With Squeel, you can write subqueries, access named functions provided by RDMBS and more without writing SQL strings.
Squeel lets you write your Active Record queries with fewer strings, and more Ruby, by making the Arel awesomeness that lies beneath Active Record more accessible.

Squeel lets you rewrite...

<pre>
Article.where ['created_at >= ?', 2.weeks.ago]
...as...
Article.where{created_at >= 2.weeks.ago}
</pre>

Squeel enhances the normal Active Record query methods by enabling them to accept blocks. Inside a block, the Squeel query DSL can be used. Note the use of curly braces in the above example instead of parentheses. {} denotes a Squeel DSL query.

Stubs and keypaths are the two primary building blocks used in a Squeel DSL query.

Stubs are, for most intents and purposes, just like Symbols in a normal call to Relation#where (note the need for doubling up on the curly braces here, the first ones start the block, the second are the hash braces):
<pre>
Person.where{{name => ‘Ernie’ }}
</pre>

You normally wouldn't bother using the DSL in this case, as a simple hash would suffice. However, stubs serve as a building block for keypaths, and keypaths are very handy.

A Squeel keypath is essentially a more concise and readable alternative to a deeply nested hash. For instance, in standard Active Record, you might join several associations like this to perform a query:
<pre>
Person.joins(:articles => { :comments => :person}).references(:all)
</pre>

With a keypath, this would look like:
<pre>
Person.joins{articles.comments.person}.references(:all)
</pre>

The Squeel DSL works its magic using instance_eval which means that inside a Squeel DSL block, self isn't the same thing that it is outside the block.
This carries with it an important implication: Instance variables and instance methods inside the block won't refer to your object's variables/methods.
Use one of the following methods to get access to the object's methods and variables:
* Assign the variable locally before the DSL block, and access it as you would normally.
* Supply an arity to the DSL block, as in Person.where{|q| q.name == @my_name} Downside: You'll need to prefix stubs, keypaths, and functions with the DSL object.
* Wrap the method or instance variable inside the block with my{}. Person.where{name == my{some_method_to_return_a_name}}

==Merb==
[http://en.wikipedia.org/wiki/Merb Merb], short for "Mongrel+Erb", is a model view controller framework written in Ruby. Merb was merged into Rails web framework on December 23, 2008 as part of the Ruby on Rails 3.0 release.
Merb itself provides only the controller of an MVC model which can be extended to create a full-stack application environment. This effectively means Merb itself is not an ORM but can accommodate other ORMs.
Some features of Merb are as follows :
* Speed - Merb is ORM, JavaScript library and template language agnostic, preferring plugins that add support for features rather than producing a monolithic library with everything in the core.
* Lightweight - Rather than trying to cram every feature into a single code, things are kept bare minimum without sacrificing anything important.
* Powerful and extensible - For any features not covered in Merb’s core, there are plugins.
Some basic Command distinction between Ruby on Rails and Merb :
{| class="comparison" border="1"
! Action
! Ruby on Rails
! Merb
|-
| Create new application 'app1' || rails new app1 || merb-gen app app1
|-
| Start server || rails server || merb
|-
| Start cluster of 3 beginning at port 3000 || N/A || merb -p 3000 -c 3
|-
| Interactive console || rails console || merb -i
|}

=Alternative to ORM=
==NonSQL databases==
Instead of ORM we can also use Object-Oriented Database Management System (OODBMS) or document-oriented database like XML, where in databases are designed to store object oriented values, thus eliminating the need to convert data to and from its SQL form. Document oriented databases also eliminates the need to retrieve objects as data rows. Query languages like XQuery can be used to retrieve data sets.

The only issue is we won't be able to create application independent queries for retrieving data without restrictions to access path. Also OODBMS limits the extent of processing SQL queries.
A Relational database allows concurrent access to data, locking, indexing (fast search), as well as many other features that are not available while using XML files.

Other OODBMS (such as RavenDB) provide replication to SQL databases, as a means of addressing the need for ad-hoc queries, while preserving the increased performance and reduced complexity that may be achieved with an OODBMS for an application that has well-known query patterns.

NonSQL databases don’t provide mechanism to maintain relationship between tables. In real life though, business objects or entities do have relationship among them. ORM solutions may allow you to define these relationships in business objects and handle their storage and retrieval behind the scene

=Comparison of ORM Features=

{|cellspacing="0" border="1"
!style="width:8%"|Features
!style="width:23%"|ActiveRecord
!style="width:23%"|Sequel
!style="width:23%"|DataMapper
!style="width:23%"|MyBatis
|-
! Databases 
| MySQL, PostgreSQL, SQLite, Oracle, SQLServer, and DB2
| ADO, DataObjects, DB2, DBI, Firebird, Informix, JDBC, MySQL, ODBC, OpenBase, Oracle, PostgreSQL and SQLite3
| SQLite, MySQL, PostgreSQL, Oracle, MongoDB, SimpleDB, many others, including CouchDB, Apache Solr, Google Data API
| MySQL, PostgreSQL, SQLite, Oracle, SQLServer, and DB2
|-
! Migrations 
| Yes
| Yes
| Yes, but optional
| Yes, provides migration by Mybatis schema migration system.
|-
! EagerLoading 
| Supported by scanning the SQL fragments
| Supported using eager (preloading) and eager_graph (joins)
| Strategic Eager Loading and by using :summary
| Yes.this can be enabled or disabled by setting the lazyLoadingEnabled flag
|-
! Flexible Overriding 
| No. Overriding is done using alias methods.
| Using methods and by calling 'super'
| Using methods
| No
|-
! Dynamic Finders 
| Yes. Uses 'Method Missing'
| No. Alternative is to use <Model>.FindOrCreate(:name=>"John")
| Yes. Using the dm_ar_finders plugin
| Similar feature is supported in the form of Dynamic SQL
|}

=Further Reading=
To get more information on ORM and the different type of ORM's available for Ruby , please look into the [http://wiki.expertiza.ncsu.edu/index.php/CSC/ECE_517_Spring_2013/ch1_1d_zk CSC/ECE 517 Spring 2013/ch1 1d zk] and [http://wiki.expertiza.ncsu.edu/index.php/CSC/ECE_517_Fall_2010/ch3_3f_ac Fall 2010 detailed ORM explanation] wiki pages.
# [http://www.cs.colorado.edu/~kena/classes/5448/f11/lectures/29-orm.pdf ORM - University of Colorado]
# [http://www.lynda.com/Ruby-Rails-tutorials/Understanding-ActiveRecord-ActiveRelation/139989/159093-4.html Active Record Tutorial]
# [http://digitalcommons.macalester.edu/context/mathcs_honors/article/1006/type/native/viewcontent/ Research papers on object relational mapping]
# [http://www.sitepoint.com/top-ruby-frameworks-rails-and-merb-join-forces/ Merb and Rails]

=Future Work=
More work can be done in the area of comparison between the different ORMs available for Ruby, especially a more detailed feature-by-feature comparison that includes performance differences between the ORMs.

=References =
# [http://en.wikipedia.org/wiki/Object-relational_mapping Object Relational Mapping]
# [http://en.wikipedia.org/wiki/Object-oriented_programming object-oriented programming]
# [http://en.wikipedia.org/wiki/Data_access data access]
# [http://en.wikipedia.org/wiki/Metaprogramming metaprogramming]
# [http://guides.rubyonrails.org/active_record_basics.html Active Record]
# [http://guides.rubyonrails.org/getting_started.html#the-mvc-architecture MVC]
# [http://sequel.jeremyevans.net/documentation.html Sequel]
# [http://datamapper.org/ DataMapper]
# [http://sequel.jeremyevans.net/rdoc/classes/Sequel/ThreadedConnectionPool.html Connection Pooling]
# [http://guides.rubyonrails.org/active_record_querying.html#eager-loading-associations Eager Loading]
# [http://rubydoc.info/gems/squeel/1.1.1/frames Squeel]
# [http://www.techopedia.com/definition/24200/object-relational-mapping--orm ORM]
# [http://en.wikipedia.org/wiki/Merb Merb]
# [http://www.merbivore.com/ Merb Website]
# [http://wiki.expertiza.ncsu.edu/index.php/CSC/ECE_517_Spring_2013/ch1_1d_zk Object Relational Mapping Spring 2013]

CSC/ECE 517 Fall 2014/ch1a 25 ks

2014-09-24T23:05:19Z

Knimgao: /* Further Reading */

=Object Relational Mapping=

__TOC__

==Introduction==
[http://en.wikipedia.org/wiki/Object-relational_mapping Object Relational Mapping] (ORM, O/RM, and O/R mapping) in computer science is a programming technique for converting data between incompatible type systems in object-oriented programming languages. This creates, in effect, a "virtual object database" that can be used from within the programming language. There are both free and commercial packages available that perform object-relational mapping, although some programmers opt to create their own ORM tools.

==Overview==
Object Relational Mapping is a programming technique in which a metadata descriptor is used to connect object code to a relational database. ORM converts data between type systems that are unable to coexist within relational databases and OOP languages.

In [http://en.wikipedia.org/wiki/Object-oriented_programming object-oriented programming], data management tasks act on object-oriented (OO) objects that are almost always non-scalar values. For example, consider an address book entry that represents a single person along with zero or more phone numbers and zero or more addresses. This could be modeled in an object-oriented implementation by a "Person object" with attributes/fields to hold each data item that the entry comprises: the person's name, a list of phone numbers, and a list of addresses. The list of phone numbers would itself contain "PhoneNumber objects" and so on. The address book entry is treated as a single object by the programming language (it can be referenced by a single variable containing a pointer to the object, for instance). Various methods can be associated with the object, such as a method to return the preferred phone number, the home address, and so on.

The heart of the problem is translating the logical representation of the objects into an atomized form that is capable of being stored in the database, while preserving the properties of the objects and their relationships so that they can be reloaded as objects when needed. If this storage and retrieval functionality is implemented, the objects are said to be persistent.

==Simple Explanation==
A simple answer is that you wrap your tables or stored procedures in classes in your programming language, so that instead of writing SQL statements to interact with your database, you use methods and properties of objects.

In other words, instead of something like this:
<pre>
String sql = "SELECT ... FROM persons WHERE id = 10"
DbCommand cmd = new DbCommand(connection, sql);
Result res = cmd.Execute();
String name = res[0]["FIRST_NAME"];
</pre>
you do something like this:
<pre>
Person p = repository.GetPerson(10);
String name = p.FirstName;
</pre>
or similar code (lots of variations here.) Some frameworks also put a lot of the code in as static methods on the classes themselves, which means you could do something like this instead:
<pre>
Person p = Person.Get(10);
</pre>
Some also implement complex query systems, so you could do this:
<pre>
Person p = Person.Get(Person.Properties.Id == 10);
</pre>
The framework is what makes this code possible.

==Features==
Object-relational Mapping (ORM) frameworks unburden the designer of the complex translation between database and object space.

Typical ORM features:
* Automatic mapping from classes to database tables
** Class instance variables to database columns
** Class instances to table rows
* Aggregation and association relationships between mapped classes are managed
** Example, :has_many, :belongs_to associations in ActiveRecord
** Inheritance cases are mapped to tables
* Validation of data prior to table storage
* Class extensions to enable search, as well as creation, read, update, and deletion (CRUD) of instances/records
* Usually abstracts the database from program space in such a way that alternate database types can be easily chosen (SQLite, Oracle, etc)

The diagram below depicts a simple mapping of an object to a database table….

[[Image:3j_ks_pic1.jpg]]

ORM framework is used to persist model objects to a relational database and retrieve them, and the ORM framework will take care of converting the data between the two otherwise incompatible states. Most ORM tools rely heavily on metadata about both the database and objects, so that the objects need to know nothing about the database and the database doesn’t need to know anything about how the data is structured in the application. ORM provides a clean separation of concerns in a well-designed data application, and the database and application can each work with data in its native form. Database rows map to objects, thus making the program more easily accessible and allowing the usage of information in a way that is internally consistent and easy to understand. The ORM gives the programmer an ability to manipulate data with the programming language, instead of having to manipulate each attribute as its data type as obtained by the database management system.

When applied to Ruby, implementations of ORM often leverage the language’s [http://en.wikipedia.org/wiki/Metaprogramming metaprogramming] strengths to create intuitive application-specific methods and otherwise extend classes to support database functionality. With the addition of Rails, the ORM becomes much more important, as it is necessary to have an ORM to connect the models of the MVC (model-view-controller) stack used by Ruby on Rails with the application's database. Since the models are Ruby objects, the ORM allows modifications to the database to be done through changes to these models, independent of the type of database used.

With the release of Rails 3.0, the platform became ORM independent. With this change, it is much easier to use the ORM most preferred by the programmer, rather than being corralled into using one particular one. To allow this, the ORM needed to be extracted from the model and the database, to be a pure mediator between the two. Then any ORM can be used as long as it can successfully understand the model and the database used.

==Advantages ==
In addition to the [http://en.wikipedia.org/wiki/Data_access data access] technique, ORM's benefits also include:
*First of all, you hide the SQL away from your logic code. This has the benefit of allowing you to more easily support more database engines. For instance, MS SQL Server and Oracle has different names on typical functions, and different ways to do calculations with dates, so a query to "get me all persons edited the last 24 hours" might entail different SQL syntax just for those two database engines. This difference can be put away from your logic code.
*Additionally, you can focus on writing the logic, instead of getting all the SQL right. The code will typically be more readable as well, since it doesn't contain all the "plumbing" necessary to talk to the database.
*Simplified development because it automates object-to-table and table-to-object conversion, resulting in lower development and maintenance costs
*Less code compared to embedded SQL and handwritten stored procedures
*Transparent object caching in the application tier, improving system performance
*An optimized solution making an application faster and easier to maintain

==Disadvantages ==
*ORM’s emergence in multiple application development has created disagreement among experts. Key concerns are that ORM does not perform well and that stored procedures might be a better solution.
*In addition, ORM dependence may result in poorly-designed databases in certain circumstances.
*Performance – like every "proxy" technology
*Complexity – learning curve
*Difficulty / inability to make complex queries

=ORM Frameworks=

==Active Records==
[http://guides.rubyonrails.org/active_record_basics.html Active Record] was described by Martin Fowler in his book Patterns of Enterprise Application Architecture. Active Record is the M in [http://guides.rubyonrails.org/getting_started.html#the-mvc-architecture MVC]- the model - which is the layer of the system responsible for representing business data and logic. In Active Record, objects carry both persistent data and behavior which operates on that data. A database table or view is wrapped into a class and an object instance is tied to a single row in the table. Each Active Record object has CRUD (Create, Read, Update, and Delete) methods for database access. In addition, Active Record allows you to validate the state of a model before it gets written into the database.

Active Record gives us several mechanisms, the most important being the ability to:
* Represent models and their data.
* Represent associations between these models.
* Represent inheritance hierarchies through related models.
* Validate models before they get persisted to the database.
* Perform database operations in an object-oriented fashion.

The naming conventions used in Active Records are :
* Database Table - Plural with underscores separating words (e.g., book_clubs).
* Model Class - Singular with the first letter of each word capitalized (e.g., BookClub).

To create a table, ActiveRecord makes use of a migration class rather than including table definition in the actual class being modeled. As an example, the following code creates a table ‘’users’’ to store a collection of class ‘’User’’ objects:
<pre>
class CreateUsers < ActiveRecord::Migration
def self.up
create_table :users do |t|
t.string :name
t.string :email
t.string :age
t.references :cheer
t.references :post

t.timestamps # add creation and modification timestamps
end
end

def self.down # undo the table creation
drop_table :users
end
end
</pre>

The ActiveRecord’s migration scheme provides a means for backing out changes via the ‘’self.down’’ method. In addition, a table key ‘’id’’ is added to the new table without an explicit definition and record creation and modification timestamps are included via the ‘’timestamps’’ method provided by ActiveRecord.

ActiveRecord manages associations between table elements and provides the means to define such associations in the model definition. For example, the ‘’User’’ class shown below defines a ‘’has_many’’ (one-to-many) association with both the cheers and posts tables. These associations are represented in the migration class with the references operator. Also note ActiveRecord’s integrated support for validation of table information when attempting an update.

<pre>
class User < ActiveRecord::Base
has_many :cheers
has_many :posts

validates_presence_of :name
validates_presence_of :age
validates_uniqueness_of :name
validates_length_of :name, :within => 3..20
end
</pre>

To access the data in the table one calls the class function related to that column. For example, to find the user who's name is Bob, one would use @user = User.find_by_name('Bob'). Then one could find Bob's e-mail by using @user.email. Users can be searched for by any attribute in this way, as find methods are created for every combination of attributes.
While ActiveRecord provides the flexibility to create more sophisticated table relationships to represent class hierarchy, its base scheme is a single table inheritance, which trades some storage efficiency for simplicity in the database design. The following figure illustrates this concept of simplicity over efficiency.

[[Image:3j_ks_pic2.jpg]]

'''Pros''' -
* Integrated with popular Rails development framework
* Dynamically created database search methods (eg: User.find_by_address) ease db queries and make queries database syntax independent
* DB creation/management using the migrate scheme provides a means for backing out unwanted table changes
'''Cons''' -
* DB creation/management is decoupled from the model, requiring a separate utility (rake/migrate) that must be kept in sync with application.

==ORM Adaptor==
[https://github.com/ianwhite/orm_adapter ORM Adaptors] provide a single point of entry for popular ruby ORMs. Its target audience is gem authors who want to support more than one ORM.
ORM Adapter's goal is to support a minimum API used by most of the plugins that needs agnosticism beyond Active Model.
ORM Adapter will support only basic methods, as get, find_first, create! and so forth. It is not ORM Adapter's goal to support different query constructions, handle table joins, etc.
ORM adapter provides a consistent API for these basic class or 'factory' methods. It does not attempt to unify the behaviour of model instances returned by these methods. This means that unifying the behaviour of methods such as `model.save`, and `model.valid?` is beyond the scope of orm_adapter.
If you need complex queries, it is recommended to subclass ORM Adapters in your plugin and extend it expressing these query conditions as part of your domain logic.
<pre>
Example :
require 'orm_adapter'
User # is it an ActiveRecord, DM Resource, MongoMapper or MongoId Document?
User.to_adapter.find_first :name => 'Fred' # we don't care!
user_model = User.to_adapter
user_model.get!(1) # find a record by id
user_model.find_first(:name => 'fred') # find first fred
user_model.find_first(:level => 'awesome', :id => 23) # find user 23, only if it's level is awesome
user_model.find_all # find all users
user_model.find_all(:name => 'fred') # find all freds
user_model.find_all(:order => :name) # find all freds, ordered by name
user_model.create!(:name => 'fred') # create a fred
user_model.destroy(object) # destroy the user object
</pre>

==Sequel==
[http://sequel.jeremyevans.net/documentation.html Sequel] was originally developed by Sharon Rosner and the first release was in March 2007. It is based on the active record pattern. Sequel and Active Record share a lot of common features , for example association and inheritance. But Sequel handles these features in a much more flexible manner. Currently Sequel is at version 3.44.0. Initially Sequel had three core modules - sequel, sequel_core and sequel_model. Starting from version 1.4 , sequel and sequel_model were merged. Sequel handles validations using a validation plug-in and helpers.

<pre>
class CreateUser < Sequel::Migration
def up
create_table(:user) {
primary_key :id
String :name
String :age
String :email}
end
def down
drop_table(:user)
end
end # CreateUser.apply(DB, :up)
</pre>

Sequel supports associations and validations similar to Active Record. The following example shows how validations and associations can be enforced in the User table that has been created above. It enforces one to many relationships between the user table and the cheers and posts tables. It also validates for the presence , uniqueness and the length of the attribute '''name'''.

<pre>
class User < Sequel::Model
one_to_many :cheers
one_to_many :posts

validates_presence [:name, :age]
validates_unique(:name)
validates_length_range 3..20, :name
end
</pre>

To access the data in Sequel, one can use where clauses. For instance, to find Bob again one would use DB[:items].where(Sequel.like(:name, 'Bob'). While the ability to use SQL-like where clauses is quite flexible, it is not quite as pure an object-oriented approach as Active Record's dynamically created find methods.

Some of the key features of sequel are,
* [http://sequel.jeremyevans.net/rdoc/classes/Sequel/ThreadedConnectionPool.html Connection Pooling]
* Thread Safety
* [http://guides.rubyonrails.org/active_record_querying.html#eager-loading-associations Eager Loading] / Lazy Loading
* Model Caching
* Supports advanced database features such as prepared statements, bound variables, stored procedures, savepoints, two-phase commit, transaction isolation, master/slave configurations, and database sharding.

==Data Mapper==
[http://datamapper.org/ DataMapper] is an Object Relational Mapper written in Ruby developed by Sam Smoot with the goal to create an ORM which is fast, thread-safe and feature rich.
A Data Mapper is a Data Access Layer that performs bidirectional transfer of data between a persistent data store (often a relational database) and an in memory data representation (the domain layer). The goal of the pattern is to keep the in memory representation and the persistent data store independent of each other and the data mapper itself. The layer is composed of one or more mappers (or Data Access Objects), performing the data transfer.
DataMapper comes with the ability to use the same API to talk to a multitude of different datastores. There are adapters for the usual RDBMS suspects, NoSQL stores, various file formats and some web services. With DataMapper, you define your mappings in your model. Your data store can develop independently of your model using Migrations.

Some features of Data Mapper are as follows :
* No need to write structural migrations
* Scoped relations
* Lazy loading on certain attribute types
* Strategic eager loading to avoid (N+1) queries
* Default support for composite and natural keys
* Query chaining, and not evaluating the query until absolutely necessary (using a lazy array implementation)
* An API not too heavily oriented to SQL databases

DataMapper was designed to be a more abstract ORM, not strictly SQL, based on Martin Fowler's enterprise pattern. As a result, DataMapper adapters have been built for other non-SQL databases, such as CouchDB, [http://github.com/lritter/dm-solr-adapter/tree/master Apache Solr], and webservices such as [http://github.com/halorgium/dm-salesforce/tree/master Salesforce].

Example of table definition in the model:
<pre>
class User
include DataMapper::Resource

property :id, Serial # key
property :name, String, :required => true, :unique => true
property :age, String, :required => true, :length => 3..20
property :email, String

has n, :posts # one to many association
has n, :cheers # one to many association
end
</pre>

Notice that in the example above , ":required = true" is an example for Auto Validation. Unlike ActiveRecord and Sequel, DataMapper supports auto validations , i.e. these in turn call the validation helpers to enforce basic validations such as length, uniqueness, format, presence etc.

==MyBatis/iBatis==
[http://en.wikipedia.org/wiki/MyBatis MyBatis/iBatis] was a persistence framework which allowed easy access of the database from a Rails application without being a full ORM. It was created by the Apache Foundation in 2002, and is available for several platforms, including Ruby (the Ruby release is known as RBatis). On 6/16/2010, after releasing iBATIS 3.0, the project team moved from Apache to Google Code, changed the project's name to MyBatis, and stopped supporting Ruby.

The MyBatis data mapper framework makes it easier to use a relational database with object-oriented applications. MyBatis couples objects with stored procedures or SQL statements using a XML descriptor. To use the MyBatis data mapper,we make use of our own objects, XML, and SQL.

SQL statements are stored in XML files or annotations. Following is a MyBatis mapper, that consists of a Java interface with some MyBatis annotations:
<pre>
package org.mybatis.example;

public interface BlogMapper {
@Select("select * from Blog where id = #{id}")
Blog selectBlog(int id);
}
</pre>
The sentence is executed as follows.
<pre>
BlogMapper mapper = session.getMapper(BlogMapper.class);
Blog blog = mapper.selectBlog(101);
</pre>

It can also be executed using MyBatis API.
<pre>
Blog blog = session.selectOne("org.mybatis.example.BlogMapper.selectBlog", 101);
</pre>

SQL statements and mappings can also be externalized to an XML file like this.
<pre>
<?xml version="1.0" encoding="UTF-8" ?>
<!DOCTYPE mapper PUBLIC "-//mybatis.org//DTD Mapper 3.0//EN" "http://mybatis.org/dtd/mybatis-3-mapper.dtd">

<mapper namespace="org.mybatis.example.BlogMapper">
<select id="selectBlog" parameterType="int" resultType="Blog">
select * from Blog where id = #{id}
</select>
</mapper>
</pre>

==Squeel==
[http://rubydoc.info/gems/squeel/1.1.1/frames Squeel]unlocks the power of Arel in Rails applications with a handy block-based syntax. It is supporting in Rails 3 and 4. With Squeel, you can write subqueries, access named functions provided by RDMBS and more without writing SQL strings.
Squeel lets you write your Active Record queries with fewer strings, and more Ruby, by making the Arel awesomeness that lies beneath Active Record more accessible.

Squeel lets you rewrite...

<pre>
Article.where ['created_at >= ?', 2.weeks.ago]
...as...
Article.where{created_at >= 2.weeks.ago}
</pre>

Squeel enhances the normal Active Record query methods by enabling them to accept blocks. Inside a block, the Squeel query DSL can be used. Note the use of curly braces in the above example instead of parentheses. {} denotes a Squeel DSL query.

Stubs and keypaths are the two primary building blocks used in a Squeel DSL query.

Stubs are, for most intents and purposes, just like Symbols in a normal call to Relation#where (note the need for doubling up on the curly braces here, the first ones start the block, the second are the hash braces):
<pre>
Person.where{{name => ‘Ernie’ }}
</pre>

You normally wouldn't bother using the DSL in this case, as a simple hash would suffice. However, stubs serve as a building block for keypaths, and keypaths are very handy.

A Squeel keypath is essentially a more concise and readable alternative to a deeply nested hash. For instance, in standard Active Record, you might join several associations like this to perform a query:
<pre>
Person.joins(:articles => { :comments => :person}).references(:all)
</pre>

With a keypath, this would look like:
<pre>
Person.joins{articles.comments.person}.references(:all)
</pre>

The Squeel DSL works its magic using instance_eval which means that inside a Squeel DSL block, self isn't the same thing that it is outside the block.
This carries with it an important implication: Instance variables and instance methods inside the block won't refer to your object's variables/methods.
Use one of the following methods to get access to the object's methods and variables:
* Assign the variable locally before the DSL block, and access it as you would normally.
* Supply an arity to the DSL block, as in Person.where{|q| q.name == @my_name} Downside: You'll need to prefix stubs, keypaths, and functions with the DSL object.
* Wrap the method or instance variable inside the block with my{}. Person.where{name == my{some_method_to_return_a_name}}

==Merb==
[http://en.wikipedia.org/wiki/Merb Merb], short for "Mongrel+Erb", is a model view controller framework written in Ruby. Merb was merged into Rails web framework on December 23, 2008 as part of the Ruby on Rails 3.0 release.
Merb itself provides only the controller of an MVC model which can be extended to create a full-stack application environment. This effectively means Merb itself is not an ORM but can accommodate other ORMs.
Some features of Merb are as follows :
* Speed - Merb is ORM, JavaScript library and template language agnostic, preferring plugins that add support for features rather than producing a monolithic library with everything in the core.
* Lightweight - Rather than trying to cram every feature into a single code, things are kept bare minimum without sacrificing anything important.
* Powerful and extensible - For any features not covered in Merb’s core, there are plugins.
Some basic Command distinction between Ruby on Rails and Merb :
{| class="comparison" border="1"
! Action
! Ruby on Rails
! Merb
|-
| Create new application 'app1' || rails new app1 || merb-gen app app1
|-
| Start server || rails server || merb
|-
| Start cluster of 3 beginning at port 3000 || N/A || merb -p 3000 -c 3
|-
| Interactive console || rails console || merb -i
|}

=Alternative to ORM=
==NonSQL databases==
Instead of ORM we can also use Object-Oriented Database Management System (OODBMS) or document-oriented database like XML, where in databases are designed to store object oriented values, thus eliminating the need to convert data to and from its SQL form. Document oriented databases also eliminates the need to retrieve objects as data rows. Query languages like XQuery can be used to retrieve data sets.

The only issue is we won't be able to create application independent queries for retrieving data without restrictions to access path. Also OODBMS limits the extent of processing SQL queries.
A Relational database allows concurrent access to data, locking, indexing (fast search), as well as many other features that are not available while using XML files.

Other OODBMS (such as RavenDB) provide replication to SQL databases, as a means of addressing the need for ad-hoc queries, while preserving the increased performance and reduced complexity that may be achieved with an OODBMS for an application that has well-known query patterns.

NonSQL databases don’t provide mechanism to maintain relationship between tables. In real life though, business objects or entities do have relationship among them. ORM solutions may allow you to define these relationships in business objects and handle their storage and retrieval behind the scene

=Comparison of ORM Features=

{|cellspacing="0" border="1"
!style="width:8%"|Features
!style="width:23%"|ActiveRecord
!style="width:23%"|Sequel
!style="width:23%"|DataMapper
!style="width:23%"|MyBatis
|-
! Databases 
| MySQL, PostgreSQL, SQLite, Oracle, SQLServer, and DB2
| ADO, DataObjects, DB2, DBI, Firebird, Informix, JDBC, MySQL, ODBC, OpenBase, Oracle, PostgreSQL and SQLite3
| SQLite, MySQL, PostgreSQL, Oracle, MongoDB, SimpleDB, many others, including CouchDB, Apache Solr, Google Data API
| MySQL, PostgreSQL, SQLite, Oracle, SQLServer, and DB2
|-
! Migrations 
| Yes
| Yes
| Yes, but optional
| Yes, provides migration by Mybatis schema migration system.
|-
! EagerLoading 
| Supported by scanning the SQL fragments
| Supported using eager (preloading) and eager_graph (joins)
| Strategic Eager Loading and by using :summary
| Yes.this can be enabled or disabled by setting the lazyLoadingEnabled flag
|-
! Flexible Overriding 
| No. Overriding is done using alias methods.
| Using methods and by calling 'super'
| Using methods
| No
|-
! Dynamic Finders 
| Yes. Uses 'Method Missing'
| No. Alternative is to use <Model>.FindOrCreate(:name=>"John")
| Yes. Using the dm_ar_finders plugin
| Similar feature is supported in the form of Dynamic SQL
|}

=Further Reading=
To get more information on ORM and the different type of ORM's available for Ruby , please look into the [http://wiki.expertiza.ncsu.edu/index.php/CSC/ECE_517_Spring_2013/ch1_1d_zk CSC/ECE 517 Spring 2013/ch1 1d zk] and [http://wiki.expertiza.ncsu.edu/index.php/CSC/ECE_517_Fall_2010/ch3_3f_ac Fall 2010 detailed ORM explanation] wiki pages.
# [http://www.cs.colorado.edu/~kena/classes/5448/f11/lectures/29-orm.pdf ORM - University of Colorado]
# [http://www.lynda.com/Ruby-Rails-tutorials/Understanding-ActiveRecord-ActiveRelation/139989/159093-4.html Active Record Tutorial]
# [http://digitalcommons.macalester.edu/context/mathcs_honors/article/1006/type/native/viewcontent/ Research papers on object relational mapping]
# [http://www.sitepoint.com/top-ruby-frameworks-rails-and-merb-join-forces/ Merb and Rails

=Future Work=
More work can be done in the area of comparison between the different ORMs available for Ruby, especially a more detailed feature-by-feature comparison that includes performance differences between the ORMs.

=References =
# [http://en.wikipedia.org/wiki/Object-relational_mapping Object Relational Mapping]
# [http://en.wikipedia.org/wiki/Object-oriented_programming object-oriented programming]
# [http://en.wikipedia.org/wiki/Data_access data access]
# [http://en.wikipedia.org/wiki/Metaprogramming metaprogramming]
# [http://guides.rubyonrails.org/active_record_basics.html Active Record]
# [http://guides.rubyonrails.org/getting_started.html#the-mvc-architecture MVC]
# [http://sequel.jeremyevans.net/documentation.html Sequel]
# [http://datamapper.org/ DataMapper]
# [http://sequel.jeremyevans.net/rdoc/classes/Sequel/ThreadedConnectionPool.html Connection Pooling]
# [http://guides.rubyonrails.org/active_record_querying.html#eager-loading-associations Eager Loading]
# [http://rubydoc.info/gems/squeel/1.1.1/frames Squeel]
# [http://www.techopedia.com/definition/24200/object-relational-mapping--orm ORM]
# [http://en.wikipedia.org/wiki/Merb Merb]
# [http://www.merbivore.com/ Merb Website]
# [http://wiki.expertiza.ncsu.edu/index.php/CSC/ECE_517_Spring_2013/ch1_1d_zk Object Relational Mapping Spring 2013]

CSC/ECE 517 Fall 2014/ch1a 25 ks

2014-09-24T22:58:45Z

Knimgao:

=Object Relational Mapping=

__TOC__

==Introduction==
[http://en.wikipedia.org/wiki/Object-relational_mapping Object Relational Mapping] (ORM, O/RM, and O/R mapping) in computer science is a programming technique for converting data between incompatible type systems in object-oriented programming languages. This creates, in effect, a "virtual object database" that can be used from within the programming language. There are both free and commercial packages available that perform object-relational mapping, although some programmers opt to create their own ORM tools.

==Overview==
Object Relational Mapping is a programming technique in which a metadata descriptor is used to connect object code to a relational database. ORM converts data between type systems that are unable to coexist within relational databases and OOP languages.

In [http://en.wikipedia.org/wiki/Object-oriented_programming object-oriented programming], data management tasks act on object-oriented (OO) objects that are almost always non-scalar values. For example, consider an address book entry that represents a single person along with zero or more phone numbers and zero or more addresses. This could be modeled in an object-oriented implementation by a "Person object" with attributes/fields to hold each data item that the entry comprises: the person's name, a list of phone numbers, and a list of addresses. The list of phone numbers would itself contain "PhoneNumber objects" and so on. The address book entry is treated as a single object by the programming language (it can be referenced by a single variable containing a pointer to the object, for instance). Various methods can be associated with the object, such as a method to return the preferred phone number, the home address, and so on.

The heart of the problem is translating the logical representation of the objects into an atomized form that is capable of being stored in the database, while preserving the properties of the objects and their relationships so that they can be reloaded as objects when needed. If this storage and retrieval functionality is implemented, the objects are said to be persistent.

==Simple Explanation==
A simple answer is that you wrap your tables or stored procedures in classes in your programming language, so that instead of writing SQL statements to interact with your database, you use methods and properties of objects.

In other words, instead of something like this:
<pre>
String sql = "SELECT ... FROM persons WHERE id = 10"
DbCommand cmd = new DbCommand(connection, sql);
Result res = cmd.Execute();
String name = res[0]["FIRST_NAME"];
</pre>
you do something like this:
<pre>
Person p = repository.GetPerson(10);
String name = p.FirstName;
</pre>
or similar code (lots of variations here.) Some frameworks also put a lot of the code in as static methods on the classes themselves, which means you could do something like this instead:
<pre>
Person p = Person.Get(10);
</pre>
Some also implement complex query systems, so you could do this:
<pre>
Person p = Person.Get(Person.Properties.Id == 10);
</pre>
The framework is what makes this code possible.

==Features==
Object-relational Mapping (ORM) frameworks unburden the designer of the complex translation between database and object space.

Typical ORM features:
* Automatic mapping from classes to database tables
** Class instance variables to database columns
** Class instances to table rows
* Aggregation and association relationships between mapped classes are managed
** Example, :has_many, :belongs_to associations in ActiveRecord
** Inheritance cases are mapped to tables
* Validation of data prior to table storage
* Class extensions to enable search, as well as creation, read, update, and deletion (CRUD) of instances/records
* Usually abstracts the database from program space in such a way that alternate database types can be easily chosen (SQLite, Oracle, etc)

The diagram below depicts a simple mapping of an object to a database table….

[[Image:3j_ks_pic1.jpg]]

ORM framework is used to persist model objects to a relational database and retrieve them, and the ORM framework will take care of converting the data between the two otherwise incompatible states. Most ORM tools rely heavily on metadata about both the database and objects, so that the objects need to know nothing about the database and the database doesn’t need to know anything about how the data is structured in the application. ORM provides a clean separation of concerns in a well-designed data application, and the database and application can each work with data in its native form. Database rows map to objects, thus making the program more easily accessible and allowing the usage of information in a way that is internally consistent and easy to understand. The ORM gives the programmer an ability to manipulate data with the programming language, instead of having to manipulate each attribute as its data type as obtained by the database management system.

When applied to Ruby, implementations of ORM often leverage the language’s [http://en.wikipedia.org/wiki/Metaprogramming metaprogramming] strengths to create intuitive application-specific methods and otherwise extend classes to support database functionality. With the addition of Rails, the ORM becomes much more important, as it is necessary to have an ORM to connect the models of the MVC (model-view-controller) stack used by Ruby on Rails with the application's database. Since the models are Ruby objects, the ORM allows modifications to the database to be done through changes to these models, independent of the type of database used.

With the release of Rails 3.0, the platform became ORM independent. With this change, it is much easier to use the ORM most preferred by the programmer, rather than being corralled into using one particular one. To allow this, the ORM needed to be extracted from the model and the database, to be a pure mediator between the two. Then any ORM can be used as long as it can successfully understand the model and the database used.

==Advantages ==
In addition to the [http://en.wikipedia.org/wiki/Data_access data access] technique, ORM's benefits also include:
*First of all, you hide the SQL away from your logic code. This has the benefit of allowing you to more easily support more database engines. For instance, MS SQL Server and Oracle has different names on typical functions, and different ways to do calculations with dates, so a query to "get me all persons edited the last 24 hours" might entail different SQL syntax just for those two database engines. This difference can be put away from your logic code.
*Additionally, you can focus on writing the logic, instead of getting all the SQL right. The code will typically be more readable as well, since it doesn't contain all the "plumbing" necessary to talk to the database.
*Simplified development because it automates object-to-table and table-to-object conversion, resulting in lower development and maintenance costs
*Less code compared to embedded SQL and handwritten stored procedures
*Transparent object caching in the application tier, improving system performance
*An optimized solution making an application faster and easier to maintain

==Disadvantages ==
*ORM’s emergence in multiple application development has created disagreement among experts. Key concerns are that ORM does not perform well and that stored procedures might be a better solution.
*In addition, ORM dependence may result in poorly-designed databases in certain circumstances.
*Performance – like every "proxy" technology
*Complexity – learning curve
*Difficulty / inability to make complex queries

=ORM Frameworks=

==Active Records==
[http://guides.rubyonrails.org/active_record_basics.html Active Record] was described by Martin Fowler in his book Patterns of Enterprise Application Architecture. Active Record is the M in [http://guides.rubyonrails.org/getting_started.html#the-mvc-architecture MVC]- the model - which is the layer of the system responsible for representing business data and logic. In Active Record, objects carry both persistent data and behavior which operates on that data. A database table or view is wrapped into a class and an object instance is tied to a single row in the table. Each Active Record object has CRUD (Create, Read, Update, and Delete) methods for database access. In addition, Active Record allows you to validate the state of a model before it gets written into the database.

Active Record gives us several mechanisms, the most important being the ability to:
* Represent models and their data.
* Represent associations between these models.
* Represent inheritance hierarchies through related models.
* Validate models before they get persisted to the database.
* Perform database operations in an object-oriented fashion.

The naming conventions used in Active Records are :
* Database Table - Plural with underscores separating words (e.g., book_clubs).
* Model Class - Singular with the first letter of each word capitalized (e.g., BookClub).

To create a table, ActiveRecord makes use of a migration class rather than including table definition in the actual class being modeled. As an example, the following code creates a table ‘’users’’ to store a collection of class ‘’User’’ objects:
<pre>
class CreateUsers < ActiveRecord::Migration
def self.up
create_table :users do |t|
t.string :name
t.string :email
t.string :age
t.references :cheer
t.references :post

t.timestamps # add creation and modification timestamps
end
end

def self.down # undo the table creation
drop_table :users
end
end
</pre>

The ActiveRecord’s migration scheme provides a means for backing out changes via the ‘’self.down’’ method. In addition, a table key ‘’id’’ is added to the new table without an explicit definition and record creation and modification timestamps are included via the ‘’timestamps’’ method provided by ActiveRecord.

ActiveRecord manages associations between table elements and provides the means to define such associations in the model definition. For example, the ‘’User’’ class shown below defines a ‘’has_many’’ (one-to-many) association with both the cheers and posts tables. These associations are represented in the migration class with the references operator. Also note ActiveRecord’s integrated support for validation of table information when attempting an update.

<pre>
class User < ActiveRecord::Base
has_many :cheers
has_many :posts

validates_presence_of :name
validates_presence_of :age
validates_uniqueness_of :name
validates_length_of :name, :within => 3..20
end
</pre>

To access the data in the table one calls the class function related to that column. For example, to find the user who's name is Bob, one would use @user = User.find_by_name('Bob'). Then one could find Bob's e-mail by using @user.email. Users can be searched for by any attribute in this way, as find methods are created for every combination of attributes.
While ActiveRecord provides the flexibility to create more sophisticated table relationships to represent class hierarchy, its base scheme is a single table inheritance, which trades some storage efficiency for simplicity in the database design. The following figure illustrates this concept of simplicity over efficiency.

[[Image:3j_ks_pic2.jpg]]

'''Pros''' -
* Integrated with popular Rails development framework
* Dynamically created database search methods (eg: User.find_by_address) ease db queries and make queries database syntax independent
* DB creation/management using the migrate scheme provides a means for backing out unwanted table changes
'''Cons''' -
* DB creation/management is decoupled from the model, requiring a separate utility (rake/migrate) that must be kept in sync with application.

==ORM Adaptor==
[https://github.com/ianwhite/orm_adapter ORM Adaptors] provide a single point of entry for popular ruby ORMs. Its target audience is gem authors who want to support more than one ORM.
ORM Adapter's goal is to support a minimum API used by most of the plugins that needs agnosticism beyond Active Model.
ORM Adapter will support only basic methods, as get, find_first, create! and so forth. It is not ORM Adapter's goal to support different query constructions, handle table joins, etc.
ORM adapter provides a consistent API for these basic class or 'factory' methods. It does not attempt to unify the behaviour of model instances returned by these methods. This means that unifying the behaviour of methods such as `model.save`, and `model.valid?` is beyond the scope of orm_adapter.
If you need complex queries, it is recommended to subclass ORM Adapters in your plugin and extend it expressing these query conditions as part of your domain logic.
<pre>
Example :
require 'orm_adapter'
User # is it an ActiveRecord, DM Resource, MongoMapper or MongoId Document?
User.to_adapter.find_first :name => 'Fred' # we don't care!
user_model = User.to_adapter
user_model.get!(1) # find a record by id
user_model.find_first(:name => 'fred') # find first fred
user_model.find_first(:level => 'awesome', :id => 23) # find user 23, only if it's level is awesome
user_model.find_all # find all users
user_model.find_all(:name => 'fred') # find all freds
user_model.find_all(:order => :name) # find all freds, ordered by name
user_model.create!(:name => 'fred') # create a fred
user_model.destroy(object) # destroy the user object
</pre>

==Sequel==
[http://sequel.jeremyevans.net/documentation.html Sequel] was originally developed by Sharon Rosner and the first release was in March 2007. It is based on the active record pattern. Sequel and Active Record share a lot of common features , for example association and inheritance. But Sequel handles these features in a much more flexible manner. Currently Sequel is at version 3.44.0. Initially Sequel had three core modules - sequel, sequel_core and sequel_model. Starting from version 1.4 , sequel and sequel_model were merged. Sequel handles validations using a validation plug-in and helpers.

<pre>
class CreateUser < Sequel::Migration
def up
create_table(:user) {
primary_key :id
String :name
String :age
String :email}
end
def down
drop_table(:user)
end
end # CreateUser.apply(DB, :up)
</pre>

Sequel supports associations and validations similar to Active Record. The following example shows how validations and associations can be enforced in the User table that has been created above. It enforces one to many relationships between the user table and the cheers and posts tables. It also validates for the presence , uniqueness and the length of the attribute '''name'''.

<pre>
class User < Sequel::Model
one_to_many :cheers
one_to_many :posts

validates_presence [:name, :age]
validates_unique(:name)
validates_length_range 3..20, :name
end
</pre>

To access the data in Sequel, one can use where clauses. For instance, to find Bob again one would use DB[:items].where(Sequel.like(:name, 'Bob'). While the ability to use SQL-like where clauses is quite flexible, it is not quite as pure an object-oriented approach as Active Record's dynamically created find methods.

Some of the key features of sequel are,
* [http://sequel.jeremyevans.net/rdoc/classes/Sequel/ThreadedConnectionPool.html Connection Pooling]
* Thread Safety
* [http://guides.rubyonrails.org/active_record_querying.html#eager-loading-associations Eager Loading] / Lazy Loading
* Model Caching
* Supports advanced database features such as prepared statements, bound variables, stored procedures, savepoints, two-phase commit, transaction isolation, master/slave configurations, and database sharding.

==Data Mapper==
[http://datamapper.org/ DataMapper] is an Object Relational Mapper written in Ruby developed by Sam Smoot with the goal to create an ORM which is fast, thread-safe and feature rich.
A Data Mapper is a Data Access Layer that performs bidirectional transfer of data between a persistent data store (often a relational database) and an in memory data representation (the domain layer). The goal of the pattern is to keep the in memory representation and the persistent data store independent of each other and the data mapper itself. The layer is composed of one or more mappers (or Data Access Objects), performing the data transfer.
DataMapper comes with the ability to use the same API to talk to a multitude of different datastores. There are adapters for the usual RDBMS suspects, NoSQL stores, various file formats and some web services. With DataMapper, you define your mappings in your model. Your data store can develop independently of your model using Migrations.

Some features of Data Mapper are as follows :
* No need to write structural migrations
* Scoped relations
* Lazy loading on certain attribute types
* Strategic eager loading to avoid (N+1) queries
* Default support for composite and natural keys
* Query chaining, and not evaluating the query until absolutely necessary (using a lazy array implementation)
* An API not too heavily oriented to SQL databases

DataMapper was designed to be a more abstract ORM, not strictly SQL, based on Martin Fowler's enterprise pattern. As a result, DataMapper adapters have been built for other non-SQL databases, such as CouchDB, [http://github.com/lritter/dm-solr-adapter/tree/master Apache Solr], and webservices such as [http://github.com/halorgium/dm-salesforce/tree/master Salesforce].

Example of table definition in the model:
<pre>
class User
include DataMapper::Resource

property :id, Serial # key
property :name, String, :required => true, :unique => true
property :age, String, :required => true, :length => 3..20
property :email, String

has n, :posts # one to many association
has n, :cheers # one to many association
end
</pre>

Notice that in the example above , ":required = true" is an example for Auto Validation. Unlike ActiveRecord and Sequel, DataMapper supports auto validations , i.e. these in turn call the validation helpers to enforce basic validations such as length, uniqueness, format, presence etc.

==MyBatis/iBatis==
[http://en.wikipedia.org/wiki/MyBatis MyBatis/iBatis] was a persistence framework which allowed easy access of the database from a Rails application without being a full ORM. It was created by the Apache Foundation in 2002, and is available for several platforms, including Ruby (the Ruby release is known as RBatis). On 6/16/2010, after releasing iBATIS 3.0, the project team moved from Apache to Google Code, changed the project's name to MyBatis, and stopped supporting Ruby.

The MyBatis data mapper framework makes it easier to use a relational database with object-oriented applications. MyBatis couples objects with stored procedures or SQL statements using a XML descriptor. To use the MyBatis data mapper,we make use of our own objects, XML, and SQL.

SQL statements are stored in XML files or annotations. Following is a MyBatis mapper, that consists of a Java interface with some MyBatis annotations:
<pre>
package org.mybatis.example;

public interface BlogMapper {
@Select("select * from Blog where id = #{id}")
Blog selectBlog(int id);
}
</pre>
The sentence is executed as follows.
<pre>
BlogMapper mapper = session.getMapper(BlogMapper.class);
Blog blog = mapper.selectBlog(101);
</pre>

It can also be executed using MyBatis API.
<pre>
Blog blog = session.selectOne("org.mybatis.example.BlogMapper.selectBlog", 101);
</pre>

SQL statements and mappings can also be externalized to an XML file like this.
<pre>
<?xml version="1.0" encoding="UTF-8" ?>
<!DOCTYPE mapper PUBLIC "-//mybatis.org//DTD Mapper 3.0//EN" "http://mybatis.org/dtd/mybatis-3-mapper.dtd">

<mapper namespace="org.mybatis.example.BlogMapper">
<select id="selectBlog" parameterType="int" resultType="Blog">
select * from Blog where id = #{id}
</select>
</mapper>
</pre>

==Squeel==
[http://rubydoc.info/gems/squeel/1.1.1/frames Squeel]unlocks the power of Arel in Rails applications with a handy block-based syntax. It is supporting in Rails 3 and 4. With Squeel, you can write subqueries, access named functions provided by RDMBS and more without writing SQL strings.
Squeel lets you write your Active Record queries with fewer strings, and more Ruby, by making the Arel awesomeness that lies beneath Active Record more accessible.

Squeel lets you rewrite...

<pre>
Article.where ['created_at >= ?', 2.weeks.ago]
...as...
Article.where{created_at >= 2.weeks.ago}
</pre>

Squeel enhances the normal Active Record query methods by enabling them to accept blocks. Inside a block, the Squeel query DSL can be used. Note the use of curly braces in the above example instead of parentheses. {} denotes a Squeel DSL query.

Stubs and keypaths are the two primary building blocks used in a Squeel DSL query.

Stubs are, for most intents and purposes, just like Symbols in a normal call to Relation#where (note the need for doubling up on the curly braces here, the first ones start the block, the second are the hash braces):
<pre>
Person.where{{name => ‘Ernie’ }}
</pre>

You normally wouldn't bother using the DSL in this case, as a simple hash would suffice. However, stubs serve as a building block for keypaths, and keypaths are very handy.

A Squeel keypath is essentially a more concise and readable alternative to a deeply nested hash. For instance, in standard Active Record, you might join several associations like this to perform a query:
<pre>
Person.joins(:articles => { :comments => :person}).references(:all)
</pre>

With a keypath, this would look like:
<pre>
Person.joins{articles.comments.person}.references(:all)
</pre>

The Squeel DSL works its magic using instance_eval which means that inside a Squeel DSL block, self isn't the same thing that it is outside the block.
This carries with it an important implication: Instance variables and instance methods inside the block won't refer to your object's variables/methods.
Use one of the following methods to get access to the object's methods and variables:
* Assign the variable locally before the DSL block, and access it as you would normally.
* Supply an arity to the DSL block, as in Person.where{|q| q.name == @my_name} Downside: You'll need to prefix stubs, keypaths, and functions with the DSL object.
* Wrap the method or instance variable inside the block with my{}. Person.where{name == my{some_method_to_return_a_name}}

==Merb==
[http://en.wikipedia.org/wiki/Merb Merb], short for "Mongrel+Erb", is a model view controller framework written in Ruby. Merb was merged into Rails web framework on December 23, 2008 as part of the Ruby on Rails 3.0 release.
Merb itself provides only the controller of an MVC model which can be extended to create a full-stack application environment. This effectively means Merb itself is not an ORM but can accommodate other ORMs.
Some features of Merb are as follows :
* Speed - Merb is ORM, JavaScript library and template language agnostic, preferring plugins that add support for features rather than producing a monolithic library with everything in the core.
* Lightweight - Rather than trying to cram every feature into a single code, things are kept bare minimum without sacrificing anything important.
* Powerful and extensible - For any features not covered in Merb’s core, there are plugins.
Some basic Command distinction between Ruby on Rails and Merb :
{| class="comparison" border="1"
! Action
! Ruby on Rails
! Merb
|-
| Create new application 'app1' || rails new app1 || merb-gen app app1
|-
| Start server || rails server || merb
|-
| Start cluster of 3 beginning at port 3000 || N/A || merb -p 3000 -c 3
|-
| Interactive console || rails console || merb -i
|}

=Alternative to ORM=
==NonSQL databases==
Instead of ORM we can also use Object-Oriented Database Management System (OODBMS) or document-oriented database like XML, where in databases are designed to store object oriented values, thus eliminating the need to convert data to and from its SQL form. Document oriented databases also eliminates the need to retrieve objects as data rows. Query languages like XQuery can be used to retrieve data sets.

The only issue is we won't be able to create application independent queries for retrieving data without restrictions to access path. Also OODBMS limits the extent of processing SQL queries.
A Relational database allows concurrent access to data, locking, indexing (fast search), as well as many other features that are not available while using XML files.

Other OODBMS (such as RavenDB) provide replication to SQL databases, as a means of addressing the need for ad-hoc queries, while preserving the increased performance and reduced complexity that may be achieved with an OODBMS for an application that has well-known query patterns.

NonSQL databases don’t provide mechanism to maintain relationship between tables. In real life though, business objects or entities do have relationship among them. ORM solutions may allow you to define these relationships in business objects and handle their storage and retrieval behind the scene

=Comparison of ORM Features=

{|cellspacing="0" border="1"
!style="width:8%"|Features
!style="width:23%"|ActiveRecord
!style="width:23%"|Sequel
!style="width:23%"|DataMapper
!style="width:23%"|MyBatis
|-
! Databases 
| MySQL, PostgreSQL, SQLite, Oracle, SQLServer, and DB2
| ADO, DataObjects, DB2, DBI, Firebird, Informix, JDBC, MySQL, ODBC, OpenBase, Oracle, PostgreSQL and SQLite3
| SQLite, MySQL, PostgreSQL, Oracle, MongoDB, SimpleDB, many others, including CouchDB, Apache Solr, Google Data API
| MySQL, PostgreSQL, SQLite, Oracle, SQLServer, and DB2
|-
! Migrations 
| Yes
| Yes
| Yes, but optional
| Yes, provides migration by Mybatis schema migration system.
|-
! EagerLoading 
| Supported by scanning the SQL fragments
| Supported using eager (preloading) and eager_graph (joins)
| Strategic Eager Loading and by using :summary
| Yes.this can be enabled or disabled by setting the lazyLoadingEnabled flag
|-
! Flexible Overriding 
| No. Overriding is done using alias methods.
| Using methods and by calling 'super'
| Using methods
| No
|-
! Dynamic Finders 
| Yes. Uses 'Method Missing'
| No. Alternative is to use <Model>.FindOrCreate(:name=>"John")
| Yes. Using the dm_ar_finders plugin
| Similar feature is supported in the form of Dynamic SQL
|}

=Further Reading=
To get more information on ORM and the different type of ORM's available for Ruby , please look into the [http://wiki.expertiza.ncsu.edu/index.php/CSC/ECE_517_Spring_2013/ch1_1d_zk CSC/ECE 517 Spring 2013/ch1 1d zk] and [http://wiki.expertiza.ncsu.edu/index.php/CSC/ECE_517_Fall_2010/ch3_3f_ac Fall 2010 detailed ORM explanation] wiki pages.
# [http://www.cs.colorado.edu/~kena/classes/5448/f11/lectures/29-orm.pdf ORM - University of Colorado]
# [http://www.lynda.com/Ruby-Rails-tutorials/Understanding-ActiveRecord-ActiveRelation/139989/159093-4.html Active Record Tutorial]

=Future Work=
More work can be done in the area of comparison between the different ORMs available for Ruby, especially a more detailed feature-by-feature comparison that includes performance differences between the ORMs.

=References =
# [http://en.wikipedia.org/wiki/Object-relational_mapping Object Relational Mapping]
# [http://en.wikipedia.org/wiki/Object-oriented_programming object-oriented programming]
# [http://en.wikipedia.org/wiki/Data_access data access]
# [http://en.wikipedia.org/wiki/Metaprogramming metaprogramming]
# [http://guides.rubyonrails.org/active_record_basics.html Active Record]
# [http://guides.rubyonrails.org/getting_started.html#the-mvc-architecture MVC]
# [http://sequel.jeremyevans.net/documentation.html Sequel]
# [http://datamapper.org/ DataMapper]
# [http://sequel.jeremyevans.net/rdoc/classes/Sequel/ThreadedConnectionPool.html Connection Pooling]
# [http://guides.rubyonrails.org/active_record_querying.html#eager-loading-associations Eager Loading]
# [http://rubydoc.info/gems/squeel/1.1.1/frames Squeel]
# [http://www.techopedia.com/definition/24200/object-relational-mapping--orm ORM]
# [http://en.wikipedia.org/wiki/Merb Merb]
# [http://www.merbivore.com/ Merb Website]
# [http://wiki.expertiza.ncsu.edu/index.php/CSC/ECE_517_Spring_2013/ch1_1d_zk Object Relational Mapping Spring 2013]

CSC/ECE 517 Fall 2014/ch1a 25 ks

2014-09-24T22:52:51Z

Knimgao: /* Further Reading */

==Object Relational Mapping==

__TOC__

==Introduction==
[http://en.wikipedia.org/wiki/Object-relational_mapping Object Relational Mapping] (ORM, O/RM, and O/R mapping) in computer science is a programming technique for converting data between incompatible type systems in object-oriented programming languages. This creates, in effect, a "virtual object database" that can be used from within the programming language. There are both free and commercial packages available that perform object-relational mapping, although some programmers opt to create their own ORM tools.

==Overview==
Object Relational Mapping is a programming technique in which a metadata descriptor is used to connect object code to a relational database. ORM converts data between type systems that are unable to coexist within relational databases and OOP languages.

In [http://en.wikipedia.org/wiki/Object-oriented_programming object-oriented programming], data management tasks act on object-oriented (OO) objects that are almost always non-scalar values. For example, consider an address book entry that represents a single person along with zero or more phone numbers and zero or more addresses. This could be modeled in an object-oriented implementation by a "Person object" with attributes/fields to hold each data item that the entry comprises: the person's name, a list of phone numbers, and a list of addresses. The list of phone numbers would itself contain "PhoneNumber objects" and so on. The address book entry is treated as a single object by the programming language (it can be referenced by a single variable containing a pointer to the object, for instance). Various methods can be associated with the object, such as a method to return the preferred phone number, the home address, and so on.

The heart of the problem is translating the logical representation of the objects into an atomized form that is capable of being stored in the database, while preserving the properties of the objects and their relationships so that they can be reloaded as objects when needed. If this storage and retrieval functionality is implemented, the objects are said to be persistent.

==Simple Explanation==
A simple answer is that you wrap your tables or stored procedures in classes in your programming language, so that instead of writing SQL statements to interact with your database, you use methods and properties of objects.

In other words, instead of something like this:
<pre>
String sql = "SELECT ... FROM persons WHERE id = 10"
DbCommand cmd = new DbCommand(connection, sql);
Result res = cmd.Execute();
String name = res[0]["FIRST_NAME"];
</pre>
you do something like this:
<pre>
Person p = repository.GetPerson(10);
String name = p.FirstName;
</pre>
or similar code (lots of variations here.) Some frameworks also put a lot of the code in as static methods on the classes themselves, which means you could do something like this instead:
<pre>
Person p = Person.Get(10);
</pre>
Some also implement complex query systems, so you could do this:
<pre>
Person p = Person.Get(Person.Properties.Id == 10);
</pre>
The framework is what makes this code possible.

==Features==
Object-relational Mapping (ORM) frameworks unburden the designer of the complex translation between database and object space.

Typical ORM features:
* Automatic mapping from classes to database tables
** Class instance variables to database columns
** Class instances to table rows
* Aggregation and association relationships between mapped classes are managed
** Example, :has_many, :belongs_to associations in ActiveRecord
** Inheritance cases are mapped to tables
* Validation of data prior to table storage
* Class extensions to enable search, as well as creation, read, update, and deletion (CRUD) of instances/records
* Usually abstracts the database from program space in such a way that alternate database types can be easily chosen (SQLite, Oracle, etc)

The diagram below depicts a simple mapping of an object to a database table….

[[Image:3j_ks_pic1.jpg]]

ORM framework is used to persist model objects to a relational database and retrieve them, and the ORM framework will take care of converting the data between the two otherwise incompatible states. Most ORM tools rely heavily on metadata about both the database and objects, so that the objects need to know nothing about the database and the database doesn’t need to know anything about how the data is structured in the application. ORM provides a clean separation of concerns in a well-designed data application, and the database and application can each work with data in its native form. Database rows map to objects, thus making the program more easily accessible and allowing the usage of information in a way that is internally consistent and easy to understand. The ORM gives the programmer an ability to manipulate data with the programming language, instead of having to manipulate each attribute as its data type as obtained by the database management system.

When applied to Ruby, implementations of ORM often leverage the language’s [http://en.wikipedia.org/wiki/Metaprogramming metaprogramming] strengths to create intuitive application-specific methods and otherwise extend classes to support database functionality. With the addition of Rails, the ORM becomes much more important, as it is necessary to have an ORM to connect the models of the MVC (model-view-controller) stack used by Ruby on Rails with the application's database. Since the models are Ruby objects, the ORM allows modifications to the database to be done through changes to these models, independent of the type of database used.

With the release of Rails 3.0, the platform became ORM independent. With this change, it is much easier to use the ORM most preferred by the programmer, rather than being corralled into using one particular one. To allow this, the ORM needed to be extracted from the model and the database, to be a pure mediator between the two. Then any ORM can be used as long as it can successfully understand the model and the database used.

==Advantages ==
In addition to the [http://en.wikipedia.org/wiki/Data_access data access] technique, ORM's benefits also include:
*First of all, you hide the SQL away from your logic code. This has the benefit of allowing you to more easily support more database engines. For instance, MS SQL Server and Oracle has different names on typical functions, and different ways to do calculations with dates, so a query to "get me all persons edited the last 24 hours" might entail different SQL syntax just for those two database engines. This difference can be put away from your logic code.
*Additionally, you can focus on writing the logic, instead of getting all the SQL right. The code will typically be more readable as well, since it doesn't contain all the "plumbing" necessary to talk to the database.
*Simplified development because it automates object-to-table and table-to-object conversion, resulting in lower development and maintenance costs
*Less code compared to embedded SQL and handwritten stored procedures
*Transparent object caching in the application tier, improving system performance
*An optimized solution making an application faster and easier to maintain

==Disadvantages ==
*ORM’s emergence in multiple application development has created disagreement among experts. Key concerns are that ORM does not perform well and that stored procedures might be a better solution.
*In addition, ORM dependence may result in poorly-designed databases in certain circumstances.
*Performance – like every "proxy" technology
*Complexity – learning curve
*Difficulty / inability to make complex queries

==Active Records==
[http://guides.rubyonrails.org/active_record_basics.html Active Record] was described by Martin Fowler in his book Patterns of Enterprise Application Architecture. Active Record is the M in [http://guides.rubyonrails.org/getting_started.html#the-mvc-architecture MVC]- the model - which is the layer of the system responsible for representing business data and logic. In Active Record, objects carry both persistent data and behavior which operates on that data. A database table or view is wrapped into a class and an object instance is tied to a single row in the table. Each Active Record object has CRUD (Create, Read, Update, and Delete) methods for database access. In addition, Active Record allows you to validate the state of a model before it gets written into the database.

Active Record gives us several mechanisms, the most important being the ability to:
* Represent models and their data.
* Represent associations between these models.
* Represent inheritance hierarchies through related models.
* Validate models before they get persisted to the database.
* Perform database operations in an object-oriented fashion.

The naming conventions used in Active Records are :
* Database Table - Plural with underscores separating words (e.g., book_clubs).
* Model Class - Singular with the first letter of each word capitalized (e.g., BookClub).

To create a table, ActiveRecord makes use of a migration class rather than including table definition in the actual class being modeled. As an example, the following code creates a table ‘’users’’ to store a collection of class ‘’User’’ objects:
<pre>
class CreateUsers < ActiveRecord::Migration
def self.up
create_table :users do |t|
t.string :name
t.string :email
t.string :age
t.references :cheer
t.references :post

t.timestamps # add creation and modification timestamps
end
end

def self.down # undo the table creation
drop_table :users
end
end
</pre>

The ActiveRecord’s migration scheme provides a means for backing out changes via the ‘’self.down’’ method. In addition, a table key ‘’id’’ is added to the new table without an explicit definition and record creation and modification timestamps are included via the ‘’timestamps’’ method provided by ActiveRecord.

ActiveRecord manages associations between table elements and provides the means to define such associations in the model definition. For example, the ‘’User’’ class shown below defines a ‘’has_many’’ (one-to-many) association with both the cheers and posts tables. These associations are represented in the migration class with the references operator. Also note ActiveRecord’s integrated support for validation of table information when attempting an update.

<pre>
class User < ActiveRecord::Base
has_many :cheers
has_many :posts

validates_presence_of :name
validates_presence_of :age
validates_uniqueness_of :name
validates_length_of :name, :within => 3..20
end
</pre>

To access the data in the table one calls the class function related to that column. For example, to find the user who's name is Bob, one would use @user = User.find_by_name('Bob'). Then one could find Bob's e-mail by using @user.email. Users can be searched for by any attribute in this way, as find methods are created for every combination of attributes.
While ActiveRecord provides the flexibility to create more sophisticated table relationships to represent class hierarchy, its base scheme is a single table inheritance, which trades some storage efficiency for simplicity in the database design. The following figure illustrates this concept of simplicity over efficiency.

[[Image:3j_ks_pic2.jpg]]

'''Pros''' -
* Integrated with popular Rails development framework
* Dynamically created database search methods (eg: User.find_by_address) ease db queries and make queries database syntax independent
* DB creation/management using the migrate scheme provides a means for backing out unwanted table changes
'''Cons''' -
* DB creation/management is decoupled from the model, requiring a separate utility (rake/migrate) that must be kept in sync with application.

==ORM Adaptor==
[https://github.com/ianwhite/orm_adapter ORM Adaptors] provide a single point of entry for popular ruby ORMs. Its target audience is gem authors who want to support more than one ORM.
ORM Adapter's goal is to support a minimum API used by most of the plugins that needs agnosticism beyond Active Model.
ORM Adapter will support only basic methods, as get, find_first, create! and so forth. It is not ORM Adapter's goal to support different query constructions, handle table joins, etc.
ORM adapter provides a consistent API for these basic class or 'factory' methods. It does not attempt to unify the behaviour of model instances returned by these methods. This means that unifying the behaviour of methods such as `model.save`, and `model.valid?` is beyond the scope of orm_adapter.
If you need complex queries, it is recommended to subclass ORM Adapters in your plugin and extend it expressing these query conditions as part of your domain logic.
<pre>
Example :
require 'orm_adapter'
User # is it an ActiveRecord, DM Resource, MongoMapper or MongoId Document?
User.to_adapter.find_first :name => 'Fred' # we don't care!
user_model = User.to_adapter
user_model.get!(1) # find a record by id
user_model.find_first(:name => 'fred') # find first fred
user_model.find_first(:level => 'awesome', :id => 23) # find user 23, only if it's level is awesome
user_model.find_all # find all users
user_model.find_all(:name => 'fred') # find all freds
user_model.find_all(:order => :name) # find all freds, ordered by name
user_model.create!(:name => 'fred') # create a fred
user_model.destroy(object) # destroy the user object
</pre>

==Sequel==
[http://sequel.jeremyevans.net/documentation.html Sequel] was originally developed by Sharon Rosner and the first release was in March 2007. It is based on the active record pattern. Sequel and Active Record share a lot of common features , for example association and inheritance. But Sequel handles these features in a much more flexible manner. Currently Sequel is at version 3.44.0. Initially Sequel had three core modules - sequel, sequel_core and sequel_model. Starting from version 1.4 , sequel and sequel_model were merged. Sequel handles validations using a validation plug-in and helpers.

<pre>
class CreateUser < Sequel::Migration
def up
create_table(:user) {
primary_key :id
String :name
String :age
String :email}
end
def down
drop_table(:user)
end
end # CreateUser.apply(DB, :up)
</pre>

Sequel supports associations and validations similar to Active Record. The following example shows how validations and associations can be enforced in the User table that has been created above. It enforces one to many relationships between the user table and the cheers and posts tables. It also validates for the presence , uniqueness and the length of the attribute '''name'''.

<pre>
class User < Sequel::Model
one_to_many :cheers
one_to_many :posts

validates_presence [:name, :age]
validates_unique(:name)
validates_length_range 3..20, :name
end
</pre>

To access the data in Sequel, one can use where clauses. For instance, to find Bob again one would use DB[:items].where(Sequel.like(:name, 'Bob'). While the ability to use SQL-like where clauses is quite flexible, it is not quite as pure an object-oriented approach as Active Record's dynamically created find methods.

Some of the key features of sequel are,
* [http://sequel.jeremyevans.net/rdoc/classes/Sequel/ThreadedConnectionPool.html Connection Pooling]
* Thread Safety
* [http://guides.rubyonrails.org/active_record_querying.html#eager-loading-associations Eager Loading] / Lazy Loading
* Model Caching
* Supports advanced database features such as prepared statements, bound variables, stored procedures, savepoints, two-phase commit, transaction isolation, master/slave configurations, and database sharding.

==Data Mapper==
[http://datamapper.org/ DataMapper] is an Object Relational Mapper written in Ruby developed by Sam Smoot with the goal to create an ORM which is fast, thread-safe and feature rich.
A Data Mapper is a Data Access Layer that performs bidirectional transfer of data between a persistent data store (often a relational database) and an in memory data representation (the domain layer). The goal of the pattern is to keep the in memory representation and the persistent data store independent of each other and the data mapper itself. The layer is composed of one or more mappers (or Data Access Objects), performing the data transfer.
DataMapper comes with the ability to use the same API to talk to a multitude of different datastores. There are adapters for the usual RDBMS suspects, NoSQL stores, various file formats and some web services. With DataMapper, you define your mappings in your model. Your data store can develop independently of your model using Migrations.

Some features of Data Mapper are as follows :
* No need to write structural migrations
* Scoped relations
* Lazy loading on certain attribute types
* Strategic eager loading to avoid (N+1) queries
* Default support for composite and natural keys
* Query chaining, and not evaluating the query until absolutely necessary (using a lazy array implementation)
* An API not too heavily oriented to SQL databases

DataMapper was designed to be a more abstract ORM, not strictly SQL, based on Martin Fowler's enterprise pattern. As a result, DataMapper adapters have been built for other non-SQL databases, such as CouchDB, [http://github.com/lritter/dm-solr-adapter/tree/master Apache Solr], and webservices such as [http://github.com/halorgium/dm-salesforce/tree/master Salesforce].

Example of table definition in the model:
<pre>
class User
include DataMapper::Resource

property :id, Serial # key
property :name, String, :required => true, :unique => true
property :age, String, :required => true, :length => 3..20
property :email, String

has n, :posts # one to many association
has n, :cheers # one to many association
end
</pre>

Notice that in the example above , ":required = true" is an example for Auto Validation. Unlike ActiveRecord and Sequel, DataMapper supports auto validations , i.e. these in turn call the validation helpers to enforce basic validations such as length, uniqueness, format, presence etc.

==MyBatis/iBatis==
[http://en.wikipedia.org/wiki/MyBatis MyBatis/iBatis] was a persistence framework which allowed easy access of the database from a Rails application without being a full ORM. It was created by the Apache Foundation in 2002, and is available for several platforms, including Ruby (the Ruby release is known as RBatis). On 6/16/2010, after releasing iBATIS 3.0, the project team moved from Apache to Google Code, changed the project's name to MyBatis, and stopped supporting Ruby.

The MyBatis data mapper framework makes it easier to use a relational database with object-oriented applications. MyBatis couples objects with stored procedures or SQL statements using a XML descriptor. To use the MyBatis data mapper,we make use of our own objects, XML, and SQL.

SQL statements are stored in XML files or annotations. Following is a MyBatis mapper, that consists of a Java interface with some MyBatis annotations:
<pre>
package org.mybatis.example;

public interface BlogMapper {
@Select("select * from Blog where id = #{id}")
Blog selectBlog(int id);
}
</pre>
The sentence is executed as follows.
<pre>
BlogMapper mapper = session.getMapper(BlogMapper.class);
Blog blog = mapper.selectBlog(101);
</pre>

It can also be executed using MyBatis API.
<pre>
Blog blog = session.selectOne("org.mybatis.example.BlogMapper.selectBlog", 101);
</pre>

SQL statements and mappings can also be externalized to an XML file like this.
<pre>
<?xml version="1.0" encoding="UTF-8" ?>
<!DOCTYPE mapper PUBLIC "-//mybatis.org//DTD Mapper 3.0//EN" "http://mybatis.org/dtd/mybatis-3-mapper.dtd">

<mapper namespace="org.mybatis.example.BlogMapper">
<select id="selectBlog" parameterType="int" resultType="Blog">
select * from Blog where id = #{id}
</select>
</mapper>
</pre>

==Squeel==
[http://rubydoc.info/gems/squeel/1.1.1/frames Squeel]unlocks the power of Arel in Rails applications with a handy block-based syntax. It is supporting in Rails 3 and 4. With Squeel, you can write subqueries, access named functions provided by RDMBS and more without writing SQL strings.
Squeel lets you write your Active Record queries with fewer strings, and more Ruby, by making the Arel awesomeness that lies beneath Active Record more accessible.

Squeel lets you rewrite...

<pre>
Article.where ['created_at >= ?', 2.weeks.ago]
...as...
Article.where{created_at >= 2.weeks.ago}
</pre>

Squeel enhances the normal Active Record query methods by enabling them to accept blocks. Inside a block, the Squeel query DSL can be used. Note the use of curly braces in the above example instead of parentheses. {} denotes a Squeel DSL query.

Stubs and keypaths are the two primary building blocks used in a Squeel DSL query.

Stubs are, for most intents and purposes, just like Symbols in a normal call to Relation#where (note the need for doubling up on the curly braces here, the first ones start the block, the second are the hash braces):
<pre>
Person.where{{name => ‘Ernie’ }}
</pre>

You normally wouldn't bother using the DSL in this case, as a simple hash would suffice. However, stubs serve as a building block for keypaths, and keypaths are very handy.

A Squeel keypath is essentially a more concise and readable alternative to a deeply nested hash. For instance, in standard Active Record, you might join several associations like this to perform a query:
<pre>
Person.joins(:articles => { :comments => :person}).references(:all)
</pre>

With a keypath, this would look like:
<pre>
Person.joins{articles.comments.person}.references(:all)
</pre>

The Squeel DSL works its magic using instance_eval which means that inside a Squeel DSL block, self isn't the same thing that it is outside the block.
This carries with it an important implication: Instance variables and instance methods inside the block won't refer to your object's variables/methods.
Use one of the following methods to get access to the object's methods and variables:
* Assign the variable locally before the DSL block, and access it as you would normally.
* Supply an arity to the DSL block, as in Person.where{|q| q.name == @my_name} Downside: You'll need to prefix stubs, keypaths, and functions with the DSL object.
* Wrap the method or instance variable inside the block with my{}. Person.where{name == my{some_method_to_return_a_name}}

==Merb==
[http://en.wikipedia.org/wiki/Merb Merb], short for "Mongrel+Erb", is a model view controller framework written in Ruby. Merb was merged into Rails web framework on December 23, 2008 as part of the Ruby on Rails 3.0 release.
Merb itself provides only the controller of an MVC model which can be extended to create a full-stack application environment. This effectively means Merb itself is not an ORM but can accommodate other ORMs.
Some features of Merb are as follows :
* Speed - Merb is ORM, JavaScript library and template language agnostic, preferring plugins that add support for features rather than producing a monolithic library with everything in the core.
* Lightweight - Rather than trying to cram every feature into a single code, things are kept bare minimum without sacrificing anything important.
* Powerful and extensible - For any features not covered in Merb’s core, there are plugins.
Some basic Command distinction between Ruby on Rails and Merb :
{| class="comparison" border="1"
! Action
! Ruby on Rails
! Merb
|-
| Create new application 'app1' || rails new app1 || merb-gen app app1
|-
| Start server || rails server || merb
|-
| Start cluster of 3 beginning at port 3000 || N/A || merb -p 3000 -c 3
|-
| Interactive console || rails console || merb -i
|}

==NonSQL databases==
Instead of ORM we can also use Object-Oriented Database Management System (OODBMS) or document-oriented database like XML, where in databases are designed to store object oriented values, thus eliminating the need to convert data to and from its SQL form. Document oriented databases also eliminates the need to retrieve objects as data rows. Query languages like XQuery can be used to retrieve data sets.

The only issue is we won't be able to create application independent queries for retrieving data without restrictions to access path. Also OODBMS limits the extent of processing SQL queries.
A Relational database allows concurrent access to data, locking, indexing (fast search), as well as many other features that are not available while using XML files.

Other OODBMS (such as RavenDB) provide replication to SQL databases, as a means of addressing the need for ad-hoc queries, while preserving the increased performance and reduced complexity that may be achieved with an OODBMS for an application that has well-known query patterns.

NonSQL databases don’t provide mechanism to maintain relationship between tables. In real life though, business objects or entities do have relationship among them. ORM solutions may allow you to define these relationships in business objects and handle their storage and retrieval behind the scene

==Comparison of ORM Features==

{|cellspacing="0" border="1"
!style="width:8%"|Features
!style="width:23%"|ActiveRecord
!style="width:23%"|Sequel
!style="width:23%"|DataMapper
!style="width:23%"|MyBatis
|-
! Databases 
| MySQL, PostgreSQL, SQLite, Oracle, SQLServer, and DB2
| ADO, DataObjects, DB2, DBI, Firebird, Informix, JDBC, MySQL, ODBC, OpenBase, Oracle, PostgreSQL and SQLite3
| SQLite, MySQL, PostgreSQL, Oracle, MongoDB, SimpleDB, many others, including CouchDB, Apache Solr, Google Data API
| MySQL, PostgreSQL, SQLite, Oracle, SQLServer, and DB2
|-
! Migrations 
| Yes
| Yes
| Yes, but optional
| Yes, provides migration by Mybatis schema migration system.
|-
! EagerLoading 
| Supported by scanning the SQL fragments
| Supported using eager (preloading) and eager_graph (joins)
| Strategic Eager Loading and by using :summary
| Yes.this can be enabled or disabled by setting the lazyLoadingEnabled flag
|-
! Flexible Overriding 
| No. Overriding is done using alias methods.
| Using methods and by calling 'super'
| Using methods
| No
|-
! Dynamic Finders 
| Yes. Uses 'Method Missing'
| No. Alternative is to use <Model>.FindOrCreate(:name=>"John")
| Yes. Using the dm_ar_finders plugin
| Similar feature is supported in the form of Dynamic SQL
|}

==Further Reading==
To get more information on ORM and the different type of ORM's available for Ruby , please look into the [http://wiki.expertiza.ncsu.edu/index.php/CSC/ECE_517_Spring_2013/ch1_1d_zk CSC/ECE 517 Spring 2013/ch1 1d zk] and [http://wiki.expertiza.ncsu.edu/index.php/CSC/ECE_517_Fall_2010/ch3_3f_ac Fall 2010 detailed ORM explanation] wiki pages.
# [http://www.cs.colorado.edu/~kena/classes/5448/f11/lectures/29-orm.pdf ORM - University of Colorado]

==Future Work==
More work can be done in the area of comparison between the different ORMs available for Ruby, especially a more detailed feature-by-feature comparison that includes performance differences between the ORMs.

==References ==
# [http://en.wikipedia.org/wiki/Object-relational_mapping Object Relational Mapping]
# [http://en.wikipedia.org/wiki/Object-oriented_programming object-oriented programming]
# [http://en.wikipedia.org/wiki/Data_access data access]
# [http://en.wikipedia.org/wiki/Metaprogramming metaprogramming]
# [http://guides.rubyonrails.org/active_record_basics.html Active Record]
# [http://guides.rubyonrails.org/getting_started.html#the-mvc-architecture MVC]
# [http://sequel.jeremyevans.net/documentation.html Sequel]
# [http://datamapper.org/ DataMapper]
# [http://sequel.jeremyevans.net/rdoc/classes/Sequel/ThreadedConnectionPool.html Connection Pooling]
# [http://guides.rubyonrails.org/active_record_querying.html#eager-loading-associations Eager Loading]
# [http://rubydoc.info/gems/squeel/1.1.1/frames Squeel]
# [http://www.techopedia.com/definition/24200/object-relational-mapping--orm ORM]
# [http://en.wikipedia.org/wiki/Merb Merb]
# [http://www.merbivore.com/ Merb Website]
# [http://wiki.expertiza.ncsu.edu/index.php/CSC/ECE_517_Spring_2013/ch1_1d_zk Object Relational Mapping Spring 2013]

CSC/ECE 517 Fall 2014/ch1a 25 ks

2014-09-24T22:52:29Z

Knimgao: /* Further Reading */

==Object Relational Mapping==

__TOC__

==Introduction==
[http://en.wikipedia.org/wiki/Object-relational_mapping Object Relational Mapping] (ORM, O/RM, and O/R mapping) in computer science is a programming technique for converting data between incompatible type systems in object-oriented programming languages. This creates, in effect, a "virtual object database" that can be used from within the programming language. There are both free and commercial packages available that perform object-relational mapping, although some programmers opt to create their own ORM tools.

==Overview==
Object Relational Mapping is a programming technique in which a metadata descriptor is used to connect object code to a relational database. ORM converts data between type systems that are unable to coexist within relational databases and OOP languages.

In [http://en.wikipedia.org/wiki/Object-oriented_programming object-oriented programming], data management tasks act on object-oriented (OO) objects that are almost always non-scalar values. For example, consider an address book entry that represents a single person along with zero or more phone numbers and zero or more addresses. This could be modeled in an object-oriented implementation by a "Person object" with attributes/fields to hold each data item that the entry comprises: the person's name, a list of phone numbers, and a list of addresses. The list of phone numbers would itself contain "PhoneNumber objects" and so on. The address book entry is treated as a single object by the programming language (it can be referenced by a single variable containing a pointer to the object, for instance). Various methods can be associated with the object, such as a method to return the preferred phone number, the home address, and so on.

The heart of the problem is translating the logical representation of the objects into an atomized form that is capable of being stored in the database, while preserving the properties of the objects and their relationships so that they can be reloaded as objects when needed. If this storage and retrieval functionality is implemented, the objects are said to be persistent.

==Simple Explanation==
A simple answer is that you wrap your tables or stored procedures in classes in your programming language, so that instead of writing SQL statements to interact with your database, you use methods and properties of objects.

In other words, instead of something like this:
<pre>
String sql = "SELECT ... FROM persons WHERE id = 10"
DbCommand cmd = new DbCommand(connection, sql);
Result res = cmd.Execute();
String name = res[0]["FIRST_NAME"];
</pre>
you do something like this:
<pre>
Person p = repository.GetPerson(10);
String name = p.FirstName;
</pre>
or similar code (lots of variations here.) Some frameworks also put a lot of the code in as static methods on the classes themselves, which means you could do something like this instead:
<pre>
Person p = Person.Get(10);
</pre>
Some also implement complex query systems, so you could do this:
<pre>
Person p = Person.Get(Person.Properties.Id == 10);
</pre>
The framework is what makes this code possible.

==Features==
Object-relational Mapping (ORM) frameworks unburden the designer of the complex translation between database and object space.

Typical ORM features:
* Automatic mapping from classes to database tables
** Class instance variables to database columns
** Class instances to table rows
* Aggregation and association relationships between mapped classes are managed
** Example, :has_many, :belongs_to associations in ActiveRecord
** Inheritance cases are mapped to tables
* Validation of data prior to table storage
* Class extensions to enable search, as well as creation, read, update, and deletion (CRUD) of instances/records
* Usually abstracts the database from program space in such a way that alternate database types can be easily chosen (SQLite, Oracle, etc)

The diagram below depicts a simple mapping of an object to a database table….

[[Image:3j_ks_pic1.jpg]]

ORM framework is used to persist model objects to a relational database and retrieve them, and the ORM framework will take care of converting the data between the two otherwise incompatible states. Most ORM tools rely heavily on metadata about both the database and objects, so that the objects need to know nothing about the database and the database doesn’t need to know anything about how the data is structured in the application. ORM provides a clean separation of concerns in a well-designed data application, and the database and application can each work with data in its native form. Database rows map to objects, thus making the program more easily accessible and allowing the usage of information in a way that is internally consistent and easy to understand. The ORM gives the programmer an ability to manipulate data with the programming language, instead of having to manipulate each attribute as its data type as obtained by the database management system.

When applied to Ruby, implementations of ORM often leverage the language’s [http://en.wikipedia.org/wiki/Metaprogramming metaprogramming] strengths to create intuitive application-specific methods and otherwise extend classes to support database functionality. With the addition of Rails, the ORM becomes much more important, as it is necessary to have an ORM to connect the models of the MVC (model-view-controller) stack used by Ruby on Rails with the application's database. Since the models are Ruby objects, the ORM allows modifications to the database to be done through changes to these models, independent of the type of database used.

With the release of Rails 3.0, the platform became ORM independent. With this change, it is much easier to use the ORM most preferred by the programmer, rather than being corralled into using one particular one. To allow this, the ORM needed to be extracted from the model and the database, to be a pure mediator between the two. Then any ORM can be used as long as it can successfully understand the model and the database used.

==Advantages ==
In addition to the [http://en.wikipedia.org/wiki/Data_access data access] technique, ORM's benefits also include:
*First of all, you hide the SQL away from your logic code. This has the benefit of allowing you to more easily support more database engines. For instance, MS SQL Server and Oracle has different names on typical functions, and different ways to do calculations with dates, so a query to "get me all persons edited the last 24 hours" might entail different SQL syntax just for those two database engines. This difference can be put away from your logic code.
*Additionally, you can focus on writing the logic, instead of getting all the SQL right. The code will typically be more readable as well, since it doesn't contain all the "plumbing" necessary to talk to the database.
*Simplified development because it automates object-to-table and table-to-object conversion, resulting in lower development and maintenance costs
*Less code compared to embedded SQL and handwritten stored procedures
*Transparent object caching in the application tier, improving system performance
*An optimized solution making an application faster and easier to maintain

==Disadvantages ==
*ORM’s emergence in multiple application development has created disagreement among experts. Key concerns are that ORM does not perform well and that stored procedures might be a better solution.
*In addition, ORM dependence may result in poorly-designed databases in certain circumstances.
*Performance – like every "proxy" technology
*Complexity – learning curve
*Difficulty / inability to make complex queries

==Active Records==
[http://guides.rubyonrails.org/active_record_basics.html Active Record] was described by Martin Fowler in his book Patterns of Enterprise Application Architecture. Active Record is the M in [http://guides.rubyonrails.org/getting_started.html#the-mvc-architecture MVC]- the model - which is the layer of the system responsible for representing business data and logic. In Active Record, objects carry both persistent data and behavior which operates on that data. A database table or view is wrapped into a class and an object instance is tied to a single row in the table. Each Active Record object has CRUD (Create, Read, Update, and Delete) methods for database access. In addition, Active Record allows you to validate the state of a model before it gets written into the database.

Active Record gives us several mechanisms, the most important being the ability to:
* Represent models and their data.
* Represent associations between these models.
* Represent inheritance hierarchies through related models.
* Validate models before they get persisted to the database.
* Perform database operations in an object-oriented fashion.

The naming conventions used in Active Records are :
* Database Table - Plural with underscores separating words (e.g., book_clubs).
* Model Class - Singular with the first letter of each word capitalized (e.g., BookClub).

To create a table, ActiveRecord makes use of a migration class rather than including table definition in the actual class being modeled. As an example, the following code creates a table ‘’users’’ to store a collection of class ‘’User’’ objects:
<pre>
class CreateUsers < ActiveRecord::Migration
def self.up
create_table :users do |t|
t.string :name
t.string :email
t.string :age
t.references :cheer
t.references :post

t.timestamps # add creation and modification timestamps
end
end

def self.down # undo the table creation
drop_table :users
end
end
</pre>

The ActiveRecord’s migration scheme provides a means for backing out changes via the ‘’self.down’’ method. In addition, a table key ‘’id’’ is added to the new table without an explicit definition and record creation and modification timestamps are included via the ‘’timestamps’’ method provided by ActiveRecord.

ActiveRecord manages associations between table elements and provides the means to define such associations in the model definition. For example, the ‘’User’’ class shown below defines a ‘’has_many’’ (one-to-many) association with both the cheers and posts tables. These associations are represented in the migration class with the references operator. Also note ActiveRecord’s integrated support for validation of table information when attempting an update.

<pre>
class User < ActiveRecord::Base
has_many :cheers
has_many :posts

validates_presence_of :name
validates_presence_of :age
validates_uniqueness_of :name
validates_length_of :name, :within => 3..20
end
</pre>

To access the data in the table one calls the class function related to that column. For example, to find the user who's name is Bob, one would use @user = User.find_by_name('Bob'). Then one could find Bob's e-mail by using @user.email. Users can be searched for by any attribute in this way, as find methods are created for every combination of attributes.
While ActiveRecord provides the flexibility to create more sophisticated table relationships to represent class hierarchy, its base scheme is a single table inheritance, which trades some storage efficiency for simplicity in the database design. The following figure illustrates this concept of simplicity over efficiency.

[[Image:3j_ks_pic2.jpg]]

'''Pros''' -
* Integrated with popular Rails development framework
* Dynamically created database search methods (eg: User.find_by_address) ease db queries and make queries database syntax independent
* DB creation/management using the migrate scheme provides a means for backing out unwanted table changes
'''Cons''' -
* DB creation/management is decoupled from the model, requiring a separate utility (rake/migrate) that must be kept in sync with application.

==ORM Adaptor==
[https://github.com/ianwhite/orm_adapter ORM Adaptors] provide a single point of entry for popular ruby ORMs. Its target audience is gem authors who want to support more than one ORM.
ORM Adapter's goal is to support a minimum API used by most of the plugins that needs agnosticism beyond Active Model.
ORM Adapter will support only basic methods, as get, find_first, create! and so forth. It is not ORM Adapter's goal to support different query constructions, handle table joins, etc.
ORM adapter provides a consistent API for these basic class or 'factory' methods. It does not attempt to unify the behaviour of model instances returned by these methods. This means that unifying the behaviour of methods such as `model.save`, and `model.valid?` is beyond the scope of orm_adapter.
If you need complex queries, it is recommended to subclass ORM Adapters in your plugin and extend it expressing these query conditions as part of your domain logic.
<pre>
Example :
require 'orm_adapter'
User # is it an ActiveRecord, DM Resource, MongoMapper or MongoId Document?
User.to_adapter.find_first :name => 'Fred' # we don't care!
user_model = User.to_adapter
user_model.get!(1) # find a record by id
user_model.find_first(:name => 'fred') # find first fred
user_model.find_first(:level => 'awesome', :id => 23) # find user 23, only if it's level is awesome
user_model.find_all # find all users
user_model.find_all(:name => 'fred') # find all freds
user_model.find_all(:order => :name) # find all freds, ordered by name
user_model.create!(:name => 'fred') # create a fred
user_model.destroy(object) # destroy the user object
</pre>

==Sequel==
[http://sequel.jeremyevans.net/documentation.html Sequel] was originally developed by Sharon Rosner and the first release was in March 2007. It is based on the active record pattern. Sequel and Active Record share a lot of common features , for example association and inheritance. But Sequel handles these features in a much more flexible manner. Currently Sequel is at version 3.44.0. Initially Sequel had three core modules - sequel, sequel_core and sequel_model. Starting from version 1.4 , sequel and sequel_model were merged. Sequel handles validations using a validation plug-in and helpers.

<pre>
class CreateUser < Sequel::Migration
def up
create_table(:user) {
primary_key :id
String :name
String :age
String :email}
end
def down
drop_table(:user)
end
end # CreateUser.apply(DB, :up)
</pre>

Sequel supports associations and validations similar to Active Record. The following example shows how validations and associations can be enforced in the User table that has been created above. It enforces one to many relationships between the user table and the cheers and posts tables. It also validates for the presence , uniqueness and the length of the attribute '''name'''.

<pre>
class User < Sequel::Model
one_to_many :cheers
one_to_many :posts

validates_presence [:name, :age]
validates_unique(:name)
validates_length_range 3..20, :name
end
</pre>

To access the data in Sequel, one can use where clauses. For instance, to find Bob again one would use DB[:items].where(Sequel.like(:name, 'Bob'). While the ability to use SQL-like where clauses is quite flexible, it is not quite as pure an object-oriented approach as Active Record's dynamically created find methods.

Some of the key features of sequel are,
* [http://sequel.jeremyevans.net/rdoc/classes/Sequel/ThreadedConnectionPool.html Connection Pooling]
* Thread Safety
* [http://guides.rubyonrails.org/active_record_querying.html#eager-loading-associations Eager Loading] / Lazy Loading
* Model Caching
* Supports advanced database features such as prepared statements, bound variables, stored procedures, savepoints, two-phase commit, transaction isolation, master/slave configurations, and database sharding.

==Data Mapper==
[http://datamapper.org/ DataMapper] is an Object Relational Mapper written in Ruby developed by Sam Smoot with the goal to create an ORM which is fast, thread-safe and feature rich.
A Data Mapper is a Data Access Layer that performs bidirectional transfer of data between a persistent data store (often a relational database) and an in memory data representation (the domain layer). The goal of the pattern is to keep the in memory representation and the persistent data store independent of each other and the data mapper itself. The layer is composed of one or more mappers (or Data Access Objects), performing the data transfer.
DataMapper comes with the ability to use the same API to talk to a multitude of different datastores. There are adapters for the usual RDBMS suspects, NoSQL stores, various file formats and some web services. With DataMapper, you define your mappings in your model. Your data store can develop independently of your model using Migrations.

Some features of Data Mapper are as follows :
* No need to write structural migrations
* Scoped relations
* Lazy loading on certain attribute types
* Strategic eager loading to avoid (N+1) queries
* Default support for composite and natural keys
* Query chaining, and not evaluating the query until absolutely necessary (using a lazy array implementation)
* An API not too heavily oriented to SQL databases

DataMapper was designed to be a more abstract ORM, not strictly SQL, based on Martin Fowler's enterprise pattern. As a result, DataMapper adapters have been built for other non-SQL databases, such as CouchDB, [http://github.com/lritter/dm-solr-adapter/tree/master Apache Solr], and webservices such as [http://github.com/halorgium/dm-salesforce/tree/master Salesforce].

Example of table definition in the model:
<pre>
class User
include DataMapper::Resource

property :id, Serial # key
property :name, String, :required => true, :unique => true
property :age, String, :required => true, :length => 3..20
property :email, String

has n, :posts # one to many association
has n, :cheers # one to many association
end
</pre>

Notice that in the example above , ":required = true" is an example for Auto Validation. Unlike ActiveRecord and Sequel, DataMapper supports auto validations , i.e. these in turn call the validation helpers to enforce basic validations such as length, uniqueness, format, presence etc.

==MyBatis/iBatis==
[http://en.wikipedia.org/wiki/MyBatis MyBatis/iBatis] was a persistence framework which allowed easy access of the database from a Rails application without being a full ORM. It was created by the Apache Foundation in 2002, and is available for several platforms, including Ruby (the Ruby release is known as RBatis). On 6/16/2010, after releasing iBATIS 3.0, the project team moved from Apache to Google Code, changed the project's name to MyBatis, and stopped supporting Ruby.

The MyBatis data mapper framework makes it easier to use a relational database with object-oriented applications. MyBatis couples objects with stored procedures or SQL statements using a XML descriptor. To use the MyBatis data mapper,we make use of our own objects, XML, and SQL.

SQL statements are stored in XML files or annotations. Following is a MyBatis mapper, that consists of a Java interface with some MyBatis annotations:
<pre>
package org.mybatis.example;

public interface BlogMapper {
@Select("select * from Blog where id = #{id}")
Blog selectBlog(int id);
}
</pre>
The sentence is executed as follows.
<pre>
BlogMapper mapper = session.getMapper(BlogMapper.class);
Blog blog = mapper.selectBlog(101);
</pre>

It can also be executed using MyBatis API.
<pre>
Blog blog = session.selectOne("org.mybatis.example.BlogMapper.selectBlog", 101);
</pre>

SQL statements and mappings can also be externalized to an XML file like this.
<pre>
<?xml version="1.0" encoding="UTF-8" ?>
<!DOCTYPE mapper PUBLIC "-//mybatis.org//DTD Mapper 3.0//EN" "http://mybatis.org/dtd/mybatis-3-mapper.dtd">

<mapper namespace="org.mybatis.example.BlogMapper">
<select id="selectBlog" parameterType="int" resultType="Blog">
select * from Blog where id = #{id}
</select>
</mapper>
</pre>

==Squeel==
[http://rubydoc.info/gems/squeel/1.1.1/frames Squeel]unlocks the power of Arel in Rails applications with a handy block-based syntax. It is supporting in Rails 3 and 4. With Squeel, you can write subqueries, access named functions provided by RDMBS and more without writing SQL strings.
Squeel lets you write your Active Record queries with fewer strings, and more Ruby, by making the Arel awesomeness that lies beneath Active Record more accessible.

Squeel lets you rewrite...

<pre>
Article.where ['created_at >= ?', 2.weeks.ago]
...as...
Article.where{created_at >= 2.weeks.ago}
</pre>

Squeel enhances the normal Active Record query methods by enabling them to accept blocks. Inside a block, the Squeel query DSL can be used. Note the use of curly braces in the above example instead of parentheses. {} denotes a Squeel DSL query.

Stubs and keypaths are the two primary building blocks used in a Squeel DSL query.

Stubs are, for most intents and purposes, just like Symbols in a normal call to Relation#where (note the need for doubling up on the curly braces here, the first ones start the block, the second are the hash braces):
<pre>
Person.where{{name => ‘Ernie’ }}
</pre>

You normally wouldn't bother using the DSL in this case, as a simple hash would suffice. However, stubs serve as a building block for keypaths, and keypaths are very handy.

A Squeel keypath is essentially a more concise and readable alternative to a deeply nested hash. For instance, in standard Active Record, you might join several associations like this to perform a query:
<pre>
Person.joins(:articles => { :comments => :person}).references(:all)
</pre>

With a keypath, this would look like:
<pre>
Person.joins{articles.comments.person}.references(:all)
</pre>

The Squeel DSL works its magic using instance_eval which means that inside a Squeel DSL block, self isn't the same thing that it is outside the block.
This carries with it an important implication: Instance variables and instance methods inside the block won't refer to your object's variables/methods.
Use one of the following methods to get access to the object's methods and variables:
* Assign the variable locally before the DSL block, and access it as you would normally.
* Supply an arity to the DSL block, as in Person.where{|q| q.name == @my_name} Downside: You'll need to prefix stubs, keypaths, and functions with the DSL object.
* Wrap the method or instance variable inside the block with my{}. Person.where{name == my{some_method_to_return_a_name}}

==Merb==
[http://en.wikipedia.org/wiki/Merb Merb], short for "Mongrel+Erb", is a model view controller framework written in Ruby. Merb was merged into Rails web framework on December 23, 2008 as part of the Ruby on Rails 3.0 release.
Merb itself provides only the controller of an MVC model which can be extended to create a full-stack application environment. This effectively means Merb itself is not an ORM but can accommodate other ORMs.
Some features of Merb are as follows :
* Speed - Merb is ORM, JavaScript library and template language agnostic, preferring plugins that add support for features rather than producing a monolithic library with everything in the core.
* Lightweight - Rather than trying to cram every feature into a single code, things are kept bare minimum without sacrificing anything important.
* Powerful and extensible - For any features not covered in Merb’s core, there are plugins.
Some basic Command distinction between Ruby on Rails and Merb :
{| class="comparison" border="1"
! Action
! Ruby on Rails
! Merb
|-
| Create new application 'app1' || rails new app1 || merb-gen app app1
|-
| Start server || rails server || merb
|-
| Start cluster of 3 beginning at port 3000 || N/A || merb -p 3000 -c 3
|-
| Interactive console || rails console || merb -i
|}

==NonSQL databases==
Instead of ORM we can also use Object-Oriented Database Management System (OODBMS) or document-oriented database like XML, where in databases are designed to store object oriented values, thus eliminating the need to convert data to and from its SQL form. Document oriented databases also eliminates the need to retrieve objects as data rows. Query languages like XQuery can be used to retrieve data sets.

The only issue is we won't be able to create application independent queries for retrieving data without restrictions to access path. Also OODBMS limits the extent of processing SQL queries.
A Relational database allows concurrent access to data, locking, indexing (fast search), as well as many other features that are not available while using XML files.

Other OODBMS (such as RavenDB) provide replication to SQL databases, as a means of addressing the need for ad-hoc queries, while preserving the increased performance and reduced complexity that may be achieved with an OODBMS for an application that has well-known query patterns.

NonSQL databases don’t provide mechanism to maintain relationship between tables. In real life though, business objects or entities do have relationship among them. ORM solutions may allow you to define these relationships in business objects and handle their storage and retrieval behind the scene

==Comparison of ORM Features==

{|cellspacing="0" border="1"
!style="width:8%"|Features
!style="width:23%"|ActiveRecord
!style="width:23%"|Sequel
!style="width:23%"|DataMapper
!style="width:23%"|MyBatis
|-
! Databases 
| MySQL, PostgreSQL, SQLite, Oracle, SQLServer, and DB2
| ADO, DataObjects, DB2, DBI, Firebird, Informix, JDBC, MySQL, ODBC, OpenBase, Oracle, PostgreSQL and SQLite3
| SQLite, MySQL, PostgreSQL, Oracle, MongoDB, SimpleDB, many others, including CouchDB, Apache Solr, Google Data API
| MySQL, PostgreSQL, SQLite, Oracle, SQLServer, and DB2
|-
! Migrations 
| Yes
| Yes
| Yes, but optional
| Yes, provides migration by Mybatis schema migration system.
|-
! EagerLoading 
| Supported by scanning the SQL fragments
| Supported using eager (preloading) and eager_graph (joins)
| Strategic Eager Loading and by using :summary
| Yes.this can be enabled or disabled by setting the lazyLoadingEnabled flag
|-
! Flexible Overriding 
| No. Overriding is done using alias methods.
| Using methods and by calling 'super'
| Using methods
| No
|-
! Dynamic Finders 
| Yes. Uses 'Method Missing'
| No. Alternative is to use <Model>.FindOrCreate(:name=>"John")
| Yes. Using the dm_ar_finders plugin
| Similar feature is supported in the form of Dynamic SQL
|}

==Further Reading==
To get more information on ORM and the different type of ORM's available for Ruby , please look into the [http://wiki.expertiza.ncsu.edu/index.php/CSC/ECE_517_Spring_2013/ch1_1d_zk CSC/ECE 517 Spring 2013/ch1 1d zk] and [http://wiki.expertiza.ncsu.edu/index.php/CSC/ECE_517_Fall_2010/ch3_3f_ac Fall 2010 detailed ORM explanation] wiki pages.
[http://www.cs.colorado.edu/~kena/classes/5448/f11/lectures/29-orm.pdf ORM - University of Colorado]

==Future Work==
More work can be done in the area of comparison between the different ORMs available for Ruby, especially a more detailed feature-by-feature comparison that includes performance differences between the ORMs.

==References ==
# [http://en.wikipedia.org/wiki/Object-relational_mapping Object Relational Mapping]
# [http://en.wikipedia.org/wiki/Object-oriented_programming object-oriented programming]
# [http://en.wikipedia.org/wiki/Data_access data access]
# [http://en.wikipedia.org/wiki/Metaprogramming metaprogramming]
# [http://guides.rubyonrails.org/active_record_basics.html Active Record]
# [http://guides.rubyonrails.org/getting_started.html#the-mvc-architecture MVC]
# [http://sequel.jeremyevans.net/documentation.html Sequel]
# [http://datamapper.org/ DataMapper]
# [http://sequel.jeremyevans.net/rdoc/classes/Sequel/ThreadedConnectionPool.html Connection Pooling]
# [http://guides.rubyonrails.org/active_record_querying.html#eager-loading-associations Eager Loading]
# [http://rubydoc.info/gems/squeel/1.1.1/frames Squeel]
# [http://www.techopedia.com/definition/24200/object-relational-mapping--orm ORM]
# [http://en.wikipedia.org/wiki/Merb Merb]
# [http://www.merbivore.com/ Merb Website]
# [http://wiki.expertiza.ncsu.edu/index.php/CSC/ECE_517_Spring_2013/ch1_1d_zk Object Relational Mapping Spring 2013]

CSC/ECE 517 Fall 2014/ch1a 25 ks

2014-09-24T22:50:54Z

Knimgao:

==Object Relational Mapping==

__TOC__

==Introduction==
[http://en.wikipedia.org/wiki/Object-relational_mapping Object Relational Mapping] (ORM, O/RM, and O/R mapping) in computer science is a programming technique for converting data between incompatible type systems in object-oriented programming languages. This creates, in effect, a "virtual object database" that can be used from within the programming language. There are both free and commercial packages available that perform object-relational mapping, although some programmers opt to create their own ORM tools.

==Overview==
Object Relational Mapping is a programming technique in which a metadata descriptor is used to connect object code to a relational database. ORM converts data between type systems that are unable to coexist within relational databases and OOP languages.

In [http://en.wikipedia.org/wiki/Object-oriented_programming object-oriented programming], data management tasks act on object-oriented (OO) objects that are almost always non-scalar values. For example, consider an address book entry that represents a single person along with zero or more phone numbers and zero or more addresses. This could be modeled in an object-oriented implementation by a "Person object" with attributes/fields to hold each data item that the entry comprises: the person's name, a list of phone numbers, and a list of addresses. The list of phone numbers would itself contain "PhoneNumber objects" and so on. The address book entry is treated as a single object by the programming language (it can be referenced by a single variable containing a pointer to the object, for instance). Various methods can be associated with the object, such as a method to return the preferred phone number, the home address, and so on.

The heart of the problem is translating the logical representation of the objects into an atomized form that is capable of being stored in the database, while preserving the properties of the objects and their relationships so that they can be reloaded as objects when needed. If this storage and retrieval functionality is implemented, the objects are said to be persistent.

==Simple Explanation==
A simple answer is that you wrap your tables or stored procedures in classes in your programming language, so that instead of writing SQL statements to interact with your database, you use methods and properties of objects.

In other words, instead of something like this:
<pre>
String sql = "SELECT ... FROM persons WHERE id = 10"
DbCommand cmd = new DbCommand(connection, sql);
Result res = cmd.Execute();
String name = res[0]["FIRST_NAME"];
</pre>
you do something like this:
<pre>
Person p = repository.GetPerson(10);
String name = p.FirstName;
</pre>
or similar code (lots of variations here.) Some frameworks also put a lot of the code in as static methods on the classes themselves, which means you could do something like this instead:
<pre>
Person p = Person.Get(10);
</pre>
Some also implement complex query systems, so you could do this:
<pre>
Person p = Person.Get(Person.Properties.Id == 10);
</pre>
The framework is what makes this code possible.

==Features==
Object-relational Mapping (ORM) frameworks unburden the designer of the complex translation between database and object space.

Typical ORM features:
* Automatic mapping from classes to database tables
** Class instance variables to database columns
** Class instances to table rows
* Aggregation and association relationships between mapped classes are managed
** Example, :has_many, :belongs_to associations in ActiveRecord
** Inheritance cases are mapped to tables
* Validation of data prior to table storage
* Class extensions to enable search, as well as creation, read, update, and deletion (CRUD) of instances/records
* Usually abstracts the database from program space in such a way that alternate database types can be easily chosen (SQLite, Oracle, etc)

The diagram below depicts a simple mapping of an object to a database table….

[[Image:3j_ks_pic1.jpg]]

ORM framework is used to persist model objects to a relational database and retrieve them, and the ORM framework will take care of converting the data between the two otherwise incompatible states. Most ORM tools rely heavily on metadata about both the database and objects, so that the objects need to know nothing about the database and the database doesn’t need to know anything about how the data is structured in the application. ORM provides a clean separation of concerns in a well-designed data application, and the database and application can each work with data in its native form. Database rows map to objects, thus making the program more easily accessible and allowing the usage of information in a way that is internally consistent and easy to understand. The ORM gives the programmer an ability to manipulate data with the programming language, instead of having to manipulate each attribute as its data type as obtained by the database management system.

When applied to Ruby, implementations of ORM often leverage the language’s [http://en.wikipedia.org/wiki/Metaprogramming metaprogramming] strengths to create intuitive application-specific methods and otherwise extend classes to support database functionality. With the addition of Rails, the ORM becomes much more important, as it is necessary to have an ORM to connect the models of the MVC (model-view-controller) stack used by Ruby on Rails with the application's database. Since the models are Ruby objects, the ORM allows modifications to the database to be done through changes to these models, independent of the type of database used.

With the release of Rails 3.0, the platform became ORM independent. With this change, it is much easier to use the ORM most preferred by the programmer, rather than being corralled into using one particular one. To allow this, the ORM needed to be extracted from the model and the database, to be a pure mediator between the two. Then any ORM can be used as long as it can successfully understand the model and the database used.

==Advantages ==
In addition to the [http://en.wikipedia.org/wiki/Data_access data access] technique, ORM's benefits also include:
*First of all, you hide the SQL away from your logic code. This has the benefit of allowing you to more easily support more database engines. For instance, MS SQL Server and Oracle has different names on typical functions, and different ways to do calculations with dates, so a query to "get me all persons edited the last 24 hours" might entail different SQL syntax just for those two database engines. This difference can be put away from your logic code.
*Additionally, you can focus on writing the logic, instead of getting all the SQL right. The code will typically be more readable as well, since it doesn't contain all the "plumbing" necessary to talk to the database.
*Simplified development because it automates object-to-table and table-to-object conversion, resulting in lower development and maintenance costs
*Less code compared to embedded SQL and handwritten stored procedures
*Transparent object caching in the application tier, improving system performance
*An optimized solution making an application faster and easier to maintain

==Disadvantages ==
*ORM’s emergence in multiple application development has created disagreement among experts. Key concerns are that ORM does not perform well and that stored procedures might be a better solution.
*In addition, ORM dependence may result in poorly-designed databases in certain circumstances.
*Performance – like every "proxy" technology
*Complexity – learning curve
*Difficulty / inability to make complex queries

==Active Records==
[http://guides.rubyonrails.org/active_record_basics.html Active Record] was described by Martin Fowler in his book Patterns of Enterprise Application Architecture. Active Record is the M in [http://guides.rubyonrails.org/getting_started.html#the-mvc-architecture MVC]- the model - which is the layer of the system responsible for representing business data and logic. In Active Record, objects carry both persistent data and behavior which operates on that data. A database table or view is wrapped into a class and an object instance is tied to a single row in the table. Each Active Record object has CRUD (Create, Read, Update, and Delete) methods for database access. In addition, Active Record allows you to validate the state of a model before it gets written into the database.

Active Record gives us several mechanisms, the most important being the ability to:
* Represent models and their data.
* Represent associations between these models.
* Represent inheritance hierarchies through related models.
* Validate models before they get persisted to the database.
* Perform database operations in an object-oriented fashion.

The naming conventions used in Active Records are :
* Database Table - Plural with underscores separating words (e.g., book_clubs).
* Model Class - Singular with the first letter of each word capitalized (e.g., BookClub).

To create a table, ActiveRecord makes use of a migration class rather than including table definition in the actual class being modeled. As an example, the following code creates a table ‘’users’’ to store a collection of class ‘’User’’ objects:
<pre>
class CreateUsers < ActiveRecord::Migration
def self.up
create_table :users do |t|
t.string :name
t.string :email
t.string :age
t.references :cheer
t.references :post

t.timestamps # add creation and modification timestamps
end
end

def self.down # undo the table creation
drop_table :users
end
end
</pre>

The ActiveRecord’s migration scheme provides a means for backing out changes via the ‘’self.down’’ method. In addition, a table key ‘’id’’ is added to the new table without an explicit definition and record creation and modification timestamps are included via the ‘’timestamps’’ method provided by ActiveRecord.

ActiveRecord manages associations between table elements and provides the means to define such associations in the model definition. For example, the ‘’User’’ class shown below defines a ‘’has_many’’ (one-to-many) association with both the cheers and posts tables. These associations are represented in the migration class with the references operator. Also note ActiveRecord’s integrated support for validation of table information when attempting an update.

<pre>
class User < ActiveRecord::Base
has_many :cheers
has_many :posts

validates_presence_of :name
validates_presence_of :age
validates_uniqueness_of :name
validates_length_of :name, :within => 3..20
end
</pre>

To access the data in the table one calls the class function related to that column. For example, to find the user who's name is Bob, one would use @user = User.find_by_name('Bob'). Then one could find Bob's e-mail by using @user.email. Users can be searched for by any attribute in this way, as find methods are created for every combination of attributes.
While ActiveRecord provides the flexibility to create more sophisticated table relationships to represent class hierarchy, its base scheme is a single table inheritance, which trades some storage efficiency for simplicity in the database design. The following figure illustrates this concept of simplicity over efficiency.

[[Image:3j_ks_pic2.jpg]]

'''Pros''' -
* Integrated with popular Rails development framework
* Dynamically created database search methods (eg: User.find_by_address) ease db queries and make queries database syntax independent
* DB creation/management using the migrate scheme provides a means for backing out unwanted table changes
'''Cons''' -
* DB creation/management is decoupled from the model, requiring a separate utility (rake/migrate) that must be kept in sync with application.

==ORM Adaptor==
[https://github.com/ianwhite/orm_adapter ORM Adaptors] provide a single point of entry for popular ruby ORMs. Its target audience is gem authors who want to support more than one ORM.
ORM Adapter's goal is to support a minimum API used by most of the plugins that needs agnosticism beyond Active Model.
ORM Adapter will support only basic methods, as get, find_first, create! and so forth. It is not ORM Adapter's goal to support different query constructions, handle table joins, etc.
ORM adapter provides a consistent API for these basic class or 'factory' methods. It does not attempt to unify the behaviour of model instances returned by these methods. This means that unifying the behaviour of methods such as `model.save`, and `model.valid?` is beyond the scope of orm_adapter.
If you need complex queries, it is recommended to subclass ORM Adapters in your plugin and extend it expressing these query conditions as part of your domain logic.
<pre>
Example :
require 'orm_adapter'
User # is it an ActiveRecord, DM Resource, MongoMapper or MongoId Document?
User.to_adapter.find_first :name => 'Fred' # we don't care!
user_model = User.to_adapter
user_model.get!(1) # find a record by id
user_model.find_first(:name => 'fred') # find first fred
user_model.find_first(:level => 'awesome', :id => 23) # find user 23, only if it's level is awesome
user_model.find_all # find all users
user_model.find_all(:name => 'fred') # find all freds
user_model.find_all(:order => :name) # find all freds, ordered by name
user_model.create!(:name => 'fred') # create a fred
user_model.destroy(object) # destroy the user object
</pre>

==Sequel==
[http://sequel.jeremyevans.net/documentation.html Sequel] was originally developed by Sharon Rosner and the first release was in March 2007. It is based on the active record pattern. Sequel and Active Record share a lot of common features , for example association and inheritance. But Sequel handles these features in a much more flexible manner. Currently Sequel is at version 3.44.0. Initially Sequel had three core modules - sequel, sequel_core and sequel_model. Starting from version 1.4 , sequel and sequel_model were merged. Sequel handles validations using a validation plug-in and helpers.

<pre>
class CreateUser < Sequel::Migration
def up
create_table(:user) {
primary_key :id
String :name
String :age
String :email}
end
def down
drop_table(:user)
end
end # CreateUser.apply(DB, :up)
</pre>

Sequel supports associations and validations similar to Active Record. The following example shows how validations and associations can be enforced in the User table that has been created above. It enforces one to many relationships between the user table and the cheers and posts tables. It also validates for the presence , uniqueness and the length of the attribute '''name'''.

<pre>
class User < Sequel::Model
one_to_many :cheers
one_to_many :posts

validates_presence [:name, :age]
validates_unique(:name)
validates_length_range 3..20, :name
end
</pre>

To access the data in Sequel, one can use where clauses. For instance, to find Bob again one would use DB[:items].where(Sequel.like(:name, 'Bob'). While the ability to use SQL-like where clauses is quite flexible, it is not quite as pure an object-oriented approach as Active Record's dynamically created find methods.

Some of the key features of sequel are,
* [http://sequel.jeremyevans.net/rdoc/classes/Sequel/ThreadedConnectionPool.html Connection Pooling]
* Thread Safety
* [http://guides.rubyonrails.org/active_record_querying.html#eager-loading-associations Eager Loading] / Lazy Loading
* Model Caching
* Supports advanced database features such as prepared statements, bound variables, stored procedures, savepoints, two-phase commit, transaction isolation, master/slave configurations, and database sharding.

==Data Mapper==
[http://datamapper.org/ DataMapper] is an Object Relational Mapper written in Ruby developed by Sam Smoot with the goal to create an ORM which is fast, thread-safe and feature rich.
A Data Mapper is a Data Access Layer that performs bidirectional transfer of data between a persistent data store (often a relational database) and an in memory data representation (the domain layer). The goal of the pattern is to keep the in memory representation and the persistent data store independent of each other and the data mapper itself. The layer is composed of one or more mappers (or Data Access Objects), performing the data transfer.
DataMapper comes with the ability to use the same API to talk to a multitude of different datastores. There are adapters for the usual RDBMS suspects, NoSQL stores, various file formats and some web services. With DataMapper, you define your mappings in your model. Your data store can develop independently of your model using Migrations.

Some features of Data Mapper are as follows :
* No need to write structural migrations
* Scoped relations
* Lazy loading on certain attribute types
* Strategic eager loading to avoid (N+1) queries
* Default support for composite and natural keys
* Query chaining, and not evaluating the query until absolutely necessary (using a lazy array implementation)
* An API not too heavily oriented to SQL databases

DataMapper was designed to be a more abstract ORM, not strictly SQL, based on Martin Fowler's enterprise pattern. As a result, DataMapper adapters have been built for other non-SQL databases, such as CouchDB, [http://github.com/lritter/dm-solr-adapter/tree/master Apache Solr], and webservices such as [http://github.com/halorgium/dm-salesforce/tree/master Salesforce].

Example of table definition in the model:
<pre>
class User
include DataMapper::Resource

property :id, Serial # key
property :name, String, :required => true, :unique => true
property :age, String, :required => true, :length => 3..20
property :email, String

has n, :posts # one to many association
has n, :cheers # one to many association
end
</pre>

Notice that in the example above , ":required = true" is an example for Auto Validation. Unlike ActiveRecord and Sequel, DataMapper supports auto validations , i.e. these in turn call the validation helpers to enforce basic validations such as length, uniqueness, format, presence etc.

==MyBatis/iBatis==
[http://en.wikipedia.org/wiki/MyBatis MyBatis/iBatis] was a persistence framework which allowed easy access of the database from a Rails application without being a full ORM. It was created by the Apache Foundation in 2002, and is available for several platforms, including Ruby (the Ruby release is known as RBatis). On 6/16/2010, after releasing iBATIS 3.0, the project team moved from Apache to Google Code, changed the project's name to MyBatis, and stopped supporting Ruby.

The MyBatis data mapper framework makes it easier to use a relational database with object-oriented applications. MyBatis couples objects with stored procedures or SQL statements using a XML descriptor. To use the MyBatis data mapper,we make use of our own objects, XML, and SQL.

SQL statements are stored in XML files or annotations. Following is a MyBatis mapper, that consists of a Java interface with some MyBatis annotations:
<pre>
package org.mybatis.example;

public interface BlogMapper {
@Select("select * from Blog where id = #{id}")
Blog selectBlog(int id);
}
</pre>
The sentence is executed as follows.
<pre>
BlogMapper mapper = session.getMapper(BlogMapper.class);
Blog blog = mapper.selectBlog(101);
</pre>

It can also be executed using MyBatis API.
<pre>
Blog blog = session.selectOne("org.mybatis.example.BlogMapper.selectBlog", 101);
</pre>

SQL statements and mappings can also be externalized to an XML file like this.
<pre>
<?xml version="1.0" encoding="UTF-8" ?>
<!DOCTYPE mapper PUBLIC "-//mybatis.org//DTD Mapper 3.0//EN" "http://mybatis.org/dtd/mybatis-3-mapper.dtd">

<mapper namespace="org.mybatis.example.BlogMapper">
<select id="selectBlog" parameterType="int" resultType="Blog">
select * from Blog where id = #{id}
</select>
</mapper>
</pre>

==Squeel==
[http://rubydoc.info/gems/squeel/1.1.1/frames Squeel]unlocks the power of Arel in Rails applications with a handy block-based syntax. It is supporting in Rails 3 and 4. With Squeel, you can write subqueries, access named functions provided by RDMBS and more without writing SQL strings.
Squeel lets you write your Active Record queries with fewer strings, and more Ruby, by making the Arel awesomeness that lies beneath Active Record more accessible.

Squeel lets you rewrite...

<pre>
Article.where ['created_at >= ?', 2.weeks.ago]
...as...
Article.where{created_at >= 2.weeks.ago}
</pre>

Squeel enhances the normal Active Record query methods by enabling them to accept blocks. Inside a block, the Squeel query DSL can be used. Note the use of curly braces in the above example instead of parentheses. {} denotes a Squeel DSL query.

Stubs and keypaths are the two primary building blocks used in a Squeel DSL query.

Stubs are, for most intents and purposes, just like Symbols in a normal call to Relation#where (note the need for doubling up on the curly braces here, the first ones start the block, the second are the hash braces):
<pre>
Person.where{{name => ‘Ernie’ }}
</pre>

You normally wouldn't bother using the DSL in this case, as a simple hash would suffice. However, stubs serve as a building block for keypaths, and keypaths are very handy.

A Squeel keypath is essentially a more concise and readable alternative to a deeply nested hash. For instance, in standard Active Record, you might join several associations like this to perform a query:
<pre>
Person.joins(:articles => { :comments => :person}).references(:all)
</pre>

With a keypath, this would look like:
<pre>
Person.joins{articles.comments.person}.references(:all)
</pre>

The Squeel DSL works its magic using instance_eval which means that inside a Squeel DSL block, self isn't the same thing that it is outside the block.
This carries with it an important implication: Instance variables and instance methods inside the block won't refer to your object's variables/methods.
Use one of the following methods to get access to the object's methods and variables:
* Assign the variable locally before the DSL block, and access it as you would normally.
* Supply an arity to the DSL block, as in Person.where{|q| q.name == @my_name} Downside: You'll need to prefix stubs, keypaths, and functions with the DSL object.
* Wrap the method or instance variable inside the block with my{}. Person.where{name == my{some_method_to_return_a_name}}

==Merb==
[http://en.wikipedia.org/wiki/Merb Merb], short for "Mongrel+Erb", is a model view controller framework written in Ruby. Merb was merged into Rails web framework on December 23, 2008 as part of the Ruby on Rails 3.0 release.
Merb itself provides only the controller of an MVC model which can be extended to create a full-stack application environment. This effectively means Merb itself is not an ORM but can accommodate other ORMs.
Some features of Merb are as follows :
* Speed - Merb is ORM, JavaScript library and template language agnostic, preferring plugins that add support for features rather than producing a monolithic library with everything in the core.
* Lightweight - Rather than trying to cram every feature into a single code, things are kept bare minimum without sacrificing anything important.
* Powerful and extensible - For any features not covered in Merb’s core, there are plugins.
Some basic Command distinction between Ruby on Rails and Merb :
{| class="comparison" border="1"
! Action
! Ruby on Rails
! Merb
|-
| Create new application 'app1' || rails new app1 || merb-gen app app1
|-
| Start server || rails server || merb
|-
| Start cluster of 3 beginning at port 3000 || N/A || merb -p 3000 -c 3
|-
| Interactive console || rails console || merb -i
|}

==NonSQL databases==
Instead of ORM we can also use Object-Oriented Database Management System (OODBMS) or document-oriented database like XML, where in databases are designed to store object oriented values, thus eliminating the need to convert data to and from its SQL form. Document oriented databases also eliminates the need to retrieve objects as data rows. Query languages like XQuery can be used to retrieve data sets.

The only issue is we won't be able to create application independent queries for retrieving data without restrictions to access path. Also OODBMS limits the extent of processing SQL queries.
A Relational database allows concurrent access to data, locking, indexing (fast search), as well as many other features that are not available while using XML files.

Other OODBMS (such as RavenDB) provide replication to SQL databases, as a means of addressing the need for ad-hoc queries, while preserving the increased performance and reduced complexity that may be achieved with an OODBMS for an application that has well-known query patterns.

NonSQL databases don’t provide mechanism to maintain relationship between tables. In real life though, business objects or entities do have relationship among them. ORM solutions may allow you to define these relationships in business objects and handle their storage and retrieval behind the scene

==Comparison of ORM Features==

{|cellspacing="0" border="1"
!style="width:8%"|Features
!style="width:23%"|ActiveRecord
!style="width:23%"|Sequel
!style="width:23%"|DataMapper
!style="width:23%"|MyBatis
|-
! Databases 
| MySQL, PostgreSQL, SQLite, Oracle, SQLServer, and DB2
| ADO, DataObjects, DB2, DBI, Firebird, Informix, JDBC, MySQL, ODBC, OpenBase, Oracle, PostgreSQL and SQLite3
| SQLite, MySQL, PostgreSQL, Oracle, MongoDB, SimpleDB, many others, including CouchDB, Apache Solr, Google Data API
| MySQL, PostgreSQL, SQLite, Oracle, SQLServer, and DB2
|-
! Migrations 
| Yes
| Yes
| Yes, but optional
| Yes, provides migration by Mybatis schema migration system.
|-
! EagerLoading 
| Supported by scanning the SQL fragments
| Supported using eager (preloading) and eager_graph (joins)
| Strategic Eager Loading and by using :summary
| Yes.this can be enabled or disabled by setting the lazyLoadingEnabled flag
|-
! Flexible Overriding 
| No. Overriding is done using alias methods.
| Using methods and by calling 'super'
| Using methods
| No
|-
! Dynamic Finders 
| Yes. Uses 'Method Missing'
| No. Alternative is to use <Model>.FindOrCreate(:name=>"John")
| Yes. Using the dm_ar_finders plugin
| Similar feature is supported in the form of Dynamic SQL
|}

==Further Reading==
To get more information on ORM and the different type of ORM's available for Ruby , please look into the [http://wiki.expertiza.ncsu.edu/index.php/CSC/ECE_517_Spring_2013/ch1_1d_zk CSC/ECE 517 Spring 2013/ch1 1d zk] and [http://wiki.expertiza.ncsu.edu/index.php/CSC/ECE_517_Fall_2010/ch3_3f_ac Fall 2010 detailed ORM explanation] wiki pages.
[http://www.cs.colorado.edu/~kena/classes/5448/f11/lectures/29-orm.pdf]

==Future Work==
More work can be done in the area of comparison between the different ORMs available for Ruby, especially a more detailed feature-by-feature comparison that includes performance differences between the ORMs.

==References ==
# [http://en.wikipedia.org/wiki/Object-relational_mapping Object Relational Mapping]
# [http://en.wikipedia.org/wiki/Object-oriented_programming object-oriented programming]
# [http://en.wikipedia.org/wiki/Data_access data access]
# [http://en.wikipedia.org/wiki/Metaprogramming metaprogramming]
# [http://guides.rubyonrails.org/active_record_basics.html Active Record]
# [http://guides.rubyonrails.org/getting_started.html#the-mvc-architecture MVC]
# [http://sequel.jeremyevans.net/documentation.html Sequel]
# [http://datamapper.org/ DataMapper]
# [http://sequel.jeremyevans.net/rdoc/classes/Sequel/ThreadedConnectionPool.html Connection Pooling]
# [http://guides.rubyonrails.org/active_record_querying.html#eager-loading-associations Eager Loading]
# [http://rubydoc.info/gems/squeel/1.1.1/frames Squeel]
# [http://www.techopedia.com/definition/24200/object-relational-mapping--orm ORM]
# [http://en.wikipedia.org/wiki/Merb Merb]
# [http://www.merbivore.com/ Merb Website]
# [http://wiki.expertiza.ncsu.edu/index.php/CSC/ECE_517_Spring_2013/ch1_1d_zk Object Relational Mapping Spring 2013]

CSC/ECE 517 Fall 2014/ch1a 25 ks

2014-09-24T22:24:53Z

Knimgao:

==Object Relational Mapping==

__TOC__

==Introduction==
[http://en.wikipedia.org/wiki/Object-relational_mapping Object Relational Mapping] (ORM, O/RM, and O/R mapping) in computer science is a programming technique for converting data between incompatible type systems in object-oriented programming languages. This creates, in effect, a "virtual object database" that can be used from within the programming language. There are both free and commercial packages available that perform object-relational mapping, although some programmers opt to create their own ORM tools.

==Overview==
Object Relational Mapping is a programming technique in which a metadata descriptor is used to connect object code to a relational database. ORM converts data between type systems that are unable to coexist within relational databases and OOP languages.

In [http://en.wikipedia.org/wiki/Object-oriented_programming object-oriented programming], data management tasks act on object-oriented (OO) objects that are almost always non-scalar values. For example, consider an address book entry that represents a single person along with zero or more phone numbers and zero or more addresses. This could be modeled in an object-oriented implementation by a "Person object" with attributes/fields to hold each data item that the entry comprises: the person's name, a list of phone numbers, and a list of addresses. The list of phone numbers would itself contain "PhoneNumber objects" and so on. The address book entry is treated as a single object by the programming language (it can be referenced by a single variable containing a pointer to the object, for instance). Various methods can be associated with the object, such as a method to return the preferred phone number, the home address, and so on.

The heart of the problem is translating the logical representation of the objects into an atomized form that is capable of being stored in the database, while preserving the properties of the objects and their relationships so that they can be reloaded as objects when needed. If this storage and retrieval functionality is implemented, the objects are said to be persistent.

==Simple Explanation==
A simple answer is that you wrap your tables or stored procedures in classes in your programming language, so that instead of writing SQL statements to interact with your database, you use methods and properties of objects.

In other words, instead of something like this:
<pre>
String sql = "SELECT ... FROM persons WHERE id = 10"
DbCommand cmd = new DbCommand(connection, sql);
Result res = cmd.Execute();
String name = res[0]["FIRST_NAME"];
</pre>
you do something like this:
<pre>
Person p = repository.GetPerson(10);
String name = p.FirstName;
</pre>
or similar code (lots of variations here.) Some frameworks also put a lot of the code in as static methods on the classes themselves, which means you could do something like this instead:
<pre>
Person p = Person.Get(10);
</pre>
Some also implement complex query systems, so you could do this:
<pre>
Person p = Person.Get(Person.Properties.Id == 10);
</pre>
The framework is what makes this code possible.

==Features==
Object-relational Mapping (ORM) frameworks unburden the designer of the complex translation between database and object space.

Typical ORM features:
* Automatic mapping from classes to database tables
** Class instance variables to database columns
** Class instances to table rows
* Aggregation and association relationships between mapped classes are managed
** Example, :has_many, :belongs_to associations in ActiveRecord
** Inheritance cases are mapped to tables
* Validation of data prior to table storage
* Class extensions to enable search, as well as creation, read, update, and deletion (CRUD) of instances/records
* Usually abstracts the database from program space in such a way that alternate database types can be easily chosen (SQLite, Oracle, etc)

The diagram below depicts a simple mapping of an object to a database table….

[[Image:3j_ks_pic1.jpg]]

ORM framework is used to persist model objects to a relational database and retrieve them, and the ORM framework will take care of converting the data between the two otherwise incompatible states. Most ORM tools rely heavily on metadata about both the database and objects, so that the objects need to know nothing about the database and the database doesn’t need to know anything about how the data is structured in the application. ORM provides a clean separation of concerns in a well-designed data application, and the database and application can each work with data in its native form. Database rows map to objects, thus making the program more easily accessible and allowing the usage of information in a way that is internally consistent and easy to understand. The ORM gives the programmer an ability to manipulate data with the programming language, instead of having to manipulate each attribute as its data type as obtained by the database management system.

When applied to Ruby, implementations of ORM often leverage the language’s [http://en.wikipedia.org/wiki/Metaprogramming metaprogramming] strengths to create intuitive application-specific methods and otherwise extend classes to support database functionality. With the addition of Rails, the ORM becomes much more important, as it is necessary to have an ORM to connect the models of the MVC (model-view-controller) stack used by Ruby on Rails with the application's database. Since the models are Ruby objects, the ORM allows modifications to the database to be done through changes to these models, independent of the type of database used.

With the release of Rails 3.0, the platform became ORM independent. With this change, it is much easier to use the ORM most preferred by the programmer, rather than being corralled into using one particular one. To allow this, the ORM needed to be extracted from the model and the database, to be a pure mediator between the two. Then any ORM can be used as long as it can successfully understand the model and the database used.

==Advantages ==
In addition to the [http://en.wikipedia.org/wiki/Data_access data access] technique, ORM's benefits also include:
*First of all, you hide the SQL away from your logic code. This has the benefit of allowing you to more easily support more database engines. For instance, MS SQL Server and Oracle has different names on typical functions, and different ways to do calculations with dates, so a query to "get me all persons edited the last 24 hours" might entail different SQL syntax just for those two database engines. This difference can be put away from your logic code.
*Additionally, you can focus on writing the logic, instead of getting all the SQL right. The code will typically be more readable as well, since it doesn't contain all the "plumbing" necessary to talk to the database.
*Simplified development because it automates object-to-table and table-to-object conversion, resulting in lower development and maintenance costs
*Less code compared to embedded SQL and handwritten stored procedures
*Transparent object caching in the application tier, improving system performance
*An optimized solution making an application faster and easier to maintain

==Disadvantages ==
*ORM’s emergence in multiple application development has created disagreement among experts. Key concerns are that ORM does not perform well and that stored procedures might be a better solution.
*In addition, ORM dependence may result in poorly-designed databases in certain circumstances.
*Performance – like every "proxy" technology
*Complexity – learning curve
*Difficulty / inability to make complex queries

==Active Records==
[http://guides.rubyonrails.org/active_record_basics.html Active Record] was described by Martin Fowler in his book Patterns of Enterprise Application Architecture. Active Record is the M in [http://guides.rubyonrails.org/getting_started.html#the-mvc-architecture MVC]- the model - which is the layer of the system responsible for representing business data and logic. In Active Record, objects carry both persistent data and behavior which operates on that data. A database table or view is wrapped into a class and an object instance is tied to a single row in the table. Each Active Record object has CRUD (Create, Read, Update, and Delete) methods for database access. In addition, Active Record allows you to validate the state of a model before it gets written into the database.

Active Record gives us several mechanisms, the most important being the ability to:
* Represent models and their data.
* Represent associations between these models.
* Represent inheritance hierarchies through related models.
* Validate models before they get persisted to the database.
* Perform database operations in an object-oriented fashion.

The naming conventions used in Active Records are :
* Database Table - Plural with underscores separating words (e.g., book_clubs).
* Model Class - Singular with the first letter of each word capitalized (e.g., BookClub).

To create a table, ActiveRecord makes use of a migration class rather than including table definition in the actual class being modeled. As an example, the following code creates a table ‘’users’’ to store a collection of class ‘’User’’ objects:
<pre>
class CreateUsers < ActiveRecord::Migration
def self.up
create_table :users do |t|
t.string :name
t.string :email
t.string :age
t.references :cheer
t.references :post

t.timestamps # add creation and modification timestamps
end
end

def self.down # undo the table creation
drop_table :users
end
end
</pre>

The ActiveRecord’s migration scheme provides a means for backing out changes via the ‘’self.down’’ method. In addition, a table key ‘’id’’ is added to the new table without an explicit definition and record creation and modification timestamps are included via the ‘’timestamps’’ method provided by ActiveRecord.

ActiveRecord manages associations between table elements and provides the means to define such associations in the model definition. For example, the ‘’User’’ class shown below defines a ‘’has_many’’ (one-to-many) association with both the cheers and posts tables. These associations are represented in the migration class with the references operator. Also note ActiveRecord’s integrated support for validation of table information when attempting an update.

<pre>
class User < ActiveRecord::Base
has_many :cheers
has_many :posts

validates_presence_of :name
validates_presence_of :age
validates_uniqueness_of :name
validates_length_of :name, :within => 3..20
end
</pre>

To access the data in the table one calls the class function related to that column. For example, to find the user who's name is Bob, one would use @user = User.find_by_name('Bob'). Then one could find Bob's e-mail by using @user.email. Users can be searched for by any attribute in this way, as find methods are created for every combination of attributes.
While ActiveRecord provides the flexibility to create more sophisticated table relationships to represent class hierarchy, its base scheme is a single table inheritance, which trades some storage efficiency for simplicity in the database design. The following figure illustrates this concept of simplicity over efficiency.

[[Image:3j_ks_pic2.jpg]]

'''Pros''' -
* Integrated with popular Rails development framework
* Dynamically created database search methods (eg: User.find_by_address) ease db queries and make queries database syntax independent
* DB creation/management using the migrate scheme provides a means for backing out unwanted table changes
'''Cons''' -
* DB creation/management is decoupled from the model, requiring a separate utility (rake/migrate) that must be kept in sync with application.

==ORM Adaptor==
[https://github.com/ianwhite/orm_adapter ORM Adaptors] provide a single point of entry for popular ruby ORMs. Its target audience is gem authors who want to support more than one ORM.
ORM Adapter's goal is to support a minimum API used by most of the plugins that needs agnosticism beyond Active Model.
ORM Adapter will support only basic methods, as get, find_first, create! and so forth. It is not ORM Adapter's goal to support different query constructions, handle table joins, etc.
ORM adapter provides a consistent API for these basic class or 'factory' methods. It does not attempt to unify the behaviour of model instances returned by these methods. This means that unifying the behaviour of methods such as `model.save`, and `model.valid?` is beyond the scope of orm_adapter.
If you need complex queries, it is recommended to subclass ORM Adapters in your plugin and extend it expressing these query conditions as part of your domain logic.
<pre>
Example :
require 'orm_adapter'
User # is it an ActiveRecord, DM Resource, MongoMapper or MongoId Document?
User.to_adapter.find_first :name => 'Fred' # we don't care!
user_model = User.to_adapter
user_model.get!(1) # find a record by id
user_model.find_first(:name => 'fred') # find first fred
user_model.find_first(:level => 'awesome', :id => 23) # find user 23, only if it's level is awesome
user_model.find_all # find all users
user_model.find_all(:name => 'fred') # find all freds
user_model.find_all(:order => :name) # find all freds, ordered by name
user_model.create!(:name => 'fred') # create a fred
user_model.destroy(object) # destroy the user object
</pre>

==Sequel==
[http://sequel.jeremyevans.net/documentation.html Sequel] was originally developed by Sharon Rosner and the first release was in March 2007. It is based on the active record pattern. Sequel and Active Record share a lot of common features , for example association and inheritance. But Sequel handles these features in a much more flexible manner. Currently Sequel is at version 3.44.0. Initially Sequel had three core modules - sequel, sequel_core and sequel_model. Starting from version 1.4 , sequel and sequel_model were merged. Sequel handles validations using a validation plug-in and helpers.

<pre>
class CreateUser < Sequel::Migration
def up
create_table(:user) {
primary_key :id
String :name
String :age
String :email}
end
def down
drop_table(:user)
end
end # CreateUser.apply(DB, :up)
</pre>

Sequel supports associations and validations similar to Active Record. The following example shows how validations and associations can be enforced in the User table that has been created above. It enforces one to many relationships between the user table and the cheers and posts tables. It also validates for the presence , uniqueness and the length of the attribute '''name'''.

<pre>
class User < Sequel::Model
one_to_many :cheers
one_to_many :posts

validates_presence [:name, :age]
validates_unique(:name)
validates_length_range 3..20, :name
end
</pre>

To access the data in Sequel, one can use where clauses. For instance, to find Bob again one would use DB[:items].where(Sequel.like(:name, 'Bob'). While the ability to use SQL-like where clauses is quite flexible, it is not quite as pure an object-oriented approach as Active Record's dynamically created find methods.

Some of the key features of sequel are,
* [http://sequel.jeremyevans.net/rdoc/classes/Sequel/ThreadedConnectionPool.html Connection Pooling]
* Thread Safety
* [http://guides.rubyonrails.org/active_record_querying.html#eager-loading-associations Eager Loading] / Lazy Loading
* Model Caching
* Supports advanced database features such as prepared statements, bound variables, stored procedures, savepoints, two-phase commit, transaction isolation, master/slave configurations, and database sharding.

==Data Mapper==
[http://datamapper.org/ DataMapper] is an Object Relational Mapper written in Ruby developed by Sam Smoot with the goal to create an ORM which is fast, thread-safe and feature rich.
A Data Mapper is a Data Access Layer that performs bidirectional transfer of data between a persistent data store (often a relational database) and an in memory data representation (the domain layer). The goal of the pattern is to keep the in memory representation and the persistent data store independent of each other and the data mapper itself. The layer is composed of one or more mappers (or Data Access Objects), performing the data transfer.
DataMapper comes with the ability to use the same API to talk to a multitude of different datastores. There are adapters for the usual RDBMS suspects, NoSQL stores, various file formats and some web services. With DataMapper, you define your mappings in your model. Your data store can develop independently of your model using Migrations.

Some features of Data Mapper are as follows :
* No need to write structural migrations
* Scoped relations
* Lazy loading on certain attribute types
* Strategic eager loading to avoid (N+1) queries
* Default support for composite and natural keys
* Query chaining, and not evaluating the query until absolutely necessary (using a lazy array implementation)
* An API not too heavily oriented to SQL databases

DataMapper was designed to be a more abstract ORM, not strictly SQL, based on Martin Fowler's enterprise pattern. As a result, DataMapper adapters have been built for other non-SQL databases, such as CouchDB, [http://github.com/lritter/dm-solr-adapter/tree/master Apache Solr], and webservices such as [http://github.com/halorgium/dm-salesforce/tree/master Salesforce].

Example of table definition in the model:
<pre>
class User
include DataMapper::Resource

property :id, Serial # key
property :name, String, :required => true, :unique => true
property :age, String, :required => true, :length => 3..20
property :email, String

has n, :posts # one to many association
has n, :cheers # one to many association
end
</pre>

Notice that in the example above , ":required = true" is an example for Auto Validation. Unlike ActiveRecord and Sequel, DataMapper supports auto validations , i.e. these in turn call the validation helpers to enforce basic validations such as length, uniqueness, format, presence etc.

==MyBatis/iBatis==
[http://en.wikipedia.org/wiki/MyBatis MyBatis/iBatis] was a persistence framework which allowed easy access of the database from a Rails application without being a full ORM. It was created by the Apache Foundation in 2002, and is available for several platforms, including Ruby (the Ruby release is known as RBatis). On 6/16/2010, after releasing iBATIS 3.0, the project team moved from Apache to Google Code, changed the project's name to MyBatis, and stopped supporting Ruby.

The MyBatis data mapper framework makes it easier to use a relational database with object-oriented applications. MyBatis couples objects with stored procedures or SQL statements using a XML descriptor. To use the MyBatis data mapper,we make use of our own objects, XML, and SQL.

SQL statements are stored in XML files or annotations. Following is a MyBatis mapper, that consists of a Java interface with some MyBatis annotations:
<pre>
package org.mybatis.example;

public interface BlogMapper {
@Select("select * from Blog where id = #{id}")
Blog selectBlog(int id);
}
</pre>
The sentence is executed as follows.
<pre>
BlogMapper mapper = session.getMapper(BlogMapper.class);
Blog blog = mapper.selectBlog(101);
</pre>

It can also be executed using MyBatis API.
<pre>
Blog blog = session.selectOne("org.mybatis.example.BlogMapper.selectBlog", 101);
</pre>

SQL statements and mappings can also be externalized to an XML file like this.
<pre>
<?xml version="1.0" encoding="UTF-8" ?>
<!DOCTYPE mapper PUBLIC "-//mybatis.org//DTD Mapper 3.0//EN" "http://mybatis.org/dtd/mybatis-3-mapper.dtd">

<mapper namespace="org.mybatis.example.BlogMapper">
<select id="selectBlog" parameterType="int" resultType="Blog">
select * from Blog where id = #{id}
</select>
</mapper>
</pre>

==Squeel==
[http://rubydoc.info/gems/squeel/1.1.1/frames Squeel]unlocks the power of Arel in Rails applications with a handy block-based syntax. It is supporting in Rails 3 and 4. With Squeel, you can write subqueries, access named functions provided by RDMBS and more without writing SQL strings.
Squeel lets you write your Active Record queries with fewer strings, and more Ruby, by making the Arel awesomeness that lies beneath Active Record more accessible.

Squeel lets you rewrite...

<pre>
Article.where ['created_at >= ?', 2.weeks.ago]
...as...
Article.where{created_at >= 2.weeks.ago}
</pre>

Squeel enhances the normal Active Record query methods by enabling them to accept blocks. Inside a block, the Squeel query DSL can be used. Note the use of curly braces in the above example instead of parentheses. {} denotes a Squeel DSL query.

Stubs and keypaths are the two primary building blocks used in a Squeel DSL query.

Stubs are, for most intents and purposes, just like Symbols in a normal call to Relation#where (note the need for doubling up on the curly braces here, the first ones start the block, the second are the hash braces):
<pre>
Person.where{{name => ‘Ernie’ }}
</pre>

You normally wouldn't bother using the DSL in this case, as a simple hash would suffice. However, stubs serve as a building block for keypaths, and keypaths are very handy.

A Squeel keypath is essentially a more concise and readable alternative to a deeply nested hash. For instance, in standard Active Record, you might join several associations like this to perform a query:
<pre>
Person.joins(:articles => { :comments => :person}).references(:all)
</pre>

With a keypath, this would look like:
<pre>
Person.joins{articles.comments.person}.references(:all)
</pre>

The Squeel DSL works its magic using instance_eval which means that inside a Squeel DSL block, self isn't the same thing that it is outside the block.
This carries with it an important implication: Instance variables and instance methods inside the block won't refer to your object's variables/methods.
Use one of the following methods to get access to the object's methods and variables:
* Assign the variable locally before the DSL block, and access it as you would normally.
* Supply an arity to the DSL block, as in Person.where{|q| q.name == @my_name} Downside: You'll need to prefix stubs, keypaths, and functions with the DSL object.
* Wrap the method or instance variable inside the block with my{}. Person.where{name == my{some_method_to_return_a_name}}

==Merb==
[http://en.wikipedia.org/wiki/Merb Merb], short for "Mongrel+Erb", is a model view controller framework written in Ruby. Merb was merged into Rails web framework on December 23, 2008 as part of the Ruby on Rails 3.0 release.
Merb itself provides only the controller of an MVC model which can be extended to create a full-stack application environment. This effectively means Merb itself is not an ORM but can accommodate other ORMs.
Some features of Merb are as follows :
* Speed - Merb is ORM, JavaScript library and template language agnostic, preferring plugins that add support for features rather than producing a monolithic library with everything in the core.
* Lightweight - Rather than trying to cram every feature into a single code, things are kept bare minimum without sacrificing anything important.
* Powerful and extensible - For any features not covered in Merb’s core, there are plugins.
Some basic Command distinction between Ruby on Rails and Merb :
{| class="comparison" border="1"
! Action
! Ruby on Rails
! Merb
|-
| Create new application 'app1' || rails new app1 || merb-gen app app1
|-
| Start server || rails server || merb
|-
| Start cluster of 3 beginning at port 3000 || N/A || merb -p 3000 -c 3
|-
| Interactive console || rails console || merb -i
|}

==NonSQL databases==
Instead of ORM we can also use Object-Oriented Database Management System (OODBMS) or document-oriented database like XML, where in databases are designed to store object oriented values, thus eliminating the need to convert data to and from its SQL form. Document oriented databases also eliminates the need to retrieve objects as data rows. Query languages like XQuery can be used to retrieve data sets.

The only issue is we won't be able to create application independent queries for retrieving data without restrictions to access path. Also OODBMS limits the extent of processing SQL queries.
A Relational database allows concurrent access to data, locking, indexing (fast search), as well as many other features that are not available while using XML files.

Other OODBMS (such as RavenDB) provide replication to SQL databases, as a means of addressing the need for ad-hoc queries, while preserving the increased performance and reduced complexity that may be achieved with an OODBMS for an application that has well-known query patterns.

NonSQL databases don’t provide mechanism to maintain relationship between tables. In real life though, business objects or entities do have relationship among them. ORM solutions may allow you to define these relationships in business objects and handle their storage and retrieval behind the scene

==Comparison of ORM Features==

{|cellspacing="0" border="1"
!style="width:8%"|Features
!style="width:23%"|ActiveRecord
!style="width:23%"|Sequel
!style="width:23%"|DataMapper
!style="width:23%"|MyBatis
|-
! Databases 
| MySQL, PostgreSQL, SQLite, Oracle, SQLServer, and DB2
| ADO, DataObjects, DB2, DBI, Firebird, Informix, JDBC, MySQL, ODBC, OpenBase, Oracle, PostgreSQL and SQLite3
| SQLite, MySQL, PostgreSQL, Oracle, MongoDB, SimpleDB, many others, including CouchDB, Apache Solr, Google Data API
| MySQL, PostgreSQL, SQLite, Oracle, SQLServer, and DB2
|-
! Migrations 
| Yes
| Yes
| Yes, but optional
| Yes, provides migration by Mybatis schema migration system.
|-
! EagerLoading 
| Supported by scanning the SQL fragments
| Supported using eager (preloading) and eager_graph (joins)
| Strategic Eager Loading and by using :summary
| Yes.this can be enabled or disabled by setting the lazyLoadingEnabled flag
|-
! Flexible Overriding 
| No. Overriding is done using alias methods.
| Using methods and by calling 'super'
| Using methods
| No
|-
! Dynamic Finders 
| Yes. Uses 'Method Missing'
| No. Alternative is to use <Model>.FindOrCreate(:name=>"John")
| Yes. Using the dm_ar_finders plugin
| Similar feature is supported in the form of Dynamic SQL
|}

==Further Reading==
To get more information on ORM and the different type of ORM's available for Ruby , please look into the [http://wiki.expertiza.ncsu.edu/index.php/CSC/ECE_517_Spring_2013/ch1_1d_zk CSC/ECE 517 Spring 2013/ch1 1d zk] and [http://wiki.expertiza.ncsu.edu/index.php/CSC/ECE_517_Fall_2010/ch3_3f_ac Fall 2010 detailed ORM explanation] wiki pages.

==Future Work==
More work can be done in the area of comparison between the different ORMs available for Ruby, especially a more detailed feature-by-feature comparison that includes performance differences between the ORMs.

==References ==
# [http://en.wikipedia.org/wiki/Object-relational_mapping Object Relational Mapping]
# [http://en.wikipedia.org/wiki/Object-oriented_programming object-oriented programming]
# [http://en.wikipedia.org/wiki/Data_access data access]
# [http://en.wikipedia.org/wiki/Metaprogramming metaprogramming]
# [http://guides.rubyonrails.org/active_record_basics.html Active Record]
# [http://guides.rubyonrails.org/getting_started.html#the-mvc-architecture MVC]
# [http://sequel.jeremyevans.net/documentation.html Sequel]
# [http://datamapper.org/ DataMapper]
# [http://sequel.jeremyevans.net/rdoc/classes/Sequel/ThreadedConnectionPool.html Connection Pooling]
# [http://guides.rubyonrails.org/active_record_querying.html#eager-loading-associations Eager Loading]
# [http://rubydoc.info/gems/squeel/1.1.1/frames Squeel]
# [http://www.techopedia.com/definition/24200/object-relational-mapping--orm ORM]
# [http://en.wikipedia.org/wiki/Merb Merb]
# [http://www.merbivore.com/ Merb Website]
# [http://wiki.expertiza.ncsu.edu/index.php/CSC/ECE_517_Spring_2013/ch1_1d_zk Object Relational Mapping Spring 2013]

CSC/ECE 517 Fall 2014/ch1a 25 ks

2014-09-24T22:22:52Z

Knimgao: /* Sequel */

==Object Relational Mapping==

__TOC__

==Introduction==
[http://en.wikipedia.org/wiki/Object-relational_mapping Object Relational Mapping] (ORM, O/RM, and O/R mapping) in computer science is a programming technique for converting data between incompatible type systems in object-oriented programming languages. This creates, in effect, a "virtual object database" that can be used from within the programming language. There are both free and commercial packages available that perform object-relational mapping, although some programmers opt to create their own ORM tools.

==Overview==
Object Relational Mapping is a programming technique in which a metadata descriptor is used to connect object code to a relational database. ORM converts data between type systems that are unable to coexist within relational databases and OOP languages.

In [http://en.wikipedia.org/wiki/Object-oriented_programming object-oriented programming], data management tasks act on object-oriented (OO) objects that are almost always non-scalar values. For example, consider an address book entry that represents a single person along with zero or more phone numbers and zero or more addresses. This could be modeled in an object-oriented implementation by a "Person object" with attributes/fields to hold each data item that the entry comprises: the person's name, a list of phone numbers, and a list of addresses. The list of phone numbers would itself contain "PhoneNumber objects" and so on. The address book entry is treated as a single object by the programming language (it can be referenced by a single variable containing a pointer to the object, for instance). Various methods can be associated with the object, such as a method to return the preferred phone number, the home address, and so on.

The heart of the problem is translating the logical representation of the objects into an atomized form that is capable of being stored in the database, while preserving the properties of the objects and their relationships so that they can be reloaded as objects when needed. If this storage and retrieval functionality is implemented, the objects are said to be persistent.

==Simple Explanation==
A simple answer is that you wrap your tables or stored procedures in classes in your programming language, so that instead of writing SQL statements to interact with your database, you use methods and properties of objects.

In other words, instead of something like this:
<pre>
String sql = "SELECT ... FROM persons WHERE id = 10"
DbCommand cmd = new DbCommand(connection, sql);
Result res = cmd.Execute();
String name = res[0]["FIRST_NAME"];
</pre>
you do something like this:
<pre>
Person p = repository.GetPerson(10);
String name = p.FirstName;
</pre>
or similar code (lots of variations here.) Some frameworks also put a lot of the code in as static methods on the classes themselves, which means you could do something like this instead:
<pre>
Person p = Person.Get(10);
</pre>
Some also implement complex query systems, so you could do this:
<pre>
Person p = Person.Get(Person.Properties.Id == 10);
</pre>
The framework is what makes this code possible.

==Features==
Object-relational Mapping (ORM) frameworks unburden the designer of the complex translation between database and object space.

Typical ORM features:
* Automatic mapping from classes to database tables
** Class instance variables to database columns
** Class instances to table rows
* Aggregation and association relationships between mapped classes are managed
** Example, :has_many, :belongs_to associations in ActiveRecord
** Inheritance cases are mapped to tables
* Validation of data prior to table storage
* Class extensions to enable search, as well as creation, read, update, and deletion (CRUD) of instances/records
* Usually abstracts the database from program space in such a way that alternate database types can be easily chosen (SQLite, Oracle, etc)

The diagram below depicts a simple mapping of an object to a database table….

[[Image:3j_ks_pic1.jpg]]

ORM framework is used to persist model objects to a relational database and retrieve them, and the ORM framework will take care of converting the data between the two otherwise incompatible states. Most ORM tools rely heavily on metadata about both the database and objects, so that the objects need to know nothing about the database and the database doesn’t need to know anything about how the data is structured in the application. ORM provides a clean separation of concerns in a well-designed data application, and the database and application can each work with data in its native form. Database rows map to objects, thus making the program more easily accessible and allowing the usage of information in a way that is internally consistent and easy to understand. The ORM gives the programmer an ability to manipulate data with the programming language, instead of having to manipulate each attribute as its data type as obtained by the database management system.

When applied to Ruby, implementations of ORM often leverage the language’s [http://en.wikipedia.org/wiki/Metaprogramming metaprogramming] strengths to create intuitive application-specific methods and otherwise extend classes to support database functionality. With the addition of Rails, the ORM becomes much more important, as it is necessary to have an ORM to connect the models of the MVC (model-view-controller) stack used by Ruby on Rails with the application's database. Since the models are Ruby objects, the ORM allows modifications to the database to be done through changes to these models, independent of the type of database used.

With the release of Rails 3.0, the platform became ORM independent. With this change, it is much easier to use the ORM most preferred by the programmer, rather than being corralled into using one particular one. To allow this, the ORM needed to be extracted from the model and the database, to be a pure mediator between the two. Then any ORM can be used as long as it can successfully understand the model and the database used.

==Advantages ==
In addition to the [http://en.wikipedia.org/wiki/Data_access data access] technique, ORM's benefits also include:
*First of all, you hide the SQL away from your logic code. This has the benefit of allowing you to more easily support more database engines. For instance, MS SQL Server and Oracle has different names on typical functions, and different ways to do calculations with dates, so a query to "get me all persons edited the last 24 hours" might entail different SQL syntax just for those two database engines. This difference can be put away from your logic code.
*Additionally, you can focus on writing the logic, instead of getting all the SQL right. The code will typically be more readable as well, since it doesn't contain all the "plumbing" necessary to talk to the database.
*Simplified development because it automates object-to-table and table-to-object conversion, resulting in lower development and maintenance costs
*Less code compared to embedded SQL and handwritten stored procedures
*Transparent object caching in the application tier, improving system performance
*An optimized solution making an application faster and easier to maintain

==Disadvantages ==
*ORM’s emergence in multiple application development has created disagreement among experts. Key concerns are that ORM does not perform well and that stored procedures might be a better solution.
*In addition, ORM dependence may result in poorly-designed databases in certain circumstances.
*Performance – like every "proxy" technology
*Complexity – learning curve
*Difficulty / inability to make complex queries

==Active Records==
[http://guides.rubyonrails.org/active_record_basics.html Active Record] was described by Martin Fowler in his book Patterns of Enterprise Application Architecture. Active Record is the M in [http://guides.rubyonrails.org/getting_started.html#the-mvc-architecture MVC]- the model - which is the layer of the system responsible for representing business data and logic. In Active Record, objects carry both persistent data and behavior which operates on that data. A database table or view is wrapped into a class and an object instance is tied to a single row in the table. Each Active Record object has CRUD (Create, Read, Update, and Delete) methods for database access. In addition, Active Record allows you to validate the state of a model before it gets written into the database.

Active Record gives us several mechanisms, the most important being the ability to:
* Represent models and their data.
* Represent associations between these models.
* Represent inheritance hierarchies through related models.
* Validate models before they get persisted to the database.
* Perform database operations in an object-oriented fashion.

The naming conventions used in Active Records are :
* Database Table - Plural with underscores separating words (e.g., book_clubs).
* Model Class - Singular with the first letter of each word capitalized (e.g., BookClub).

To create a table, ActiveRecord makes use of a migration class rather than including table definition in the actual class being modeled. As an example, the following code creates a table ‘’users’’ to store a collection of class ‘’User’’ objects:
<pre>
class CreateUsers < ActiveRecord::Migration
def self.up
create_table :users do |t|
t.string :name
t.string :email
t.string :age
t.references :cheer
t.references :post

t.timestamps # add creation and modification timestamps
end
end

def self.down # undo the table creation
drop_table :users
end
end
</pre>

The ActiveRecord’s migration scheme provides a means for backing out changes via the ‘’self.down’’ method. In addition, a table key ‘’id’’ is added to the new table without an explicit definition and record creation and modification timestamps are included via the ‘’timestamps’’ method provided by ActiveRecord.

ActiveRecord manages associations between table elements and provides the means to define such associations in the model definition. For example, the ‘’User’’ class shown below defines a ‘’has_many’’ (one-to-many) association with both the cheers and posts tables. These associations are represented in the migration class with the references operator. Also note ActiveRecord’s integrated support for validation of table information when attempting an update.

<pre>
class User < ActiveRecord::Base
has_many :cheers
has_many :posts

validates_presence_of :name
validates_presence_of :age
validates_uniqueness_of :name
validates_length_of :name, :within => 3..20
end
</pre>

To access the data in the table one calls the class function related to that column. For example, to find the user who's name is Bob, one would use @user = User.find_by_name('Bob'). Then one could find Bob's e-mail by using @user.email. Users can be searched for by any attribute in this way, as find methods are created for every combination of attributes.
While ActiveRecord provides the flexibility to create more sophisticated table relationships to represent class hierarchy, its base scheme is a single table inheritance, which trades some storage efficiency for simplicity in the database design. The following figure illustrates this concept of simplicity over efficiency.

[[Image:3j_ks_pic2.jpg]]

'''Pros''' -
* Integrated with popular Rails development framework
* Dynamically created database search methods (eg: User.find_by_address) ease db queries and make queries database syntax independent
* DB creation/management using the migrate scheme provides a means for backing out unwanted table changes
'''Cons''' -
* DB creation/management is decoupled from the model, requiring a separate utility (rake/migrate) that must be kept in sync with application.

==ORM Adaptor==
[https://github.com/ianwhite/orm_adapter ORM Adaptors] provide a single point of entry for popular ruby ORMs. Its target audience is gem authors who want to support more than one ORM.
ORM Adapter's goal is to support a minimum API used by most of the plugins that needs agnosticism beyond Active Model.
ORM Adapter will support only basic methods, as get, find_first, create! and so forth. It is not ORM Adapter's goal to support different query constructions, handle table joins, etc.
ORM adapter provides a consistent API for these basic class or 'factory' methods. It does not attempt to unify the behaviour of model instances returned by these methods. This means that unifying the behaviour of methods such as `model.save`, and `model.valid?` is beyond the scope of orm_adapter.
If you need complex queries, it is recommended to subclass ORM Adapters in your plugin and extend it expressing these query conditions as part of your domain logic.
<pre>
Example :
require 'orm_adapter'
User # is it an ActiveRecord, DM Resource, MongoMapper or MongoId Document?
User.to_adapter.find_first :name => 'Fred' # we don't care!
user_model = User.to_adapter
user_model.get!(1) # find a record by id
user_model.find_first(:name => 'fred') # find first fred
user_model.find_first(:level => 'awesome', :id => 23) # find user 23, only if it's level is awesome
user_model.find_all # find all users
user_model.find_all(:name => 'fred') # find all freds
user_model.find_all(:order => :name) # find all freds, ordered by name
user_model.create!(:name => 'fred') # create a fred
user_model.destroy(object) # destroy the user object
</pre>

==Sequel==
[http://sequel.jeremyevans.net/documentation.html Sequel] was originally developed by Sharon Rosner and the first release was in March 2007. It is based on the active record pattern. Sequel and Active Record share a lot of common features , for example association and inheritance. But Sequel handles these features in a much more flexible manner. Currently Sequel is at version 3.44.0. Initially Sequel had three core modules - sequel, sequel_core and sequel_model. Starting from version 1.4 , sequel and sequel_model were merged. Sequel handles validations using a validation plug-in and helpers.

<pre>
class CreateUser < Sequel::Migration
def up
create_table(:user) {
primary_key :id
String :name
String :age
String :email}
end
def down
drop_table(:user)
end
end # CreateUser.apply(DB, :up)
</pre>

Sequel supports associations and validations similar to Active Record. The following example shows how validations and associations can be enforced in the User table that has been created above. It enforces one to many relationships between the user table and the cheers and posts tables. It also validates for the presence , uniqueness and the length of the attribute '''name'''.

<pre>
class User < Sequel::Model
one_to_many :cheers
one_to_many :posts

validates_presence [:name, :age]
validates_unique(:name)
validates_length_range 3..20, :name
end
</pre>

To access the data in Sequel, one can use where clauses. For instance, to find Bob again one would use DB[:items].where(Sequel.like(:name, 'Bob'). While the ability to use SQL-like where clauses is quite flexible, it is not quite as pure an object-oriented approach as Active Record's dynamically created find methods.

Some of the key features of sequel are,
* [http://sequel.jeremyevans.net/rdoc/classes/Sequel/ThreadedConnectionPool.html Connection Pooling]
* Thread Safety
* [http://guides.rubyonrails.org/active_record_querying.html#eager-loading-associations Eager Loading] / Lazy Loading
* Model Caching
* Supports advanced database features such as prepared statements, bound variables, stored procedures, savepoints, two-phase commit, transaction isolation, master/slave configurations, and database sharding.

==Data Mapper==
[http://datamapper.org/ DataMapper] is an Object Relational Mapper written in Ruby developed by Sam Smoot with the goal to create an ORM which is fast, thread-safe and feature rich.
A Data Mapper is a Data Access Layer that performs bidirectional transfer of data between a persistent data store (often a relational database) and an in memory data representation (the domain layer). The goal of the pattern is to keep the in memory representation and the persistent data store independent of each other and the data mapper itself. The layer is composed of one or more mappers (or Data Access Objects), performing the data transfer.
DataMapper comes with the ability to use the same API to talk to a multitude of different datastores. There are adapters for the usual RDBMS suspects, NoSQL stores, various file formats and some web services. With DataMapper, you define your mappings in your model. Your data store can develop independently of your model using Migrations.

Some features of Data Mapper are as follows :
* No need to write structural migrations
* Scoped relations
* Lazy loading on certain attribute types
* Strategic eager loading to avoid (N+1) queries
* Default support for composite and natural keys
* Query chaining, and not evaluating the query until absolutely necessary (using a lazy array implementation)
* An API not too heavily oriented to SQL databases

DataMapper was designed to be a more abstract ORM, not strictly SQL, based on Martin Fowler's enterprise pattern. As a result, DataMapper adapters have been built for other non-SQL databases, such as CouchDB, [http://github.com/lritter/dm-solr-adapter/tree/master Apache Solr], and webservices such as [http://github.com/halorgium/dm-salesforce/tree/master Salesforce].

Example of table definition in the model:
<pre>
class User
include DataMapper::Resource

property :id, Serial # key
property :name, String, :required => true, :unique => true
property :age, String, :required => true, :length => 3..20
property :email, String

has n, :posts # one to many association
has n, :cheers # one to many association
end
</pre>

Notice that in the example above , ":required = true" is an example for Auto Validation. Unlike ActiveRecord and Sequel, DataMapper supports auto validations , i.e. these in turn call the validation helpers to enforce basic validations such as length, uniqueness, format, presence etc.

==MyBatis/iBatis==
[http://en.wikipedia.org/wiki/MyBatis MyBatis/iBatis] was a persistence framework which allowed easy access of the database from a Rails application without being a full ORM. It was created by the Apache Foundation in 2002, and is available for several platforms, including Ruby (the Ruby release is known as RBatis). On 6/16/2010, after releasing iBATIS 3.0, the project team moved from Apache to Google Code, changed the project's name to MyBatis, and stopped supporting Ruby.

The MyBatis data mapper framework makes it easier to use a relational database with object-oriented applications. MyBatis couples objects with stored procedures or SQL statements using a XML descriptor. To use the MyBatis data mapper,we make use of our own objects, XML, and SQL.

SQL statements are stored in XML files or annotations. Following is a MyBatis mapper, that consists of a Java interface with some MyBatis annotations:
<pre>
package org.mybatis.example;

public interface BlogMapper {
@Select("select * from Blog where id = #{id}")
Blog selectBlog(int id);
}
</pre>
The sentence is executed as follows.
<pre>
BlogMapper mapper = session.getMapper(BlogMapper.class);
Blog blog = mapper.selectBlog(101);
</pre>

It can also be executed using MyBatis API.
<pre>
Blog blog = session.selectOne("org.mybatis.example.BlogMapper.selectBlog", 101);
</pre>

SQL statements and mappings can also be externalized to an XML file like this.
<pre>
<?xml version="1.0" encoding="UTF-8" ?>
<!DOCTYPE mapper PUBLIC "-//mybatis.org//DTD Mapper 3.0//EN" "http://mybatis.org/dtd/mybatis-3-mapper.dtd">

<mapper namespace="org.mybatis.example.BlogMapper">
<select id="selectBlog" parameterType="int" resultType="Blog">
select * from Blog where id = #{id}
</select>
</mapper>
</pre>

==Squeel==
[http://rubydoc.info/gems/squeel/1.1.1/frames Squeel]unlocks the power of Arel in Rails applications with a handy block-based syntax. It is supporting in Rails 3 and 4. With Squeel, you can write subqueries, access named functions provided by RDMBS and more without writing SQL strings.
Squeel lets you write your Active Record queries with fewer strings, and more Ruby, by making the Arel awesomeness that lies beneath Active Record more accessible.

Squeel lets you rewrite...

<pre>
Article.where ['created_at >= ?', 2.weeks.ago]
...as...
Article.where{created_at >= 2.weeks.ago}
</pre>

Squeel enhances the normal Active Record query methods by enabling them to accept blocks. Inside a block, the Squeel query DSL can be used. Note the use of curly braces in the above example instead of parentheses. {} denotes a Squeel DSL query.

Stubs and keypaths are the two primary building blocks used in a Squeel DSL query.

Stubs are, for most intents and purposes, just like Symbols in a normal call to Relation#where (note the need for doubling up on the curly braces here, the first ones start the block, the second are the hash braces):
<pre>
Person.where{{name => ‘Ernie’ }}
</pre>

You normally wouldn't bother using the DSL in this case, as a simple hash would suffice. However, stubs serve as a building block for keypaths, and keypaths are very handy.

A Squeel keypath is essentially a more concise and readable alternative to a deeply nested hash. For instance, in standard Active Record, you might join several associations like this to perform a query:
<pre>
Person.joins(:articles => { :comments => :person}).references(:all)
</pre>

With a keypath, this would look like:
<pre>
Person.joins{articles.comments.person}.references(:all)
</pre>

The Squeel DSL works its magic using instance_eval which means that inside a Squeel DSL block, self isn't the same thing that it is outside the block.
This carries with it an important implication: Instance variables and instance methods inside the block won't refer to your object's variables/methods.
Use one of the following methods to get access to the object's methods and variables:
* Assign the variable locally before the DSL block, and access it as you would normally.
* Supply an arity to the DSL block, as in Person.where{|q| q.name == @my_name} Downside: You'll need to prefix stubs, keypaths, and functions with the DSL object.
* Wrap the method or instance variable inside the block with my{}. Person.where{name == my{some_method_to_return_a_name}}

==Merb==
[http://en.wikipedia.org/wiki/Merb Merb], short for "Mongrel+Erb", is a model view controller framework written in Ruby. Merb was merged into Rails web framework on December 23, 2008 as part of the Ruby on Rails 3.0 release.
Merb itself provides only the controller of an MVC model which can be extended to create a full-stack application environment. This effectively means Merb itself is not an ORM but can accommodate other ORMs.
Some features of Merb are as follows :
* Speed - Merb is ORM, JavaScript library and template language agnostic, preferring plugins that add support for features rather than producing a monolithic library with everything in the core.
* Lightweight - Rather than trying to cram every feature into a single code, things are kept bare minimum without sacrificing anything important.
* Powerful and extensible - For any features not covered in Merb’s core, there are plugins.
Some basic Command distinction between Ruby on Rails and Merb :
{| class="comparison" border="1"
! Action
! Ruby on Rails
! Merb
|-
| Create new application 'app1' || rails new app1 || merb-gen app app1
|-
| Start server || rails server || merb
|-
| Start cluster of 3 beginning at port 3000 || N/A || merb -p 3000 -c 3
|-
| Interactive console || rails console || merb -i
|}

==NonSQL databases==
Instead of ORM we can also use Object-Oriented Database Management System (OODBMS) or document-oriented database like XML, where in databases are designed to store object oriented values, thus eliminating the need to convert data to and from its SQL form. Document oriented databases also eliminates the need to retrieve objects as data rows. Query languages like XQuery can be used to retrieve data sets.

The only issue is we won't be able to create application independent queries for retrieving data without restrictions to access path. Also OODBMS limits the extent of processing SQL queries.
A Relational database allows concurrent access to data, locking, indexing (fast search), as well as many other features that are not available while using XML files.

Other OODBMS (such as RavenDB) provide replication to SQL databases, as a means of addressing the need for ad-hoc queries, while preserving the increased performance and reduced complexity that may be achieved with an OODBMS for an application that has well-known query patterns.

NonSQL databases don’t provide mechanism to maintain relationship between tables. In real life though, business objects or entities do have relationship among them. ORM solutions may allow you to define these relationships in business objects and handle their storage and retrieval behind the scene

==Comparison of ORM Features==

{|cellspacing="0" border="1"
!style="width:8%"|Features
!style="width:23%"|ActiveRecord
!style="width:23%"|Sequel
!style="width:23%"|DataMapper
!style="width:23%"|MyBatis
|-
! Databases 
| MySQL, PostgreSQL, SQLite, Oracle, SQLServer, and DB2
| ADO, DataObjects, DB2, DBI, Firebird, Informix, JDBC, MySQL, ODBC, OpenBase, Oracle, PostgreSQL and SQLite3
| SQLite, MySQL, PostgreSQL, Oracle, MongoDB, SimpleDB, many others, including CouchDB, Apache Solr, Google Data API
| MySQL, PostgreSQL, SQLite, Oracle, SQLServer, and DB2
|-
! Migrations 
| Yes
| Yes
| Yes, but optional
| Yes, provides migration by Mybatis schema migration system.
|-
! EagerLoading 
| Supported by scanning the SQL fragments
| Supported using eager (preloading) and eager_graph (joins)
| Strategic Eager Loading and by using :summary
| Yes.this can be enabled or disabled by setting the lazyLoadingEnabled flag
|-
! Flexible Overriding 
| No. Overriding is done using alias methods.
| Using methods and by calling 'super'
| Using methods
| No
|-
! Dynamic Finders 
| Yes. Uses 'Method Missing'
| No. Alternative is to use <Model>.FindOrCreate(:name=>"John")
| Yes. Using the dm_ar_finders plugin
| Similar feature is supported in the form of Dynamic SQL
|}

==Further Reading==
To get more information on ORM and the different type of ORM's available for Ruby , please look into the [http://wiki.expertiza.ncsu.edu/index.php/CSC/ECE_517_Spring_2013/ch1_1d_zk CSC/ECE 517 Spring 2013/ch1 1d zk] and [http://wiki.expertiza.ncsu.edu/index.php/CSC/ECE_517_Fall_2010/ch3_3f_ac Fall 2010 detailed ORM explanation] wiki pages.

==Future Work==
More work can be done in the area of comparison between the different ORMs available for Ruby, especially a more detailed feature-by-feature comparison that includes performance differences between the ORMs.

==References ==
# [http://en.wikipedia.org/wiki/Object-relational_mapping Object Relational Mapping]
# [http://en.wikipedia.org/wiki/Object-oriented_programming object-oriented programming]
# [http://en.wikipedia.org/wiki/Data_access data access]
# [http://en.wikipedia.org/wiki/Metaprogramming metaprogramming]
# [http://guides.rubyonrails.org/active_record_basics.html Active Record]
# [http://guides.rubyonrails.org/getting_started.html#the-mvc-architecture MVC]
# [http://sequel.jeremyevans.net/documentation.html Sequel]
# [http://datamapper.org/ DataMapper]
# [http://guides.rubyonrails.org/active_record_querying.html#eager-loading-associations Eager Loading]
# [http://rubydoc.info/gems/squeel/1.1.1/frames Squeel]
# [http://www.techopedia.com/definition/24200/object-relational-mapping--orm ORM]
# [http://en.wikipedia.org/wiki/Merb Merb]
# [http://www.merbivore.com/ Merb Website]
# [http://wiki.expertiza.ncsu.edu/index.php/CSC/ECE_517_Spring_2013/ch1_1d_zk Object Relational Mapping Spring 2013]

CSC/ECE 517 Fall 2014/ch1a 25 ks

2014-09-19T23:27:42Z

Knimgao: /* Overview */

==Object Relational Mapping==

__TOC__

==Introduction==
[http://en.wikipedia.org/wiki/Object-relational_mapping Object Relational Mapping] (ORM, O/RM, and O/R mapping) in computer science is a programming technique for converting data between incompatible type systems in object-oriented programming languages. This creates, in effect, a "virtual object database" that can be used from within the programming language. There are both free and commercial packages available that perform object-relational mapping, although some programmers opt to create their own ORM tools.

==Overview==
Object Relational Mapping is a programming technique in which a metadata descriptor is used to connect object code to a relational database. ORM converts data between type systems that are unable to coexist within relational databases and OOP languages.

In [http://en.wikipedia.org/wiki/Object-oriented_programming object-oriented programming], data management tasks act on object-oriented (OO) objects that are almost always non-scalar values. For example, consider an address book entry that represents a single person along with zero or more phone numbers and zero or more addresses. This could be modeled in an object-oriented implementation by a "Person object" with attributes/fields to hold each data item that the entry comprises: the person's name, a list of phone numbers, and a list of addresses. The list of phone numbers would itself contain "PhoneNumber objects" and so on. The address book entry is treated as a single object by the programming language (it can be referenced by a single variable containing a pointer to the object, for instance). Various methods can be associated with the object, such as a method to return the preferred phone number, the home address, and so on.

The heart of the problem is translating the logical representation of the objects into an atomized form that is capable of being stored in the database, while preserving the properties of the objects and their relationships so that they can be reloaded as objects when needed. If this storage and retrieval functionality is implemented, the objects are said to be persistent.

==Simple Explanation==
A simple answer is that you wrap your tables or stored procedures in classes in your programming language, so that instead of writing SQL statements to interact with your database, you use methods and properties of objects.

In other words, instead of something like this:
<pre>
String sql = "SELECT ... FROM persons WHERE id = 10"
DbCommand cmd = new DbCommand(connection, sql);
Result res = cmd.Execute();
String name = res[0]["FIRST_NAME"];
</pre>
you do something like this:
<pre>
Person p = repository.GetPerson(10);
String name = p.FirstName;
</pre>
or similar code (lots of variations here.) Some frameworks also put a lot of the code in as static methods on the classes themselves, which means you could do something like this instead:
<pre>
Person p = Person.Get(10);
</pre>
Some also implement complex query systems, so you could do this:
<pre>
Person p = Person.Get(Person.Properties.Id == 10);
</pre>
The framework is what makes this code possible.

==Features==
Object-relational Mapping (ORM) frameworks unburden the designer of the complex translation between database and object space.

Typical ORM features:
* Automatic mapping from classes to database tables
** Class instance variables to database columns
** Class instances to table rows
* Aggregation and association relationships between mapped classes are managed
** Example, :has_many, :belongs_to associations in ActiveRecord
** Inheritance cases are mapped to tables
* Validation of data prior to table storage
* Class extensions to enable search, as well as creation, read, update, and deletion (CRUD) of instances/records
* Usually abstracts the database from program space in such a way that alternate database types can be easily chosen (SQLite, Oracle, etc)

The diagram below depicts a simple mapping of an object to a database table….

[[Image:3j_ks_pic1.jpg]]

ORM framework is used to persist model objects to a relational database and retrieve them, and the ORM framework will take care of converting the data between the two otherwise incompatible states. Most ORM tools rely heavily on metadata about both the database and objects, so that the objects need to know nothing about the database and the database doesn’t need to know anything about how the data is structured in the application. ORM provides a clean separation of concerns in a well-designed data application, and the database and application can each work with data in its native form. Database rows map to objects, thus making the program more easily accessible and allowing the usage of information in a way that is internally consistent and easy to understand. The ORM gives the programmer an ability to manipulate data with the programming language, instead of having to manipulate each attribute as its data type as obtained by the database management system.

When applied to Ruby, implementations of ORM often leverage the language’s [http://en.wikipedia.org/wiki/Metaprogramming metaprogramming] strengths to create intuitive application-specific methods and otherwise extend classes to support database functionality. With the addition of Rails, the ORM becomes much more important, as it is necessary to have an ORM to connect the models of the MVC (model-view-controller) stack used by Ruby on Rails with the application's database. Since the models are Ruby objects, the ORM allows modifications to the database to be done through changes to these models, independent of the type of database used.

With the release of Rails 3.0, the platform became ORM independent. With this change, it is much easier to use the ORM most preferred by the programmer, rather than being corralled into using one particular one. To allow this, the ORM needed to be extracted from the model and the database, to be a pure mediator between the two. Then any ORM can be used as long as it can successfully understand the model and the database used.

==Advantages ==
In addition to the [http://en.wikipedia.org/wiki/Data_access data access] technique, ORM's benefits also include:
*First of all, you hide the SQL away from your logic code. This has the benefit of allowing you to more easily support more database engines. For instance, MS SQL Server and Oracle has different names on typical functions, and different ways to do calculations with dates, so a query to "get me all persons edited the last 24 hours" might entail different SQL syntax just for those two database engines. This difference can be put away from your logic code.
*Additionally, you can focus on writing the logic, instead of getting all the SQL right. The code will typically be more readable as well, since it doesn't contain all the "plumbing" necessary to talk to the database.
*Simplified development because it automates object-to-table and table-to-object conversion, resulting in lower development and maintenance costs
*Less code compared to embedded SQL and handwritten stored procedures
*Transparent object caching in the application tier, improving system performance
*An optimized solution making an application faster and easier to maintain

==Disadvantages ==
*ORM’s emergence in multiple application development has created disagreement among experts. Key concerns are that ORM does not perform well and that stored procedures might be a better solution.
*In addition, ORM dependence may result in poorly-designed databases in certain circumstances.
*Performance – like every "proxy" technology
*Complexity – learning curve
*Difficulty / inability to make complex queries

==Active Records==
[http://guides.rubyonrails.org/active_record_basics.html Active Record] was described by Martin Fowler in his book Patterns of Enterprise Application Architecture. Active Record is the M in [http://guides.rubyonrails.org/getting_started.html#the-mvc-architecture MVC]- the model - which is the layer of the system responsible for representing business data and logic. In Active Record, objects carry both persistent data and behavior which operates on that data. A database table or view is wrapped into a class and an object instance is tied to a single row in the table. Each Active Record object has CRUD (Create, Read, Update, and Delete) methods for database access. In addition, Active Record allows you to validate the state of a model before it gets written into the database.

Active Record gives us several mechanisms, the most important being the ability to:
* Represent models and their data.
* Represent associations between these models.
* Represent inheritance hierarchies through related models.
* Validate models before they get persisted to the database.
* Perform database operations in an object-oriented fashion.

The naming conventions used in Active Records are :
* Database Table - Plural with underscores separating words (e.g., book_clubs).
* Model Class - Singular with the first letter of each word capitalized (e.g., BookClub).

To create a table, ActiveRecord makes use of a migration class rather than including table definition in the actual class being modeled. As an example, the following code creates a table ‘’users’’ to store a collection of class ‘’User’’ objects:
<pre>
class CreateUsers < ActiveRecord::Migration
def self.up
create_table :users do |t|
t.string :name
t.string :email
t.string :age
t.references :cheer
t.references :post

t.timestamps # add creation and modification timestamps
end
end

def self.down # undo the table creation
drop_table :users
end
end
</pre>

The ActiveRecord’s migration scheme provides a means for backing out changes via the ‘’self.down’’ method. In addition, a table key ‘’id’’ is added to the new table without an explicit definition and record creation and modification timestamps are included via the ‘’timestamps’’ method provided by ActiveRecord.

ActiveRecord manages associations between table elements and provides the means to define such associations in the model definition. For example, the ‘’User’’ class shown below defines a ‘’has_many’’ (one-to-many) association with both the cheers and posts tables. These associations are represented in the migration class with the references operator. Also note ActiveRecord’s integrated support for validation of table information when attempting an update.

<pre>
class User < ActiveRecord::Base
has_many :cheers
has_many :posts

validates_presence_of :name
validates_presence_of :age
validates_uniqueness_of :name
validates_length_of :name, :within => 3..20
end
</pre>

To access the data in the table one calls the class function related to that column. For example, to find the user who's name is Bob, one would use @user = User.find_by_name('Bob'). Then one could find Bob's e-mail by using @user.email. Users can be searched for by any attribute in this way, as find methods are created for every combination of attributes.
While ActiveRecord provides the flexibility to create more sophisticated table relationships to represent class hierarchy, its base scheme is a single table inheritance, which trades some storage efficiency for simplicity in the database design. The following figure illustrates this concept of simplicity over efficiency.

[[Image:3j_ks_pic2.jpg]]

'''Pros''' -
* Integrated with popular Rails development framework
* Dynamically created database search methods (eg: User.find_by_address) ease db queries and make queries database syntax independent
* DB creation/management using the migrate scheme provides a means for backing out unwanted table changes
'''Cons''' -
* DB creation/management is decoupled from the model, requiring a separate utility (rake/migrate) that must be kept in sync with application.

==ORM Adaptor==
[https://github.com/ianwhite/orm_adapter ORM Adaptors] provide a single point of entry for popular ruby ORMs. Its target audience is gem authors who want to support more than one ORM.
ORM Adapter's goal is to support a minimum API used by most of the plugins that needs agnosticism beyond Active Model.
ORM Adapter will support only basic methods, as get, find_first, create! and so forth. It is not ORM Adapter's goal to support different query constructions, handle table joins, etc.
ORM adapter provides a consistent API for these basic class or 'factory' methods. It does not attempt to unify the behaviour of model instances returned by these methods. This means that unifying the behaviour of methods such as `model.save`, and `model.valid?` is beyond the scope of orm_adapter.
If you need complex queries, it is recommended to subclass ORM Adapters in your plugin and extend it expressing these query conditions as part of your domain logic.
<pre>
Example :
require 'orm_adapter'
User # is it an ActiveRecord, DM Resource, MongoMapper or MongoId Document?
User.to_adapter.find_first :name => 'Fred' # we don't care!
user_model = User.to_adapter
user_model.get!(1) # find a record by id
user_model.find_first(:name => 'fred') # find first fred
user_model.find_first(:level => 'awesome', :id => 23) # find user 23, only if it's level is awesome
user_model.find_all # find all users
user_model.find_all(:name => 'fred') # find all freds
user_model.find_all(:order => :name) # find all freds, ordered by name
user_model.create!(:name => 'fred') # create a fred
user_model.destroy(object) # destroy the user object
</pre>

==Sequel==
[http://sequel.jeremyevans.net/documentation.html Sequel] was originally developed by Sharon Rosner and the first release was in March 2007. It is based on the active record pattern. Sequel and Active Record share a lot of common features , for example association and inheritance. But Sequel handles these features in a much more flexible manner. Currently Sequel is at version 3.44.0. Initially Sequel had three core modules - sequel, sequel_core and sequel_model. Starting from version 1.4 , sequel and sequel_model were merged. Sequel handles validations using a validation plug-in and helpers.

<pre>
class CreateUser < Sequel::Migration
def up
create_table(:user) {
primary_key :id
String :name
String :age
String :email}
end
def down
drop_table(:user)
end
end # CreateUser.apply(DB, :up)
</pre>

Sequel supports associations and validations similar to Active Record. The following example shows how validations and associations can be enforced in the User table that has been created above. It enforces one to many relationships between the user table and the cheers and posts tables. It also validates for the presence , uniqueness and the length of the attribute '''name'''.

<pre>
class User < Sequel::Model
one_to_many :cheers
one_to_many :posts

validates_presence [:name, :age]
validates_unique(:name)
validates_length_range 3..20, :name
end
</pre>

To access the data in Sequel, one can use where clauses. For instance, to find Bob again one would use DB[:items].where(Sequel.like(:name, 'Bob'). While the ability to use SQL-like where clauses is quite flexible, it is not quite as pure an object-oriented approach as Active Record's dynamically created find methods.

Some of the key features of sequel are,
* Connection Pooling
* Thread Safety
* [http://guides.rubyonrails.org/active_record_querying.html#eager-loading-associations Eager Loading] / Lazy Loading
* Model Caching
* Supports advanced database features such as prepared statements, bound variables, stored procedures, savepoints, two-phase commit, transaction isolation, master/slave configurations, and database sharding.

==Data Mapper==
[http://datamapper.org/ DataMapper] is an Object Relational Mapper written in Ruby developed by Sam Smoot with the goal to create an ORM which is fast, thread-safe and feature rich.
A Data Mapper is a Data Access Layer that performs bidirectional transfer of data between a persistent data store (often a relational database) and an in memory data representation (the domain layer). The goal of the pattern is to keep the in memory representation and the persistent data store independent of each other and the data mapper itself. The layer is composed of one or more mappers (or Data Access Objects), performing the data transfer.
DataMapper comes with the ability to use the same API to talk to a multitude of different datastores. There are adapters for the usual RDBMS suspects, NoSQL stores, various file formats and some web services. With DataMapper, you define your mappings in your model. Your data store can develop independently of your model using Migrations.

Some features of Data Mapper are as follows :
* No need to write structural migrations
* Scoped relations
* Lazy loading on certain attribute types
* Strategic eager loading to avoid (N+1) queries
* Default support for composite and natural keys
* Query chaining, and not evaluating the query until absolutely necessary (using a lazy array implementation)
* An API not too heavily oriented to SQL databases

DataMapper was designed to be a more abstract ORM, not strictly SQL, based on Martin Fowler's enterprise pattern. As a result, DataMapper adapters have been built for other non-SQL databases, such as CouchDB, [http://github.com/lritter/dm-solr-adapter/tree/master Apache Solr], and webservices such as [http://github.com/halorgium/dm-salesforce/tree/master Salesforce].

Example of table definition in the model:
<pre>
class User
include DataMapper::Resource

property :id, Serial # key
property :name, String, :required => true, :unique => true
property :age, String, :required => true, :length => 3..20
property :email, String

has n, :posts # one to many association
has n, :cheers # one to many association
end
</pre>

Notice that in the example above , ":required = true" is an example for Auto Validation. Unlike ActiveRecord and Sequel, DataMapper supports auto validations , i.e. these in turn call the validation helpers to enforce basic validations such as length, uniqueness, format, presence etc.

==MyBatis/iBatis==
[http://en.wikipedia.org/wiki/MyBatis MyBatis/iBatis] was a persistence framework which allowed easy access of the database from a Rails application without being a full ORM. It was created by the Apache Foundation in 2002, and is available for several platforms, including Ruby (the Ruby release is known as RBatis). On 6/16/2010, after releasing iBATIS 3.0, the project team moved from Apache to Google Code, changed the project's name to MyBatis, and stopped supporting Ruby.

The MyBatis data mapper framework makes it easier to use a relational database with object-oriented applications. MyBatis couples objects with stored procedures or SQL statements using a XML descriptor. To use the MyBatis data mapper,we make use of our own objects, XML, and SQL.

SQL statements are stored in XML files or annotations. Following is a MyBatis mapper, that consists of a Java interface with some MyBatis annotations:
<pre>
package org.mybatis.example;

public interface BlogMapper {
@Select("select * from Blog where id = #{id}")
Blog selectBlog(int id);
}
</pre>
The sentence is executed as follows.
<pre>
BlogMapper mapper = session.getMapper(BlogMapper.class);
Blog blog = mapper.selectBlog(101);
</pre>

It can also be executed using MyBatis API.
<pre>
Blog blog = session.selectOne("org.mybatis.example.BlogMapper.selectBlog", 101);
</pre>

SQL statements and mappings can also be externalized to an XML file like this.
<pre>
<?xml version="1.0" encoding="UTF-8" ?>
<!DOCTYPE mapper PUBLIC "-//mybatis.org//DTD Mapper 3.0//EN" "http://mybatis.org/dtd/mybatis-3-mapper.dtd">

<mapper namespace="org.mybatis.example.BlogMapper">
<select id="selectBlog" parameterType="int" resultType="Blog">
select * from Blog where id = #{id}
</select>
</mapper>
</pre>

==Squeel==
[http://rubydoc.info/gems/squeel/1.1.1/frames Squeel]unlocks the power of Arel in Rails applications with a handy block-based syntax. It is supporting in Rails 3 and 4. With Squeel, you can write subqueries, access named functions provided by RDMBS and more without writing SQL strings.
Squeel lets you write your Active Record queries with fewer strings, and more Ruby, by making the Arel awesomeness that lies beneath Active Record more accessible.

Squeel lets you rewrite...

<pre>
Article.where ['created_at >= ?', 2.weeks.ago]
...as...
Article.where{created_at >= 2.weeks.ago}
</pre>

Squeel enhances the normal Active Record query methods by enabling them to accept blocks. Inside a block, the Squeel query DSL can be used. Note the use of curly braces in the above example instead of parentheses. {} denotes a Squeel DSL query.

Stubs and keypaths are the two primary building blocks used in a Squeel DSL query.

Stubs are, for most intents and purposes, just like Symbols in a normal call to Relation#where (note the need for doubling up on the curly braces here, the first ones start the block, the second are the hash braces):
<pre>
Person.where{{name => ‘Ernie’ }}
</pre>

You normally wouldn't bother using the DSL in this case, as a simple hash would suffice. However, stubs serve as a building block for keypaths, and keypaths are very handy.

A Squeel keypath is essentially a more concise and readable alternative to a deeply nested hash. For instance, in standard Active Record, you might join several associations like this to perform a query:
<pre>
Person.joins(:articles => { :comments => :person}).references(:all)
</pre>

With a keypath, this would look like:
<pre>
Person.joins{articles.comments.person}.references(:all)
</pre>

The Squeel DSL works its magic using instance_eval which means that inside a Squeel DSL block, self isn't the same thing that it is outside the block.
This carries with it an important implication: Instance variables and instance methods inside the block won't refer to your object's variables/methods.
Use one of the following methods to get access to the object's methods and variables:
* Assign the variable locally before the DSL block, and access it as you would normally.
* Supply an arity to the DSL block, as in Person.where{|q| q.name == @my_name} Downside: You'll need to prefix stubs, keypaths, and functions with the DSL object.
* Wrap the method or instance variable inside the block with my{}. Person.where{name == my{some_method_to_return_a_name}}

==Merb==
[http://en.wikipedia.org/wiki/Merb Merb], short for "Mongrel+Erb", is a model view controller framework written in Ruby. Merb was merged into Rails web framework on December 23, 2008 as part of the Ruby on Rails 3.0 release.
Merb itself provides only the controller of an MVC model which can be extended to create a full-stack application environment. This effectively means Merb itself is not an ORM but can accommodate other ORMs.
Some features of Merb are as follows :
* Speed - Merb is ORM, JavaScript library and template language agnostic, preferring plugins that add support for features rather than producing a monolithic library with everything in the core.
* Lightweight - Rather than trying to cram every feature into a single code, things are kept bare minimum without sacrificing anything important.
* Powerful and extensible - For any features not covered in Merb’s core, there are plugins.
Some basic Command distinction between Ruby on Rails and Merb :
{| class="comparison" border="1"
! Action
! Ruby on Rails
! Merb
|-
| Create new application 'app1' || rails new app1 || merb-gen app app1
|-
| Start server || rails server || merb
|-
| Start cluster of 3 beginning at port 3000 || N/A || merb -p 3000 -c 3
|-
| Interactive console || rails console || merb -i
|}

==NonSQL databases==
Instead of ORM we can also use Object-Oriented Database Management System (OODBMS) or document-oriented database like XML, where in databases are designed to store object oriented values, thus eliminating the need to convert data to and from its SQL form. Document oriented databases also eliminates the need to retrieve objects as data rows. Query languages like XQuery can be used to retrieve data sets.

The only issue is we won't be able to create application independent queries for retrieving data without restrictions to access path. Also OODBMS limits the extent of processing SQL queries.
A Relational database allows concurrent access to data, locking, indexing (fast search), as well as many other features that are not available while using XML files.

Other OODBMS (such as RavenDB) provide replication to SQL databases, as a means of addressing the need for ad-hoc queries, while preserving the increased performance and reduced complexity that may be achieved with an OODBMS for an application that has well-known query patterns.

NonSQL databases don’t provide mechanism to maintain relationship between tables. In real life though, business objects or entities do have relationship among them. ORM solutions may allow you to define these relationships in business objects and handle their storage and retrieval behind the scene

==Comparison of ORM Features==

{|cellspacing="0" border="1"
!style="width:8%"|Features
!style="width:23%"|ActiveRecord
!style="width:23%"|Sequel
!style="width:23%"|DataMapper
!style="width:23%"|MyBatis
|-
! Databases 
| MySQL, PostgreSQL, SQLite, Oracle, SQLServer, and DB2
| ADO, DataObjects, DB2, DBI, Firebird, Informix, JDBC, MySQL, ODBC, OpenBase, Oracle, PostgreSQL and SQLite3
| SQLite, MySQL, PostgreSQL, Oracle, MongoDB, SimpleDB, many others, including CouchDB, Apache Solr, Google Data API
| MySQL, PostgreSQL, SQLite, Oracle, SQLServer, and DB2
|-
! Migrations 
| Yes
| Yes
| Yes, but optional
| Yes, provides migration by Mybatis schema migration system.
|-
! EagerLoading 
| Supported by scanning the SQL fragments
| Supported using eager (preloading) and eager_graph (joins)
| Strategic Eager Loading and by using :summary
| Yes.this can be enabled or disabled by setting the lazyLoadingEnabled flag
|-
! Flexible Overriding 
| No. Overriding is done using alias methods.
| Using methods and by calling 'super'
| Using methods
| No
|-
! Dynamic Finders 
| Yes. Uses 'Method Missing'
| No. Alternative is to use <Model>.FindOrCreate(:name=>"John")
| Yes. Using the dm_ar_finders plugin
| Similar feature is supported in the form of Dynamic SQL
|}

==Further Reading==
To get more information on ORM and the different type of ORM's available for Ruby , please look into the [http://wiki.expertiza.ncsu.edu/index.php/CSC/ECE_517_Spring_2013/ch1_1d_zk CSC/ECE 517 Spring 2013/ch1 1d zk] and [http://wiki.expertiza.ncsu.edu/index.php/CSC/ECE_517_Fall_2010/ch3_3f_ac Fall 2010 detailed ORM explanation] wiki pages.

==Future Work==
More work can be done in the area of comparison between the different ORMs available for Ruby, especially a more detailed feature-by-feature comparison that includes performance differences between the ORMs.

==References ==
# [http://en.wikipedia.org/wiki/Object-relational_mapping Object Relational Mapping]
# [http://en.wikipedia.org/wiki/Object-oriented_programming object-oriented programming]
# [http://en.wikipedia.org/wiki/Data_access data access]
# [http://en.wikipedia.org/wiki/Metaprogramming metaprogramming]
# [http://guides.rubyonrails.org/active_record_basics.html Active Record]
# [http://guides.rubyonrails.org/getting_started.html#the-mvc-architecture MVC]
# [http://sequel.jeremyevans.net/documentation.html Sequel]
# [http://datamapper.org/ DataMapper]
# [http://guides.rubyonrails.org/active_record_querying.html#eager-loading-associations Eager Loading]
# [http://rubydoc.info/gems/squeel/1.1.1/frames Squeel]
# [http://www.techopedia.com/definition/24200/object-relational-mapping--orm ORM]
# [http://en.wikipedia.org/wiki/Merb Merb]
# [http://www.merbivore.com/ Merb Website]
# [http://wiki.expertiza.ncsu.edu/index.php/CSC/ECE_517_Spring_2013/ch1_1d_zk Object Relational Mapping Spring 2013]

CSC/ECE 517 Fall 2014/ch1a 25 ks

2014-09-18T04:04:30Z

Knimgao: /* Squeel */

==Object Relational Mapping==

__TOC__

==Introduction==
[http://en.wikipedia.org/wiki/Object-relational_mapping Object Relational Mapping] (ORM, O/RM, and O/R mapping) in computer science is a programming technique for converting data between incompatible type systems in object-oriented programming languages. This creates, in effect, a "virtual object database" that can be used from within the programming language. There are both free and commercial packages available that perform object-relational mapping, although some programmers opt to create their own ORM tools.

==Overview==
Onject Relational Mapping is a programming technique in which a metadata descriptor is used to connect object code to a relational database. ORM converts data between type systems that are unable to coexist within relational databases and OOP languages.

In [http://en.wikipedia.org/wiki/Object-oriented_programming object-oriented programming], data management tasks act on object-oriented (OO) objects that are almost always non-scalar values. For example, consider an address book entry that represents a single person along with zero or more phone numbers and zero or more addresses. This could be modeled in an object-oriented implementation by a "Person object" with attributes/fields to hold each data item that the entry comprises: the person's name, a list of phone numbers, and a list of addresses. The list of phone numbers would itself contain "PhoneNumber objects" and so on. The address book entry is treated as a single object by the programming language (it can be referenced by a single variable containing a pointer to the object, for instance). Various methods can be associated with the object, such as a method to return the preferred phone number, the home address, and so on.

The heart of the problem is translating the logical representation of the objects into an atomized form that is capable of being stored in the database, while preserving the properties of the objects and their relationships so that they can be reloaded as objects when needed. If this storage and retrieval functionality is implemented, the objects are said to be persistent.

==Simple Explanation==
A simple answer is that you wrap your tables or stored procedures in classes in your programming language, so that instead of writing SQL statements to interact with your database, you use methods and properties of objects.

In other words, instead of something like this:
<pre>
String sql = "SELECT ... FROM persons WHERE id = 10"
DbCommand cmd = new DbCommand(connection, sql);
Result res = cmd.Execute();
String name = res[0]["FIRST_NAME"];
</pre>
you do something like this:
<pre>
Person p = repository.GetPerson(10);
String name = p.FirstName;
</pre>
or similar code (lots of variations here.) Some frameworks also put a lot of the code in as static methods on the classes themselves, which means you could do something like this instead:
<pre>
Person p = Person.Get(10);
</pre>
Some also implement complex query systems, so you could do this:
<pre>
Person p = Person.Get(Person.Properties.Id == 10);
</pre>
The framework is what makes this code possible.

==Features==
Object-relational Mapping (ORM) frameworks unburden the designer of the complex translation between database and object space.

Typical ORM features:
* Automatic mapping from classes to database tables
** Class instance variables to database columns
** Class instances to table rows
* Aggregation and association relationships between mapped classes are managed
** Example, :has_many, :belongs_to associations in ActiveRecord
** Inheritance cases are mapped to tables
* Validation of data prior to table storage
* Class extensions to enable search, as well as creation, read, update, and deletion (CRUD) of instances/records
* Usually abstracts the database from program space in such a way that alternate database types can be easily chosen (SQLite, Oracle, etc)

The diagram below depicts a simple mapping of an object to a database table….

[[Image:3j_ks_pic1.jpg]]

ORM framework is used to persist model objects to a relational database and retrieve them, and the ORM framework will take care of converting the data between the two otherwise incompatible states. Most ORM tools rely heavily on metadata about both the database and objects, so that the objects need to know nothing about the database and the database doesn’t need to know anything about how the data is structured in the application. ORM provides a clean separation of concerns in a well-designed data application, and the database and application can each work with data in its native form. Database rows map to objects, thus making the program more easily accessible and allowing the usage of information in a way that is internally consistent and easy to understand. The ORM gives the programmer an ability to manipulate data with the programming language, instead of having to manipulate each attribute as its data type as obtained by the database management system.

When applied to Ruby, implementations of ORM often leverage the language’s [http://en.wikipedia.org/wiki/Metaprogramming metaprogramming] strengths to create intuitive application-specific methods and otherwise extend classes to support database functionality. With the addition of Rails, the ORM becomes much more important, as it is necessary to have an ORM to connect the models of the MVC (model-view-controller) stack used by Ruby on Rails with the application's database. Since the models are Ruby objects, the ORM allows modifications to the database to be done through changes to these models, independent of the type of database used.

With the release of Rails 3.0, the platform became ORM independent. With this change, it is much easier to use the ORM most preferred by the programmer, rather than being corralled into using one particular one. To allow this, the ORM needed to be extracted from the model and the database, to be a pure mediator between the two. Then any ORM can be used as long as it can successfully understand the model and the database used.

==Advantages ==
In addition to the [http://en.wikipedia.org/wiki/Data_access data access] technique, ORM's benefits also include:
*First of all, you hide the SQL away from your logic code. This has the benefit of allowing you to more easily support more database engines. For instance, MS SQL Server and Oracle has different names on typical functions, and different ways to do calculations with dates, so a query to "get me all persons edited the last 24 hours" might entail different SQL syntax just for those two database engines. This difference can be put away from your logic code.
*Additionally, you can focus on writing the logic, instead of getting all the SQL right. The code will typically be more readable as well, since it doesn't contain all the "plumbing" necessary to talk to the database.
*Simplified development because it automates object-to-table and table-to-object conversion, resulting in lower development and maintenance costs
*Less code compared to embedded SQL and handwritten stored procedures
*Transparent object caching in the application tier, improving system performance
*An optimized solution making an application faster and easier to maintain

==Disadvantages ==
*ORM’s emergence in multiple application development has created disagreement among experts. Key concerns are that ORM does not perform well and that stored procedures might be a better solution.
*In addition, ORM dependence may result in poorly-designed databases in certain circumstances.
*Performance – like every "proxy" technology
*Complexity – learning curve
*Difficulty / inability to make complex queries

==Active Records==
[http://guides.rubyonrails.org/active_record_basics.html Active Record] was described by Martin Fowler in his book Patterns of Enterprise Application Architecture. Active Record is the M in [http://guides.rubyonrails.org/getting_started.html#the-mvc-architecture MVC]- the model - which is the layer of the system responsible for representing business data and logic. In Active Record, objects carry both persistent data and behavior which operates on that data. A database table or view is wrapped into a class and an object instance is tied to a single row in the table. Each Active Record object has CRUD (Create, Read, Update, and Delete) methods for database access. In addition, Active Record allows you to validate the state of a model before it gets written into the database.

Active Record gives us several mechanisms, the most important being the ability to:
* Represent models and their data.
* Represent associations between these models.
* Represent inheritance hierarchies through related models.
* Validate models before they get persisted to the database.
* Perform database operations in an object-oriented fashion.

The naming conventions used in Active Records are :
* Database Table - Plural with underscores separating words (e.g., book_clubs).
* Model Class - Singular with the first letter of each word capitalized (e.g., BookClub).

To create a table, ActiveRecord makes use of a migration class rather than including table definition in the actual class being modeled. As an example, the following code creates a table ‘’users’’ to store a collection of class ‘’User’’ objects:
<pre>
class CreateUsers < ActiveRecord::Migration
def self.up
create_table :users do |t|
t.string :name
t.string :email
t.string :age
t.references :cheer
t.references :post

t.timestamps # add creation and modification timestamps
end
end

def self.down # undo the table creation
drop_table :users
end
end
</pre>

The ActiveRecord’s migration scheme provides a means for backing out changes via the ‘’self.down’’ method. In addition, a table key ‘’id’’ is added to the new table without an explicit definition and record creation and modification timestamps are included via the ‘’timestamps’’ method provided by ActiveRecord.

ActiveRecord manages associations between table elements and provides the means to define such associations in the model definition. For example, the ‘’User’’ class shown below defines a ‘’has_many’’ (one-to-many) association with both the cheers and posts tables. These associations are represented in the migration class with the references operator. Also note ActiveRecord’s integrated support for validation of table information when attempting an update.

<pre>
class User < ActiveRecord::Base
has_many :cheers
has_many :posts

validates_presence_of :name
validates_presence_of :age
validates_uniqueness_of :name
validates_length_of :name, :within => 3..20
end
</pre>

To access the data in the table one calls the class function related to that column. For example, to find the user who's name is Bob, one would use @user = User.find_by_name('Bob'). Then one could find Bob's e-mail by using @user.email. Users can be searched for by any attribute in this way, as find methods are created for every combination of attributes.
While ActiveRecord provides the flexibility to create more sophisticated table relationships to represent class hierarchy, its base scheme is a single table inheritance, which trades some storage efficiency for simplicity in the database design. The following figure illustrates this concept of simplicity over efficiency.

[[Image:3j_ks_pic2.jpg]]

'''Pros''' -
* Integrated with popular Rails development framework
* Dynamically created database search methods (eg: User.find_by_address) ease db queries and make queries database syntax independent
* DB creation/management using the migrate scheme provides a means for backing out unwanted table changes
'''Cons''' -
* DB creation/management is decoupled from the model, requiring a separate utility (rake/migrate) that must be kept in sync with application.

==ORM Adaptor==
[https://github.com/ianwhite/orm_adapter ORM Adaptors] provide a single point of entry for popular ruby ORMs. Its target audience is gem authors who want to support more than one ORM.
ORM Adapter's goal is to support a minimum API used by most of the plugins that needs agnosticism beyond Active Model.
ORM Adapter will support only basic methods, as get, find_first, create! and so forth. It is not ORM Adapter's goal to support different query constructions, handle table joins, etc.
ORM adapter provides a consistent API for these basic class or 'factory' methods. It does not attempt to unify the behaviour of model instances returned by these methods. This means that unifying the behaviour of methods such as `model.save`, and `model.valid?` is beyond the scope of orm_adapter.
If you need complex queries, it is recommended to subclass ORM Adapters in your plugin and extend it expressing these query conditions as part of your domain logic.
<pre>
Example :
require 'orm_adapter'
User # is it an ActiveRecord, DM Resource, MongoMapper or MongoId Document?
User.to_adapter.find_first :name => 'Fred' # we don't care!
user_model = User.to_adapter
user_model.get!(1) # find a record by id
user_model.find_first(:name => 'fred') # find first fred
user_model.find_first(:level => 'awesome', :id => 23) # find user 23, only if it's level is awesome
user_model.find_all # find all users
user_model.find_all(:name => 'fred') # find all freds
user_model.find_all(:order => :name) # find all freds, ordered by name
user_model.create!(:name => 'fred') # create a fred
user_model.destroy(object) # destroy the user object
</pre>

==Sequel==
[http://sequel.rubyforge.org Sequel] was originally developed by Sharon Rosner and the first release was in March 2007. It is based on the active record pattern. Sequel and Active Record share a lot of common features , for example association and inheritance. But Sequel handles these features in a much more flexible manner. Currently Sequel is at version 3.44.0. Initially Sequel had three core modules - sequel, sequel_core and sequel_model. Starting from version 1.4 , sequel and sequel_model were merged. Sequel handles validations using a validation plug-in and helpers.

<pre>
class CreateUser < Sequel::Migration
def up
create_table(:user) {
primary_key :id
String :name
String :age
String :email}
end
def down
drop_table(:user)
end
end # CreateUser.apply(DB, :up)
</pre>

Sequel supports associations and validations similar to Active Record. The following example shows how validations and associations can be enforced in the User table that has been created above. It enforces one to many relationships between the user table and the cheers and posts tables. It also validates for the presence , uniqueness and the length of the attribute '''name'''.

<pre>
class User < Sequel::Model
one_to_many :cheers
one_to_many :posts

validates_presence [:name, :age]
validates_unique(:name)
validates_length_range 3..20, :name
end
</pre>

To access the data in Sequel, one can use where clauses. For instance, to find Bob again one would use DB[:items].where(Sequel.like(:name, 'Bob'). While the ability to use SQL-like where clauses is quite flexible, it is not quite as pure an object-oriented approach as Active Record's dynamically created find methods.

Some of the key features of sequel are,
* Connection Pooling
* Thread Safety
* [http://guides.rubyonrails.org/active_record_querying.html#eager-loading-associations Eager Loading] / Lazy Loading
* Model Caching
* Supports advanced database features such as prepared statements, bound variables, stored procedures, savepoints, two-phase commit, transaction isolation, master/slave configurations, and database sharding.

==Data Mapper==
[http://datamapper.org/ DataMapper] is an Object Relational Mapper written in Ruby developed by Sam Smoot with the goal to create an ORM which is fast, thread-safe and feature rich.
A Data Mapper is a Data Access Layer that performs bidirectional transfer of data between a persistent data store (often a relational database) and an in memory data representation (the domain layer). The goal of the pattern is to keep the in memory representation and the persistent data store independent of each other and the data mapper itself. The layer is composed of one or more mappers (or Data Access Objects), performing the data transfer.
DataMapper comes with the ability to use the same API to talk to a multitude of different datastores. There are adapters for the usual RDBMS suspects, NoSQL stores, various file formats and some web services. With DataMapper, you define your mappings in your model. Your data store can develop independently of your model using Migrations.

Some features of Data Mapper are as follows :
* No need to write structural migrations
* Scoped relations
* Lazy loading on certain attribute types
* Strategic eager loading to avoid (N+1) queries
* Default support for composite and natural keys
* Query chaining, and not evaluating the query until absolutely necessary (using a lazy array implementation)
* An API not too heavily oriented to SQL databases

DataMapper was designed to be a more abstract ORM, not strictly SQL, based on Martin Fowler's enterprise pattern. As a result, DataMapper adapters have been built for other non-SQL databases, such as CouchDB, [http://github.com/lritter/dm-solr-adapter/tree/master Apache Solr], and webservices such as [http://github.com/halorgium/dm-salesforce/tree/master Salesforce].

Example of table definition in the model:
<pre>
class User
include DataMapper::Resource

property :id, Serial # key
property :name, String, :required => true, :unique => true
property :age, String, :required => true, :length => 3..20
property :email, String

has n, :posts # one to many association
has n, :cheers # one to many association
end
</pre>

Notice that in the example above , ":required = true" is an example for Auto Validation. Unlike ActiveRecord and Sequel, DataMapper supports auto validations , i.e. these in turn call the validation helpers to enforce basic validations such as length, uniqueness, format, presence etc.

==MyBatis/iBatis==
[http://en.wikipedia.org/wiki/MyBatis MyBatis/iBatis] was a persistence framework which allowed easy access of the database from a Rails application without being a full ORM. It was created by the Apache Foundation in 2002, and is available for several platforms, including Ruby (the Ruby release is known as RBatis). On 6/16/2010, after releasing iBATIS 3.0, the project team moved from Apache to Google Code, changed the project's name to MyBatis, and stopped supporting Ruby.

The MyBatis data mapper framework makes it easier to use a relational database with object-oriented applications. MyBatis couples objects with stored procedures or SQL statements using a XML descriptor. To use the MyBatis data mapper,we make use of our own objects, XML, and SQL.

SQL statements are stored in XML files or annotations. Following is a MyBatis mapper, that consists of a Java interface with some MyBatis annotations:
<pre>
package org.mybatis.example;

public interface BlogMapper {
@Select("select * from Blog where id = #{id}")
Blog selectBlog(int id);
}
</pre>
The sentence is executed as follows.
<pre>
BlogMapper mapper = session.getMapper(BlogMapper.class);
Blog blog = mapper.selectBlog(101);
</pre>

It can also be executed using MyBatis API.
<pre>
Blog blog = session.selectOne("org.mybatis.example.BlogMapper.selectBlog", 101);
</pre>

SQL statements and mappings can also be externalized to an XML file like this.
<pre>
<?xml version="1.0" encoding="UTF-8" ?>
<!DOCTYPE mapper PUBLIC "-//mybatis.org//DTD Mapper 3.0//EN" "http://mybatis.org/dtd/mybatis-3-mapper.dtd">

<mapper namespace="org.mybatis.example.BlogMapper">
<select id="selectBlog" parameterType="int" resultType="Blog">
select * from Blog where id = #{id}
</select>
</mapper>
</pre>

==Squeel==
[http://rubydoc.info/gems/squeel/1.1.1/frames Squeel]unlocks the power of Arel in Rails applications with a handy block-based syntax. It is supporting in Rails 3 and 4. With Squeel, you can write subqueries, access named functions provided by RDMBS and more without writing SQL strings.
Squeel lets you write your Active Record queries with fewer strings, and more Ruby, by making the Arel awesomeness that lies beneath Active Record more accessible.

Squeel lets you rewrite...

<pre>
Article.where ['created_at >= ?', 2.weeks.ago]
...as...
Article.where{created_at >= 2.weeks.ago}
</pre>

Squeel enhances the normal Active Record query methods by enabling them to accept blocks. Inside a block, the Squeel query DSL can be used. Note the use of curly braces in the above example instead of parentheses. {} denotes a Squeel DSL query.

Stubs and keypaths are the two primary building blocks used in a Squeel DSL query.

Stubs are, for most intents and purposes, just like Symbols in a normal call to Relation#where (note the need for doubling up on the curly braces here, the first ones start the block, the second are the hash braces):
<pre>
Person.where{{name => ‘Ernie’ }}
</pre>

You normally wouldn't bother using the DSL in this case, as a simple hash would suffice. However, stubs serve as a building block for keypaths, and keypaths are very handy.

A Squeel keypath is essentially a more concise and readable alternative to a deeply nested hash. For instance, in standard Active Record, you might join several associations like this to perform a query:
<pre>
Person.joins(:articles => { :comments => :person}).references(:all)
</pre>

With a keypath, this would look like:
<pre>
Person.joins{articles.comments.person}.references(:all)
</pre>

The Squeel DSL works its magic using instance_eval which means that inside a Squeel DSL block, self isn't the same thing that it is outside the block.
This carries with it an important implication: Instance variables and instance methods inside the block won't refer to your object's variables/methods.
Use one of the following methods to get access to the object's methods and variables:
* Assign the variable locally before the DSL block, and access it as you would normally.
* Supply an arity to the DSL block, as in Person.where{|q| q.name == @my_name} Downside: You'll need to prefix stubs, keypaths, and functions with the DSL object.
* Wrap the method or instance variable inside the block with my{}. Person.where{name == my{some_method_to_return_a_name}}

==Merb==
[http://en.wikipedia.org/wiki/Merb Merb], short for "Mongrel+Erb", is a model view controller framework written in Ruby. Merb was merged into Rails web framework on December 23, 2008 as part of the Ruby on Rails 3.0 release.
Merb itself provides only the controller of an MVC model which can be extended to create a full-stack application environment. This effectively means Merb itself is not an ORM but can accommodate other ORMs.
Some features of Merb are as follows :
* Speed - Merb is ORM, JavaScript library and template language agnostic, preferring plugins that add support for features rather than producing a monolithic library with everything in the core.
* Lightweight - Rather than trying to cram every feature into a single code, things are kept bare minimum without sacrificing anything important.
* Powerful and extensible - For any features not covered in Merb’s core, there are plugins.
Some basic Command distinction between Ruby on Rails and Merb :
{| class="comparison" border="1"
! Action
! Ruby on Rails
! Merb
|-
| Create new application 'app1' || rails new app1 || merb-gen app app1
|-
| Start server || rails server || merb
|-
| Start cluster of 3 beginning at port 3000 || N/A || merb -p 3000 -c 3
|-
| Interactive console || rails console || merb -i
|}

==NonSQL databases==
Instead of ORM we can also use Object-Oriented Database Management System (OODBMS) or document-oriented database like XML, where in databases are designed to store object oriented values, thus eliminating the need to convert data to and from its SQL form. Document oriented databases also eliminates the need to retrieve objects as data rows. Query languages like XQuery can be used to retrieve data sets.

The only issue is we won't be able to create application independent queries for retrieving data without restrictions to access path. Also OODBMS limits the extent of processing SQL queries.
A Relational database allows concurrent access to data, locking, indexing (fast search), as well as many other features that are not available while using XML files.

Other OODBMS (such as RavenDB) provide replication to SQL databases, as a means of addressing the need for ad-hoc queries, while preserving the increased performance and reduced complexity that may be achieved with an OODBMS for an application that has well-known query patterns.

NonSQL databases don’t provide mechanism to maintain relationship between tables. In real life though, business objects or entities do have relationship among them. ORM solutions may allow you to define these relationships in business objects and handle their storage and retrieval behind the scene

==Comparison of ORM Features==

{|cellspacing="0" border="1"
!style="width:8%"|Features
!style="width:23%"|ActiveRecord
!style="width:23%"|Sequel
!style="width:23%"|DataMapper
!style="width:23%"|MyBatis
|-
! Databases 
| MySQL, PostgreSQL, SQLite, Oracle, SQLServer, and DB2
| ADO, DataObjects, DB2, DBI, Firebird, Informix, JDBC, MySQL, ODBC, OpenBase, Oracle, PostgreSQL and SQLite3
| SQLite, MySQL, PostgreSQL, Oracle, MongoDB, SimpleDB, many others, including CouchDB, Apache Solr, Google Data API
| MySQL, PostgreSQL, SQLite, Oracle, SQLServer, and DB2
|-
! Migrations 
| Yes
| Yes
| Yes, but optional
| Yes, provides migration by Mybatis schema migration system.
|-
! EagerLoading 
| Supported by scanning the SQL fragments
| Supported using eager (preloading) and eager_graph (joins)
| Strategic Eager Loading and by using :summary
| Yes.this can be enabled or disabled by setting the lazyLoadingEnabled flag
|-
! Flexible Overriding 
| No. Overriding is done using alias methods.
| Using methods and by calling 'super'
| Using methods
| No
|-
! Dynamic Finders 
| Yes. Uses 'Method Missing'
| No. Alternative is to use <Model>.FindOrCreate(:name=>"John")
| Yes. Using the dm_ar_finders plugin
| Similar feature is supported in the form of Dynamic SQL
|}

==Further Reading==
To get more information on ORM and the different type of ORM's available for Ruby , please look into the [http://wiki.expertiza.ncsu.edu/index.php/CSC/ECE_517_Spring_2013/ch1_1d_zk CSC/ECE 517 Spring 2013/ch1 1d zk] and [http://wiki.expertiza.ncsu.edu/index.php/CSC/ECE_517_Fall_2010/ch3_3f_ac Fall 2010 detailed ORM explanation] wiki pages.

==Future Work==
More work can be done in the area of comparison between the different ORMs available for Ruby, especially a more detailed feature-by-feature comparison that includes performance differences between the ORMs.

==References ==
# [http://en.wikipedia.org/wiki/Object-relational_mapping Object Relational Mapping]
# [http://en.wikipedia.org/wiki/Object-oriented_programming object-oriented programming]
# [http://en.wikipedia.org/wiki/Data_access data access]
# [http://en.wikipedia.org/wiki/Metaprogramming metaprogramming]
# [http://guides.rubyonrails.org/active_record_basics.html Active Record]
# [http://guides.rubyonrails.org/getting_started.html#the-mvc-architecture MVC]
# [http://sequel.jeremyevans.net/documentation.html Sequel]
# [http://datamapper.org/ DataMapper]
# [http://guides.rubyonrails.org/active_record_querying.html#eager-loading-associations Eager Loading]
# [http://rubydoc.info/gems/squeel/1.1.1/frames Squeel]
# [http://www.techopedia.com/definition/24200/object-relational-mapping--orm ORM]
# [http://en.wikipedia.org/wiki/Merb Merb]
# [http://www.merbivore.com/ Merb Website]
# [http://wiki.expertiza.ncsu.edu/index.php/CSC/ECE_517_Spring_2013/ch1_1d_zk Object Relational Mapping Spring 2013]