Expertiza_Wiki - User contributions [en]

CSC/ECE 517 Fall 2013/oss cmh

2013-10-30T17:03:58Z

Mrsreena: /* Future Work */

== Introduction ==

The invitation controller within Expertiza handles the invite functionality which allows user to send and receives invitations. Users can create teams and invite users to join there team. The invitation controller handles the creation of the invite and the accept or decline of an invite. The invitation controller also handles requests to join teams via advertisements. After advertisements are sent a user can request to receive and invite to the team and subsequent functionality is handled by the invitation controller once an invite is sent. Our project was to refactor the code around invitations mainly dealing with the invitation controller and invitation model.

== Project Description ==
'''Classes:''' invitation_controller.rb (104 lines)
invitation.rb (5 lines)

'''What it does:''' Handles invitations to join teams.

'''What needs to be done:''' The code is deeply nested and quite confusing. There should be a single method responsible for finding whether a user is already on a team, adding someone onto a waitlist, dropping someone off of a waitlist, changing/updating the topic that the user is assigned to, etc. Some of these methods should be in model classes, such as invitation.rb and signed_up_user.rb. Break the complicated methods into shorter methods with clear names, and place these methods in the most appropriate class, moving a lot of functionality to the model classes.

Currently, after someone joins a team, pending invitations are not removed. There should be a method handling deletion of invitations (including declined invitations) to a user after that user joins a team. This should be a model method.

Though this class is not long, the code looks and reads like it is very complicated. Breaking it down into multiple methods with clear names and proper division of functionality between classes will be a challenge.

== Motivation ==

As is noted in the project description section our project was centered around refactoring the invitation controller. Much of the functionality that was implemented within the invitation controller actually should have been in model classes. There was only about 5 lines of code in the invitation model while there were 104 lines in the invitation controller. A lot of the code in the invitation controller needed to be dispersed amongst the invitation model and various other models within the application. The code within the invitation controller was also very confusing and difficult to understand for a number of reasons. Some of the problems causing the code to be complicated included deeply nested if statements, dense methods and variable names that did not accurately reflect the values they held. The goal of our project was to make the overall design of the invitation controller simpler thus making the code easier to understand and ensuring that distribution of functionality in the application honored the MVC framework.

== Design Changes ==

=== Create Method ===
Though the create method is relatively small and fairly understandable, it still asked for a few changes.There were a few method calls to the deprecated method "find" which had to be replaced with calls to the "first" and the "all" methods. 
Example:
The call to
<pre>
AssignmentParticipant.find(:first, :conditions => ['user_id =? and parent_id =?', user.id, student.parent_id])
</pre>
is replaced with
<pre>
AssignmentParticipant.first( :conditions => ['user_id =? and parent_id =?', user.id, student.parent_id])
</pre>
The call to
<pre>
TeamsUser.find(:all, :conditions => ['team_id =? and user_id =?', team.id, user.id])
</pre>
is replaced with
<pre>
TeamsUser.all(:conditions => ['team_id =? and user_id =?', team.id, user.id])
</pre>

'''Before Refactor'''
<pre>
def create
user = User.find_by_name(params[:user][:name].strip)
team = AssignmentTeam.find_by_id(params[:team_id])
student = AssignmentParticipant.find(params[:student_id])
return unless current_user_id?(student.user_id)

#check if the invited user is valid
if !user
flash[:notice] = "\"#{params[:user][:name].strip}\" does not exist. Please make sure the name entered is correct."
else
participant = AssignmentParticipant.find(:first, :conditions => ['user_id =? and parent_id =?', user.id, student.parent_id])
if !participant
flash[:notice] = "\"#{params[:user][:name].strip}\" is not a participant of this assignment."
else
team_member = TeamsUser.find(:all, :conditions => ['team_id =? and user_id =?', team.id, user.id])
#check if invited user is already in the team
if (team_member.size > 0)
flash[:notice] = "\"#{user.name}\" is already a member of team."
else
sent_invitation = Invitation.find(:all, :conditions => ['from_id = ? and to_id = ? and assignment_id = ? and reply_status = "W"', student.user_id, user.id, student.parent_id])
#check if the invited user is already invited (i.e. awaiting reply)
if sent_invitation.length == 0
@invitation = Invitation.new
@invitation.to_id = user.id
@invitation.from_id = student.user_id
@invitation.assignment_id = student.parent_id
@invitation.reply_status = 'W'
@invitation.save
else
flash[:notice] = "You have already sent an invitation to \"#{user.name}\"."
end
end
end
end
redirect_to :controller => 'student_team', :action => 'view', :id=> student.id
end
</pre>

'''After Refactor'''
<pre>
def create
user = User.find_by_name(params[:user][:name].strip)
team = AssignmentTeam.find_by_id(params[:team_id])
student = AssignmentParticipant.find(params[:student_id])
return unless current_user_id?(student.user_id)

#check if the invited user is valid
if !user
flash[:note] = "\"#{params[:user][:name].strip}\" does not exist. Please make sure the name entered is correct."
else
participant= AssignmentParticipant.first( :conditions => ['user_id =? and parent_id =?', user.id, student.parent_id])
#check if the user is a participant of the assignment
if !participant
flash[:note] = "\"#{params[:user][:name].strip}\" is not a participant of this assignment."
else
team_member = TeamsUser.all(:conditions => ['team_id =? and user_id =?', team.id, user.id])
#check if invited user is already in the team
if (team_member.size > 0)
flash[:note] = "\"#{user.name}\" is already a member of team."
else
#check if the invited user is already invited (i.e. awaiting reply)
if Invitation.is_invited?(student.user_id, user.id, student.parent_id)
@invitation = Invitation.new
@invitation.to_id = user.id
@invitation.from_id = student.user_id
@invitation.assignment_id = student.parent_id
@invitation.reply_status = 'W'
@invitation.save
else
flash[:note] = "You have already sent an invitation to \"#{user.name}\"."
end
end
end
end

update_join_team_request user,student

redirect_to :controller => 'student_team', :action => 'view', :id=> student.id
end
</pre>

=== Accept Method ===

The theme that we went with for refactoring the accept method is “Skinny Controller, Fat Model.” <ref> Best Practices [http://www.sitepoint.com/10-ruby-on-rails-best-practices/ "10 Ruby on Rails Best Practices"] </ref> We wanted to move much of the logistics out of the accept method letting models handle this while keeping the controller limited to being the interface between the view and model. Before accept method was refactored it was very dense and contained too much functionality. The accept method was in the invitation controller was performing much of the invitation logic that should have been handled in the invitation model and various other models throughout the application. The accept method also played many different roles in that not only was it handling items that the model was responsible for but it was performing many different operations. There are many actions that need to take place when a user accepts an invitation and the controller method was taking care of all of these things. We began to eliminate these issues by extracting smaller operations that the accept method was handling into various methods and moving this code into various models such as the invitation.rb, signed_up_user.rb and team_user.rb.

==== Skinny Controller, Fat Model ====

'''Before: invitation_controller.rb - accept method''' 
The following code served the purpose of moving a user out of their current team when they accept an invite to join another team. The code actually belonged in the teams_user model because it was affecting the teams_user table in the DB. The code was extracted into the subsequent method displayed below and called from the invitation controller.
<pre>
old_entry = TeamsUser.find(:first, :conditions => ['user_id = ? and team_id = ?', student.user_id, params[:team_id]])
if old_entry != nil
old_entry.destroy
end
</pre>

'''After: invitation_controller.rb - accept method'''
<pre>
TeamsUser.remove_previous_team(student.user_id, params[:team_id])
</pre>

'''After: teams-user.rb''' 
The two methods displayed below are the sample method. The first iteration of refactoring produced the first version of the method. After reviewing method names and variable names we found that our first solution could be improved and this came up with the second and final version of the method. <ref> Coding Conventions [http://www.slideshare.net/davidpaluy/ruby-on-rails-coding-conventions-standards-and-best-practices "Ruby On Rails coding conventions, standards and best practices"] </ref>
<pre>
def self.remove_previous_team(user_id, team_id)
old_entry = TeamsUser.find(:first, :conditions => ['user_id = ? and team_id = ?', user_id, team_id])
if old_entry != nil
old_entry.destroy
end
end

def self.remove_team(user_id, team_id)
team_user = TeamsUser.find(:first, :conditions => ['user_id = ? and team_id = ?', user_id, team_id])
if team_user != nil
team_user.destroy
end
end
</pre>

'''Before: invitation_controller.rb - accept method''' 
As with the previous example we found many more examples where a few lines of code serving one purpose could be extracted into its own method. The below code serves the purpose of removing a users team from the assignment team table in the DB. This would take place if a user joins a new team and they had previously created a team and was the only member of that team.
<pre>
old_team = AssignmentTeam.find(:first, :conditions => ['id = ?', params[:team_id]])
if old_team != nil
old_team.destroy
end
</pre>

'''After: invitation_controller.rb - accept method''' 
This is the subsequent method call for the extracted code which was placed in the invitation controller accept method.
<pre>
AssignmentTeam.remove_team_by_id(params[:team_id])
</pre>

'''After: assignment_team.rb''' 
The method created in assignment_team.rb can be seen below.
<pre>
#Remove a team given the team id
def self.remove_team_by_id(id)
old_team = AssignmentTeam.find(id)
if old_team != nil
old_team.destroy
end
end
</pre>

As in the two previous examples there were many method extractions from code within the accept method.
==== Code Readability ====
'''Scopes''' 
Scopes are a useful feature of rails that for creations of reusable constraints for database interactions. Scopes help create reusable code and more readable code. Where one would typically have to write a whole query within their code a scope and be used to minimize the need to write the same query over and over again and decrease the amount of code.

Query within accept method:
<pre>other_members = TeamsUser.find(:all, :conditions => ['team_id = ?', params[:team_id]])</pre>

Query within accept method with scope:
<pre>other_members = TeamsUser.by_team_id(params[:team_id])</pre>

Scope Added in teams_user.rb:
<pre>scope :by_team_id, ->(team_id) { where("team_id = ?", team_id) }</pre>

The help promote better code readability we added a few more scopes during the course of refactoring the accept method.

The below example shows the before and after version of a query. The subsequent version makes the query more readable. 
Before:
<pre>SignUpTopic.find(old_teams_signup.topic_id)['assignment_id']</pre>
After: 
<pre>SignUpTopic.find(old_teams_signup.topic_id).assignment_id</pre>

'''Variable Names''' 
The following variable was used to capture where a member could be added to a team (i.e. is there enough space on the team for the user to join). The boolean value was returned from a method call and stored in the following variable but we felt the variable name was not an accurate representation of it's purpose
<pre>add_member_return</pre>

so we renamed it to the following.
<pre>can_add_member</pre>

After the above design changes the accept method still contained a quite a few calls to the various methods. This cause us to create a model method called accept_invite which served the purpose of encapsulating these function call into a single method that was not in the controller. This method was called from the accept method thus making the accept method considerably smaller. The purpose of the accept_invite method is to handle all of the changes that take place once a user accepts an invite. Below the starting and final version of the accept method can be seen. The accept method is much smaller and more readable since our refactoring.

'''Before Refactor'''
<pre>
def accept
@inv = Invitation.find(params[:inv_id])
@inv.reply_status = 'A'
@inv.save

student = Participant.find(params[:student_id])

#if you are on a team and you accept another invitation, remove your previous entry in the teams_users table.
old_entry = TeamsUser.find(:first, :conditions => ['user_id = ? and team_id = ?', student.user_id, params[:team_id]])
if old_entry != nil
old_entry.destroy
end

#if you are on a team and you accept another invitation and if your old team does not have any members, delete the entry for the team
other_members = TeamsUser.find(:all, :conditions => ['team_id = ?', params[:team_id]])
if other_members.nil? || other_members.length == 0
old_team = AssignmentTeam.find(:first, :conditions => ['id = ?', params[:team_id]])
if old_team != nil
old_team.destroy
end

#if a signup sheet exists then release all the topics selected by this team into the pool.
old_teams_signups = SignedUpUser.find_all_by_creator_id(params[:team_id])
if !old_teams_signups.nil?
for old_teams_signup in old_teams_signups
if old_teams_signup.is_waitlisted == false # i.e., if the old team was occupying a slot, & thus is releasing a slot ...
first_waitlisted_signup = SignedUpUser.find_by_topic_id_and_is_waitlisted(old_teams_signup.topic_id, true)
if !first_waitlisted_signup.nil?
#As this user is going to be allocated a confirmed topic, all of his waitlisted topic signups should be purged
first_waitlisted_signup.is_waitlisted = false
first_waitlisted_signup.save

#Also update the participant table. But first_waitlisted_signup.creator_id is the team id
#so find one of the users on the team because the update_topic_id function in participant
#will take care of updating all the participants on the team
user_id = TeamsUser.find(:first, :conditions => {:team_id => first_waitlisted_signup.creator_id}).user_id
participant = Participant.find_by_user_id_and_parent_id(user_id,old_team.assignment.id)
participant.update_topic_id(old_teams_signup.topic_id)

SignUpTopic.cancel_all_waitlists(first_waitlisted_signup.creator_id, SignUpTopic.find(old_teams_signup.topic_id)['assignment_id'])
end # if !first_waitlisted_signup.nil
# Remove the now-empty team from the slot it is occupying.
end # if old_teams_signup.is_waitlisted == false
old_teams_signup.destroy
end
end
end
</pre>

'''After Refactor'''
<pre>
def accept
@inv = Invitation.find(params[:inv_id])
@inv.reply_status = 'A'
@inv.save

invited_user_id = Participant.find(params[:student_id]).user_id

#Remove the users previous team since they are accepting an invite for possibly a new team.
TeamsUser.remove_team(invited_user_id, params[:team_id])
#Accept the invite and return boolean on whether the add was successful
add_successful = Invitation.accept_invite(params[:team_id], @inv.from_id, @inv.to_id)
#If add wasn't successful because team was full display message
unless add_successful
flash[:error]= "The team already has the maximum number of members."
end

redirect_to :controller => 'student_team', :action => 'view', :id => Participant.find(params[:student_id]).id
end
</pre>

== Bug Fixes ==

=== Invite Requests ===
==== Problem Description ====

When a particular user responds to a advertisement sent out by another user (advertiser) a new Request invitation is created which is displayed in the advertiser's received request section of the team page as shown below: 
[[File:Receivercmh.jpg]]

When the advertiser clicks on the invite the corresponding received request should be removed from the received requests list and the request sender should see the status as accepted when he logs in again as shown below: 
[[File:sendcmh.jpg]]

====Complete steps to reproduce the bug fix====

<pre>
1. Login as admin with password"pass"
2. Create new course and an assignment within the course
- Set all the properties appropriately
- Set the assignment as a team assignment
- Set the deadlines properly.
3. Add 2 participants(user1 and user2) to the assignment(users need to be created who act as participants)
4. Create a topic within the assignment
5. Login as user1 and select the topic in the signup sheet
6. Create an advertisement in the your team link of the assignments
7. Now login as user2 and click on signup sheet. You should see an advertisement sent out by user1.
8. Click on the advertise link and request an invitation.
9. Login as user1 again and go to the your team link.
10. User1 should see the the invitation request in the received requests with the invite and decline button next to it.
11. When user1 clicks on the invite button the request invitation should be removed and when user2 logs in again he should see the sent request as accepted.
</pre>

====Code changes done to fix the bug====
A new method was introduced to update the "status" field of the join_table_requests
.The method is a follows: 
<pre>
def update_join_team_request
old_entry = JoinTeamRequest.first(:conditions => ['participant_id =? and team_id =?', params[:participant_id],params[:team_id]])
if old_entry
old_entry.update_attribute("status",'A')
end
end
</pre>

=== Error Messages ===
====Problem Description====
We working on bug fixes and refactoring we noticed that some of the error messages which were not bring displayed. The issue was that the create method was setting these error messages using notice which was not handled by the flash messages partial used throughout the application. We fixed this so that error message are now being displayed properly as shown below: 

[[File:messagecmh.jpg]]

====Code Changes====
#The flash[:notice] is changed to flash[:note] in the invitation_controller.rb file 
#The _flash_messages.html.erb file is updated to include :notice which may be used in some other parts of the application.

== Future Work ==
===Refactoring===
For the current project we only focused on refactoring the invitation_controller.rb and the models associated with it.A thorough and a wholesome approach can lead to better code reuse. 
===Testing===
Since this project was about refactoring an existing code, we could not strictly follow the TDD model where RSpecs are written before the methods are designed.This may be considered for future assignments. 
===Documentation===
A detailed documentation of the invitation and the team advertisement process can be produced which will help the users understand the feature clearly. 

= References =
<references/>

CSC/ECE 517 Fall 2013/oss cmh

2013-10-30T16:51:49Z

Mrsreena: /* Create Method */

CSC/ECE 517 Fall 2013/oss cmh

2013-10-30T16:51:11Z

Mrsreena: /* Create Method */

== Introduction ==

The invitation controller within Expertiza handles the invite functionality which allows user to send and receives invitations. Users can create teams and invite users to join there team. The invitation controller handles the creation of the invite and the accept or decline of an invite. The invitation controller also handles requests to join teams via advertisements. After advertisements are sent a user can request to receive and invite to the team and subsequent functionality is handled by the invitation controller once an invite is sent. Our project was to refactor the code around invitations mainly dealing with the invitation controller and invitation model.

== Project Description ==
'''Classes:''' invitation_controller.rb (104 lines)
invitation.rb (5 lines)

'''What it does:''' Handles invitations to join teams.

'''What needs to be done:''' The code is deeply nested and quite confusing. There should be a single method responsible for finding whether a user is already on a team, adding someone onto a waitlist, dropping someone off of a waitlist, changing/updating the topic that the user is assigned to, etc. Some of these methods should be in model classes, such as invitation.rb and signed_up_user.rb. Break the complicated methods into shorter methods with clear names, and place these methods in the most appropriate class, moving a lot of functionality to the model classes.

Currently, after someone joins a team, pending invitations are not removed. There should be a method handling deletion of invitations (including declined invitations) to a user after that user joins a team. This should be a model method.

Though this class is not long, the code looks and reads like it is very complicated. Breaking it down into multiple methods with clear names and proper division of functionality between classes will be a challenge.

== Motivation ==

As is noted in the project description section our project was centered around refactoring the invitation controller. Much of the functionality that was implemented within the invitation controller actually should have been in model classes. There was only about 5 lines of code in the invitation model while there were 104 lines in the invitation controller. A lot of the code in the invitation controller needed to be dispersed amongst the invitation model and various other models within the application. The code within the invitation controller was also very confusing and difficult to understand for a number of reasons. Some of the problems causing the code to be complicated included deeply nested if statements, dense methods and variable names that did not accurately reflect the values they held. The goal of our project was to make the overall design of the invitation controller simpler thus making the code easier to understand and ensuring that distribution of functionality in the application honored the MVC framework.

== Design Changes ==

=== Create Method ===
Though the create method is relatively small and fairly understandable, it still asked for a few changes.There were a few method calls to the deprecated method "find" which had to be replaced with calls to the "first" and the "all" methods.
Example:
The call to
<pre>
AssignmentParticipant.find(:first, :conditions => ['user_id =? and parent_id =?', user.id, student.parent_id])
</pre>
is replaced with
<pre>
AssignmentParticipant.first( :conditions => ['user_id =? and parent_id =?', user.id, student.parent_id])
</pre>
The call to
<pre>
TeamsUser.find(:all, :conditions => ['team_id =? and user_id =?', team.id, user.id])
</pre>
is replaced with
<pre>
TeamsUser.all(:conditions => ['team_id =? and user_id =?', team.id, user.id])
</pre>

'''Before Refactor'''
<pre>
def create
user = User.find_by_name(params[:user][:name].strip)
team = AssignmentTeam.find_by_id(params[:team_id])
student = AssignmentParticipant.find(params[:student_id])
return unless current_user_id?(student.user_id)

#check if the invited user is valid
if !user
flash[:notice] = "\"#{params[:user][:name].strip}\" does not exist. Please make sure the name entered is correct."
else
participant = AssignmentParticipant.find(:first, :conditions => ['user_id =? and parent_id =?', user.id, student.parent_id])
if !participant
flash[:notice] = "\"#{params[:user][:name].strip}\" is not a participant of this assignment."
else
team_member = TeamsUser.find(:all, :conditions => ['team_id =? and user_id =?', team.id, user.id])
#check if invited user is already in the team
if (team_member.size > 0)
flash[:notice] = "\"#{user.name}\" is already a member of team."
else
sent_invitation = Invitation.find(:all, :conditions => ['from_id = ? and to_id = ? and assignment_id = ? and reply_status = "W"', student.user_id, user.id, student.parent_id])
#check if the invited user is already invited (i.e. awaiting reply)
if sent_invitation.length == 0
@invitation = Invitation.new
@invitation.to_id = user.id
@invitation.from_id = student.user_id
@invitation.assignment_id = student.parent_id
@invitation.reply_status = 'W'
@invitation.save
else
flash[:notice] = "You have already sent an invitation to \"#{user.name}\"."
end
end
end
end
redirect_to :controller => 'student_team', :action => 'view', :id=> student.id
end
</pre>

'''After Refactor'''
<pre>
def create
user = User.find_by_name(params[:user][:name].strip)
team = AssignmentTeam.find_by_id(params[:team_id])
student = AssignmentParticipant.find(params[:student_id])
return unless current_user_id?(student.user_id)

#check if the invited user is valid
if !user
flash[:note] = "\"#{params[:user][:name].strip}\" does not exist. Please make sure the name entered is correct."
else
participant= AssignmentParticipant.first( :conditions => ['user_id =? and parent_id =?', user.id, student.parent_id])
#check if the user is a participant of the assignment
if !participant
flash[:note] = "\"#{params[:user][:name].strip}\" is not a participant of this assignment."
else
team_member = TeamsUser.all(:conditions => ['team_id =? and user_id =?', team.id, user.id])
#check if invited user is already in the team
if (team_member.size > 0)
flash[:note] = "\"#{user.name}\" is already a member of team."
else
#check if the invited user is already invited (i.e. awaiting reply)
if Invitation.is_invited?(student.user_id, user.id, student.parent_id)
@invitation = Invitation.new
@invitation.to_id = user.id
@invitation.from_id = student.user_id
@invitation.assignment_id = student.parent_id
@invitation.reply_status = 'W'
@invitation.save
else
flash[:note] = "You have already sent an invitation to \"#{user.name}\"."
end
end
end
end

update_join_team_request user,student

redirect_to :controller => 'student_team', :action => 'view', :id=> student.id
end
</pre>

=== Accept Method ===

The theme that we went with for refactoring the accept method is “Skinny Controller, Fat Model.” <ref> Best Practices [http://www.sitepoint.com/10-ruby-on-rails-best-practices/ "10 Ruby on Rails Best Practices"] </ref> We wanted to move much of the logistics out of the accept method letting models handle this while keeping the controller limited to being the interface between the view and model. Before accept method was refactored it was very dense and contained too much functionality. The accept method was in the invitation controller was performing much of the invitation logic that should have been handled in the invitation model and various other models throughout the application. The accept method also played many different roles in that not only was it handling items that the model was responsible for but it was performing many different operations. There are many actions that need to take place when a user accepts an invitation and the controller method was taking care of all of these things. We began to eliminate these issues by extracting smaller operations that the accept method was handling into various methods and moving this code into various models such as the invitation.rb, signed_up_user.rb and team_user.rb.

==== Skinny Controller, Fat Model ====

'''Before: invitation_controller.rb - accept method''' 
The following code served the purpose of moving a user out of their current team when they accept an invite to join another team. The code actually belonged in the teams_user model because it was affecting the teams_user table in the DB. The code was extracted into the subsequent method displayed below and called from the invitation controller.
<pre>
old_entry = TeamsUser.find(:first, :conditions => ['user_id = ? and team_id = ?', student.user_id, params[:team_id]])
if old_entry != nil
old_entry.destroy
end
</pre>

'''After: invitation_controller.rb - accept method'''
<pre>
TeamsUser.remove_previous_team(student.user_id, params[:team_id])
</pre>

'''After: teams-user.rb''' 
The two methods displayed below are the sample method. The first iteration of refactoring produced the first version of the method. After reviewing method names and variable names we found that our first solution could be improved and this came up with the second and final version of the method. <ref> Coding Conventions [http://www.slideshare.net/davidpaluy/ruby-on-rails-coding-conventions-standards-and-best-practices "Ruby On Rails coding conventions, standards and best practices"] </ref>
<pre>
def self.remove_previous_team(user_id, team_id)
old_entry = TeamsUser.find(:first, :conditions => ['user_id = ? and team_id = ?', user_id, team_id])
if old_entry != nil
old_entry.destroy
end
end

def self.remove_team(user_id, team_id)
team_user = TeamsUser.find(:first, :conditions => ['user_id = ? and team_id = ?', user_id, team_id])
if team_user != nil
team_user.destroy
end
end
</pre>

'''Before: invitation_controller.rb - accept method''' 
As with the previous example we found many more examples where a few lines of code serving one purpose could be extracted into its own method. The below code serves the purpose of removing a users team from the assignment team table in the DB. This would take place if a user joins a new team and they had previously created a team and was the only member of that team.
<pre>
old_team = AssignmentTeam.find(:first, :conditions => ['id = ?', params[:team_id]])
if old_team != nil
old_team.destroy
end
</pre>

'''After: invitation_controller.rb - accept method''' 
This is the subsequent method call for the extracted code which was placed in the invitation controller accept method.
<pre>
AssignmentTeam.remove_team_by_id(params[:team_id])
</pre>

'''After: assignment_team.rb''' 
The method created in assignment_team.rb can be seen below.
<pre>
#Remove a team given the team id
def self.remove_team_by_id(id)
old_team = AssignmentTeam.find(id)
if old_team != nil
old_team.destroy
end
end
</pre>

As in the two previous examples there were many method extractions from code within the accept method.
==== Code Readability ====
'''Scopes''' 
Scopes are a useful feature of rails that for creations of reusable constraints for database interactions. Scopes help create reusable code and more readable code. Where one would typically have to write a whole query within their code a scope and be used to minimize the need to write the same query over and over again and decrease the amount of code.

Query within accept method:
<pre>other_members = TeamsUser.find(:all, :conditions => ['team_id = ?', params[:team_id]])</pre>

Query within accept method with scope:
<pre>other_members = TeamsUser.by_team_id(params[:team_id])</pre>

Scope Added in teams_user.rb:
<pre>scope :by_team_id, ->(team_id) { where("team_id = ?", team_id) }</pre>

The help promote better code readability we added a few more scopes during the course of refactoring the accept method.

The below example shows the before and after version of a query. The subsequent version makes the query more readable. 
Before:
<pre>SignUpTopic.find(old_teams_signup.topic_id)['assignment_id']</pre>
After: 
<pre>SignUpTopic.find(old_teams_signup.topic_id).assignment_id</pre>

'''Variable Names''' 
The following variable was used to capture where a member could be added to a team (i.e. is there enough space on the team for the user to join). The boolean value was returned from a method call and stored in the following variable but we felt the variable name was not an accurate representation of it's purpose
<pre>add_member_return</pre>

so we renamed it to the following.
<pre>can_add_member</pre>

After the above design changes the accept method still contained a quite a few calls to the various methods. This cause us to create a model method called accept_invite which served the purpose of encapsulating these function call into a single method that was not in the controller. This method was called from the accept method thus making the accept method considerably smaller. The purpose of the accept_invite method is to handle all of the changes that take place once a user accepts an invite. Below the starting and final version of the accept method can be seen. The accept method is much smaller and more readable since our refactoring.

'''Before Refactor'''
<pre>
def accept
@inv = Invitation.find(params[:inv_id])
@inv.reply_status = 'A'
@inv.save

student = Participant.find(params[:student_id])

#if you are on a team and you accept another invitation, remove your previous entry in the teams_users table.
old_entry = TeamsUser.find(:first, :conditions => ['user_id = ? and team_id = ?', student.user_id, params[:team_id]])
if old_entry != nil
old_entry.destroy
end

#if you are on a team and you accept another invitation and if your old team does not have any members, delete the entry for the team
other_members = TeamsUser.find(:all, :conditions => ['team_id = ?', params[:team_id]])
if other_members.nil? || other_members.length == 0
old_team = AssignmentTeam.find(:first, :conditions => ['id = ?', params[:team_id]])
if old_team != nil
old_team.destroy
end

#if a signup sheet exists then release all the topics selected by this team into the pool.
old_teams_signups = SignedUpUser.find_all_by_creator_id(params[:team_id])
if !old_teams_signups.nil?
for old_teams_signup in old_teams_signups
if old_teams_signup.is_waitlisted == false # i.e., if the old team was occupying a slot, & thus is releasing a slot ...
first_waitlisted_signup = SignedUpUser.find_by_topic_id_and_is_waitlisted(old_teams_signup.topic_id, true)
if !first_waitlisted_signup.nil?
#As this user is going to be allocated a confirmed topic, all of his waitlisted topic signups should be purged
first_waitlisted_signup.is_waitlisted = false
first_waitlisted_signup.save

#Also update the participant table. But first_waitlisted_signup.creator_id is the team id
#so find one of the users on the team because the update_topic_id function in participant
#will take care of updating all the participants on the team
user_id = TeamsUser.find(:first, :conditions => {:team_id => first_waitlisted_signup.creator_id}).user_id
participant = Participant.find_by_user_id_and_parent_id(user_id,old_team.assignment.id)
participant.update_topic_id(old_teams_signup.topic_id)

SignUpTopic.cancel_all_waitlists(first_waitlisted_signup.creator_id, SignUpTopic.find(old_teams_signup.topic_id)['assignment_id'])
end # if !first_waitlisted_signup.nil
# Remove the now-empty team from the slot it is occupying.
end # if old_teams_signup.is_waitlisted == false
old_teams_signup.destroy
end
end
end
</pre>

'''After Refactor'''
<pre>
def accept
@inv = Invitation.find(params[:inv_id])
@inv.reply_status = 'A'
@inv.save

invited_user_id = Participant.find(params[:student_id]).user_id

#Remove the users previous team since they are accepting an invite for possibly a new team.
TeamsUser.remove_team(invited_user_id, params[:team_id])
#Accept the invite and return boolean on whether the add was successful
add_successful = Invitation.accept_invite(params[:team_id], @inv.from_id, @inv.to_id)
#If add wasn't successful because team was full display message
unless add_successful
flash[:error]= "The team already has the maximum number of members."
end

redirect_to :controller => 'student_team', :action => 'view', :id => Participant.find(params[:student_id]).id
end
</pre>

== Bug Fixes ==

=== Invite Requests ===
==== Problem Description ====

When a particular user responds to a advertisement sent out by another user (advertiser) a new Request invitation is created which is displayed in the advertiser's received request section of the team page as shown below: 
[[File:Receivercmh.jpg]]

When the advertiser clicks on the invite the corresponding received request should be removed from the received requests list and the request sender should see the status as accepted when he logs in again as shown below: 
[[File:sendcmh.jpg]]

====Complete steps to reproduce the bug fix====

<pre>
1. Login as admin with password"pass"
2. Create new course and an assignment within the course
- Set all the properties appropriately
- Set the assignment as a team assignment
- Set the deadlines properly.
3. Add 2 participants(user1 and user2) to the assignment(users need to be created who act as participants)
4. Create a topic within the assignment
5. Login as user1 and select the topic in the signup sheet
6. Create an advertisement in the your team link of the assignments
7. Now login as user2 and click on signup sheet. You should see an advertisement sent out by user1.
8. Click on the advertise link and request an invitation.
9. Login as user1 again and go to the your team link.
10. User1 should see the the invitation request in the received requests with the invite and decline button next to it.
11. When user1 clicks on the invite button the request invitation should be removed and when user2 logs in again he should see the sent request as accepted.
</pre>

====Code changes done to fix the bug====
A new method was introduced to update the "status" field of the join_table_requests
.The method is a follows: 
<pre>
def update_join_team_request
old_entry = JoinTeamRequest.first(:conditions => ['participant_id =? and team_id =?', params[:participant_id],params[:team_id]])
if old_entry
old_entry.update_attribute("status",'A')
end
end
</pre>

=== Error Messages ===
====Problem Description====
We working on bug fixes and refactoring we noticed that some of the error messages which were not bring displayed. The issue was that the create method was setting these error messages using notice which was not handled by the flash messages partial used throughout the application. We fixed this so that error message are now being displayed properly as shown below: 

[[File:messagecmh.jpg]]

====Code Changes====
#The flash[:notice] is changed to flash[:note] in the invitation_controller.rb file 
#The _flash_messages.html.erb file is updated to include :notice which may be used in some other parts of the application.

== Future Work ==

= References =
<references/>

CSC/ECE 517 Fall 2013/oss cmh

2013-10-30T16:28:07Z

Mrsreena: /* Create Method */

== Introduction ==

The invitation controller within Expertiza handles the invite functionality which allows user to send and receives invitations. Users can create teams and invite users to join there team. The invitation controller handles the creation of the invite and the accept or decline of an invite. The invitation controller also handles requests to join teams via advertisements. After advertisements are sent a user can request to receive and invite to the team and subsequent functionality is handled by the invitation controller once an invite is sent. Our project was to refactor the code around invitations mainly dealing with the invitation controller and invitation model.

== Project Description ==
'''Classes:''' invitation_controller.rb (104 lines)
invitation.rb (5 lines)

'''What it does:''' Handles invitations to join teams.

'''What needs to be done:''' The code is deeply nested and quite confusing. There should be a single method responsible for finding whether a user is already on a team, adding someone onto a waitlist, dropping someone off of a waitlist, changing/updating the topic that the user is assigned to, etc. Some of these methods should be in model classes, such as invitation.rb and signed_up_user.rb. Break the complicated methods into shorter methods with clear names, and place these methods in the most appropriate class, moving a lot of functionality to the model classes.

Currently, after someone joins a team, pending invitations are not removed. There should be a method handling deletion of invitations (including declined invitations) to a user after that user joins a team. This should be a model method.

Though this class is not long, the code looks and reads like it is very complicated. Breaking it down into multiple methods with clear names and proper division of functionality between classes will be a challenge.

== Motivation ==

As is noted in the project description section our project was centered around refactoring the invitation controller. Much of the functionality that was implemented within the invitation controller actually should have been in model classes. There was only about 5 lines of code in the invitation model while there were 104 lines in the invitation controller. A lot of the code in the invitation controller needed to be dispersed amongst the invitation model and various other models within the application. The code within the invitation controller was also very confusing and difficult to understand for a number of reasons. Some of the problems causing the code to be complicated included deeply nested if statements, dense methods and variable names that did not accurately reflect the values they held. The goal of our project was to make the overall design of the invitation controller simpler thus making the code easier to understand and ensuring that distribution of functionality in the application honored the MVC framework.

== Design Changes ==

=== Create Method ===
'''Before Refactor'''
<pre>
def create
user = User.find_by_name(params[:user][:name].strip)
team = AssignmentTeam.find_by_id(params[:team_id])
student = AssignmentParticipant.find(params[:student_id])
return unless current_user_id?(student.user_id)

#check if the invited user is valid
if !user
flash[:notice] = "\"#{params[:user][:name].strip}\" does not exist. Please make sure the name entered is correct."
else
participant = AssignmentParticipant.find(:first, :conditions => ['user_id =? and parent_id =?', user.id, student.parent_id])
if !participant
flash[:notice] = "\"#{params[:user][:name].strip}\" is not a participant of this assignment."
else
team_member = TeamsUser.find(:all, :conditions => ['team_id =? and user_id =?', team.id, user.id])
#check if invited user is already in the team
if (team_member.size > 0)
flash[:notice] = "\"#{user.name}\" is already a member of team."
else
sent_invitation = Invitation.find(:all, :conditions => ['from_id = ? and to_id = ? and assignment_id = ? and reply_status = "W"', student.user_id, user.id, student.parent_id])
#check if the invited user is already invited (i.e. awaiting reply)
if sent_invitation.length == 0
@invitation = Invitation.new
@invitation.to_id = user.id
@invitation.from_id = student.user_id
@invitation.assignment_id = student.parent_id
@invitation.reply_status = 'W'
@invitation.save
else
flash[:notice] = "You have already sent an invitation to \"#{user.name}\"."
end
end
end
end
redirect_to :controller => 'student_team', :action => 'view', :id=> student.id
end
</pre>

'''After Refactor'''
<pre>
def create
user = User.find_by_name(params[:user][:name].strip)
team = AssignmentTeam.find_by_id(params[:team_id])
student = AssignmentParticipant.find(params[:student_id])
return unless current_user_id?(student.user_id)

#check if the invited user is valid
if !user
flash[:note] = "\"#{params[:user][:name].strip}\" does not exist. Please make sure the name entered is correct."
else
participant= AssignmentParticipant.first( :conditions => ['user_id =? and parent_id =?', user.id, student.parent_id])
#check if the user is a participant of the assignment
if !participant
flash[:note] = "\"#{params[:user][:name].strip}\" is not a participant of this assignment."
else
team_member = TeamsUser.all(:conditions => ['team_id =? and user_id =?', team.id, user.id])
#check if invited user is already in the team
if (team_member.size > 0)
flash[:note] = "\"#{user.name}\" is already a member of team."
else
#check if the invited user is already invited (i.e. awaiting reply)
if Invitation.is_invited?(student.user_id, user.id, student.parent_id)
@invitation = Invitation.new
@invitation.to_id = user.id
@invitation.from_id = student.user_id
@invitation.assignment_id = student.parent_id
@invitation.reply_status = 'W'
@invitation.save
else
flash[:note] = "You have already sent an invitation to \"#{user.name}\"."
end
end
end
end

update_join_team_request user,student

redirect_to :controller => 'student_team', :action => 'view', :id=> student.id
end
</pre>

=== Accept Method ===

The theme that we went with for refactoring the accept method is “Skinny Controller, Fat Model.” <ref> Best Practices [http://www.sitepoint.com/10-ruby-on-rails-best-practices/ "10 Ruby on Rails Best Practices"] </ref> We wanted to move much of the logistics out of the accept method letting models handle this while keeping the controller limited to being the interface between the view and model. Before accept method was refactored it was very dense and contained too much functionality. The accept method was in the invitation controller was performing much of the invitation logic that should have been handled in the invitation model and various other models throughout the application. The accept method also played many different roles in that not only was it handling items that the model was responsible for but it was performing many different operations. There are many actions that need to take place when a user accepts an invitation and the controller method was taking care of all of these things. We began to eliminate these issues by extracting smaller operations that the accept method was handling into various methods and moving this code into various models such as the invitation.rb, signed_up_user.rb and team_user.rb.

==== Skinny Controller, Fat Model ====

'''Before: invitation_controller.rb - accept method''' 
The following code served the purpose of moving a user out of their current team when they accept an invite to join another team. The code actually belonged in the teams_user model because it was affecting the teams_user table in the DB. The code was extracted into the subsequent method displayed below and called from the invitation controller.
<pre>
old_entry = TeamsUser.find(:first, :conditions => ['user_id = ? and team_id = ?', student.user_id, params[:team_id]])
if old_entry != nil
old_entry.destroy
end
</pre>

'''After: invitation_controller.rb - accept method'''
<pre>
TeamsUser.remove_previous_team(student.user_id, params[:team_id])
</pre>

'''After: teams-user.rb''' 
The two methods displayed below are the sample method. The first iteration of refactoring produced the first version of the method. After reviewing method names and variable names we found that our first solution could be improved and this came up with the second and final version of the method. <ref> Coding Conventions [http://www.slideshare.net/davidpaluy/ruby-on-rails-coding-conventions-standards-and-best-practices "Ruby On Rails coding conventions, standards and best practices"] </ref>
<pre>
def self.remove_previous_team(user_id, team_id)
old_entry = TeamsUser.find(:first, :conditions => ['user_id = ? and team_id = ?', user_id, team_id])
if old_entry != nil
old_entry.destroy
end
end

def self.remove_team(user_id, team_id)
team_user = TeamsUser.find(:first, :conditions => ['user_id = ? and team_id = ?', user_id, team_id])
if team_user != nil
team_user.destroy
end
end
</pre>

'''Before: invitation_controller.rb - accept method''' 
As with the previous example we found many more examples where a few lines of code serving one purpose could be extracted into its own method. The below code serves the purpose of removing a users team from the assignment team table in the DB. This would take place if a user joins a new team and they had previously created a team and was the only member of that team.
<pre>
old_team = AssignmentTeam.find(:first, :conditions => ['id = ?', params[:team_id]])
if old_team != nil
old_team.destroy
end
</pre>

'''After: invitation_controller.rb - accept method''' 
This is the subsequent method call for the extracted code which was placed in the invitation controller accept method.
<pre>
AssignmentTeam.remove_team_by_id(params[:team_id])
</pre>

'''After: assignment_team.rb''' 
The method created in assignment_team.rb can be seen below.
<pre>
#Remove a team given the team id
def self.remove_team_by_id(id)
old_team = AssignmentTeam.find(id)
if old_team != nil
old_team.destroy
end
end
</pre>

As in the two previous examples there were many method extractions from code within the accept method.
==== Code Readability ====
'''Scopes''' 
Scopes are a useful feature of rails that for creations of reusable constraints for database interactions. Scopes help create reusable code and more readable code. Where one would typically have to write a whole query within their code a scope and be used to minimize the need to write the same query over and over again and decrease the amount of code.

Query within accept method:
<pre>other_members = TeamsUser.find(:all, :conditions => ['team_id = ?', params[:team_id]])</pre>

Query within accept method with scope:
<pre>other_members = TeamsUser.by_team_id(params[:team_id])</pre>

Scope Added in teams_user.rb:
<pre>scope :by_team_id, ->(team_id) { where("team_id = ?", team_id) }</pre>

The help promote better code readability we added a few more scopes during the course of refactoring the accept method.

The below example shows the before and after version of a query. The subsequent version makes the query more readable. 
Before:
<pre>SignUpTopic.find(old_teams_signup.topic_id)['assignment_id']</pre>
After: 
<pre>SignUpTopic.find(old_teams_signup.topic_id).assignment_id</pre>

'''Variable Names''' 
The following variable was used to capture where a member could be added to a team (i.e. is there enough space on the team for the user to join). The boolean value was returned from a method call and stored in the following variable but we felt the variable name was not an accurate representation of it's purpose
<pre>add_member_return</pre>

so we renamed it to the following.
<pre>can_add_member</pre>

After the above design changes the accept method still contained a quite a few calls to the various methods. This cause us to create a model method called accept_invite which served the purpose of encapsulating these function call into a single method that was not in the controller. This method was called from the accept method thus making the accept method considerably smaller. The purpose of the accept_invite method is to handle all of the changes that take place once a user accepts an invite. Below the starting and final version of the accept method can be seen. The accept method is much smaller and more readable since our refactoring.

'''Before Refactor'''
<pre>
def accept
@inv = Invitation.find(params[:inv_id])
@inv.reply_status = 'A'
@inv.save

student = Participant.find(params[:student_id])

#if you are on a team and you accept another invitation, remove your previous entry in the teams_users table.
old_entry = TeamsUser.find(:first, :conditions => ['user_id = ? and team_id = ?', student.user_id, params[:team_id]])
if old_entry != nil
old_entry.destroy
end

#if you are on a team and you accept another invitation and if your old team does not have any members, delete the entry for the team
other_members = TeamsUser.find(:all, :conditions => ['team_id = ?', params[:team_id]])
if other_members.nil? || other_members.length == 0
old_team = AssignmentTeam.find(:first, :conditions => ['id = ?', params[:team_id]])
if old_team != nil
old_team.destroy
end

#if a signup sheet exists then release all the topics selected by this team into the pool.
old_teams_signups = SignedUpUser.find_all_by_creator_id(params[:team_id])
if !old_teams_signups.nil?
for old_teams_signup in old_teams_signups
if old_teams_signup.is_waitlisted == false # i.e., if the old team was occupying a slot, & thus is releasing a slot ...
first_waitlisted_signup = SignedUpUser.find_by_topic_id_and_is_waitlisted(old_teams_signup.topic_id, true)
if !first_waitlisted_signup.nil?
#As this user is going to be allocated a confirmed topic, all of his waitlisted topic signups should be purged
first_waitlisted_signup.is_waitlisted = false
first_waitlisted_signup.save

#Also update the participant table. But first_waitlisted_signup.creator_id is the team id
#so find one of the users on the team because the update_topic_id function in participant
#will take care of updating all the participants on the team
user_id = TeamsUser.find(:first, :conditions => {:team_id => first_waitlisted_signup.creator_id}).user_id
participant = Participant.find_by_user_id_and_parent_id(user_id,old_team.assignment.id)
participant.update_topic_id(old_teams_signup.topic_id)

SignUpTopic.cancel_all_waitlists(first_waitlisted_signup.creator_id, SignUpTopic.find(old_teams_signup.topic_id)['assignment_id'])
end # if !first_waitlisted_signup.nil
# Remove the now-empty team from the slot it is occupying.
end # if old_teams_signup.is_waitlisted == false
old_teams_signup.destroy
end
end
end
</pre>

'''After Refactor'''
<pre>
def accept
@inv = Invitation.find(params[:inv_id])
@inv.reply_status = 'A'
@inv.save

invited_user_id = Participant.find(params[:student_id]).user_id

#Remove the users previous team since they are accepting an invite for possibly a new team.
TeamsUser.remove_team(invited_user_id, params[:team_id])
#Accept the invite and return boolean on whether the add was successful
add_successful = Invitation.accept_invite(params[:team_id], @inv.from_id, @inv.to_id)
#If add wasn't successful because team was full display message
unless add_successful
flash[:error]= "The team already has the maximum number of members."
end

redirect_to :controller => 'student_team', :action => 'view', :id => Participant.find(params[:student_id]).id
end
</pre>

== Bug Fixes ==

=== Invite Requests ===
==== Problem Description ====

When a particular user responds to a advertisement sent out by another user (advertiser) a new Request invitation is created which is displayed in the advertiser's received request section of the team page as shown below: 
[[File:Receivercmh.jpg]]

When the advertiser clicks on the invite the corresponding received request should be removed from the received requests list and the request sender should see the status as accepted when he logs in again as shown below: 
[[File:sendcmh.jpg]]

====Complete steps to reproduce the bug fix====

<pre>
1. Login as admin with password"pass"
2. Create new course and an assignment within the course
- Set all the properties appropriately
- Set the assignment as a team assignment
- Set the deadlines properly.
3. Add 2 participants(user1 and user2) to the assignment(users need to be created who act as participants)
4. Create a topic within the assignment
5. Login as user1 and select the topic in the signup sheet
6. Create an advertisement in the your team link of the assignments
7. Now login as user2 and click on signup sheet. You should see an advertisement sent out by user1.
8. Click on the advertise link and request an invitation.
9. Login as user1 again and go to the your team link.
10. User1 should see the the invitation request in the received requests with the invite and decline button next to it.
11. When user1 clicks on the invite button the request invitation should be removed and when user2 logs in again he should see the sent request as accepted.
</pre>

====Code changes done to fix the bug====
A new method was introduced to update the "status" field of the join_table_requests
.The method is a follows: 
<pre>
def update_join_team_request
old_entry = JoinTeamRequest.first(:conditions => ['participant_id =? and team_id =?', params[:participant_id],params[:team_id]])
if old_entry
old_entry.update_attribute("status",'A')
end
end
</pre>

=== Error Messages ===
====Problem Description====
We working on bug fixes and refactoring we noticed that some of the error messages which were not bring displayed. The issue was that the create method was setting these error messages using notice which was not handled by the flash messages partial used throughout the application. We fixed this so that error message are now being displayed properly as shown below: 

[[File:messagecmh.jpg]]

====Code Changes====
#The flash[:notice] is changed to flash[:note] in the invitation_controller.rb file 
#The _flash_messages.html.erb file is updated to include :notice which may be used in some other parts of the application.

== Future Work ==

= References =
<references/>

CSC/ECE 517 Fall 2013/oss cmh

2013-10-29T23:18:19Z

Mrsreena: /* Problem Description */

== Introduction ==

What the invitation controller does and the process advertising, creating invites and accepting invites.

== Project Description ==
'''Classes:''' invitation_controller.rb (104 lines)
invitation.rb (5 lines)

'''What it does:''' Handles invitations to join teams.

'''What needs to be done:''' The code is deeply nested and quite confusing. There should be a single method responsible for finding whether a user is already on a team, adding someone onto a waitlist, dropping someone off of a waitlist, changing/updating the topic that the user is assigned to, etc. Some of these methods should be in model classes, such as invitation.rb and signed_up_user.rb. Break the complicated methods into shorter methods with clear names, and place these methods in the most appropriate class, moving a lot of functionality to the model classes.

Currently, after someone joins a team, pending invitations are not removed. There should be a method handling deletion of invitations (including declined invitations) to a user after that user joins a team. This should be a model method.

Though this class is not long, the code looks and reads like it is very complicated. Breaking it down into multiple methods with clear names and proper division of functionality between classes will be a challenge.

== Motivation ==

Briefly talk about why invitation controller needed refactoring.

== Design Changes ==

=== Create Method ===
'''Before Refactor'''
<pre>
def create
user = User.find_by_name(params[:user][:name].strip)
team = AssignmentTeam.find_by_id(params[:team_id])
student = AssignmentParticipant.find(params[:student_id])
return unless current_user_id?(student.user_id)

#check if the invited user is valid
if !user
flash[:notice] = "\"#{params[:user][:name].strip}\" does not exist. Please make sure the name entered is correct."
else
participant = AssignmentParticipant.find(:first, :conditions => ['user_id =? and parent_id =?', user.id, student.parent_id])
if !participant
flash[:notice] = "\"#{params[:user][:name].strip}\" is not a participant of this assignment."
else
team_member = TeamsUser.find(:all, :conditions => ['team_id =? and user_id =?', team.id, user.id])
#check if invited user is already in the team
if (team_member.size > 0)
flash[:notice] = "\"#{user.name}\" is already a member of team."
else
sent_invitation = Invitation.find(:all, :conditions => ['from_id = ? and to_id = ? and assignment_id = ? and reply_status = "W"', student.user_id, user.id, student.parent_id])
#check if the invited user is already invited (i.e. awaiting reply)
if sent_invitation.length == 0
@invitation = Invitation.new
@invitation.to_id = user.id
@invitation.from_id = student.user_id
@invitation.assignment_id = student.parent_id
@invitation.reply_status = 'W'
@invitation.save
else
flash[:notice] = "You have already sent an invitation to \"#{user.name}\"."
end
end
end
end
redirect_to :controller => 'student_team', :action => 'view', :id=> student.id
end
</pre>

'''After Refactor'''
<pre>
def create
user = User.find_by_name(params[:user][:name].strip)
team = AssignmentTeam.find_by_id(params[:team_id])
student = AssignmentParticipant.find(params[:student_id])
return unless current_user_id?(student.user_id)

#check if the invited user is valid
if !user
flash[:note] = "\"#{params[:user][:name].strip}\" does not exist. Please make sure the name entered is correct."
else
participant= AssignmentParticipant.first( :conditions => ['user_id =? and parent_id =?', user.id, student.parent_id])
#check if the user is a participant of the assignment
if !participant
flash[:note] = "\"#{params[:user][:name].strip}\" is not a participant of this assignment."
else
team_member = TeamsUser.all(:conditions => ['team_id =? and user_id =?', team.id, user.id])
#check if invited user is already in the team
if (team_member.size > 0)
flash[:note] = "\"#{user.name}\" is already a member of team."
else
#check if the invited user is already invited (i.e. awaiting reply)
if Invitation.is_invited?(student.user_id, user.id, student.parent_id)
@invitation = Invitation.new
@invitation.to_id = user.id
@invitation.from_id = student.user_id
@invitation.assignment_id = student.parent_id
@invitation.reply_status = 'W'
@invitation.save
else
flash[:note] = "You have already sent an invitation to \"#{user.name}\"."
end
end
end
end

update_join_team_request

redirect_to :controller => 'student_team', :action => 'view', :id=> student.id
end
</pre>

=== Accept Method ===

The theme that we went with for refactoring the accept method is “Skinny Controller, Fat Model.” <ref> Best Practices [http://www.sitepoint.com/10-ruby-on-rails-best-practices/ "10 Ruby on Rails Best Practices"] </ref> We wanted to move much of the logistics out of the accept method letting models handle this while keeping the controller limited to being the interface between the view and model. Before accept method was refactored it was very dense and contained too much functionality. The accept method was in the invitation controller was performing much of the invitation logic that should have been handled in the invitation model and various other models throughout the application. The accept method also played many different roles in that not only was it handling items that the model was responsible for but it was performing many different operations. There are many actions that need to take place when a user accepts an invitation and the controller method was taking care of all of these things. We began to eliminate these issues by extracting smaller operations that the accept method was handling into various methods and moving this code into various models such as the invitation.rb, signed_up_user.rb and team_user.rb.

==== Skinny Controller, Fat Model ====

'''Before: invitation_controller.rb - accept method''' 
The following code served the purpose of moving a user out of their current team when they accept an invite to join another team. The code actually belonged in the teams_user model because it was affecting the teams_user table in the DB. The code was extracted into the subsequent method displayed below and called from the invitation controller.
<pre>
old_entry = TeamsUser.find(:first, :conditions => ['user_id = ? and team_id = ?', student.user_id, params[:team_id]])
if old_entry != nil
old_entry.destroy
end
</pre>

'''After: invitation_controller.rb - accept method'''
<pre>
TeamsUser.remove_previous_team(student.user_id, params[:team_id])
</pre>

'''After: teams-user.rb''' 
The two methods displayed below are the sample method. The first iteration of refactoring produced the first version of the method. After reviewing method names and variable names we found that our first solution could be improved and this came up with the second and final version of the method. <ref> Coding Conventions [http://www.slideshare.net/davidpaluy/ruby-on-rails-coding-conventions-standards-and-best-practices "Ruby On Rails coding conventions, standards and best practices"] </ref>
<pre>
def self.remove_previous_team(user_id, team_id)
old_entry = TeamsUser.find(:first, :conditions => ['user_id = ? and team_id = ?', user_id, team_id])
if old_entry != nil
old_entry.destroy
end
end

def self.remove_team(user_id, team_id)
team_user = TeamsUser.find(:first, :conditions => ['user_id = ? and team_id = ?', user_id, team_id])
if team_user != nil
team_user.destroy
end
end
</pre>

'''Before: invitation_controller.rb - accept method''' 
As with the previous example we found many more examples where a few lines of code serving one purpose could be extracted into its own method. The below code serves the purpose of removing a users team from the assignment team table in the DB. This would take place if a user joins a new team and they had previously created a team and was the only member of that team.
<pre>
old_team = AssignmentTeam.find(:first, :conditions => ['id = ?', params[:team_id]])
if old_team != nil
old_team.destroy
end
</pre>

'''After: invitation_controller.rb - accept method''' 
This is the subsequent method call for the extracted code which was placed in the invitation controller accept method.
<pre>
AssignmentTeam.remove_team_by_id(params[:team_id])
</pre>

'''After: assignment_team.rb''' 
The method created in assignment_team.rb can be seen below.
<pre>
#Remove a team given the team id
def self.remove_team_by_id(id)
old_team = AssignmentTeam.find(id)
if old_team != nil
old_team.destroy
end
end
</pre>

As in the two previous examples there were many method extractions from code within the accept method.
==== Code Readability ====
'''Scopes''' 
Scopes are a useful feature of rails that for creations of reusable constraints for database interactions. Scopes help create reusable code and more readable code. Where one would typically have to write a whole query within their code a scope and be used to minimize the need to write the same query over and over again and decrease the amount of code.

Query within accept method:
<pre>other_members = TeamsUser.find(:all, :conditions => ['team_id = ?', params[:team_id]])</pre>

Query within accept method with scope:
<pre>other_members = TeamsUser.by_team_id(params[:team_id])</pre>

Scope Added in teams_user.rb:
<pre>scope :by_team_id, ->(team_id) { where("team_id = ?", team_id) }</pre>

The help promote better code readability we added a few more scopes during the course of refactoring the accept method.

Below the starting and final version of the accept method can be seen. The accept method is much smaller and more readable since our refactoring.

'''Before Refactor'''
<pre>
def accept
@inv = Invitation.find(params[:inv_id])
@inv.reply_status = 'A'
@inv.save

student = Participant.find(params[:student_id])

#if you are on a team and you accept another invitation, remove your previous entry in the teams_users table.
old_entry = TeamsUser.find(:first, :conditions => ['user_id = ? and team_id = ?', student.user_id, params[:team_id]])
if old_entry != nil
old_entry.destroy
end

#if you are on a team and you accept another invitation and if your old team does not have any members, delete the entry for the team
other_members = TeamsUser.find(:all, :conditions => ['team_id = ?', params[:team_id]])
if other_members.nil? || other_members.length == 0
old_team = AssignmentTeam.find(:first, :conditions => ['id = ?', params[:team_id]])
if old_team != nil
old_team.destroy
end

#if a signup sheet exists then release all the topics selected by this team into the pool.
old_teams_signups = SignedUpUser.find_all_by_creator_id(params[:team_id])
if !old_teams_signups.nil?
for old_teams_signup in old_teams_signups
if old_teams_signup.is_waitlisted == false # i.e., if the old team was occupying a slot, & thus is releasing a slot ...
first_waitlisted_signup = SignedUpUser.find_by_topic_id_and_is_waitlisted(old_teams_signup.topic_id, true)
if !first_waitlisted_signup.nil?
#As this user is going to be allocated a confirmed topic, all of his waitlisted topic signups should be purged
first_waitlisted_signup.is_waitlisted = false
first_waitlisted_signup.save

#Also update the participant table. But first_waitlisted_signup.creator_id is the team id
#so find one of the users on the team because the update_topic_id function in participant
#will take care of updating all the participants on the team
user_id = TeamsUser.find(:first, :conditions => {:team_id => first_waitlisted_signup.creator_id}).user_id
participant = Participant.find_by_user_id_and_parent_id(user_id,old_team.assignment.id)
participant.update_topic_id(old_teams_signup.topic_id)

SignUpTopic.cancel_all_waitlists(first_waitlisted_signup.creator_id, SignUpTopic.find(old_teams_signup.topic_id)['assignment_id'])
end # if !first_waitlisted_signup.nil
# Remove the now-empty team from the slot it is occupying.
end # if old_teams_signup.is_waitlisted == false
old_teams_signup.destroy
end
end
end
</pre>

'''After Refactor'''
<pre>
def accept
@inv = Invitation.find(params[:inv_id])
@inv.reply_status = 'A'
@inv.save

invited_user_id = Participant.find(params[:student_id]).user_id

#Remove the users previous team since they are accepting an invite for possibly a new team.
TeamsUser.remove_team(invited_user_id, params[:team_id])
#Accept the invite and return boolean on whether the add was successful
add_successful = Invitation.accept_invite(params[:team_id], @inv.from_id, @inv.to_id)
#If add wasn't successful because team was full display message
unless add_successful
flash[:error]= "The team already has the maximum number of members."
end

redirect_to :controller => 'student_team', :action => 'view', :id => Participant.find(params[:student_id]).id
end
</pre>

== Bug Fixes ==

=== Invite Requests ===
==== Problem Description ====

When a particular user responds to a advertisement sent out by another user(advertiser), a new Request invitation is created which is displayed in the advertiser's received request section of the team page as shown below: 
[[File:Receivercmh.jpg]]

When the advertiser clicks on the invite, the corresponding received request should be removed from the received requests list and the request sender should see the status as accepted when he logs in again as shown below: 
[[File:sendcmh.jpg]]

====Complete steps to reproduce the bug fix====
<pre>
1)login as admin with password"pass"
2) create new course and an assignment within the course
set all the properties appropriately-
set the assignment as a team assignment
set the deadlines properly.
3) add 2 participants(user1 and user2) to the assignment(users need to be created who act as participants)
4) create a topic within the assignment
5) login as user1 and select the topic in the signup sheet
6) create an advertisement in the your team link of the assignments
7) Now login as user2 and click on signupsheet.You should see an advertisement sent out by user1.
8) click on the advertise link and request an invitation.
9) Login as user1 again and go to the your team link.
10) user1 should see the the invitation request in the received requests with the invite and decline button next to it.
11)when user1 clicks on the invite button, the request invitation should be removed and when user2 logs in again , he should see the sent request as accepted
</pre>
====Code changes done to fix the bug====
A new method was introduced to update the "status" field of the join_table_requests
.The method is a follows: 
<pre>
def update_join_team_request
old_entry = JoinTeamRequest.first(:conditions => ['participant_id =? and team_id =?', params[:participant_id],params[:team_id]])
if old_entry
old_entry.update_attribute("status",'A')
end
end
</pre>

=== Error Messages ===
====Problem Description====
Some of the error messages which were not getting displayed are now getting displayed properly as shown below: 

[[File:messagecmh.jpg]]

====Code Changes====
1)The flash[:notice] is changes to flash[:note] in the invitation_controller.rb file 
2)The _flash_messages.html.erb file is updated to include :notice which may be used in some other parts of the application.

== Future Work ==

= References =
<references/>

CSC/ECE 517 Fall 2013/oss cmh

2013-10-29T22:08:19Z

Mrsreena: /* Code Changes */

== Introduction ==

What the invitation controller does and the process advertising, creating invites and accepting invites.

== Project Description ==
'''Classes:''' invitation_controller.rb (104 lines)
invitation.rb (5 lines)

'''What it does:''' Handles invitations to join teams.

'''What needs to be done:''' The code is deeply nested and quite confusing. There should be a single method responsible for finding whether a user is already on a team, adding someone onto a waitlist, dropping someone off of a waitlist, changing/updating the topic that the user is assigned to, etc. Some of these methods should be in model classes, such as invitation.rb and signed_up_user.rb. Break the complicated methods into shorter methods with clear names, and place these methods in the most appropriate class, moving a lot of functionality to the model classes.

Currently, after someone joins a team, pending invitations are not removed. There should be a method handling deletion of invitations (including declined invitations) to a user after that user joins a team. This should be a model method.

Though this class is not long, the code looks and reads like it is very complicated. Breaking it down into multiple methods with clear names and proper division of functionality between classes will be a challenge.

== Motivation ==

Briefly talk about why invitation controller needed refactoring.

== Design Changes ==

=== Create Method ===
'''Before Refactor'''
<pre>
def create
user = User.find_by_name(params[:user][:name].strip)
team = AssignmentTeam.find_by_id(params[:team_id])
student = AssignmentParticipant.find(params[:student_id])
return unless current_user_id?(student.user_id)

#check if the invited user is valid
if !user
flash[:notice] = "\"#{params[:user][:name].strip}\" does not exist. Please make sure the name entered is correct."
else
participant = AssignmentParticipant.find(:first, :conditions => ['user_id =? and parent_id =?', user.id, student.parent_id])
if !participant
flash[:notice] = "\"#{params[:user][:name].strip}\" is not a participant of this assignment."
else
team_member = TeamsUser.find(:all, :conditions => ['team_id =? and user_id =?', team.id, user.id])
#check if invited user is already in the team
if (team_member.size > 0)
flash[:notice] = "\"#{user.name}\" is already a member of team."
else
sent_invitation = Invitation.find(:all, :conditions => ['from_id = ? and to_id = ? and assignment_id = ? and reply_status = "W"', student.user_id, user.id, student.parent_id])
#check if the invited user is already invited (i.e. awaiting reply)
if sent_invitation.length == 0
@invitation = Invitation.new
@invitation.to_id = user.id
@invitation.from_id = student.user_id
@invitation.assignment_id = student.parent_id
@invitation.reply_status = 'W'
@invitation.save
else
flash[:notice] = "You have already sent an invitation to \"#{user.name}\"."
end
end
end
end
redirect_to :controller => 'student_team', :action => 'view', :id=> student.id
end
</pre>

'''After Refactor'''
<pre>
def create
user = User.find_by_name(params[:user][:name].strip)
team = AssignmentTeam.find_by_id(params[:team_id])
student = AssignmentParticipant.find(params[:student_id])
return unless current_user_id?(student.user_id)

#check if the invited user is valid
if !user
flash[:note] = "\"#{params[:user][:name].strip}\" does not exist. Please make sure the name entered is correct."
else
participant= AssignmentParticipant.first( :conditions => ['user_id =? and parent_id =?', user.id, student.parent_id])
#check if the user is a participant of the assignment
if !participant
flash[:note] = "\"#{params[:user][:name].strip}\" is not a participant of this assignment."
else
team_member = TeamsUser.all(:conditions => ['team_id =? and user_id =?', team.id, user.id])
#check if invited user is already in the team
if (team_member.size > 0)
flash[:note] = "\"#{user.name}\" is already a member of team."
else
#check if the invited user is already invited (i.e. awaiting reply)
if Invitation.is_invited?(student.user_id, user.id, student.parent_id)
@invitation = Invitation.new
@invitation.to_id = user.id
@invitation.from_id = student.user_id
@invitation.assignment_id = student.parent_id
@invitation.reply_status = 'W'
@invitation.save
else
flash[:note] = "You have already sent an invitation to \"#{user.name}\"."
end
end
end
end

update_join_team_request

redirect_to :controller => 'student_team', :action => 'view', :id=> student.id
end
</pre>

=== Accept Method ===

The theme that we went with for refactoring the accept method is “Skin Controller, Fat Model.” <ref> Best Practices [http://www.sitepoint.com/10-ruby-on-rails-best-practices/ "10 Ruby on Rails Best Practices"] </ref> We wanted to move much of the logistics out of the accept method letting models handle this while keeping the controller limited to being the interface between the view and model. Before accept method was refactored it was very dense and contained too much functionality. The accept method was in the invitation controller was performing much of the invitation logic that should have been handled in the invitation model and various other models throughout the application. The accept method also played many different roles in that not only was it handling items that the model was responsible for but it was performing many different operations. There are many actions that need to take place when a user accepts an invitation and the controller method was taking care of all of these things. We began to eliminate these issues by extracting smaller operations that the accept method was handling into various methods and moving this code into various models such as the invitation.rb, signed_up_user.rb and team_user.rb.

<pre>
old_entry = TeamsUser.find(:first, :conditions => ['user_id = ? and team_id = ?', student.user_id, params[:team_id]])
if old_entry != nil
old_entry.destroy
end
</pre>

<pre>
TeamsUser.remove_previous_team(student.user_id, params[:team_id])
</pre>

<pre>
'''teams_user.rb'''

def self.remove_previous_team(user_id, team_id)
old_entry = TeamsUser.find(:first, :conditions => ['user_id = ? and team_id = ?', user_id, team_id])
if old_entry != nil
old_entry.destroy
end
end
</pre>

The accept method within the controller had too much functionality. We first moved much of the functionality within the accept method to a model accept method which purpose is to make sure that all items that need to be taken care of upon a method accept are in fact handled. Just moving this code to the model did not solve the issue of complexity. We created smaller methods to handle individual changes that needed to be taken care of for example upon an accept the users topic must be updated, the topics they are waitlisted for must be dropped, amongst many other things. We took these smaller changes that needed to be made and moved them into separate methods amongst various models like signed_up_user.rb and teams_user.rb. We also noticed that some variable names did not do a good job of describing their focus so we changed these variable names to increase readability. After our refactoring the accept method is much smaller and much more readable.<ref> Coding Conventions [http://www.slideshare.net/davidpaluy/ruby-on-rails-coding-conventions-standards-and-best-practices "Ruby On Rails coding conventions, standards and best practices"] </ref>

'''Before Refactor'''
<pre>
def accept
@inv = Invitation.find(params[:inv_id])
@inv.reply_status = 'A'
@inv.save

student = Participant.find(params[:student_id])

#if you are on a team and you accept another invitation, remove your previous entry in the teams_users table.
old_entry = TeamsUser.find(:first, :conditions => ['user_id = ? and team_id = ?', student.user_id, params[:team_id]])
if old_entry != nil
old_entry.destroy
end

#if you are on a team and you accept another invitation and if your old team does not have any members, delete the entry for the team
other_members = TeamsUser.find(:all, :conditions => ['team_id = ?', params[:team_id]])
if other_members.nil? || other_members.length == 0
old_team = AssignmentTeam.find(:first, :conditions => ['id = ?', params[:team_id]])
if old_team != nil
old_team.destroy
end

#if a signup sheet exists then release all the topics selected by this team into the pool.
old_teams_signups = SignedUpUser.find_all_by_creator_id(params[:team_id])
if !old_teams_signups.nil?
for old_teams_signup in old_teams_signups
if old_teams_signup.is_waitlisted == false # i.e., if the old team was occupying a slot, & thus is releasing a slot ...
first_waitlisted_signup = SignedUpUser.find_by_topic_id_and_is_waitlisted(old_teams_signup.topic_id, true)
if !first_waitlisted_signup.nil?
#As this user is going to be allocated a confirmed topic, all of his waitlisted topic signups should be purged
first_waitlisted_signup.is_waitlisted = false
first_waitlisted_signup.save

#Also update the participant table. But first_waitlisted_signup.creator_id is the team id
#so find one of the users on the team because the update_topic_id function in participant
#will take care of updating all the participants on the team
user_id = TeamsUser.find(:first, :conditions => {:team_id => first_waitlisted_signup.creator_id}).user_id
participant = Participant.find_by_user_id_and_parent_id(user_id,old_team.assignment.id)
participant.update_topic_id(old_teams_signup.topic_id)

SignUpTopic.cancel_all_waitlists(first_waitlisted_signup.creator_id, SignUpTopic.find(old_teams_signup.topic_id)['assignment_id'])
end # if !first_waitlisted_signup.nil
# Remove the now-empty team from the slot it is occupying.
end # if old_teams_signup.is_waitlisted == false
old_teams_signup.destroy
end
end
end
</pre>

'''After Refactor'''
<pre>
def accept
@inv = Invitation.find(params[:inv_id])
@inv.reply_status = 'A'
@inv.save

invited_user_id = Participant.find(params[:student_id]).user_id

#Remove the users previous team since they are accepting an invite for possibly a new team.
TeamsUser.remove_team(invited_user_id, params[:team_id])
#Accept the invite and return boolean on whether the add was successful
add_successful = Invitation.accept_invite(params[:team_id], @inv.from_id, @inv.to_id)
#If add wasn't successful because team was full display message
unless add_successful
flash[:error]= "The team already has the maximum number of members."
end

redirect_to :controller => 'student_team', :action => 'view', :id => Participant.find(params[:student_id]).id
end
</pre>

== Bug Fixes ==

=== Invite Requests ===
==== Problem Description ====

When a particular user responds to a advertisement sent out by another user(advertiser), a new Request invitation is created which is displayed in the advertiser's received request section of the team page as shown below: 
[[File:Receivercmh.jpg]]

When the advertiser clicks on the invite, the corresponding received request should be removed from the received requests list and the request sender should see the status as accepted when he logs in again as shown below: 
[[File:sendcmh.jpg]]

====Complete steps to reproduce the bug fix====
<pre>
1)login as admin with password"pass"
2) create new course and an assignment within the course
set all the properties appropriately-
set the assignment as a team assignment
set the deadlines properly.
3) add 2 participants(user1 and user2) to the assignment(users need to be created who act as participants)
4) create a topic within the assignment
5) login as user1 and select the topic in the signup sheet
6) create an advertisement in the your team link of the assignments
7) Now login as user2 and click on signupsheet.You should see an advertisement sent out by user1.
8) click on the advertise link and request an invitation.
9) Login as user1 again and go to the your team link.
10) user1 should see the the invitation request in the received requests with the invite and decline button next to it.
11)when user1 clicks on the invite button, the request invitation should be removed and when user2 logs in again , he should see the sent request as accepted
</pre>
====Code changes done to fix the bug====
A new method was introduced to update the "status" field of the join_table_requests
.The method is a follows: 
<pre>
def update_join_team_request
old_entry = JoinTeamRequest.first(:conditions => ['participant_id =? and team_id =?', params[:participant_id],params[:team_id]])
if old_entry
old_entry.update_attribute("status",'A')
end
end
</pre>

=== Error Messages ===
====Problem Description====
Some of the error messages which were not getting displayed are now getting displayed properly as shown below: 

====Code Changes====
1)The flash[:notice] is changes to flash[:note] in the invitation_controller.rb file 
2)The _flash_messages.html.erb file is updated to include :notice which may be used in some other parts of the application.

== Future Work ==

= References =
<references/>

CSC/ECE 517 Fall 2013/oss cmh

2013-10-29T22:07:58Z

Mrsreena: /* Error Messages */

== Introduction ==

What the invitation controller does and the process advertising, creating invites and accepting invites.

== Project Description ==
'''Classes:''' invitation_controller.rb (104 lines)
invitation.rb (5 lines)

'''What it does:''' Handles invitations to join teams.

'''What needs to be done:''' The code is deeply nested and quite confusing. There should be a single method responsible for finding whether a user is already on a team, adding someone onto a waitlist, dropping someone off of a waitlist, changing/updating the topic that the user is assigned to, etc. Some of these methods should be in model classes, such as invitation.rb and signed_up_user.rb. Break the complicated methods into shorter methods with clear names, and place these methods in the most appropriate class, moving a lot of functionality to the model classes.

Currently, after someone joins a team, pending invitations are not removed. There should be a method handling deletion of invitations (including declined invitations) to a user after that user joins a team. This should be a model method.

Though this class is not long, the code looks and reads like it is very complicated. Breaking it down into multiple methods with clear names and proper division of functionality between classes will be a challenge.

== Motivation ==

Briefly talk about why invitation controller needed refactoring.

== Design Changes ==

=== Create Method ===
'''Before Refactor'''
<pre>
def create
user = User.find_by_name(params[:user][:name].strip)
team = AssignmentTeam.find_by_id(params[:team_id])
student = AssignmentParticipant.find(params[:student_id])
return unless current_user_id?(student.user_id)

#check if the invited user is valid
if !user
flash[:notice] = "\"#{params[:user][:name].strip}\" does not exist. Please make sure the name entered is correct."
else
participant = AssignmentParticipant.find(:first, :conditions => ['user_id =? and parent_id =?', user.id, student.parent_id])
if !participant
flash[:notice] = "\"#{params[:user][:name].strip}\" is not a participant of this assignment."
else
team_member = TeamsUser.find(:all, :conditions => ['team_id =? and user_id =?', team.id, user.id])
#check if invited user is already in the team
if (team_member.size > 0)
flash[:notice] = "\"#{user.name}\" is already a member of team."
else
sent_invitation = Invitation.find(:all, :conditions => ['from_id = ? and to_id = ? and assignment_id = ? and reply_status = "W"', student.user_id, user.id, student.parent_id])
#check if the invited user is already invited (i.e. awaiting reply)
if sent_invitation.length == 0
@invitation = Invitation.new
@invitation.to_id = user.id
@invitation.from_id = student.user_id
@invitation.assignment_id = student.parent_id
@invitation.reply_status = 'W'
@invitation.save
else
flash[:notice] = "You have already sent an invitation to \"#{user.name}\"."
end
end
end
end
redirect_to :controller => 'student_team', :action => 'view', :id=> student.id
end
</pre>

'''After Refactor'''
<pre>
def create
user = User.find_by_name(params[:user][:name].strip)
team = AssignmentTeam.find_by_id(params[:team_id])
student = AssignmentParticipant.find(params[:student_id])
return unless current_user_id?(student.user_id)

#check if the invited user is valid
if !user
flash[:note] = "\"#{params[:user][:name].strip}\" does not exist. Please make sure the name entered is correct."
else
participant= AssignmentParticipant.first( :conditions => ['user_id =? and parent_id =?', user.id, student.parent_id])
#check if the user is a participant of the assignment
if !participant
flash[:note] = "\"#{params[:user][:name].strip}\" is not a participant of this assignment."
else
team_member = TeamsUser.all(:conditions => ['team_id =? and user_id =?', team.id, user.id])
#check if invited user is already in the team
if (team_member.size > 0)
flash[:note] = "\"#{user.name}\" is already a member of team."
else
#check if the invited user is already invited (i.e. awaiting reply)
if Invitation.is_invited?(student.user_id, user.id, student.parent_id)
@invitation = Invitation.new
@invitation.to_id = user.id
@invitation.from_id = student.user_id
@invitation.assignment_id = student.parent_id
@invitation.reply_status = 'W'
@invitation.save
else
flash[:note] = "You have already sent an invitation to \"#{user.name}\"."
end
end
end
end

update_join_team_request

redirect_to :controller => 'student_team', :action => 'view', :id=> student.id
end
</pre>

=== Accept Method ===

The theme that we went with for refactoring the accept method is “Skin Controller, Fat Model.” <ref> Best Practices [http://www.sitepoint.com/10-ruby-on-rails-best-practices/ "10 Ruby on Rails Best Practices"] </ref> We wanted to move much of the logistics out of the accept method letting models handle this while keeping the controller limited to being the interface between the view and model. Before accept method was refactored it was very dense and contained too much functionality. The accept method was in the invitation controller was performing much of the invitation logic that should have been handled in the invitation model and various other models throughout the application. The accept method also played many different roles in that not only was it handling items that the model was responsible for but it was performing many different operations. There are many actions that need to take place when a user accepts an invitation and the controller method was taking care of all of these things. We began to eliminate these issues by extracting smaller operations that the accept method was handling into various methods and moving this code into various models such as the invitation.rb, signed_up_user.rb and team_user.rb.

<pre>
old_entry = TeamsUser.find(:first, :conditions => ['user_id = ? and team_id = ?', student.user_id, params[:team_id]])
if old_entry != nil
old_entry.destroy
end
</pre>

<pre>
TeamsUser.remove_previous_team(student.user_id, params[:team_id])
</pre>

<pre>
'''teams_user.rb'''

def self.remove_previous_team(user_id, team_id)
old_entry = TeamsUser.find(:first, :conditions => ['user_id = ? and team_id = ?', user_id, team_id])
if old_entry != nil
old_entry.destroy
end
end
</pre>

The accept method within the controller had too much functionality. We first moved much of the functionality within the accept method to a model accept method which purpose is to make sure that all items that need to be taken care of upon a method accept are in fact handled. Just moving this code to the model did not solve the issue of complexity. We created smaller methods to handle individual changes that needed to be taken care of for example upon an accept the users topic must be updated, the topics they are waitlisted for must be dropped, amongst many other things. We took these smaller changes that needed to be made and moved them into separate methods amongst various models like signed_up_user.rb and teams_user.rb. We also noticed that some variable names did not do a good job of describing their focus so we changed these variable names to increase readability. After our refactoring the accept method is much smaller and much more readable.<ref> Coding Conventions [http://www.slideshare.net/davidpaluy/ruby-on-rails-coding-conventions-standards-and-best-practices "Ruby On Rails coding conventions, standards and best practices"] </ref>

'''Before Refactor'''
<pre>
def accept
@inv = Invitation.find(params[:inv_id])
@inv.reply_status = 'A'
@inv.save

student = Participant.find(params[:student_id])

#if you are on a team and you accept another invitation, remove your previous entry in the teams_users table.
old_entry = TeamsUser.find(:first, :conditions => ['user_id = ? and team_id = ?', student.user_id, params[:team_id]])
if old_entry != nil
old_entry.destroy
end

#if you are on a team and you accept another invitation and if your old team does not have any members, delete the entry for the team
other_members = TeamsUser.find(:all, :conditions => ['team_id = ?', params[:team_id]])
if other_members.nil? || other_members.length == 0
old_team = AssignmentTeam.find(:first, :conditions => ['id = ?', params[:team_id]])
if old_team != nil
old_team.destroy
end

#if a signup sheet exists then release all the topics selected by this team into the pool.
old_teams_signups = SignedUpUser.find_all_by_creator_id(params[:team_id])
if !old_teams_signups.nil?
for old_teams_signup in old_teams_signups
if old_teams_signup.is_waitlisted == false # i.e., if the old team was occupying a slot, & thus is releasing a slot ...
first_waitlisted_signup = SignedUpUser.find_by_topic_id_and_is_waitlisted(old_teams_signup.topic_id, true)
if !first_waitlisted_signup.nil?
#As this user is going to be allocated a confirmed topic, all of his waitlisted topic signups should be purged
first_waitlisted_signup.is_waitlisted = false
first_waitlisted_signup.save

#Also update the participant table. But first_waitlisted_signup.creator_id is the team id
#so find one of the users on the team because the update_topic_id function in participant
#will take care of updating all the participants on the team
user_id = TeamsUser.find(:first, :conditions => {:team_id => first_waitlisted_signup.creator_id}).user_id
participant = Participant.find_by_user_id_and_parent_id(user_id,old_team.assignment.id)
participant.update_topic_id(old_teams_signup.topic_id)

SignUpTopic.cancel_all_waitlists(first_waitlisted_signup.creator_id, SignUpTopic.find(old_teams_signup.topic_id)['assignment_id'])
end # if !first_waitlisted_signup.nil
# Remove the now-empty team from the slot it is occupying.
end # if old_teams_signup.is_waitlisted == false
old_teams_signup.destroy
end
end
end
</pre>

'''After Refactor'''
<pre>
def accept
@inv = Invitation.find(params[:inv_id])
@inv.reply_status = 'A'
@inv.save

invited_user_id = Participant.find(params[:student_id]).user_id

#Remove the users previous team since they are accepting an invite for possibly a new team.
TeamsUser.remove_team(invited_user_id, params[:team_id])
#Accept the invite and return boolean on whether the add was successful
add_successful = Invitation.accept_invite(params[:team_id], @inv.from_id, @inv.to_id)
#If add wasn't successful because team was full display message
unless add_successful
flash[:error]= "The team already has the maximum number of members."
end

redirect_to :controller => 'student_team', :action => 'view', :id => Participant.find(params[:student_id]).id
end
</pre>

== Bug Fixes ==

=== Invite Requests ===
==== Problem Description ====

When a particular user responds to a advertisement sent out by another user(advertiser), a new Request invitation is created which is displayed in the advertiser's received request section of the team page as shown below: 
[[File:Receivercmh.jpg]]

When the advertiser clicks on the invite, the corresponding received request should be removed from the received requests list and the request sender should see the status as accepted when he logs in again as shown below: 
[[File:sendcmh.jpg]]

====Complete steps to reproduce the bug fix====
<pre>
1)login as admin with password"pass"
2) create new course and an assignment within the course
set all the properties appropriately-
set the assignment as a team assignment
set the deadlines properly.
3) add 2 participants(user1 and user2) to the assignment(users need to be created who act as participants)
4) create a topic within the assignment
5) login as user1 and select the topic in the signup sheet
6) create an advertisement in the your team link of the assignments
7) Now login as user2 and click on signupsheet.You should see an advertisement sent out by user1.
8) click on the advertise link and request an invitation.
9) Login as user1 again and go to the your team link.
10) user1 should see the the invitation request in the received requests with the invite and decline button next to it.
11)when user1 clicks on the invite button, the request invitation should be removed and when user2 logs in again , he should see the sent request as accepted
</pre>
====Code changes done to fix the bug====
A new method was introduced to update the "status" field of the join_table_requests
.The method is a follows: 
<pre>
def update_join_team_request
old_entry = JoinTeamRequest.first(:conditions => ['participant_id =? and team_id =?', params[:participant_id],params[:team_id]])
if old_entry
old_entry.update_attribute("status",'A')
end
end
</pre>

=== Error Messages ===
====Problem Description====
Some of the error messages which were not getting displayed are now getting displayed properly as shown below: 

====Code Changes====
1)The flash[:notice] is changes to flash[:note] in the invitation_controller.rb file
2)The _flash_messages.html.erb file is updated to include :notice which may be used in some other parts of the application.

== Future Work ==

= References =
<references/>

CSC/ECE 517 Fall 2013/oss cmh

2013-10-29T21:59:13Z

Mrsreena: /* Code changes done to fix the bug */

== Introduction ==

What the invitation controller does and the process advertising, creating invites and accepting invites.

== Project Description ==
'''Classes:''' invitation_controller.rb (104 lines)
invitation.rb (5 lines)

'''What it does:''' Handles invitations to join teams.

'''What needs to be done:''' The code is deeply nested and quite confusing. There should be a single method responsible for finding whether a user is already on a team, adding someone onto a waitlist, dropping someone off of a waitlist, changing/updating the topic that the user is assigned to, etc. Some of these methods should be in model classes, such as invitation.rb and signed_up_user.rb. Break the complicated methods into shorter methods with clear names, and place these methods in the most appropriate class, moving a lot of functionality to the model classes.

Currently, after someone joins a team, pending invitations are not removed. There should be a method handling deletion of invitations (including declined invitations) to a user after that user joins a team. This should be a model method.

Though this class is not long, the code looks and reads like it is very complicated. Breaking it down into multiple methods with clear names and proper division of functionality between classes will be a challenge.

== Motivation ==

Briefly talk about why invitation controller needed refactoring.

== Design Changes ==

=== Create Method ===
'''Before Refactor'''
<pre>
def create
user = User.find_by_name(params[:user][:name].strip)
team = AssignmentTeam.find_by_id(params[:team_id])
student = AssignmentParticipant.find(params[:student_id])
return unless current_user_id?(student.user_id)

#check if the invited user is valid
if !user
flash[:notice] = "\"#{params[:user][:name].strip}\" does not exist. Please make sure the name entered is correct."
else
participant = AssignmentParticipant.find(:first, :conditions => ['user_id =? and parent_id =?', user.id, student.parent_id])
if !participant
flash[:notice] = "\"#{params[:user][:name].strip}\" is not a participant of this assignment."
else
team_member = TeamsUser.find(:all, :conditions => ['team_id =? and user_id =?', team.id, user.id])
#check if invited user is already in the team
if (team_member.size > 0)
flash[:notice] = "\"#{user.name}\" is already a member of team."
else
sent_invitation = Invitation.find(:all, :conditions => ['from_id = ? and to_id = ? and assignment_id = ? and reply_status = "W"', student.user_id, user.id, student.parent_id])
#check if the invited user is already invited (i.e. awaiting reply)
if sent_invitation.length == 0
@invitation = Invitation.new
@invitation.to_id = user.id
@invitation.from_id = student.user_id
@invitation.assignment_id = student.parent_id
@invitation.reply_status = 'W'
@invitation.save
else
flash[:notice] = "You have already sent an invitation to \"#{user.name}\"."
end
end
end
end
redirect_to :controller => 'student_team', :action => 'view', :id=> student.id
end
</pre>

'''After Refactor'''
<pre>
def create
user = User.find_by_name(params[:user][:name].strip)
team = AssignmentTeam.find_by_id(params[:team_id])
student = AssignmentParticipant.find(params[:student_id])
return unless current_user_id?(student.user_id)

#check if the invited user is valid
if !user
flash[:note] = "\"#{params[:user][:name].strip}\" does not exist. Please make sure the name entered is correct."
else
participant= AssignmentParticipant.first( :conditions => ['user_id =? and parent_id =?', user.id, student.parent_id])
#check if the user is a participant of the assignment
if !participant
flash[:note] = "\"#{params[:user][:name].strip}\" is not a participant of this assignment."
else
team_member = TeamsUser.all(:conditions => ['team_id =? and user_id =?', team.id, user.id])
#check if invited user is already in the team
if (team_member.size > 0)
flash[:note] = "\"#{user.name}\" is already a member of team."
else
#check if the invited user is already invited (i.e. awaiting reply)
if Invitation.is_invited?(student.user_id, user.id, student.parent_id)
@invitation = Invitation.new
@invitation.to_id = user.id
@invitation.from_id = student.user_id
@invitation.assignment_id = student.parent_id
@invitation.reply_status = 'W'
@invitation.save
else
flash[:note] = "You have already sent an invitation to \"#{user.name}\"."
end
end
end
end

update_join_team_request

redirect_to :controller => 'student_team', :action => 'view', :id=> student.id
end
</pre>

=== Accept Method ===

The theme that we went with for refactoring the accept method is “Skin Controller, Fat Model.” <ref> Best Practices [http://www.sitepoint.com/10-ruby-on-rails-best-practices/ "10 Ruby on Rails Best Practices"] </ref> We wanted to move much of the logistics out of the accept method letting models handle this while keeping the controller limited to being the interface between the view and model. Before accept method was refactored it was very dense and contained too much functionality. The accept method was in the invitation controller was performing much of the invitation logic that should have been handled in the invitation model and various other models throughout the application. The accept method also played many different roles in that not only was it handling items that the model was responsible for but it was performing many different operations. There are many actions that need to take place when a user accepts an invitation and the controller method was taking care of all of these things. We began to eliminate these issues by extracting smaller operations that the accept method was handling into various methods and moving this code into various models such as the invitation.rb, signed_up_user.rb and team_user.rb.

<pre>
old_entry = TeamsUser.find(:first, :conditions => ['user_id = ? and team_id = ?', student.user_id, params[:team_id]])
if old_entry != nil
old_entry.destroy
end
</pre>

<pre>
TeamsUser.remove_previous_team(student.user_id, params[:team_id])
</pre>

<pre>
'''teams_user.rb'''

def self.remove_previous_team(user_id, team_id)
old_entry = TeamsUser.find(:first, :conditions => ['user_id = ? and team_id = ?', user_id, team_id])
if old_entry != nil
old_entry.destroy
end
end
</pre>

The accept method within the controller had too much functionality. We first moved much of the functionality within the accept method to a model accept method which purpose is to make sure that all items that need to be taken care of upon a method accept are in fact handled. Just moving this code to the model did not solve the issue of complexity. We created smaller methods to handle individual changes that needed to be taken care of for example upon an accept the users topic must be updated, the topics they are waitlisted for must be dropped, amongst many other things. We took these smaller changes that needed to be made and moved them into separate methods amongst various models like signed_up_user.rb and teams_user.rb. We also noticed that some variable names did not do a good job of describing their focus so we changed these variable names to increase readability. After our refactoring the accept method is much smaller and much more readable.<ref> Coding Conventions [http://www.slideshare.net/davidpaluy/ruby-on-rails-coding-conventions-standards-and-best-practices "Ruby On Rails coding conventions, standards and best practices"] </ref>

'''Before Refactor'''
<pre>
def accept
@inv = Invitation.find(params[:inv_id])
@inv.reply_status = 'A'
@inv.save

student = Participant.find(params[:student_id])

#if you are on a team and you accept another invitation, remove your previous entry in the teams_users table.
old_entry = TeamsUser.find(:first, :conditions => ['user_id = ? and team_id = ?', student.user_id, params[:team_id]])
if old_entry != nil
old_entry.destroy
end

#if you are on a team and you accept another invitation and if your old team does not have any members, delete the entry for the team
other_members = TeamsUser.find(:all, :conditions => ['team_id = ?', params[:team_id]])
if other_members.nil? || other_members.length == 0
old_team = AssignmentTeam.find(:first, :conditions => ['id = ?', params[:team_id]])
if old_team != nil
old_team.destroy
end

#if a signup sheet exists then release all the topics selected by this team into the pool.
old_teams_signups = SignedUpUser.find_all_by_creator_id(params[:team_id])
if !old_teams_signups.nil?
for old_teams_signup in old_teams_signups
if old_teams_signup.is_waitlisted == false # i.e., if the old team was occupying a slot, & thus is releasing a slot ...
first_waitlisted_signup = SignedUpUser.find_by_topic_id_and_is_waitlisted(old_teams_signup.topic_id, true)
if !first_waitlisted_signup.nil?
#As this user is going to be allocated a confirmed topic, all of his waitlisted topic signups should be purged
first_waitlisted_signup.is_waitlisted = false
first_waitlisted_signup.save

#Also update the participant table. But first_waitlisted_signup.creator_id is the team id
#so find one of the users on the team because the update_topic_id function in participant
#will take care of updating all the participants on the team
user_id = TeamsUser.find(:first, :conditions => {:team_id => first_waitlisted_signup.creator_id}).user_id
participant = Participant.find_by_user_id_and_parent_id(user_id,old_team.assignment.id)
participant.update_topic_id(old_teams_signup.topic_id)

SignUpTopic.cancel_all_waitlists(first_waitlisted_signup.creator_id, SignUpTopic.find(old_teams_signup.topic_id)['assignment_id'])
end # if !first_waitlisted_signup.nil
# Remove the now-empty team from the slot it is occupying.
end # if old_teams_signup.is_waitlisted == false
old_teams_signup.destroy
end
end
end
</pre>

'''After Refactor'''
<pre>
def accept
@inv = Invitation.find(params[:inv_id])
@inv.reply_status = 'A'
@inv.save

invited_user_id = Participant.find(params[:student_id]).user_id

#Remove the users previous team since they are accepting an invite for possibly a new team.
TeamsUser.remove_team(invited_user_id, params[:team_id])
#Accept the invite and return boolean on whether the add was successful
add_successful = Invitation.accept_invite(params[:team_id], @inv.from_id, @inv.to_id)
#If add wasn't successful because team was full display message
unless add_successful
flash[:error]= "The team already has the maximum number of members."
end

redirect_to :controller => 'student_team', :action => 'view', :id => Participant.find(params[:student_id]).id
end
</pre>

== Bug Fixes ==

=== Invite Requests ===
==== Problem Description ====

When a particular user responds to a advertisement sent out by another user(advertiser), a new Request invitation is created which is displayed in the advertiser's received request section of the team page as shown below: 
[[File:Receivercmh.jpg]]

When the advertiser clicks on the invite, the corresponding received request should be removed from the received requests list and the request sender should see the status as accepted when he logs in again as shown below: 
[[File:sendcmh.jpg]]

====Complete steps to reproduce the bug fix====
<pre>
1)login as admin with password"pass"
2) create new course and an assignment within the course
set all the properties appropriately-
set the assignment as a team assignment
set the deadlines properly.
3) add 2 participants(user1 and user2) to the assignment(users need to be created who act as participants)
4) create a topic within the assignment
5) login as user1 and select the topic in the signup sheet
6) create an advertisement in the your team link of the assignments
7) Now login as user2 and click on signupsheet.You should see an advertisement sent out by user1.
8) click on the advertise link and request an invitation.
9) Login as user1 again and go to the your team link.
10) user1 should see the the invitation request in the received requests with the invite and decline button next to it.
11)when user1 clicks on the invite button, the request invitation should be removed and when user2 logs in again , he should see the sent request as accepted
</pre>
====Code changes done to fix the bug====
A new method was introduced to update the "status" field of the join_table_requests
.The method is a follows: 
<pre>
def update_join_team_request
old_entry = JoinTeamRequest.first(:conditions => ['participant_id =? and team_id =?', params[:participant_id],params[:team_id]])
if old_entry
old_entry.update_attribute("status",'A')
end
end
</pre>

=== Error Messages ===

== Future Work ==

= References =
<references/>

CSC/ECE 517 Fall 2013/oss cmh

2013-10-29T21:58:49Z

Mrsreena: /* Bug Fixes */

== Introduction ==

What the invitation controller does and the process advertising, creating invites and accepting invites.

== Project Description ==
'''Classes:''' invitation_controller.rb (104 lines)
invitation.rb (5 lines)

'''What it does:''' Handles invitations to join teams.

'''What needs to be done:''' The code is deeply nested and quite confusing. There should be a single method responsible for finding whether a user is already on a team, adding someone onto a waitlist, dropping someone off of a waitlist, changing/updating the topic that the user is assigned to, etc. Some of these methods should be in model classes, such as invitation.rb and signed_up_user.rb. Break the complicated methods into shorter methods with clear names, and place these methods in the most appropriate class, moving a lot of functionality to the model classes.

Currently, after someone joins a team, pending invitations are not removed. There should be a method handling deletion of invitations (including declined invitations) to a user after that user joins a team. This should be a model method.

Though this class is not long, the code looks and reads like it is very complicated. Breaking it down into multiple methods with clear names and proper division of functionality between classes will be a challenge.

== Motivation ==

Briefly talk about why invitation controller needed refactoring.

== Design Changes ==

=== Create Method ===
'''Before Refactor'''
<pre>
def create
user = User.find_by_name(params[:user][:name].strip)
team = AssignmentTeam.find_by_id(params[:team_id])
student = AssignmentParticipant.find(params[:student_id])
return unless current_user_id?(student.user_id)

#check if the invited user is valid
if !user
flash[:notice] = "\"#{params[:user][:name].strip}\" does not exist. Please make sure the name entered is correct."
else
participant = AssignmentParticipant.find(:first, :conditions => ['user_id =? and parent_id =?', user.id, student.parent_id])
if !participant
flash[:notice] = "\"#{params[:user][:name].strip}\" is not a participant of this assignment."
else
team_member = TeamsUser.find(:all, :conditions => ['team_id =? and user_id =?', team.id, user.id])
#check if invited user is already in the team
if (team_member.size > 0)
flash[:notice] = "\"#{user.name}\" is already a member of team."
else
sent_invitation = Invitation.find(:all, :conditions => ['from_id = ? and to_id = ? and assignment_id = ? and reply_status = "W"', student.user_id, user.id, student.parent_id])
#check if the invited user is already invited (i.e. awaiting reply)
if sent_invitation.length == 0
@invitation = Invitation.new
@invitation.to_id = user.id
@invitation.from_id = student.user_id
@invitation.assignment_id = student.parent_id
@invitation.reply_status = 'W'
@invitation.save
else
flash[:notice] = "You have already sent an invitation to \"#{user.name}\"."
end
end
end
end
redirect_to :controller => 'student_team', :action => 'view', :id=> student.id
end
</pre>

'''After Refactor'''
<pre>
def create
user = User.find_by_name(params[:user][:name].strip)
team = AssignmentTeam.find_by_id(params[:team_id])
student = AssignmentParticipant.find(params[:student_id])
return unless current_user_id?(student.user_id)

#check if the invited user is valid
if !user
flash[:note] = "\"#{params[:user][:name].strip}\" does not exist. Please make sure the name entered is correct."
else
participant= AssignmentParticipant.first( :conditions => ['user_id =? and parent_id =?', user.id, student.parent_id])
#check if the user is a participant of the assignment
if !participant
flash[:note] = "\"#{params[:user][:name].strip}\" is not a participant of this assignment."
else
team_member = TeamsUser.all(:conditions => ['team_id =? and user_id =?', team.id, user.id])
#check if invited user is already in the team
if (team_member.size > 0)
flash[:note] = "\"#{user.name}\" is already a member of team."
else
#check if the invited user is already invited (i.e. awaiting reply)
if Invitation.is_invited?(student.user_id, user.id, student.parent_id)
@invitation = Invitation.new
@invitation.to_id = user.id
@invitation.from_id = student.user_id
@invitation.assignment_id = student.parent_id
@invitation.reply_status = 'W'
@invitation.save
else
flash[:note] = "You have already sent an invitation to \"#{user.name}\"."
end
end
end
end

update_join_team_request

redirect_to :controller => 'student_team', :action => 'view', :id=> student.id
end
</pre>

=== Accept Method ===

The theme that we went with for refactoring the accept method is “Skin Controller, Fat Model.” <ref> Best Practices [http://www.sitepoint.com/10-ruby-on-rails-best-practices/ "10 Ruby on Rails Best Practices"] </ref> We wanted to move much of the logistics out of the accept method letting models handle this while keeping the controller limited to being the interface between the view and model. Before accept method was refactored it was very dense and contained too much functionality. The accept method was in the invitation controller was performing much of the invitation logic that should have been handled in the invitation model and various other models throughout the application. The accept method also played many different roles in that not only was it handling items that the model was responsible for but it was performing many different operations. There are many actions that need to take place when a user accepts an invitation and the controller method was taking care of all of these things. We began to eliminate these issues by extracting smaller operations that the accept method was handling into various methods and moving this code into various models such as the invitation.rb, signed_up_user.rb and team_user.rb.

<pre>
old_entry = TeamsUser.find(:first, :conditions => ['user_id = ? and team_id = ?', student.user_id, params[:team_id]])
if old_entry != nil
old_entry.destroy
end
</pre>

<pre>
TeamsUser.remove_previous_team(student.user_id, params[:team_id])
</pre>

<pre>
'''teams_user.rb'''

def self.remove_previous_team(user_id, team_id)
old_entry = TeamsUser.find(:first, :conditions => ['user_id = ? and team_id = ?', user_id, team_id])
if old_entry != nil
old_entry.destroy
end
end
</pre>

The accept method within the controller had too much functionality. We first moved much of the functionality within the accept method to a model accept method which purpose is to make sure that all items that need to be taken care of upon a method accept are in fact handled. Just moving this code to the model did not solve the issue of complexity. We created smaller methods to handle individual changes that needed to be taken care of for example upon an accept the users topic must be updated, the topics they are waitlisted for must be dropped, amongst many other things. We took these smaller changes that needed to be made and moved them into separate methods amongst various models like signed_up_user.rb and teams_user.rb. We also noticed that some variable names did not do a good job of describing their focus so we changed these variable names to increase readability. After our refactoring the accept method is much smaller and much more readable.<ref> Coding Conventions [http://www.slideshare.net/davidpaluy/ruby-on-rails-coding-conventions-standards-and-best-practices "Ruby On Rails coding conventions, standards and best practices"] </ref>

'''Before Refactor'''
<pre>
def accept
@inv = Invitation.find(params[:inv_id])
@inv.reply_status = 'A'
@inv.save

student = Participant.find(params[:student_id])

#if you are on a team and you accept another invitation, remove your previous entry in the teams_users table.
old_entry = TeamsUser.find(:first, :conditions => ['user_id = ? and team_id = ?', student.user_id, params[:team_id]])
if old_entry != nil
old_entry.destroy
end

#if you are on a team and you accept another invitation and if your old team does not have any members, delete the entry for the team
other_members = TeamsUser.find(:all, :conditions => ['team_id = ?', params[:team_id]])
if other_members.nil? || other_members.length == 0
old_team = AssignmentTeam.find(:first, :conditions => ['id = ?', params[:team_id]])
if old_team != nil
old_team.destroy
end

#if a signup sheet exists then release all the topics selected by this team into the pool.
old_teams_signups = SignedUpUser.find_all_by_creator_id(params[:team_id])
if !old_teams_signups.nil?
for old_teams_signup in old_teams_signups
if old_teams_signup.is_waitlisted == false # i.e., if the old team was occupying a slot, & thus is releasing a slot ...
first_waitlisted_signup = SignedUpUser.find_by_topic_id_and_is_waitlisted(old_teams_signup.topic_id, true)
if !first_waitlisted_signup.nil?
#As this user is going to be allocated a confirmed topic, all of his waitlisted topic signups should be purged
first_waitlisted_signup.is_waitlisted = false
first_waitlisted_signup.save

#Also update the participant table. But first_waitlisted_signup.creator_id is the team id
#so find one of the users on the team because the update_topic_id function in participant
#will take care of updating all the participants on the team
user_id = TeamsUser.find(:first, :conditions => {:team_id => first_waitlisted_signup.creator_id}).user_id
participant = Participant.find_by_user_id_and_parent_id(user_id,old_team.assignment.id)
participant.update_topic_id(old_teams_signup.topic_id)

SignUpTopic.cancel_all_waitlists(first_waitlisted_signup.creator_id, SignUpTopic.find(old_teams_signup.topic_id)['assignment_id'])
end # if !first_waitlisted_signup.nil
# Remove the now-empty team from the slot it is occupying.
end # if old_teams_signup.is_waitlisted == false
old_teams_signup.destroy
end
end
end
</pre>

'''After Refactor'''
<pre>
def accept
@inv = Invitation.find(params[:inv_id])
@inv.reply_status = 'A'
@inv.save

invited_user_id = Participant.find(params[:student_id]).user_id

#Remove the users previous team since they are accepting an invite for possibly a new team.
TeamsUser.remove_team(invited_user_id, params[:team_id])
#Accept the invite and return boolean on whether the add was successful
add_successful = Invitation.accept_invite(params[:team_id], @inv.from_id, @inv.to_id)
#If add wasn't successful because team was full display message
unless add_successful
flash[:error]= "The team already has the maximum number of members."
end

redirect_to :controller => 'student_team', :action => 'view', :id => Participant.find(params[:student_id]).id
end
</pre>

== Bug Fixes ==

=== Invite Requests ===
==== Problem Description ====

When a particular user responds to a advertisement sent out by another user(advertiser), a new Request invitation is created which is displayed in the advertiser's received request section of the team page as shown below: 
[[File:Receivercmh.jpg]]

When the advertiser clicks on the invite, the corresponding received request should be removed from the received requests list and the request sender should see the status as accepted when he logs in again as shown below: 
[[File:sendcmh.jpg]]

====Complete steps to reproduce the bug fix====
<pre>
1)login as admin with password"pass"
2) create new course and an assignment within the course
set all the properties appropriately-
set the assignment as a team assignment
set the deadlines properly.
3) add 2 participants(user1 and user2) to the assignment(users need to be created who act as participants)
4) create a topic within the assignment
5) login as user1 and select the topic in the signup sheet
6) create an advertisement in the your team link of the assignments
7) Now login as user2 and click on signupsheet.You should see an advertisement sent out by user1.
8) click on the advertise link and request an invitation.
9) Login as user1 again and go to the your team link.
10) user1 should see the the invitation request in the received requests with the invite and decline button next to it.
11)when user1 clicks on the invite button, the request invitation should be removed and when user2 logs in again , he should see the sent request as accepted
</pre>
====Code changes done to fix the bug====
A new method was introduced to update the "status" field of the join_table_requests
The method is a follows: 
<pre>
def update_join_team_request
old_entry = JoinTeamRequest.first(:conditions => ['participant_id =? and team_id =?', params[:participant_id],params[:team_id]])
if old_entry
old_entry.update_attribute("status",'A')
end
end
</pre>
=== Error Messages ===

== Future Work ==

= References =
<references/>

CSC/ECE 517 Fall 2013/oss cmh

2013-10-29T21:54:58Z

Mrsreena: /* Problem Description */

== Introduction ==

What the invitation controller does and the process advertising, creating invites and accepting invites.

== Project Description ==
'''Classes:''' invitation_controller.rb (104 lines)
invitation.rb (5 lines)

'''What it does:''' Handles invitations to join teams.

'''What needs to be done:''' The code is deeply nested and quite confusing. There should be a single method responsible for finding whether a user is already on a team, adding someone onto a waitlist, dropping someone off of a waitlist, changing/updating the topic that the user is assigned to, etc. Some of these methods should be in model classes, such as invitation.rb and signed_up_user.rb. Break the complicated methods into shorter methods with clear names, and place these methods in the most appropriate class, moving a lot of functionality to the model classes.

Currently, after someone joins a team, pending invitations are not removed. There should be a method handling deletion of invitations (including declined invitations) to a user after that user joins a team. This should be a model method.

Though this class is not long, the code looks and reads like it is very complicated. Breaking it down into multiple methods with clear names and proper division of functionality between classes will be a challenge.

== Motivation ==

Briefly talk about why invitation controller needed refactoring.

== Design Changes ==

=== Create Method ===
'''Before Refactor'''
<pre>
def create
user = User.find_by_name(params[:user][:name].strip)
team = AssignmentTeam.find_by_id(params[:team_id])
student = AssignmentParticipant.find(params[:student_id])
return unless current_user_id?(student.user_id)

#check if the invited user is valid
if !user
flash[:notice] = "\"#{params[:user][:name].strip}\" does not exist. Please make sure the name entered is correct."
else
participant = AssignmentParticipant.find(:first, :conditions => ['user_id =? and parent_id =?', user.id, student.parent_id])
if !participant
flash[:notice] = "\"#{params[:user][:name].strip}\" is not a participant of this assignment."
else
team_member = TeamsUser.find(:all, :conditions => ['team_id =? and user_id =?', team.id, user.id])
#check if invited user is already in the team
if (team_member.size > 0)
flash[:notice] = "\"#{user.name}\" is already a member of team."
else
sent_invitation = Invitation.find(:all, :conditions => ['from_id = ? and to_id = ? and assignment_id = ? and reply_status = "W"', student.user_id, user.id, student.parent_id])
#check if the invited user is already invited (i.e. awaiting reply)
if sent_invitation.length == 0
@invitation = Invitation.new
@invitation.to_id = user.id
@invitation.from_id = student.user_id
@invitation.assignment_id = student.parent_id
@invitation.reply_status = 'W'
@invitation.save
else
flash[:notice] = "You have already sent an invitation to \"#{user.name}\"."
end
end
end
end
redirect_to :controller => 'student_team', :action => 'view', :id=> student.id
end
</pre>

'''After Refactor'''
<pre>
def create
user = User.find_by_name(params[:user][:name].strip)
team = AssignmentTeam.find_by_id(params[:team_id])
student = AssignmentParticipant.find(params[:student_id])
return unless current_user_id?(student.user_id)

#check if the invited user is valid
if !user
flash[:note] = "\"#{params[:user][:name].strip}\" does not exist. Please make sure the name entered is correct."
else
participant= AssignmentParticipant.first( :conditions => ['user_id =? and parent_id =?', user.id, student.parent_id])
#check if the user is a participant of the assignment
if !participant
flash[:note] = "\"#{params[:user][:name].strip}\" is not a participant of this assignment."
else
team_member = TeamsUser.all(:conditions => ['team_id =? and user_id =?', team.id, user.id])
#check if invited user is already in the team
if (team_member.size > 0)
flash[:note] = "\"#{user.name}\" is already a member of team."
else
#check if the invited user is already invited (i.e. awaiting reply)
if Invitation.is_invited?(student.user_id, user.id, student.parent_id)
@invitation = Invitation.new
@invitation.to_id = user.id
@invitation.from_id = student.user_id
@invitation.assignment_id = student.parent_id
@invitation.reply_status = 'W'
@invitation.save
else
flash[:note] = "You have already sent an invitation to \"#{user.name}\"."
end
end
end
end

update_join_team_request

redirect_to :controller => 'student_team', :action => 'view', :id=> student.id
end
</pre>

=== Accept Method ===

The theme that we went with for refactoring the accept method is “Skin Controller, Fat Model.” <ref> Best Practices [http://www.sitepoint.com/10-ruby-on-rails-best-practices/ "10 Ruby on Rails Best Practices"] </ref> We wanted to move much of the logistics out of the accept method letting models handle this while keeping the controller limited to being the interface between the view and model. Before accept method was refactored it was very dense and contained too much functionality. The accept method was in the invitation controller was performing much of the invitation logic that should have been handled in the invitation model and various other models throughout the application. The accept method also played many different roles in that not only was it handling items that the model was responsible for but it was performing many different operations. There are many actions that need to take place when a user accepts an invitation and the controller method was taking care of all of these things. We began to eliminate these issues by extracting smaller operations that the accept method was handling into various methods and moving this code into various models such as the invitation.rb, signed_up_user.rb and team_user.rb.

<pre>
old_entry = TeamsUser.find(:first, :conditions => ['user_id = ? and team_id = ?', student.user_id, params[:team_id]])
if old_entry != nil
old_entry.destroy
end
</pre>

<pre>
TeamsUser.remove_previous_team(student.user_id, params[:team_id])
</pre>

<pre>
'''teams_user.rb'''

def self.remove_previous_team(user_id, team_id)
old_entry = TeamsUser.find(:first, :conditions => ['user_id = ? and team_id = ?', user_id, team_id])
if old_entry != nil
old_entry.destroy
end
end
</pre>

The accept method within the controller had too much functionality. We first moved much of the functionality within the accept method to a model accept method which purpose is to make sure that all items that need to be taken care of upon a method accept are in fact handled. Just moving this code to the model did not solve the issue of complexity. We created smaller methods to handle individual changes that needed to be taken care of for example upon an accept the users topic must be updated, the topics they are waitlisted for must be dropped, amongst many other things. We took these smaller changes that needed to be made and moved them into separate methods amongst various models like signed_up_user.rb and teams_user.rb. We also noticed that some variable names did not do a good job of describing their focus so we changed these variable names to increase readability. After our refactoring the accept method is much smaller and much more readable.<ref> Coding Conventions [http://www.slideshare.net/davidpaluy/ruby-on-rails-coding-conventions-standards-and-best-practices "Ruby On Rails coding conventions, standards and best practices"] </ref>

'''Before Refactor'''
<pre>
def accept
@inv = Invitation.find(params[:inv_id])
@inv.reply_status = 'A'
@inv.save

student = Participant.find(params[:student_id])

#if you are on a team and you accept another invitation, remove your previous entry in the teams_users table.
old_entry = TeamsUser.find(:first, :conditions => ['user_id = ? and team_id = ?', student.user_id, params[:team_id]])
if old_entry != nil
old_entry.destroy
end

#if you are on a team and you accept another invitation and if your old team does not have any members, delete the entry for the team
other_members = TeamsUser.find(:all, :conditions => ['team_id = ?', params[:team_id]])
if other_members.nil? || other_members.length == 0
old_team = AssignmentTeam.find(:first, :conditions => ['id = ?', params[:team_id]])
if old_team != nil
old_team.destroy
end

#if a signup sheet exists then release all the topics selected by this team into the pool.
old_teams_signups = SignedUpUser.find_all_by_creator_id(params[:team_id])
if !old_teams_signups.nil?
for old_teams_signup in old_teams_signups
if old_teams_signup.is_waitlisted == false # i.e., if the old team was occupying a slot, & thus is releasing a slot ...
first_waitlisted_signup = SignedUpUser.find_by_topic_id_and_is_waitlisted(old_teams_signup.topic_id, true)
if !first_waitlisted_signup.nil?
#As this user is going to be allocated a confirmed topic, all of his waitlisted topic signups should be purged
first_waitlisted_signup.is_waitlisted = false
first_waitlisted_signup.save

#Also update the participant table. But first_waitlisted_signup.creator_id is the team id
#so find one of the users on the team because the update_topic_id function in participant
#will take care of updating all the participants on the team
user_id = TeamsUser.find(:first, :conditions => {:team_id => first_waitlisted_signup.creator_id}).user_id
participant = Participant.find_by_user_id_and_parent_id(user_id,old_team.assignment.id)
participant.update_topic_id(old_teams_signup.topic_id)

SignUpTopic.cancel_all_waitlists(first_waitlisted_signup.creator_id, SignUpTopic.find(old_teams_signup.topic_id)['assignment_id'])
end # if !first_waitlisted_signup.nil
# Remove the now-empty team from the slot it is occupying.
end # if old_teams_signup.is_waitlisted == false
old_teams_signup.destroy
end
end
end
</pre>

'''After Refactor'''
<pre>
def accept
@inv = Invitation.find(params[:inv_id])
@inv.reply_status = 'A'
@inv.save

invited_user_id = Participant.find(params[:student_id]).user_id

#Remove the users previous team since they are accepting an invite for possibly a new team.
TeamsUser.remove_team(invited_user_id, params[:team_id])
#Accept the invite and return boolean on whether the add was successful
add_successful = Invitation.accept_invite(params[:team_id], @inv.from_id, @inv.to_id)
#If add wasn't successful because team was full display message
unless add_successful
flash[:error]= "The team already has the maximum number of members."
end

redirect_to :controller => 'student_team', :action => 'view', :id => Participant.find(params[:student_id]).id
end
</pre>

== Bug Fixes ==

=== Invite Requests ===
==== Problem Description ====

When a particular user responds to a advertisement sent out by another user(advertiser), a new Request invitation is created which is displayed in the advertiser's received request section of the team page as shown below: 
[[File:Receivercmh.jpg]]

When the advertiser clicks on the invite, the corresponding received request should be removed from the received requests list and the request sender should see the status as accepted when he logs in again as shown below: 
[[File:sendcmh.jpg]]

====Complete steps to reproduce the bug fix====
<pre>
1)login as admin with password"pass"
2) create new course and an assignment within the course
set all the properties appropriately-
set the assignment as a team assignment
set the deadlines properly.
3) add 2 participants(user1 and user2) to the assignment(users need to be created who act as participants)
4) create a topic within the assignment
5) login as user1 and select the topic in the signup sheet
6) create an advertisement in the your team link of the assignments
7) Now login as user2 and click on signupsheet.You should see an advertisement sent out by user1.
8) click on the advertise link and request an invitation.
9) Login as user1 again and go to the your team link.
10) user1 should see the the invitation request in the received requests with the invite and decline button next to it.
11)when user1 clicks on the invite button, the request invitation should be removed and when user2 logs in again , he should see the sent request as accepted
</pre>

=== Error Messages ===

== Future Work ==

= References =
<references/>

CSC/ECE 517 Fall 2013/oss cmh

2013-10-29T21:54:44Z

Mrsreena: /* Problem Description */

== Introduction ==

What the invitation controller does and the process advertising, creating invites and accepting invites.

== Project Description ==
'''Classes:''' invitation_controller.rb (104 lines)
invitation.rb (5 lines)

'''What it does:''' Handles invitations to join teams.

'''What needs to be done:''' The code is deeply nested and quite confusing. There should be a single method responsible for finding whether a user is already on a team, adding someone onto a waitlist, dropping someone off of a waitlist, changing/updating the topic that the user is assigned to, etc. Some of these methods should be in model classes, such as invitation.rb and signed_up_user.rb. Break the complicated methods into shorter methods with clear names, and place these methods in the most appropriate class, moving a lot of functionality to the model classes.

Currently, after someone joins a team, pending invitations are not removed. There should be a method handling deletion of invitations (including declined invitations) to a user after that user joins a team. This should be a model method.

Though this class is not long, the code looks and reads like it is very complicated. Breaking it down into multiple methods with clear names and proper division of functionality between classes will be a challenge.

== Motivation ==

Briefly talk about why invitation controller needed refactoring.

== Design Changes ==

=== Create Method ===
'''Before Refactor'''
<pre>
def create
user = User.find_by_name(params[:user][:name].strip)
team = AssignmentTeam.find_by_id(params[:team_id])
student = AssignmentParticipant.find(params[:student_id])
return unless current_user_id?(student.user_id)

#check if the invited user is valid
if !user
flash[:notice] = "\"#{params[:user][:name].strip}\" does not exist. Please make sure the name entered is correct."
else
participant = AssignmentParticipant.find(:first, :conditions => ['user_id =? and parent_id =?', user.id, student.parent_id])
if !participant
flash[:notice] = "\"#{params[:user][:name].strip}\" is not a participant of this assignment."
else
team_member = TeamsUser.find(:all, :conditions => ['team_id =? and user_id =?', team.id, user.id])
#check if invited user is already in the team
if (team_member.size > 0)
flash[:notice] = "\"#{user.name}\" is already a member of team."
else
sent_invitation = Invitation.find(:all, :conditions => ['from_id = ? and to_id = ? and assignment_id = ? and reply_status = "W"', student.user_id, user.id, student.parent_id])
#check if the invited user is already invited (i.e. awaiting reply)
if sent_invitation.length == 0
@invitation = Invitation.new
@invitation.to_id = user.id
@invitation.from_id = student.user_id
@invitation.assignment_id = student.parent_id
@invitation.reply_status = 'W'
@invitation.save
else
flash[:notice] = "You have already sent an invitation to \"#{user.name}\"."
end
end
end
end
redirect_to :controller => 'student_team', :action => 'view', :id=> student.id
end
</pre>

'''After Refactor'''
<pre>
def create
user = User.find_by_name(params[:user][:name].strip)
team = AssignmentTeam.find_by_id(params[:team_id])
student = AssignmentParticipant.find(params[:student_id])
return unless current_user_id?(student.user_id)

#check if the invited user is valid
if !user
flash[:note] = "\"#{params[:user][:name].strip}\" does not exist. Please make sure the name entered is correct."
else
participant= AssignmentParticipant.first( :conditions => ['user_id =? and parent_id =?', user.id, student.parent_id])
#check if the user is a participant of the assignment
if !participant
flash[:note] = "\"#{params[:user][:name].strip}\" is not a participant of this assignment."
else
team_member = TeamsUser.all(:conditions => ['team_id =? and user_id =?', team.id, user.id])
#check if invited user is already in the team
if (team_member.size > 0)
flash[:note] = "\"#{user.name}\" is already a member of team."
else
#check if the invited user is already invited (i.e. awaiting reply)
if Invitation.is_invited?(student.user_id, user.id, student.parent_id)
@invitation = Invitation.new
@invitation.to_id = user.id
@invitation.from_id = student.user_id
@invitation.assignment_id = student.parent_id
@invitation.reply_status = 'W'
@invitation.save
else
flash[:note] = "You have already sent an invitation to \"#{user.name}\"."
end
end
end
end

update_join_team_request

redirect_to :controller => 'student_team', :action => 'view', :id=> student.id
end
</pre>

=== Accept Method ===

The theme that we went with for refactoring the accept method is “Skin Controller, Fat Model.” <ref> Best Practices [http://www.sitepoint.com/10-ruby-on-rails-best-practices/ "10 Ruby on Rails Best Practices"] </ref> We wanted to move much of the logistics out of the accept method letting models handle this while keeping the controller limited to being the interface between the view and model. Before accept method was refactored it was very dense and contained too much functionality. The accept method was in the invitation controller was performing much of the invitation logic that should have been handled in the invitation model and various other models throughout the application. The accept method also played many different roles in that not only was it handling items that the model was responsible for but it was performing many different operations. There are many actions that need to take place when a user accepts an invitation and the controller method was taking care of all of these things. We began to eliminate these issues by extracting smaller operations that the accept method was handling into various methods and moving this code into various models such as the invitation.rb, signed_up_user.rb and team_user.rb.

<pre>
old_entry = TeamsUser.find(:first, :conditions => ['user_id = ? and team_id = ?', student.user_id, params[:team_id]])
if old_entry != nil
old_entry.destroy
end
</pre>

<pre>
TeamsUser.remove_previous_team(student.user_id, params[:team_id])
</pre>

<pre>
'''teams_user.rb'''

def self.remove_previous_team(user_id, team_id)
old_entry = TeamsUser.find(:first, :conditions => ['user_id = ? and team_id = ?', user_id, team_id])
if old_entry != nil
old_entry.destroy
end
end
</pre>

The accept method within the controller had too much functionality. We first moved much of the functionality within the accept method to a model accept method which purpose is to make sure that all items that need to be taken care of upon a method accept are in fact handled. Just moving this code to the model did not solve the issue of complexity. We created smaller methods to handle individual changes that needed to be taken care of for example upon an accept the users topic must be updated, the topics they are waitlisted for must be dropped, amongst many other things. We took these smaller changes that needed to be made and moved them into separate methods amongst various models like signed_up_user.rb and teams_user.rb. We also noticed that some variable names did not do a good job of describing their focus so we changed these variable names to increase readability. After our refactoring the accept method is much smaller and much more readable.<ref> Coding Conventions [http://www.slideshare.net/davidpaluy/ruby-on-rails-coding-conventions-standards-and-best-practices "Ruby On Rails coding conventions, standards and best practices"] </ref>

'''Before Refactor'''
<pre>
def accept
@inv = Invitation.find(params[:inv_id])
@inv.reply_status = 'A'
@inv.save

student = Participant.find(params[:student_id])

#if you are on a team and you accept another invitation, remove your previous entry in the teams_users table.
old_entry = TeamsUser.find(:first, :conditions => ['user_id = ? and team_id = ?', student.user_id, params[:team_id]])
if old_entry != nil
old_entry.destroy
end

#if you are on a team and you accept another invitation and if your old team does not have any members, delete the entry for the team
other_members = TeamsUser.find(:all, :conditions => ['team_id = ?', params[:team_id]])
if other_members.nil? || other_members.length == 0
old_team = AssignmentTeam.find(:first, :conditions => ['id = ?', params[:team_id]])
if old_team != nil
old_team.destroy
end

#if a signup sheet exists then release all the topics selected by this team into the pool.
old_teams_signups = SignedUpUser.find_all_by_creator_id(params[:team_id])
if !old_teams_signups.nil?
for old_teams_signup in old_teams_signups
if old_teams_signup.is_waitlisted == false # i.e., if the old team was occupying a slot, & thus is releasing a slot ...
first_waitlisted_signup = SignedUpUser.find_by_topic_id_and_is_waitlisted(old_teams_signup.topic_id, true)
if !first_waitlisted_signup.nil?
#As this user is going to be allocated a confirmed topic, all of his waitlisted topic signups should be purged
first_waitlisted_signup.is_waitlisted = false
first_waitlisted_signup.save

#Also update the participant table. But first_waitlisted_signup.creator_id is the team id
#so find one of the users on the team because the update_topic_id function in participant
#will take care of updating all the participants on the team
user_id = TeamsUser.find(:first, :conditions => {:team_id => first_waitlisted_signup.creator_id}).user_id
participant = Participant.find_by_user_id_and_parent_id(user_id,old_team.assignment.id)
participant.update_topic_id(old_teams_signup.topic_id)

SignUpTopic.cancel_all_waitlists(first_waitlisted_signup.creator_id, SignUpTopic.find(old_teams_signup.topic_id)['assignment_id'])
end # if !first_waitlisted_signup.nil
# Remove the now-empty team from the slot it is occupying.
end # if old_teams_signup.is_waitlisted == false
old_teams_signup.destroy
end
end
end
</pre>

'''After Refactor'''
<pre>
def accept
@inv = Invitation.find(params[:inv_id])
@inv.reply_status = 'A'
@inv.save

invited_user_id = Participant.find(params[:student_id]).user_id

#Remove the users previous team since they are accepting an invite for possibly a new team.
TeamsUser.remove_team(invited_user_id, params[:team_id])
#Accept the invite and return boolean on whether the add was successful
add_successful = Invitation.accept_invite(params[:team_id], @inv.from_id, @inv.to_id)
#If add wasn't successful because team was full display message
unless add_successful
flash[:error]= "The team already has the maximum number of members."
end

redirect_to :controller => 'student_team', :action => 'view', :id => Participant.find(params[:student_id]).id
end
</pre>

== Bug Fixes ==

=== Invite Requests ===
==== Problem Description ====

When a particular user responds to a advertisement sent out by another user(advertiser), a new Request invitation is created which is displayed in the advertiser's received request section of the team page as shown below:
[[File:Receivercmh.jpg]]

When the advertiser clicks on the invite, the corresponding received request should be removed from the received requests list and the request sender should see the status as accepted when he logs in again as shown below:
[[File:sendcmh.jpg]]

====Complete steps to reproduce the bug fix====
<pre>
1)login as admin with password"pass"
2) create new course and an assignment within the course
set all the properties appropriately-
set the assignment as a team assignment
set the deadlines properly.
3) add 2 participants(user1 and user2) to the assignment(users need to be created who act as participants)
4) create a topic within the assignment
5) login as user1 and select the topic in the signup sheet
6) create an advertisement in the your team link of the assignments
7) Now login as user2 and click on signupsheet.You should see an advertisement sent out by user1.
8) click on the advertise link and request an invitation.
9) Login as user1 again and go to the your team link.
10) user1 should see the the invitation request in the received requests with the invite and decline button next to it.
11)when user1 clicks on the invite button, the request invitation should be removed and when user2 logs in again , he should see the sent request as accepted
</pre>

=== Error Messages ===

== Future Work ==

= References =
<references/>

CSC/ECE 517 Fall 2013/oss cmh

2013-10-29T21:53:53Z

Mrsreena: /* Problem Description */

== Introduction ==

What the invitation controller does and the process advertising, creating invites and accepting invites.

== Project Description ==
'''Classes:''' invitation_controller.rb (104 lines)
invitation.rb (5 lines)

'''What it does:''' Handles invitations to join teams.

'''What needs to be done:''' The code is deeply nested and quite confusing. There should be a single method responsible for finding whether a user is already on a team, adding someone onto a waitlist, dropping someone off of a waitlist, changing/updating the topic that the user is assigned to, etc. Some of these methods should be in model classes, such as invitation.rb and signed_up_user.rb. Break the complicated methods into shorter methods with clear names, and place these methods in the most appropriate class, moving a lot of functionality to the model classes.

Currently, after someone joins a team, pending invitations are not removed. There should be a method handling deletion of invitations (including declined invitations) to a user after that user joins a team. This should be a model method.

Though this class is not long, the code looks and reads like it is very complicated. Breaking it down into multiple methods with clear names and proper division of functionality between classes will be a challenge.

== Motivation ==

Briefly talk about why invitation controller needed refactoring.

== Design Changes ==

=== Create Method ===
'''Before Refactor'''
<pre>
def create
user = User.find_by_name(params[:user][:name].strip)
team = AssignmentTeam.find_by_id(params[:team_id])
student = AssignmentParticipant.find(params[:student_id])
return unless current_user_id?(student.user_id)

#check if the invited user is valid
if !user
flash[:notice] = "\"#{params[:user][:name].strip}\" does not exist. Please make sure the name entered is correct."
else
participant = AssignmentParticipant.find(:first, :conditions => ['user_id =? and parent_id =?', user.id, student.parent_id])
if !participant
flash[:notice] = "\"#{params[:user][:name].strip}\" is not a participant of this assignment."
else
team_member = TeamsUser.find(:all, :conditions => ['team_id =? and user_id =?', team.id, user.id])
#check if invited user is already in the team
if (team_member.size > 0)
flash[:notice] = "\"#{user.name}\" is already a member of team."
else
sent_invitation = Invitation.find(:all, :conditions => ['from_id = ? and to_id = ? and assignment_id = ? and reply_status = "W"', student.user_id, user.id, student.parent_id])
#check if the invited user is already invited (i.e. awaiting reply)
if sent_invitation.length == 0
@invitation = Invitation.new
@invitation.to_id = user.id
@invitation.from_id = student.user_id
@invitation.assignment_id = student.parent_id
@invitation.reply_status = 'W'
@invitation.save
else
flash[:notice] = "You have already sent an invitation to \"#{user.name}\"."
end
end
end
end
redirect_to :controller => 'student_team', :action => 'view', :id=> student.id
end
</pre>

'''After Refactor'''
<pre>
def create
user = User.find_by_name(params[:user][:name].strip)
team = AssignmentTeam.find_by_id(params[:team_id])
student = AssignmentParticipant.find(params[:student_id])
return unless current_user_id?(student.user_id)

#check if the invited user is valid
if !user
flash[:note] = "\"#{params[:user][:name].strip}\" does not exist. Please make sure the name entered is correct."
else
participant= AssignmentParticipant.first( :conditions => ['user_id =? and parent_id =?', user.id, student.parent_id])
#check if the user is a participant of the assignment
if !participant
flash[:note] = "\"#{params[:user][:name].strip}\" is not a participant of this assignment."
else
team_member = TeamsUser.all(:conditions => ['team_id =? and user_id =?', team.id, user.id])
#check if invited user is already in the team
if (team_member.size > 0)
flash[:note] = "\"#{user.name}\" is already a member of team."
else
#check if the invited user is already invited (i.e. awaiting reply)
if Invitation.is_invited?(student.user_id, user.id, student.parent_id)
@invitation = Invitation.new
@invitation.to_id = user.id
@invitation.from_id = student.user_id
@invitation.assignment_id = student.parent_id
@invitation.reply_status = 'W'
@invitation.save
else
flash[:note] = "You have already sent an invitation to \"#{user.name}\"."
end
end
end
end

update_join_team_request

redirect_to :controller => 'student_team', :action => 'view', :id=> student.id
end
</pre>

=== Accept Method ===

The theme that we went with for refactoring the accept method is “Skin Controller, Fat Model.” <ref> Best Practices [http://www.sitepoint.com/10-ruby-on-rails-best-practices/ "10 Ruby on Rails Best Practices"] </ref> We wanted to move much of the logistics out of the accept method letting models handle this while keeping the controller limited to being the interface between the view and model. Before accept method was refactored it was very dense and contained too much functionality. The accept method was in the invitation controller was performing much of the invitation logic that should have been handled in the invitation model and various other models throughout the application. The accept method also played many different roles in that not only was it handling items that the model was responsible for but it was performing many different operations. There are many actions that need to take place when a user accepts an invitation and the controller method was taking care of all of these things. We began to eliminate these issues by extracting smaller operations that the accept method was handling into various methods and moving this code into various models such as the invitation.rb, signed_up_user.rb and team_user.rb.

<pre>
old_entry = TeamsUser.find(:first, :conditions => ['user_id = ? and team_id = ?', student.user_id, params[:team_id]])
if old_entry != nil
old_entry.destroy
end
</pre>

<pre>
TeamsUser.remove_previous_team(student.user_id, params[:team_id])
</pre>

<pre>
'''teams_user.rb'''

def self.remove_previous_team(user_id, team_id)
old_entry = TeamsUser.find(:first, :conditions => ['user_id = ? and team_id = ?', user_id, team_id])
if old_entry != nil
old_entry.destroy
end
end
</pre>

The accept method within the controller had too much functionality. We first moved much of the functionality within the accept method to a model accept method which purpose is to make sure that all items that need to be taken care of upon a method accept are in fact handled. Just moving this code to the model did not solve the issue of complexity. We created smaller methods to handle individual changes that needed to be taken care of for example upon an accept the users topic must be updated, the topics they are waitlisted for must be dropped, amongst many other things. We took these smaller changes that needed to be made and moved them into separate methods amongst various models like signed_up_user.rb and teams_user.rb. We also noticed that some variable names did not do a good job of describing their focus so we changed these variable names to increase readability. After our refactoring the accept method is much smaller and much more readable.<ref> Coding Conventions [http://www.slideshare.net/davidpaluy/ruby-on-rails-coding-conventions-standards-and-best-practices "Ruby On Rails coding conventions, standards and best practices"] </ref>

'''Before Refactor'''
<pre>
def accept
@inv = Invitation.find(params[:inv_id])
@inv.reply_status = 'A'
@inv.save

student = Participant.find(params[:student_id])

#if you are on a team and you accept another invitation, remove your previous entry in the teams_users table.
old_entry = TeamsUser.find(:first, :conditions => ['user_id = ? and team_id = ?', student.user_id, params[:team_id]])
if old_entry != nil
old_entry.destroy
end

#if you are on a team and you accept another invitation and if your old team does not have any members, delete the entry for the team
other_members = TeamsUser.find(:all, :conditions => ['team_id = ?', params[:team_id]])
if other_members.nil? || other_members.length == 0
old_team = AssignmentTeam.find(:first, :conditions => ['id = ?', params[:team_id]])
if old_team != nil
old_team.destroy
end

#if a signup sheet exists then release all the topics selected by this team into the pool.
old_teams_signups = SignedUpUser.find_all_by_creator_id(params[:team_id])
if !old_teams_signups.nil?
for old_teams_signup in old_teams_signups
if old_teams_signup.is_waitlisted == false # i.e., if the old team was occupying a slot, & thus is releasing a slot ...
first_waitlisted_signup = SignedUpUser.find_by_topic_id_and_is_waitlisted(old_teams_signup.topic_id, true)
if !first_waitlisted_signup.nil?
#As this user is going to be allocated a confirmed topic, all of his waitlisted topic signups should be purged
first_waitlisted_signup.is_waitlisted = false
first_waitlisted_signup.save

#Also update the participant table. But first_waitlisted_signup.creator_id is the team id
#so find one of the users on the team because the update_topic_id function in participant
#will take care of updating all the participants on the team
user_id = TeamsUser.find(:first, :conditions => {:team_id => first_waitlisted_signup.creator_id}).user_id
participant = Participant.find_by_user_id_and_parent_id(user_id,old_team.assignment.id)
participant.update_topic_id(old_teams_signup.topic_id)

SignUpTopic.cancel_all_waitlists(first_waitlisted_signup.creator_id, SignUpTopic.find(old_teams_signup.topic_id)['assignment_id'])
end # if !first_waitlisted_signup.nil
# Remove the now-empty team from the slot it is occupying.
end # if old_teams_signup.is_waitlisted == false
old_teams_signup.destroy
end
end
end
</pre>

'''After Refactor'''
<pre>
def accept
@inv = Invitation.find(params[:inv_id])
@inv.reply_status = 'A'
@inv.save

invited_user_id = Participant.find(params[:student_id]).user_id

#Remove the users previous team since they are accepting an invite for possibly a new team.
TeamsUser.remove_team(invited_user_id, params[:team_id])
#Accept the invite and return boolean on whether the add was successful
add_successful = Invitation.accept_invite(params[:team_id], @inv.from_id, @inv.to_id)
#If add wasn't successful because team was full display message
unless add_successful
flash[:error]= "The team already has the maximum number of members."
end

redirect_to :controller => 'student_team', :action => 'view', :id => Participant.find(params[:student_id]).id
end
</pre>

== Bug Fixes ==

=== Invite Requests ===
==== Problem Description ====

When a particular user responds to a advertisement sent out by another user(advertiser), a new Request invitation is created which is displayed in the advertiser's received request section of the team page as shown below:
[[File:Receivercmh.jpg]]

When the advertiser clicks on the invite, the corresponding received request should be removed from the received requests list and the request sender should see the status as accepted when he logs in again as shown below:
[[File:sendcmh.jpg]]

====Complete steps to reproduce the bug fix====
<pre>
1)login as admin with password"pass"
2) create new course and an assignment within the course
set all the properties appropriately-
set the assignment as a team assignment
set the deadlines properly.
3) add 2 participants(user1 and user2) to the assignment(users need to be created who act as participants)
4) create a topic within the assignment
5) login as user1 and select the topic in the signup sheet
6) create an advertisement in the your team link of the assignments
7) Now login as user2 and click on signupsheet.You should see an advertisement sent out by user1.
8) click on the advertise link and request an invitation.
9) Login as user1 again and go to the your team link.
10) user1 should see the the invitation request in the received requests with the invite and decline button next to it.
11)when user1 clicks on the invite button, the request invitation should be removed and when user2 logs in again , he should see the sent request as accepted
</pre>

=== Error Messages ===

== Future Work ==

= References =
<references/>

CSC/ECE 517 Fall 2013/oss cmh

2013-10-29T21:53:14Z

Mrsreena: /* Introduction */

== Introduction ==

What the invitation controller does and the process advertising, creating invites and accepting invites.

== Project Description ==
'''Classes:''' invitation_controller.rb (104 lines)
invitation.rb (5 lines)

'''What it does:''' Handles invitations to join teams.

'''What needs to be done:''' The code is deeply nested and quite confusing. There should be a single method responsible for finding whether a user is already on a team, adding someone onto a waitlist, dropping someone off of a waitlist, changing/updating the topic that the user is assigned to, etc. Some of these methods should be in model classes, such as invitation.rb and signed_up_user.rb. Break the complicated methods into shorter methods with clear names, and place these methods in the most appropriate class, moving a lot of functionality to the model classes.

Currently, after someone joins a team, pending invitations are not removed. There should be a method handling deletion of invitations (including declined invitations) to a user after that user joins a team. This should be a model method.

Though this class is not long, the code looks and reads like it is very complicated. Breaking it down into multiple methods with clear names and proper division of functionality between classes will be a challenge.

== Motivation ==

Briefly talk about why invitation controller needed refactoring.

== Design Changes ==

=== Create Method ===
'''Before Refactor'''
<pre>
def create
user = User.find_by_name(params[:user][:name].strip)
team = AssignmentTeam.find_by_id(params[:team_id])
student = AssignmentParticipant.find(params[:student_id])
return unless current_user_id?(student.user_id)

#check if the invited user is valid
if !user
flash[:notice] = "\"#{params[:user][:name].strip}\" does not exist. Please make sure the name entered is correct."
else
participant = AssignmentParticipant.find(:first, :conditions => ['user_id =? and parent_id =?', user.id, student.parent_id])
if !participant
flash[:notice] = "\"#{params[:user][:name].strip}\" is not a participant of this assignment."
else
team_member = TeamsUser.find(:all, :conditions => ['team_id =? and user_id =?', team.id, user.id])
#check if invited user is already in the team
if (team_member.size > 0)
flash[:notice] = "\"#{user.name}\" is already a member of team."
else
sent_invitation = Invitation.find(:all, :conditions => ['from_id = ? and to_id = ? and assignment_id = ? and reply_status = "W"', student.user_id, user.id, student.parent_id])
#check if the invited user is already invited (i.e. awaiting reply)
if sent_invitation.length == 0
@invitation = Invitation.new
@invitation.to_id = user.id
@invitation.from_id = student.user_id
@invitation.assignment_id = student.parent_id
@invitation.reply_status = 'W'
@invitation.save
else
flash[:notice] = "You have already sent an invitation to \"#{user.name}\"."
end
end
end
end
redirect_to :controller => 'student_team', :action => 'view', :id=> student.id
end
</pre>

'''After Refactor'''
<pre>
def create
user = User.find_by_name(params[:user][:name].strip)
team = AssignmentTeam.find_by_id(params[:team_id])
student = AssignmentParticipant.find(params[:student_id])
return unless current_user_id?(student.user_id)

#check if the invited user is valid
if !user
flash[:note] = "\"#{params[:user][:name].strip}\" does not exist. Please make sure the name entered is correct."
else
participant= AssignmentParticipant.first( :conditions => ['user_id =? and parent_id =?', user.id, student.parent_id])
#check if the user is a participant of the assignment
if !participant
flash[:note] = "\"#{params[:user][:name].strip}\" is not a participant of this assignment."
else
team_member = TeamsUser.all(:conditions => ['team_id =? and user_id =?', team.id, user.id])
#check if invited user is already in the team
if (team_member.size > 0)
flash[:note] = "\"#{user.name}\" is already a member of team."
else
#check if the invited user is already invited (i.e. awaiting reply)
if Invitation.is_invited?(student.user_id, user.id, student.parent_id)
@invitation = Invitation.new
@invitation.to_id = user.id
@invitation.from_id = student.user_id
@invitation.assignment_id = student.parent_id
@invitation.reply_status = 'W'
@invitation.save
else
flash[:note] = "You have already sent an invitation to \"#{user.name}\"."
end
end
end
end

update_join_team_request

redirect_to :controller => 'student_team', :action => 'view', :id=> student.id
end
</pre>

=== Accept Method ===

The theme that we went with for refactoring the accept method is “Skin Controller, Fat Model.” <ref> Best Practices [http://www.sitepoint.com/10-ruby-on-rails-best-practices/ "10 Ruby on Rails Best Practices"] </ref> We wanted to move much of the logistics out of the accept method letting models handle this while keeping the controller limited to being the interface between the view and model. Before accept method was refactored it was very dense and contained too much functionality. The accept method was in the invitation controller was performing much of the invitation logic that should have been handled in the invitation model and various other models throughout the application. The accept method also played many different roles in that not only was it handling items that the model was responsible for but it was performing many different operations. There are many actions that need to take place when a user accepts an invitation and the controller method was taking care of all of these things. We began to eliminate these issues by extracting smaller operations that the accept method was handling into various methods and moving this code into various models such as the invitation.rb, signed_up_user.rb and team_user.rb.

<pre>
old_entry = TeamsUser.find(:first, :conditions => ['user_id = ? and team_id = ?', student.user_id, params[:team_id]])
if old_entry != nil
old_entry.destroy
end
</pre>

<pre>
TeamsUser.remove_previous_team(student.user_id, params[:team_id])
</pre>

<pre>
'''teams_user.rb'''

def self.remove_previous_team(user_id, team_id)
old_entry = TeamsUser.find(:first, :conditions => ['user_id = ? and team_id = ?', user_id, team_id])
if old_entry != nil
old_entry.destroy
end
end
</pre>

The accept method within the controller had too much functionality. We first moved much of the functionality within the accept method to a model accept method which purpose is to make sure that all items that need to be taken care of upon a method accept are in fact handled. Just moving this code to the model did not solve the issue of complexity. We created smaller methods to handle individual changes that needed to be taken care of for example upon an accept the users topic must be updated, the topics they are waitlisted for must be dropped, amongst many other things. We took these smaller changes that needed to be made and moved them into separate methods amongst various models like signed_up_user.rb and teams_user.rb. We also noticed that some variable names did not do a good job of describing their focus so we changed these variable names to increase readability. After our refactoring the accept method is much smaller and much more readable.<ref> Coding Conventions [http://www.slideshare.net/davidpaluy/ruby-on-rails-coding-conventions-standards-and-best-practices "Ruby On Rails coding conventions, standards and best practices"] </ref>

'''Before Refactor'''
<pre>
def accept
@inv = Invitation.find(params[:inv_id])
@inv.reply_status = 'A'
@inv.save

student = Participant.find(params[:student_id])

#if you are on a team and you accept another invitation, remove your previous entry in the teams_users table.
old_entry = TeamsUser.find(:first, :conditions => ['user_id = ? and team_id = ?', student.user_id, params[:team_id]])
if old_entry != nil
old_entry.destroy
end

#if you are on a team and you accept another invitation and if your old team does not have any members, delete the entry for the team
other_members = TeamsUser.find(:all, :conditions => ['team_id = ?', params[:team_id]])
if other_members.nil? || other_members.length == 0
old_team = AssignmentTeam.find(:first, :conditions => ['id = ?', params[:team_id]])
if old_team != nil
old_team.destroy
end

#if a signup sheet exists then release all the topics selected by this team into the pool.
old_teams_signups = SignedUpUser.find_all_by_creator_id(params[:team_id])
if !old_teams_signups.nil?
for old_teams_signup in old_teams_signups
if old_teams_signup.is_waitlisted == false # i.e., if the old team was occupying a slot, & thus is releasing a slot ...
first_waitlisted_signup = SignedUpUser.find_by_topic_id_and_is_waitlisted(old_teams_signup.topic_id, true)
if !first_waitlisted_signup.nil?
#As this user is going to be allocated a confirmed topic, all of his waitlisted topic signups should be purged
first_waitlisted_signup.is_waitlisted = false
first_waitlisted_signup.save

#Also update the participant table. But first_waitlisted_signup.creator_id is the team id
#so find one of the users on the team because the update_topic_id function in participant
#will take care of updating all the participants on the team
user_id = TeamsUser.find(:first, :conditions => {:team_id => first_waitlisted_signup.creator_id}).user_id
participant = Participant.find_by_user_id_and_parent_id(user_id,old_team.assignment.id)
participant.update_topic_id(old_teams_signup.topic_id)

SignUpTopic.cancel_all_waitlists(first_waitlisted_signup.creator_id, SignUpTopic.find(old_teams_signup.topic_id)['assignment_id'])
end # if !first_waitlisted_signup.nil
# Remove the now-empty team from the slot it is occupying.
end # if old_teams_signup.is_waitlisted == false
old_teams_signup.destroy
end
end
end
</pre>

'''After Refactor'''
<pre>
def accept
@inv = Invitation.find(params[:inv_id])
@inv.reply_status = 'A'
@inv.save

invited_user_id = Participant.find(params[:student_id]).user_id

#Remove the users previous team since they are accepting an invite for possibly a new team.
TeamsUser.remove_team(invited_user_id, params[:team_id])
#Accept the invite and return boolean on whether the add was successful
add_successful = Invitation.accept_invite(params[:team_id], @inv.from_id, @inv.to_id)
#If add wasn't successful because team was full display message
unless add_successful
flash[:error]= "The team already has the maximum number of members."
end

redirect_to :controller => 'student_team', :action => 'view', :id => Participant.find(params[:student_id]).id
end
</pre>

== Bug Fixes ==

=== Invite Requests ===
==== Problem Description ====

When a particular user responds to a advertisement sent out by another user(advertiser), a new Request invitation is created which is displayed in the advertiser's received request section of the team page as shown below:

When the advertiser clicks on the invite, the corresponding received request should be removed from the received requests list and the request sender should see the status as accepted when he logs in again as shown below:

Complete steps to reproduce the bug fix:
<pre>
1)login as admin with password"pass"

2) create new course and an assignment within the course
set all the properties appropriately-
set the assignment as a team assignment
set the deadlines properly.
3) add 2 participants(user1 and user2) to the assignment(users need to be created who act as participants)
4) create a topic within the assignment
5) login as user1 and select the topic in the signup sheet
6) create an advertisement in the your team link of the assignments
7) Now login as user2 and click on signupsheet.You should see an advertisement sent out by user1.
8) click on the advertise link and request an invitation.
9) Login as user1 again and go to the your team link.
10) user1 should see the the invitation request in the received requests with the invite and decline button next to it.
11)when user1 clicks on the invite button, the request invitation should be removed and when user2 logs in again , he should see the sent request as accepted
</pre>

=== Error Messages ===

== Future Work ==

= References =
<references/>

CSC/ECE 517 Fall 2013/oss cmh

2013-10-29T21:52:53Z

Mrsreena: /* Invite Requests */

== Introduction ==

What the invitation controller does and the process advertising, creating invites and accepting invites.

[[File:Receivercmh.jpg]]
[[File:sendcmh.jpg]]

== Project Description ==
'''Classes:''' invitation_controller.rb (104 lines)
invitation.rb (5 lines)

'''What it does:''' Handles invitations to join teams.

'''What needs to be done:''' The code is deeply nested and quite confusing. There should be a single method responsible for finding whether a user is already on a team, adding someone onto a waitlist, dropping someone off of a waitlist, changing/updating the topic that the user is assigned to, etc. Some of these methods should be in model classes, such as invitation.rb and signed_up_user.rb. Break the complicated methods into shorter methods with clear names, and place these methods in the most appropriate class, moving a lot of functionality to the model classes.

Currently, after someone joins a team, pending invitations are not removed. There should be a method handling deletion of invitations (including declined invitations) to a user after that user joins a team. This should be a model method.

Though this class is not long, the code looks and reads like it is very complicated. Breaking it down into multiple methods with clear names and proper division of functionality between classes will be a challenge.

== Motivation ==

Briefly talk about why invitation controller needed refactoring.

== Design Changes ==

=== Create Method ===
'''Before Refactor'''
<pre>
def create
user = User.find_by_name(params[:user][:name].strip)
team = AssignmentTeam.find_by_id(params[:team_id])
student = AssignmentParticipant.find(params[:student_id])
return unless current_user_id?(student.user_id)

#check if the invited user is valid
if !user
flash[:notice] = "\"#{params[:user][:name].strip}\" does not exist. Please make sure the name entered is correct."
else
participant = AssignmentParticipant.find(:first, :conditions => ['user_id =? and parent_id =?', user.id, student.parent_id])
if !participant
flash[:notice] = "\"#{params[:user][:name].strip}\" is not a participant of this assignment."
else
team_member = TeamsUser.find(:all, :conditions => ['team_id =? and user_id =?', team.id, user.id])
#check if invited user is already in the team
if (team_member.size > 0)
flash[:notice] = "\"#{user.name}\" is already a member of team."
else
sent_invitation = Invitation.find(:all, :conditions => ['from_id = ? and to_id = ? and assignment_id = ? and reply_status = "W"', student.user_id, user.id, student.parent_id])
#check if the invited user is already invited (i.e. awaiting reply)
if sent_invitation.length == 0
@invitation = Invitation.new
@invitation.to_id = user.id
@invitation.from_id = student.user_id
@invitation.assignment_id = student.parent_id
@invitation.reply_status = 'W'
@invitation.save
else
flash[:notice] = "You have already sent an invitation to \"#{user.name}\"."
end
end
end
end
redirect_to :controller => 'student_team', :action => 'view', :id=> student.id
end
</pre>

'''After Refactor'''
<pre>
def create
user = User.find_by_name(params[:user][:name].strip)
team = AssignmentTeam.find_by_id(params[:team_id])
student = AssignmentParticipant.find(params[:student_id])
return unless current_user_id?(student.user_id)

#check if the invited user is valid
if !user
flash[:note] = "\"#{params[:user][:name].strip}\" does not exist. Please make sure the name entered is correct."
else
participant= AssignmentParticipant.first( :conditions => ['user_id =? and parent_id =?', user.id, student.parent_id])
#check if the user is a participant of the assignment
if !participant
flash[:note] = "\"#{params[:user][:name].strip}\" is not a participant of this assignment."
else
team_member = TeamsUser.all(:conditions => ['team_id =? and user_id =?', team.id, user.id])
#check if invited user is already in the team
if (team_member.size > 0)
flash[:note] = "\"#{user.name}\" is already a member of team."
else
#check if the invited user is already invited (i.e. awaiting reply)
if Invitation.is_invited?(student.user_id, user.id, student.parent_id)
@invitation = Invitation.new
@invitation.to_id = user.id
@invitation.from_id = student.user_id
@invitation.assignment_id = student.parent_id
@invitation.reply_status = 'W'
@invitation.save
else
flash[:note] = "You have already sent an invitation to \"#{user.name}\"."
end
end
end
end

update_join_team_request

redirect_to :controller => 'student_team', :action => 'view', :id=> student.id
end
</pre>

=== Accept Method ===

The theme that we went with for refactoring the accept method is “Skin Controller, Fat Model.” <ref> Best Practices [http://www.sitepoint.com/10-ruby-on-rails-best-practices/ "10 Ruby on Rails Best Practices"] </ref> We wanted to move much of the logistics out of the accept method letting models handle this while keeping the controller limited to being the interface between the view and model. Before accept method was refactored it was very dense and contained too much functionality. The accept method was in the invitation controller was performing much of the invitation logic that should have been handled in the invitation model and various other models throughout the application. The accept method also played many different roles in that not only was it handling items that the model was responsible for but it was performing many different operations. There are many actions that need to take place when a user accepts an invitation and the controller method was taking care of all of these things. We began to eliminate these issues by extracting smaller operations that the accept method was handling into various methods and moving this code into various models such as the invitation.rb, signed_up_user.rb and team_user.rb.

<pre>
old_entry = TeamsUser.find(:first, :conditions => ['user_id = ? and team_id = ?', student.user_id, params[:team_id]])
if old_entry != nil
old_entry.destroy
end
</pre>

<pre>
TeamsUser.remove_previous_team(student.user_id, params[:team_id])
</pre>

<pre>
'''teams_user.rb'''

def self.remove_previous_team(user_id, team_id)
old_entry = TeamsUser.find(:first, :conditions => ['user_id = ? and team_id = ?', user_id, team_id])
if old_entry != nil
old_entry.destroy
end
end
</pre>

The accept method within the controller had too much functionality. We first moved much of the functionality within the accept method to a model accept method which purpose is to make sure that all items that need to be taken care of upon a method accept are in fact handled. Just moving this code to the model did not solve the issue of complexity. We created smaller methods to handle individual changes that needed to be taken care of for example upon an accept the users topic must be updated, the topics they are waitlisted for must be dropped, amongst many other things. We took these smaller changes that needed to be made and moved them into separate methods amongst various models like signed_up_user.rb and teams_user.rb. We also noticed that some variable names did not do a good job of describing their focus so we changed these variable names to increase readability. After our refactoring the accept method is much smaller and much more readable.<ref> Coding Conventions [http://www.slideshare.net/davidpaluy/ruby-on-rails-coding-conventions-standards-and-best-practices "Ruby On Rails coding conventions, standards and best practices"] </ref>

'''Before Refactor'''
<pre>
def accept
@inv = Invitation.find(params[:inv_id])
@inv.reply_status = 'A'
@inv.save

student = Participant.find(params[:student_id])

#if you are on a team and you accept another invitation, remove your previous entry in the teams_users table.
old_entry = TeamsUser.find(:first, :conditions => ['user_id = ? and team_id = ?', student.user_id, params[:team_id]])
if old_entry != nil
old_entry.destroy
end

#if you are on a team and you accept another invitation and if your old team does not have any members, delete the entry for the team
other_members = TeamsUser.find(:all, :conditions => ['team_id = ?', params[:team_id]])
if other_members.nil? || other_members.length == 0
old_team = AssignmentTeam.find(:first, :conditions => ['id = ?', params[:team_id]])
if old_team != nil
old_team.destroy
end

#if a signup sheet exists then release all the topics selected by this team into the pool.
old_teams_signups = SignedUpUser.find_all_by_creator_id(params[:team_id])
if !old_teams_signups.nil?
for old_teams_signup in old_teams_signups
if old_teams_signup.is_waitlisted == false # i.e., if the old team was occupying a slot, & thus is releasing a slot ...
first_waitlisted_signup = SignedUpUser.find_by_topic_id_and_is_waitlisted(old_teams_signup.topic_id, true)
if !first_waitlisted_signup.nil?
#As this user is going to be allocated a confirmed topic, all of his waitlisted topic signups should be purged
first_waitlisted_signup.is_waitlisted = false
first_waitlisted_signup.save

#Also update the participant table. But first_waitlisted_signup.creator_id is the team id
#so find one of the users on the team because the update_topic_id function in participant
#will take care of updating all the participants on the team
user_id = TeamsUser.find(:first, :conditions => {:team_id => first_waitlisted_signup.creator_id}).user_id
participant = Participant.find_by_user_id_and_parent_id(user_id,old_team.assignment.id)
participant.update_topic_id(old_teams_signup.topic_id)

SignUpTopic.cancel_all_waitlists(first_waitlisted_signup.creator_id, SignUpTopic.find(old_teams_signup.topic_id)['assignment_id'])
end # if !first_waitlisted_signup.nil
# Remove the now-empty team from the slot it is occupying.
end # if old_teams_signup.is_waitlisted == false
old_teams_signup.destroy
end
end
end
</pre>

'''After Refactor'''
<pre>
def accept
@inv = Invitation.find(params[:inv_id])
@inv.reply_status = 'A'
@inv.save

invited_user_id = Participant.find(params[:student_id]).user_id

#Remove the users previous team since they are accepting an invite for possibly a new team.
TeamsUser.remove_team(invited_user_id, params[:team_id])
#Accept the invite and return boolean on whether the add was successful
add_successful = Invitation.accept_invite(params[:team_id], @inv.from_id, @inv.to_id)
#If add wasn't successful because team was full display message
unless add_successful
flash[:error]= "The team already has the maximum number of members."
end

redirect_to :controller => 'student_team', :action => 'view', :id => Participant.find(params[:student_id]).id
end
</pre>

== Bug Fixes ==

=== Invite Requests ===
==== Problem Description ====

When a particular user responds to a advertisement sent out by another user(advertiser), a new Request invitation is created which is displayed in the advertiser's received request section of the team page as shown below:

When the advertiser clicks on the invite, the corresponding received request should be removed from the received requests list and the request sender should see the status as accepted when he logs in again as shown below:

Complete steps to reproduce the bug fix:
<pre>
1)login as admin with password"pass"

2) create new course and an assignment within the course
set all the properties appropriately-
set the assignment as a team assignment
set the deadlines properly.
3) add 2 participants(user1 and user2) to the assignment(users need to be created who act as participants)
4) create a topic within the assignment
5) login as user1 and select the topic in the signup sheet
6) create an advertisement in the your team link of the assignments
7) Now login as user2 and click on signupsheet.You should see an advertisement sent out by user1.
8) click on the advertise link and request an invitation.
9) Login as user1 again and go to the your team link.
10) user1 should see the the invitation request in the received requests with the invite and decline button next to it.
11)when user1 clicks on the invite button, the request invitation should be removed and when user2 logs in again , he should see the sent request as accepted
</pre>

=== Error Messages ===

== Future Work ==

= References =
<references/>

File:Receivercmh.jpg

2013-10-29T21:36:40Z

Mrsreena: uploaded a new version of "File:Receivercmh.jpg"

File:Receivercmh.jpg

2013-10-29T21:35:54Z

Mrsreena:

File:Receivercmh.png

2013-10-29T21:34:03Z

Mrsreena:

CSC/ECE 517 Fall 2013/oss cmh

2013-10-29T21:21:46Z

Mrsreena:

CSC/ECE 517 Fall 2013/ch1 1w43 sm

2013-10-07T20:51:26Z

Mrsreena: /* Squeel */

=Object Relational Mapping=

__TOC__

=Introduction=

[http://en.wikipedia.org/wiki/Object-relational_mapping Object-relational mapping (ORM)], or ORM, is a programming technique which associates data stored in a relational database with application objects. The ORM layer populates business objects on demand and persists them back into the relational database when updated.
ORM basically creates 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.In this wiki, we concenterate mainly on the top Ruby ORM's like Active Record,Sequel and DataMapper.Also, it includes a comparison of various ORM techniques and the advantages and disadvantages of various styles of ORM mapping.

=Need For ORM=
Need for ORM arose due to a major problem called the Object-Relational Impedance MisMatch Problem.
[http://en.wikipedia.org/wiki/Object-relational_impedance_mismatch Object-Relational Impedance MisMatch Problem] is a set of conceptual and technical difficulties, encountered when a relational database management system (RDBMS) is being used by an object-oriented program particularly when object/class definitions are mapped directly to database tables or schema.It implies that object models don't work together with relational models, i.e RDBMS represents data in tabular format while Object oriented languages represent data in the form of interconnected graph of objects.
The Mismatches that occur in Object-Oriented concepts are as follows:
*Encapsulation:
Mapping of private object representation to database tables is difficult due to availability of fewer constraints for the design of private representation as opposed to public data in RDBMS.
*Interface, Class, Inheritance and polymorphism:
Under an object-oriented paradigm, objects have interfaces that together provide the only access to the internals of that object. The relational model, on the other hand, utilizes derived relation variables (views) to provide varying perspectives and constraints to ensure integrity. Similarly, essential OOP concepts for classes of objects, inheritance and polymorphism are not supported by relational database systems.
*Identity:
RDBMS defines exactly one notion of 'sameness': the primary key. However, Object-oriented languages, for example Java, defines both object identity (a==b) and object equality (a.equals(b)).
*Associations:
Associations are represented as unidirectional references in Object Oriented languages whereas RDBMS uses the notion of foreign keys. For example, If you need bidirectional relationships in Java, you must define the association twice.Likewise, you cannot determine the multiplicity of a relationship by looking at the object domain model.
*Data navigation:
The way you access data in object-oriented languages is fundamentally different than the way you do it in a relational database. Like in Java, you navigate from one association to another walking the object network. This is not an efficient way of retrieving data from a relational database. You typically want to minimize the number of SQL queries and thus load several entities via JOINs and select the targeted entities before you start walking the object network.

=Overview=

Data management tasks in object-oriented (OO) programming are typically implemented by manipulating objects that are almost always non-scalar values. Like for example, Consider a Geometric object, an entity which can have shape and color.In the object oriented implementation, this entity would be modeled as a geometric object with shape and color as its attributes.Shape itself can contain objects like for triangles(equilateral or isosceles) and so on.Here each geometric object can be treated as a single object by any programming language and its attributes can be also accessed by various object methods.However, many popular database products such as structured query language database management systems (SQL DBMS) can only store and manipulate scalar values such as integers and strings organized within tables.

Hence, the programmer must either convert the object values into groups of simpler values for storage in the database (and convert them back upon retrieval), or only use simple scalar values within the program. Object-relational mapping is used to implement the first approach.The key is to translate the logical representation of the objects into an atomized form that is capable of being stored in the database, while somehow preserving the properties of the objects and their relationships so that they can be reloaded as an object whenever required. If this storage and retrieval functionality is implemented, the objects are then said to be persistent.

Object-Relational Mapping, commonly referred to as its abbreviation ORM, is a technique that connects the rich objects of an application to tables in a relational database management system. Using ORM, the properties and relationships of the objects in an application can be easily stored and retrieved from a database without writing SQL statements directly and with less overall database access code.

=Features=

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 makes access to database through the application extremely easy, as it provides connection from model of the program to the database.Treating database rows as objects, Program can easily access the information in more consistent manner.Also it gives flexibility to the programmers to manipulate the data with the language itself rather than working on the attributes retrieved from the database.

When applied to Ruby, implementations of ORM often leverage the language’s Meta-programming 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 needs to be extracted from the model and the database, and 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.

=Active Record=
[http://ar.rubyonrails.org/ ActiveRecord] insulates you from the need to use raw SQL to find database records.Active Record facilitates the creation and use of business objects whose data requires persistent storage to a database.

ActiveRecord is the default ‘model’ component of the model-view-controller web-application framework Ruby on Rails, and is also a stand-alone ORM package for other Ruby applications. In both forms, it was conceived of by David Heinemeier Hansson, and has been improved upon by a number of contributors.

Other, less popular ORMs have been released since ActiveRecord first took the stage. For example, DataMapper and Sequel show major improvements over the original ActiveRecord framework.[neutrality is disputed] As a response to their release and adoption by the Rails community, Ruby on Rails v3.0 is independent of an ORM system, so Rails users can easily plug in DataMapper or Sequel to use as their ORM of choice.

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>

Note in the preceding example, that 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 whose 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]]

Active Record will perform queries on the database for you and is compatible with most database systems (MySQL, PostgreSQL and SQLite to name a few). Regardless of which database system you are using, the ActiveRecord method format will always be the same.
To retrieve objects from the database, Active Record provides several finder methods. Each finder method allows you to pass arguments into it to perform certain queries on your database without writing raw SQL.

'''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.

=Sequel=
[http://sequel.rubyforge.org Sequel] is designed to take the hassle away from connecting to databases and manipulating them. Sequel deals with all the boring stuff like maintaining connections, formatting SQL correctly and fetching records so you can concentrate on your application.
Sequel uses the concept of datasets to retrieve data. A Dataset object encapsulates an SQL query and supports chainability, letting you fetch data using a convenient Ruby DSL that is both concise and flexible.The current sequel version is 4.2.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.

Sequel::Model is an object relational mapper built on top of Sequel core. Each model class is backed by a dataset instance, and many dataset methods can be called directly on the class. Model datasets return rows as model instances, which have fairly standard ORM instance behavior.

Sequel::Model is built completely out of plugins. Plugins can override any class, instance, or dataset method defined by a previous plugin and call super to get the default behavior

'''Features''' -
*Sequel provides thread safety, connection pooling and a concise DSL for constructing SQL *queries and table schemas.
*Sequel includes a comprehensive ORM layer for mapping records to Ruby objects and handling associated records.
*Sequel supports advanced database features such as prepared statements, bound variables, stored procedures, savepoints, two-phase commit, transaction isolation, master/slave configurations, and database sharding.
*Sequel currently has adapters for ADO, Amalgalite, CUBRID, DataObjects, DB2, DBI, Firebird, IBM_DB, Informix, JDBC, MySQL, Mysql2, ODBC, OpenBase, Oracle, PostgreSQL, SQLite3, Swift, and TinyTDS.

<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 ActiveRecord. 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.

=DataMapper=
[http://datamapper.org/why.html DataMapper] is an Object Relational Mapper written in Ruby. The goal is to create an ORM which is fast, thread-safe and feature rich.
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 even some popular web-services.

'''Features'''-
*Eager loading of child associations to avoid (N+1) queries.
*Lazy loading of select properties, e.g., larger fields.
*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,Apache Solr and web services such as 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.

=Squeel=
[http://rubydoc.info/gems/squeel/1.1.1/frames Squeel] unlocks the power of Arel in your Rails 3 application with a handy block-based syntax. You can write subqueries, access named functions provided by your RDBMS, and more, all without writing SQL strings. Squeel acts as an add on to Active Record and makes it easier to write queries with fewer strings.
A simple example is as follows:
Squeel lets you rewrite
<pre>
Article.where ['created_at >= ?', 2.weeks.ago]
</pre>
as
<pre>
Article.where{created_at >= 2.weeks.ago}
</pre>

=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. Follows below a MyBatis mapper, that consist on 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>

=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
|}

=NonSQL databases=
Instead of ORM we can also use 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 user from retrieving 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 in XML file.

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

=Advantages of ORM=

*Facilitates implementing the Domain Model pattern that allows you to model entities based on real business concepts rather than based on our database structure. ORM tools provide this functionality through mapping between the logical business model and the physical storage model.

*Huge reduction in code. Ease of use, faster development, increased productivity.

*ORM tools provide a host of services thereby allowing developers to focus on the business logic of the application rather than repetitive CRUD (Create Read Update Delete) logic.

*Changes to the object model are made in one place. One you update your object definitions, the ORM will automatically use the updated structure for retrievals and updates. There are no SQL Update, Delete and Insert statements strewn throughout different layers of the application that need modification.

*Rich query capability. ORM tools provide an object oriented query language. This allows application developers to focus on the object model and not to have to be concerned with the database structure or SQL semantics. The ORM tool itself will translate the query language into the appropriate syntax for the database.

*Navigation. You can navigate object relationships transparently. Related objects are automatically loaded as needed. For example if you load a Post and you want to access it's Comment, you can simply access Post.Comment and the ORM will take care of loading the data for you without any effort on your part.

*Data loads are completely configurable allowing you to load the data appropriate for each scenario. For example in one scenario you might want to load a list of objects without any of it's child / related objects, while in other scenarios you can specify to load an object, with all it's children etc.

*Concurrency support. Support for multiple users updating the same data simultaneously.

*Cache management. Entities are cached in memory thereby reducing load on the database.

*Transaction management and Isolation. All object changes occur scoped to a transaction. The entire transaction can either be committed or rolled back. Multiple transactions can be active in memory in the same time, and each transactions changes are isolated form on another.

*Making data access more abstract and portable. ORM implementation classes know how to write vendor-specific SQL, so you don't have to.

=Disadvantages of ORM=

*High level of abstraction obscures as to what is actually happening in the code implementation.
*Loss in developer productivity whilst they learn to program with ORM.Developers lose understanding of what the code is actually doing - the developer is more in control using SQL.
*Heavy reliance on ORM also leads to poorly designed databases.
*Data and behaviour are not separated.
**Façade needs to be built if the data model is to be made available in a distributed architecture.
**Each ORM technology/product has a different set of APIs and porting code between them is not easy.
*The biggest advantage of ORM is also the biggest disadvantage: queries are generated automatically -
**Queries can’t be optimized.
**Queries select more data than needed, things get slower, more latency.
**Compiling queries from ORM code is slow (ORM compiler written in PHP).
**SQL is more powerful than ORM query languages.
**Database abstraction forbids vendor specific optimizations.

=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_Fall_2010/ch3_3j_KS Object-relational mapping Fall 2010] 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.Also, a detailed study of alternatives to ORM like the NoSQL databases and Document-oriented approach can be included.
=References=

# [http://en.wikipedia.org/wiki/Object-relational_mapping Wikipedia, Object-relational mapping (ORM)]
# [http://docforge.com/wiki/Object-relational_mapping Object-relational mapping]
# [http://en.wikipedia.org/wiki/Object-relational_impedance_mismatch Object-Relational Impedance Matching Problem]
# [http://www.hibernate.org/about/orm The Object-Relational Impedance Mismatch]
# [http://edgeguides.rubyonrails.org/active_record_basics.html#object-relational-mapping Active Record]
# [http://loianegroner.com/2011/02/introduction-to-ibatis-mybatis-an-alternative-to-hibernate-and-jdbc/ MyBatis/iBatis]

CSC/ECE 517 Fall 2013/ch1 1w43 sm

2013-10-07T20:51:02Z

Mrsreena: /* References */

=Object Relational Mapping=

__TOC__

=Introduction=

[http://en.wikipedia.org/wiki/Object-relational_mapping Object-relational mapping (ORM)], or ORM, is a programming technique which associates data stored in a relational database with application objects. The ORM layer populates business objects on demand and persists them back into the relational database when updated.
ORM basically creates 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.In this wiki, we concenterate mainly on the top Ruby ORM's like Active Record,Sequel and DataMapper.Also, it includes a comparison of various ORM techniques and the advantages and disadvantages of various styles of ORM mapping.

=Need For ORM=
Need for ORM arose due to a major problem called the Object-Relational Impedance MisMatch Problem.
[http://en.wikipedia.org/wiki/Object-relational_impedance_mismatch Object-Relational Impedance MisMatch Problem] is a set of conceptual and technical difficulties, encountered when a relational database management system (RDBMS) is being used by an object-oriented program particularly when object/class definitions are mapped directly to database tables or schema.It implies that object models don't work together with relational models, i.e RDBMS represents data in tabular format while Object oriented languages represent data in the form of interconnected graph of objects.
The Mismatches that occur in Object-Oriented concepts are as follows:
*Encapsulation:
Mapping of private object representation to database tables is difficult due to availability of fewer constraints for the design of private representation as opposed to public data in RDBMS.
*Interface, Class, Inheritance and polymorphism:
Under an object-oriented paradigm, objects have interfaces that together provide the only access to the internals of that object. The relational model, on the other hand, utilizes derived relation variables (views) to provide varying perspectives and constraints to ensure integrity. Similarly, essential OOP concepts for classes of objects, inheritance and polymorphism are not supported by relational database systems.
*Identity:
RDBMS defines exactly one notion of 'sameness': the primary key. However, Object-oriented languages, for example Java, defines both object identity (a==b) and object equality (a.equals(b)).
*Associations:
Associations are represented as unidirectional references in Object Oriented languages whereas RDBMS uses the notion of foreign keys. For example, If you need bidirectional relationships in Java, you must define the association twice.Likewise, you cannot determine the multiplicity of a relationship by looking at the object domain model.
*Data navigation:
The way you access data in object-oriented languages is fundamentally different than the way you do it in a relational database. Like in Java, you navigate from one association to another walking the object network. This is not an efficient way of retrieving data from a relational database. You typically want to minimize the number of SQL queries and thus load several entities via JOINs and select the targeted entities before you start walking the object network.

=Overview=

Data management tasks in object-oriented (OO) programming are typically implemented by manipulating objects that are almost always non-scalar values. Like for example, Consider a Geometric object, an entity which can have shape and color.In the object oriented implementation, this entity would be modeled as a geometric object with shape and color as its attributes.Shape itself can contain objects like for triangles(equilateral or isosceles) and so on.Here each geometric object can be treated as a single object by any programming language and its attributes can be also accessed by various object methods.However, many popular database products such as structured query language database management systems (SQL DBMS) can only store and manipulate scalar values such as integers and strings organized within tables.

Hence, the programmer must either convert the object values into groups of simpler values for storage in the database (and convert them back upon retrieval), or only use simple scalar values within the program. Object-relational mapping is used to implement the first approach.The key is to translate the logical representation of the objects into an atomized form that is capable of being stored in the database, while somehow preserving the properties of the objects and their relationships so that they can be reloaded as an object whenever required. If this storage and retrieval functionality is implemented, the objects are then said to be persistent.

Object-Relational Mapping, commonly referred to as its abbreviation ORM, is a technique that connects the rich objects of an application to tables in a relational database management system. Using ORM, the properties and relationships of the objects in an application can be easily stored and retrieved from a database without writing SQL statements directly and with less overall database access code.

=Features=

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 makes access to database through the application extremely easy, as it provides connection from model of the program to the database.Treating database rows as objects, Program can easily access the information in more consistent manner.Also it gives flexibility to the programmers to manipulate the data with the language itself rather than working on the attributes retrieved from the database.

When applied to Ruby, implementations of ORM often leverage the language’s Meta-programming 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 needs to be extracted from the model and the database, and 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.

=Active Record=
[http://ar.rubyonrails.org/ ActiveRecord] insulates you from the need to use raw SQL to find database records.Active Record facilitates the creation and use of business objects whose data requires persistent storage to a database.

ActiveRecord is the default ‘model’ component of the model-view-controller web-application framework Ruby on Rails, and is also a stand-alone ORM package for other Ruby applications. In both forms, it was conceived of by David Heinemeier Hansson, and has been improved upon by a number of contributors.

Other, less popular ORMs have been released since ActiveRecord first took the stage. For example, DataMapper and Sequel show major improvements over the original ActiveRecord framework.[neutrality is disputed] As a response to their release and adoption by the Rails community, Ruby on Rails v3.0 is independent of an ORM system, so Rails users can easily plug in DataMapper or Sequel to use as their ORM of choice.

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>

Note in the preceding example, that 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 whose 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]]

Active Record will perform queries on the database for you and is compatible with most database systems (MySQL, PostgreSQL and SQLite to name a few). Regardless of which database system you are using, the ActiveRecord method format will always be the same.
To retrieve objects from the database, Active Record provides several finder methods. Each finder method allows you to pass arguments into it to perform certain queries on your database without writing raw SQL.

'''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.

=Sequel=
[http://sequel.rubyforge.org Sequel] is designed to take the hassle away from connecting to databases and manipulating them. Sequel deals with all the boring stuff like maintaining connections, formatting SQL correctly and fetching records so you can concentrate on your application.
Sequel uses the concept of datasets to retrieve data. A Dataset object encapsulates an SQL query and supports chainability, letting you fetch data using a convenient Ruby DSL that is both concise and flexible.The current sequel version is 4.2.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.

Sequel::Model is an object relational mapper built on top of Sequel core. Each model class is backed by a dataset instance, and many dataset methods can be called directly on the class. Model datasets return rows as model instances, which have fairly standard ORM instance behavior.

Sequel::Model is built completely out of plugins. Plugins can override any class, instance, or dataset method defined by a previous plugin and call super to get the default behavior

'''Features''' -
*Sequel provides thread safety, connection pooling and a concise DSL for constructing SQL *queries and table schemas.
*Sequel includes a comprehensive ORM layer for mapping records to Ruby objects and handling associated records.
*Sequel supports advanced database features such as prepared statements, bound variables, stored procedures, savepoints, two-phase commit, transaction isolation, master/slave configurations, and database sharding.
*Sequel currently has adapters for ADO, Amalgalite, CUBRID, DataObjects, DB2, DBI, Firebird, IBM_DB, Informix, JDBC, MySQL, Mysql2, ODBC, OpenBase, Oracle, PostgreSQL, SQLite3, Swift, and TinyTDS.

<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 ActiveRecord. 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.

=DataMapper=
[http://datamapper.org/why.html DataMapper] is an Object Relational Mapper written in Ruby. The goal is to create an ORM which is fast, thread-safe and feature rich.
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 even some popular web-services.

'''Features'''-
*Eager loading of child associations to avoid (N+1) queries.
*Lazy loading of select properties, e.g., larger fields.
*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,Apache Solr and web services such as 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.

=Squeel=
[https://www.ruby-toolbox.com/categories/orm Squeel] unlocks the power of Arel in your Rails 3 application with a handy block-based syntax. You can write subqueries, access named functions provided by your RDBMS, and more, all without writing SQL strings. Squeel acts as an add on to Active Record and makes it easier to write queries with fewer strings.
A simple example is as follows:
Squeel lets you rewrite
<pre>
Article.where ['created_at >= ?', 2.weeks.ago]
</pre>
as
<pre>
Article.where{created_at >= 2.weeks.ago}
</pre>

=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. Follows below a MyBatis mapper, that consist on 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>

=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
|}

=NonSQL databases=
Instead of ORM we can also use 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 user from retrieving 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 in XML file.

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

=Advantages of ORM=

*Facilitates implementing the Domain Model pattern that allows you to model entities based on real business concepts rather than based on our database structure. ORM tools provide this functionality through mapping between the logical business model and the physical storage model.

*Huge reduction in code. Ease of use, faster development, increased productivity.

*ORM tools provide a host of services thereby allowing developers to focus on the business logic of the application rather than repetitive CRUD (Create Read Update Delete) logic.

*Changes to the object model are made in one place. One you update your object definitions, the ORM will automatically use the updated structure for retrievals and updates. There are no SQL Update, Delete and Insert statements strewn throughout different layers of the application that need modification.

*Rich query capability. ORM tools provide an object oriented query language. This allows application developers to focus on the object model and not to have to be concerned with the database structure or SQL semantics. The ORM tool itself will translate the query language into the appropriate syntax for the database.

*Navigation. You can navigate object relationships transparently. Related objects are automatically loaded as needed. For example if you load a Post and you want to access it's Comment, you can simply access Post.Comment and the ORM will take care of loading the data for you without any effort on your part.

*Data loads are completely configurable allowing you to load the data appropriate for each scenario. For example in one scenario you might want to load a list of objects without any of it's child / related objects, while in other scenarios you can specify to load an object, with all it's children etc.

*Concurrency support. Support for multiple users updating the same data simultaneously.

*Cache management. Entities are cached in memory thereby reducing load on the database.

*Transaction management and Isolation. All object changes occur scoped to a transaction. The entire transaction can either be committed or rolled back. Multiple transactions can be active in memory in the same time, and each transactions changes are isolated form on another.

*Making data access more abstract and portable. ORM implementation classes know how to write vendor-specific SQL, so you don't have to.

=Disadvantages of ORM=

*High level of abstraction obscures as to what is actually happening in the code implementation.
*Loss in developer productivity whilst they learn to program with ORM.Developers lose understanding of what the code is actually doing - the developer is more in control using SQL.
*Heavy reliance on ORM also leads to poorly designed databases.
*Data and behaviour are not separated.
**Façade needs to be built if the data model is to be made available in a distributed architecture.
**Each ORM technology/product has a different set of APIs and porting code between them is not easy.
*The biggest advantage of ORM is also the biggest disadvantage: queries are generated automatically -
**Queries can’t be optimized.
**Queries select more data than needed, things get slower, more latency.
**Compiling queries from ORM code is slow (ORM compiler written in PHP).
**SQL is more powerful than ORM query languages.
**Database abstraction forbids vendor specific optimizations.

=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_Fall_2010/ch3_3j_KS Object-relational mapping Fall 2010] 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.Also, a detailed study of alternatives to ORM like the NoSQL databases and Document-oriented approach can be included.
=References=

# [http://en.wikipedia.org/wiki/Object-relational_mapping Wikipedia, Object-relational mapping (ORM)]
# [http://docforge.com/wiki/Object-relational_mapping Object-relational mapping]
# [http://en.wikipedia.org/wiki/Object-relational_impedance_mismatch Object-Relational Impedance Matching Problem]
# [http://www.hibernate.org/about/orm The Object-Relational Impedance Mismatch]
# [http://edgeguides.rubyonrails.org/active_record_basics.html#object-relational-mapping Active Record]
# [http://loianegroner.com/2011/02/introduction-to-ibatis-mybatis-an-alternative-to-hibernate-and-jdbc/ MyBatis/iBatis]

CSC/ECE 517 Fall 2013/ch1 1w43 sm

2013-10-07T20:49:28Z

Mrsreena: /* Active Record */

=Object Relational Mapping=

__TOC__

=Introduction=

[http://en.wikipedia.org/wiki/Object-relational_mapping Object-relational mapping (ORM)], or ORM, is a programming technique which associates data stored in a relational database with application objects. The ORM layer populates business objects on demand and persists them back into the relational database when updated.
ORM basically creates 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.In this wiki, we concenterate mainly on the top Ruby ORM's like Active Record,Sequel and DataMapper.Also, it includes a comparison of various ORM techniques and the advantages and disadvantages of various styles of ORM mapping.

=Need For ORM=
Need for ORM arose due to a major problem called the Object-Relational Impedance MisMatch Problem.
[http://en.wikipedia.org/wiki/Object-relational_impedance_mismatch Object-Relational Impedance MisMatch Problem] is a set of conceptual and technical difficulties, encountered when a relational database management system (RDBMS) is being used by an object-oriented program particularly when object/class definitions are mapped directly to database tables or schema.It implies that object models don't work together with relational models, i.e RDBMS represents data in tabular format while Object oriented languages represent data in the form of interconnected graph of objects.
The Mismatches that occur in Object-Oriented concepts are as follows:
*Encapsulation:
Mapping of private object representation to database tables is difficult due to availability of fewer constraints for the design of private representation as opposed to public data in RDBMS.
*Interface, Class, Inheritance and polymorphism:
Under an object-oriented paradigm, objects have interfaces that together provide the only access to the internals of that object. The relational model, on the other hand, utilizes derived relation variables (views) to provide varying perspectives and constraints to ensure integrity. Similarly, essential OOP concepts for classes of objects, inheritance and polymorphism are not supported by relational database systems.
*Identity:
RDBMS defines exactly one notion of 'sameness': the primary key. However, Object-oriented languages, for example Java, defines both object identity (a==b) and object equality (a.equals(b)).
*Associations:
Associations are represented as unidirectional references in Object Oriented languages whereas RDBMS uses the notion of foreign keys. For example, If you need bidirectional relationships in Java, you must define the association twice.Likewise, you cannot determine the multiplicity of a relationship by looking at the object domain model.
*Data navigation:
The way you access data in object-oriented languages is fundamentally different than the way you do it in a relational database. Like in Java, you navigate from one association to another walking the object network. This is not an efficient way of retrieving data from a relational database. You typically want to minimize the number of SQL queries and thus load several entities via JOINs and select the targeted entities before you start walking the object network.

=Overview=

Data management tasks in object-oriented (OO) programming are typically implemented by manipulating objects that are almost always non-scalar values. Like for example, Consider a Geometric object, an entity which can have shape and color.In the object oriented implementation, this entity would be modeled as a geometric object with shape and color as its attributes.Shape itself can contain objects like for triangles(equilateral or isosceles) and so on.Here each geometric object can be treated as a single object by any programming language and its attributes can be also accessed by various object methods.However, many popular database products such as structured query language database management systems (SQL DBMS) can only store and manipulate scalar values such as integers and strings organized within tables.

Hence, the programmer must either convert the object values into groups of simpler values for storage in the database (and convert them back upon retrieval), or only use simple scalar values within the program. Object-relational mapping is used to implement the first approach.The key is to translate the logical representation of the objects into an atomized form that is capable of being stored in the database, while somehow preserving the properties of the objects and their relationships so that they can be reloaded as an object whenever required. If this storage and retrieval functionality is implemented, the objects are then said to be persistent.

Object-Relational Mapping, commonly referred to as its abbreviation ORM, is a technique that connects the rich objects of an application to tables in a relational database management system. Using ORM, the properties and relationships of the objects in an application can be easily stored and retrieved from a database without writing SQL statements directly and with less overall database access code.

=Features=

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 makes access to database through the application extremely easy, as it provides connection from model of the program to the database.Treating database rows as objects, Program can easily access the information in more consistent manner.Also it gives flexibility to the programmers to manipulate the data with the language itself rather than working on the attributes retrieved from the database.

When applied to Ruby, implementations of ORM often leverage the language’s Meta-programming 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 needs to be extracted from the model and the database, and 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.

=Active Record=
[http://ar.rubyonrails.org/ ActiveRecord] insulates you from the need to use raw SQL to find database records.Active Record facilitates the creation and use of business objects whose data requires persistent storage to a database.

ActiveRecord is the default ‘model’ component of the model-view-controller web-application framework Ruby on Rails, and is also a stand-alone ORM package for other Ruby applications. In both forms, it was conceived of by David Heinemeier Hansson, and has been improved upon by a number of contributors.

Other, less popular ORMs have been released since ActiveRecord first took the stage. For example, DataMapper and Sequel show major improvements over the original ActiveRecord framework.[neutrality is disputed] As a response to their release and adoption by the Rails community, Ruby on Rails v3.0 is independent of an ORM system, so Rails users can easily plug in DataMapper or Sequel to use as their ORM of choice.

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>

Note in the preceding example, that 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 whose 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]]

Active Record will perform queries on the database for you and is compatible with most database systems (MySQL, PostgreSQL and SQLite to name a few). Regardless of which database system you are using, the ActiveRecord method format will always be the same.
To retrieve objects from the database, Active Record provides several finder methods. Each finder method allows you to pass arguments into it to perform certain queries on your database without writing raw SQL.

'''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.

=Sequel=
[http://sequel.rubyforge.org Sequel] is designed to take the hassle away from connecting to databases and manipulating them. Sequel deals with all the boring stuff like maintaining connections, formatting SQL correctly and fetching records so you can concentrate on your application.
Sequel uses the concept of datasets to retrieve data. A Dataset object encapsulates an SQL query and supports chainability, letting you fetch data using a convenient Ruby DSL that is both concise and flexible.The current sequel version is 4.2.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.

Sequel::Model is an object relational mapper built on top of Sequel core. Each model class is backed by a dataset instance, and many dataset methods can be called directly on the class. Model datasets return rows as model instances, which have fairly standard ORM instance behavior.

Sequel::Model is built completely out of plugins. Plugins can override any class, instance, or dataset method defined by a previous plugin and call super to get the default behavior

'''Features''' -
*Sequel provides thread safety, connection pooling and a concise DSL for constructing SQL *queries and table schemas.
*Sequel includes a comprehensive ORM layer for mapping records to Ruby objects and handling associated records.
*Sequel supports advanced database features such as prepared statements, bound variables, stored procedures, savepoints, two-phase commit, transaction isolation, master/slave configurations, and database sharding.
*Sequel currently has adapters for ADO, Amalgalite, CUBRID, DataObjects, DB2, DBI, Firebird, IBM_DB, Informix, JDBC, MySQL, Mysql2, ODBC, OpenBase, Oracle, PostgreSQL, SQLite3, Swift, and TinyTDS.

<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 ActiveRecord. 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.

=DataMapper=
[http://datamapper.org/why.html DataMapper] is an Object Relational Mapper written in Ruby. The goal is to create an ORM which is fast, thread-safe and feature rich.
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 even some popular web-services.

'''Features'''-
*Eager loading of child associations to avoid (N+1) queries.
*Lazy loading of select properties, e.g., larger fields.
*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,Apache Solr and web services such as 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.

=Squeel=
[https://www.ruby-toolbox.com/categories/orm Squeel] unlocks the power of Arel in your Rails 3 application with a handy block-based syntax. You can write subqueries, access named functions provided by your RDBMS, and more, all without writing SQL strings. Squeel acts as an add on to Active Record and makes it easier to write queries with fewer strings.
A simple example is as follows:
Squeel lets you rewrite
<pre>
Article.where ['created_at >= ?', 2.weeks.ago]
</pre>
as
<pre>
Article.where{created_at >= 2.weeks.ago}
</pre>

=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. Follows below a MyBatis mapper, that consist on 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>

=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
|}

=NonSQL databases=
Instead of ORM we can also use 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 user from retrieving 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 in XML file.

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

=Advantages of ORM=

*Facilitates implementing the Domain Model pattern that allows you to model entities based on real business concepts rather than based on our database structure. ORM tools provide this functionality through mapping between the logical business model and the physical storage model.

*Huge reduction in code. Ease of use, faster development, increased productivity.

*ORM tools provide a host of services thereby allowing developers to focus on the business logic of the application rather than repetitive CRUD (Create Read Update Delete) logic.

*Changes to the object model are made in one place. One you update your object definitions, the ORM will automatically use the updated structure for retrievals and updates. There are no SQL Update, Delete and Insert statements strewn throughout different layers of the application that need modification.

*Rich query capability. ORM tools provide an object oriented query language. This allows application developers to focus on the object model and not to have to be concerned with the database structure or SQL semantics. The ORM tool itself will translate the query language into the appropriate syntax for the database.

*Navigation. You can navigate object relationships transparently. Related objects are automatically loaded as needed. For example if you load a Post and you want to access it's Comment, you can simply access Post.Comment and the ORM will take care of loading the data for you without any effort on your part.

*Data loads are completely configurable allowing you to load the data appropriate for each scenario. For example in one scenario you might want to load a list of objects without any of it's child / related objects, while in other scenarios you can specify to load an object, with all it's children etc.

*Concurrency support. Support for multiple users updating the same data simultaneously.

*Cache management. Entities are cached in memory thereby reducing load on the database.

*Transaction management and Isolation. All object changes occur scoped to a transaction. The entire transaction can either be committed or rolled back. Multiple transactions can be active in memory in the same time, and each transactions changes are isolated form on another.

*Making data access more abstract and portable. ORM implementation classes know how to write vendor-specific SQL, so you don't have to.

=Disadvantages of ORM=

*High level of abstraction obscures as to what is actually happening in the code implementation.
*Loss in developer productivity whilst they learn to program with ORM.Developers lose understanding of what the code is actually doing - the developer is more in control using SQL.
*Heavy reliance on ORM also leads to poorly designed databases.
*Data and behaviour are not separated.
**Façade needs to be built if the data model is to be made available in a distributed architecture.
**Each ORM technology/product has a different set of APIs and porting code between them is not easy.
*The biggest advantage of ORM is also the biggest disadvantage: queries are generated automatically -
**Queries can’t be optimized.
**Queries select more data than needed, things get slower, more latency.
**Compiling queries from ORM code is slow (ORM compiler written in PHP).
**SQL is more powerful than ORM query languages.
**Database abstraction forbids vendor specific optimizations.

=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_Fall_2010/ch3_3j_KS Object-relational mapping Fall 2010] 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.Also, a detailed study of alternatives to ORM like the NoSQL databases and Document-oriented approach can be included.
=References=

# [http://en.wikipedia.org/wiki/Object-relational_mapping Wikipedia, Object-relational mapping (ORM)]
# [http://docforge.com/wiki/Object-relational_mapping Object-relational mapping]
# [http://en.wikipedia.org/wiki/Object-relational_impedance_mismatch Object-Relational Impedance Matching Problem]
# [http://www.hibernate.org/about/orm The Object-Relational Impedance Mismatch]
# [http://edgeguides.rubyonrails.org/active_record_basics.html#object-relational-mapping Active Record]
# [http://loianegroner.com/2011/02/introduction-to-ibatis-mybatis-an-alternative-to-hibernate-and-jdbc/ MyBatis/iBatis]
# [http://rubydoc.info/gems/squeel/1.1.1/frames Squeel]

CSC/ECE 517 Fall 2013/ch1 1w43 sm

2013-10-07T20:48:27Z

Mrsreena: /* DataMapper */

=Object Relational Mapping=

__TOC__

=Introduction=

[http://en.wikipedia.org/wiki/Object-relational_mapping Object-relational mapping (ORM)], or ORM, is a programming technique which associates data stored in a relational database with application objects. The ORM layer populates business objects on demand and persists them back into the relational database when updated.
ORM basically creates 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.In this wiki, we concenterate mainly on the top Ruby ORM's like Active Record,Sequel and DataMapper.Also, it includes a comparison of various ORM techniques and the advantages and disadvantages of various styles of ORM mapping.

=Need For ORM=
Need for ORM arose due to a major problem called the Object-Relational Impedance MisMatch Problem.
[http://en.wikipedia.org/wiki/Object-relational_impedance_mismatch Object-Relational Impedance MisMatch Problem] is a set of conceptual and technical difficulties, encountered when a relational database management system (RDBMS) is being used by an object-oriented program particularly when object/class definitions are mapped directly to database tables or schema.It implies that object models don't work together with relational models, i.e RDBMS represents data in tabular format while Object oriented languages represent data in the form of interconnected graph of objects.
The Mismatches that occur in Object-Oriented concepts are as follows:
*Encapsulation:
Mapping of private object representation to database tables is difficult due to availability of fewer constraints for the design of private representation as opposed to public data in RDBMS.
*Interface, Class, Inheritance and polymorphism:
Under an object-oriented paradigm, objects have interfaces that together provide the only access to the internals of that object. The relational model, on the other hand, utilizes derived relation variables (views) to provide varying perspectives and constraints to ensure integrity. Similarly, essential OOP concepts for classes of objects, inheritance and polymorphism are not supported by relational database systems.
*Identity:
RDBMS defines exactly one notion of 'sameness': the primary key. However, Object-oriented languages, for example Java, defines both object identity (a==b) and object equality (a.equals(b)).
*Associations:
Associations are represented as unidirectional references in Object Oriented languages whereas RDBMS uses the notion of foreign keys. For example, If you need bidirectional relationships in Java, you must define the association twice.Likewise, you cannot determine the multiplicity of a relationship by looking at the object domain model.
*Data navigation:
The way you access data in object-oriented languages is fundamentally different than the way you do it in a relational database. Like in Java, you navigate from one association to another walking the object network. This is not an efficient way of retrieving data from a relational database. You typically want to minimize the number of SQL queries and thus load several entities via JOINs and select the targeted entities before you start walking the object network.

=Overview=

Data management tasks in object-oriented (OO) programming are typically implemented by manipulating objects that are almost always non-scalar values. Like for example, Consider a Geometric object, an entity which can have shape and color.In the object oriented implementation, this entity would be modeled as a geometric object with shape and color as its attributes.Shape itself can contain objects like for triangles(equilateral or isosceles) and so on.Here each geometric object can be treated as a single object by any programming language and its attributes can be also accessed by various object methods.However, many popular database products such as structured query language database management systems (SQL DBMS) can only store and manipulate scalar values such as integers and strings organized within tables.

Hence, the programmer must either convert the object values into groups of simpler values for storage in the database (and convert them back upon retrieval), or only use simple scalar values within the program. Object-relational mapping is used to implement the first approach.The key is to translate the logical representation of the objects into an atomized form that is capable of being stored in the database, while somehow preserving the properties of the objects and their relationships so that they can be reloaded as an object whenever required. If this storage and retrieval functionality is implemented, the objects are then said to be persistent.

Object-Relational Mapping, commonly referred to as its abbreviation ORM, is a technique that connects the rich objects of an application to tables in a relational database management system. Using ORM, the properties and relationships of the objects in an application can be easily stored and retrieved from a database without writing SQL statements directly and with less overall database access code.

=Features=

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 makes access to database through the application extremely easy, as it provides connection from model of the program to the database.Treating database rows as objects, Program can easily access the information in more consistent manner.Also it gives flexibility to the programmers to manipulate the data with the language itself rather than working on the attributes retrieved from the database.

When applied to Ruby, implementations of ORM often leverage the language’s Meta-programming 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 needs to be extracted from the model and the database, and 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.

=Active Record=
[http://ar.rubyonrails.org/ ActiveRecord] insulates you from the need to use raw SQL to find database records.Active Record facilitates the creation and use of business objects whose data requires persistent storage to a database.

ActiveRecord is the default ‘model’ component of the model-view-controller web-application framework Ruby on Rails, and is also a stand-alone ORM package for other Ruby applications. In both forms, it was conceived of by David Heinemeier Hansson, and has been improved upon by a number of contributors.

Other, less popular ORMs have been released since ActiveRecord first took the stage. For example, DataMapper and Sequel show major improvements over the original ActiveRecord framework.[neutrality is disputed] As a response to their release and adoption by the Rails community, Ruby on Rails v3.0 is independent of an ORM system, so Rails users can easily plug in DataMapper or Sequel to use as their ORM of choice.[wiki]

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>

Note in the preceding example, that 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 whose 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]]

Active Record will perform queries on the database for you and is compatible with most database systems (MySQL, PostgreSQL and SQLite to name a few). Regardless of which database system you are using, the ActiveRecord method format will always be the same.
To retrieve objects from the database, Active Record provides several finder methods. Each finder method allows you to pass arguments into it to perform certain queries on your database without writing raw SQL.

'''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.

=Sequel=
[http://sequel.rubyforge.org Sequel] is designed to take the hassle away from connecting to databases and manipulating them. Sequel deals with all the boring stuff like maintaining connections, formatting SQL correctly and fetching records so you can concentrate on your application.
Sequel uses the concept of datasets to retrieve data. A Dataset object encapsulates an SQL query and supports chainability, letting you fetch data using a convenient Ruby DSL that is both concise and flexible.The current sequel version is 4.2.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.

Sequel::Model is an object relational mapper built on top of Sequel core. Each model class is backed by a dataset instance, and many dataset methods can be called directly on the class. Model datasets return rows as model instances, which have fairly standard ORM instance behavior.

Sequel::Model is built completely out of plugins. Plugins can override any class, instance, or dataset method defined by a previous plugin and call super to get the default behavior

'''Features''' -
*Sequel provides thread safety, connection pooling and a concise DSL for constructing SQL *queries and table schemas.
*Sequel includes a comprehensive ORM layer for mapping records to Ruby objects and handling associated records.
*Sequel supports advanced database features such as prepared statements, bound variables, stored procedures, savepoints, two-phase commit, transaction isolation, master/slave configurations, and database sharding.
*Sequel currently has adapters for ADO, Amalgalite, CUBRID, DataObjects, DB2, DBI, Firebird, IBM_DB, Informix, JDBC, MySQL, Mysql2, ODBC, OpenBase, Oracle, PostgreSQL, SQLite3, Swift, and TinyTDS.

<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 ActiveRecord. 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.

=DataMapper=
[http://datamapper.org/why.html DataMapper] is an Object Relational Mapper written in Ruby. The goal is to create an ORM which is fast, thread-safe and feature rich.
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 even some popular web-services.

'''Features'''-
*Eager loading of child associations to avoid (N+1) queries.
*Lazy loading of select properties, e.g., larger fields.
*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,Apache Solr and web services such as 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.

=Squeel=
[https://www.ruby-toolbox.com/categories/orm Squeel] unlocks the power of Arel in your Rails 3 application with a handy block-based syntax. You can write subqueries, access named functions provided by your RDBMS, and more, all without writing SQL strings. Squeel acts as an add on to Active Record and makes it easier to write queries with fewer strings.
A simple example is as follows:
Squeel lets you rewrite
<pre>
Article.where ['created_at >= ?', 2.weeks.ago]
</pre>
as
<pre>
Article.where{created_at >= 2.weeks.ago}
</pre>

=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. Follows below a MyBatis mapper, that consist on 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>

=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
|}

=NonSQL databases=
Instead of ORM we can also use 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 user from retrieving 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 in XML file.

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

=Advantages of ORM=

*Facilitates implementing the Domain Model pattern that allows you to model entities based on real business concepts rather than based on our database structure. ORM tools provide this functionality through mapping between the logical business model and the physical storage model.

*Huge reduction in code. Ease of use, faster development, increased productivity.

*ORM tools provide a host of services thereby allowing developers to focus on the business logic of the application rather than repetitive CRUD (Create Read Update Delete) logic.

*Changes to the object model are made in one place. One you update your object definitions, the ORM will automatically use the updated structure for retrievals and updates. There are no SQL Update, Delete and Insert statements strewn throughout different layers of the application that need modification.

*Rich query capability. ORM tools provide an object oriented query language. This allows application developers to focus on the object model and not to have to be concerned with the database structure or SQL semantics. The ORM tool itself will translate the query language into the appropriate syntax for the database.

*Navigation. You can navigate object relationships transparently. Related objects are automatically loaded as needed. For example if you load a Post and you want to access it's Comment, you can simply access Post.Comment and the ORM will take care of loading the data for you without any effort on your part.

*Data loads are completely configurable allowing you to load the data appropriate for each scenario. For example in one scenario you might want to load a list of objects without any of it's child / related objects, while in other scenarios you can specify to load an object, with all it's children etc.

*Concurrency support. Support for multiple users updating the same data simultaneously.

*Cache management. Entities are cached in memory thereby reducing load on the database.

*Transaction management and Isolation. All object changes occur scoped to a transaction. The entire transaction can either be committed or rolled back. Multiple transactions can be active in memory in the same time, and each transactions changes are isolated form on another.

*Making data access more abstract and portable. ORM implementation classes know how to write vendor-specific SQL, so you don't have to.

=Disadvantages of ORM=

*High level of abstraction obscures as to what is actually happening in the code implementation.
*Loss in developer productivity whilst they learn to program with ORM.Developers lose understanding of what the code is actually doing - the developer is more in control using SQL.
*Heavy reliance on ORM also leads to poorly designed databases.
*Data and behaviour are not separated.
**Façade needs to be built if the data model is to be made available in a distributed architecture.
**Each ORM technology/product has a different set of APIs and porting code between them is not easy.
*The biggest advantage of ORM is also the biggest disadvantage: queries are generated automatically -
**Queries can’t be optimized.
**Queries select more data than needed, things get slower, more latency.
**Compiling queries from ORM code is slow (ORM compiler written in PHP).
**SQL is more powerful than ORM query languages.
**Database abstraction forbids vendor specific optimizations.

=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_Fall_2010/ch3_3j_KS Object-relational mapping Fall 2010] 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.Also, a detailed study of alternatives to ORM like the NoSQL databases and Document-oriented approach can be included.
=References=

# [http://en.wikipedia.org/wiki/Object-relational_mapping Wikipedia, Object-relational mapping (ORM)]
# [http://docforge.com/wiki/Object-relational_mapping Object-relational mapping]
# [http://en.wikipedia.org/wiki/Object-relational_impedance_mismatch Object-Relational Impedance Matching Problem]
# [http://www.hibernate.org/about/orm The Object-Relational Impedance Mismatch]
# [http://edgeguides.rubyonrails.org/active_record_basics.html#object-relational-mapping Active Record]
# [http://loianegroner.com/2011/02/introduction-to-ibatis-mybatis-an-alternative-to-hibernate-and-jdbc/ MyBatis/iBatis]
# [http://rubydoc.info/gems/squeel/1.1.1/frames Squeel]

CSC/ECE 517 Fall 2013/ch1 1w43 sm

2013-10-07T20:45:03Z

Mrsreena: /* NonSQL databases */

=Object Relational Mapping=

__TOC__

=Introduction=

[http://en.wikipedia.org/wiki/Object-relational_mapping Object-relational mapping (ORM)], or ORM, is a programming technique which associates data stored in a relational database with application objects. The ORM layer populates business objects on demand and persists them back into the relational database when updated.
ORM basically creates 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.In this wiki, we concenterate mainly on the top Ruby ORM's like Active Record,Sequel and DataMapper.Also, it includes a comparison of various ORM techniques and the advantages and disadvantages of various styles of ORM mapping.

=Need For ORM=
Need for ORM arose due to a major problem called the Object-Relational Impedance MisMatch Problem.
[http://en.wikipedia.org/wiki/Object-relational_impedance_mismatch Object-Relational Impedance MisMatch Problem] is a set of conceptual and technical difficulties, encountered when a relational database management system (RDBMS) is being used by an object-oriented program particularly when object/class definitions are mapped directly to database tables or schema.It implies that object models don't work together with relational models, i.e RDBMS represents data in tabular format while Object oriented languages represent data in the form of interconnected graph of objects.
The Mismatches that occur in Object-Oriented concepts are as follows:
*Encapsulation:
Mapping of private object representation to database tables is difficult due to availability of fewer constraints for the design of private representation as opposed to public data in RDBMS.
*Interface, Class, Inheritance and polymorphism:
Under an object-oriented paradigm, objects have interfaces that together provide the only access to the internals of that object. The relational model, on the other hand, utilizes derived relation variables (views) to provide varying perspectives and constraints to ensure integrity. Similarly, essential OOP concepts for classes of objects, inheritance and polymorphism are not supported by relational database systems.
*Identity:
RDBMS defines exactly one notion of 'sameness': the primary key. However, Object-oriented languages, for example Java, defines both object identity (a==b) and object equality (a.equals(b)).
*Associations:
Associations are represented as unidirectional references in Object Oriented languages whereas RDBMS uses the notion of foreign keys. For example, If you need bidirectional relationships in Java, you must define the association twice.Likewise, you cannot determine the multiplicity of a relationship by looking at the object domain model.
*Data navigation:
The way you access data in object-oriented languages is fundamentally different than the way you do it in a relational database. Like in Java, you navigate from one association to another walking the object network. This is not an efficient way of retrieving data from a relational database. You typically want to minimize the number of SQL queries and thus load several entities via JOINs and select the targeted entities before you start walking the object network.

=Overview=

Data management tasks in object-oriented (OO) programming are typically implemented by manipulating objects that are almost always non-scalar values. Like for example, Consider a Geometric object, an entity which can have shape and color.In the object oriented implementation, this entity would be modeled as a geometric object with shape and color as its attributes.Shape itself can contain objects like for triangles(equilateral or isosceles) and so on.Here each geometric object can be treated as a single object by any programming language and its attributes can be also accessed by various object methods.However, many popular database products such as structured query language database management systems (SQL DBMS) can only store and manipulate scalar values such as integers and strings organized within tables.

Hence, the programmer must either convert the object values into groups of simpler values for storage in the database (and convert them back upon retrieval), or only use simple scalar values within the program. Object-relational mapping is used to implement the first approach.The key is to translate the logical representation of the objects into an atomized form that is capable of being stored in the database, while somehow preserving the properties of the objects and their relationships so that they can be reloaded as an object whenever required. If this storage and retrieval functionality is implemented, the objects are then said to be persistent.

Object-Relational Mapping, commonly referred to as its abbreviation ORM, is a technique that connects the rich objects of an application to tables in a relational database management system. Using ORM, the properties and relationships of the objects in an application can be easily stored and retrieved from a database without writing SQL statements directly and with less overall database access code.

=Features=

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 makes access to database through the application extremely easy, as it provides connection from model of the program to the database.Treating database rows as objects, Program can easily access the information in more consistent manner.Also it gives flexibility to the programmers to manipulate the data with the language itself rather than working on the attributes retrieved from the database.

When applied to Ruby, implementations of ORM often leverage the language’s Meta-programming 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 needs to be extracted from the model and the database, and 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.

=Active Record=
[http://ar.rubyonrails.org/ ActiveRecord] insulates you from the need to use raw SQL to find database records.Active Record facilitates the creation and use of business objects whose data requires persistent storage to a database.

ActiveRecord is the default ‘model’ component of the model-view-controller web-application framework Ruby on Rails, and is also a stand-alone ORM package for other Ruby applications. In both forms, it was conceived of by David Heinemeier Hansson, and has been improved upon by a number of contributors.

Other, less popular ORMs have been released since ActiveRecord first took the stage. For example, DataMapper and Sequel show major improvements over the original ActiveRecord framework.[neutrality is disputed] As a response to their release and adoption by the Rails community, Ruby on Rails v3.0 is independent of an ORM system, so Rails users can easily plug in DataMapper or Sequel to use as their ORM of choice.[wiki]

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>

Note in the preceding example, that 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 whose 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]]

Active Record will perform queries on the database for you and is compatible with most database systems (MySQL, PostgreSQL and SQLite to name a few). Regardless of which database system you are using, the ActiveRecord method format will always be the same.
To retrieve objects from the database, Active Record provides several finder methods. Each finder method allows you to pass arguments into it to perform certain queries on your database without writing raw SQL.

'''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.

=Sequel=
[http://sequel.rubyforge.org Sequel] is designed to take the hassle away from connecting to databases and manipulating them. Sequel deals with all the boring stuff like maintaining connections, formatting SQL correctly and fetching records so you can concentrate on your application.
Sequel uses the concept of datasets to retrieve data. A Dataset object encapsulates an SQL query and supports chainability, letting you fetch data using a convenient Ruby DSL that is both concise and flexible.The current sequel version is 4.2.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.

Sequel::Model is an object relational mapper built on top of Sequel core. Each model class is backed by a dataset instance, and many dataset methods can be called directly on the class. Model datasets return rows as model instances, which have fairly standard ORM instance behavior.

Sequel::Model is built completely out of plugins. Plugins can override any class, instance, or dataset method defined by a previous plugin and call super to get the default behavior

'''Features''' -
*Sequel provides thread safety, connection pooling and a concise DSL for constructing SQL *queries and table schemas.
*Sequel includes a comprehensive ORM layer for mapping records to Ruby objects and handling associated records.
*Sequel supports advanced database features such as prepared statements, bound variables, stored procedures, savepoints, two-phase commit, transaction isolation, master/slave configurations, and database sharding.
*Sequel currently has adapters for ADO, Amalgalite, CUBRID, DataObjects, DB2, DBI, Firebird, IBM_DB, Informix, JDBC, MySQL, Mysql2, ODBC, OpenBase, Oracle, PostgreSQL, SQLite3, Swift, and TinyTDS.

<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 ActiveRecord. 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.

=DataMapper=
DataMapper is an Object Relational Mapper written in Ruby. The goal is to create an ORM which is fast, thread-safe and feature rich.
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 even some popular webservices.[datamapper.org]

'''Features'''-
*Eager loading of child associations to avoid (N+1) queries
*Lazy loading of select properties, e.g., larger fields
*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.[2] As a result, DataMapper adapters have been built for other non-SQL databases, such as CouchDB,[3] Apache Solr,[4] and web services such as Salesforce.[wikipedia]

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.

=Squeel=
[https://www.ruby-toolbox.com/categories/orm Squeel] unlocks the power of Arel in your Rails 3 application with a handy block-based syntax. You can write subqueries, access named functions provided by your RDBMS, and more, all without writing SQL strings. Squeel acts as an add on to Active Record and makes it easier to write queries with fewer strings.
A simple example is as follows:
Squeel lets you rewrite
<pre>
Article.where ['created_at >= ?', 2.weeks.ago]
</pre>
as
<pre>
Article.where{created_at >= 2.weeks.ago}
</pre>

=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. Follows below a MyBatis mapper, that consist on 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>

=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
|}

=NonSQL databases=
Instead of ORM we can also use 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 user from retrieving 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 in XML file.

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

=Advantages of ORM=

*Facilitates implementing the Domain Model pattern that allows you to model entities based on real business concepts rather than based on our database structure. ORM tools provide this functionality through mapping between the logical business model and the physical storage model.

*Huge reduction in code. Ease of use, faster development, increased productivity.

*ORM tools provide a host of services thereby allowing developers to focus on the business logic of the application rather than repetitive CRUD (Create Read Update Delete) logic.

*Changes to the object model are made in one place. One you update your object definitions, the ORM will automatically use the updated structure for retrievals and updates. There are no SQL Update, Delete and Insert statements strewn throughout different layers of the application that need modification.

*Rich query capability. ORM tools provide an object oriented query language. This allows application developers to focus on the object model and not to have to be concerned with the database structure or SQL semantics. The ORM tool itself will translate the query language into the appropriate syntax for the database.

*Navigation. You can navigate object relationships transparently. Related objects are automatically loaded as needed. For example if you load a Post and you want to access it's Comment, you can simply access Post.Comment and the ORM will take care of loading the data for you without any effort on your part.

*Data loads are completely configurable allowing you to load the data appropriate for each scenario. For example in one scenario you might want to load a list of objects without any of it's child / related objects, while in other scenarios you can specify to load an object, with all it's children etc.

*Concurrency support. Support for multiple users updating the same data simultaneously.

*Cache management. Entities are cached in memory thereby reducing load on the database.

*Transaction management and Isolation. All object changes occur scoped to a transaction. The entire transaction can either be committed or rolled back. Multiple transactions can be active in memory in the same time, and each transactions changes are isolated form on another.

*Making data access more abstract and portable. ORM implementation classes know how to write vendor-specific SQL, so you don't have to.

=Disadvantages of ORM=

*High level of abstraction obscures as to what is actually happening in the code implementation.
*Loss in developer productivity whilst they learn to program with ORM.Developers lose understanding of what the code is actually doing - the developer is more in control using SQL.
*Heavy reliance on ORM also leads to poorly designed databases.
*Data and behaviour are not separated.
**Façade needs to be built if the data model is to be made available in a distributed architecture.
**Each ORM technology/product has a different set of APIs and porting code between them is not easy.
*The biggest advantage of ORM is also the biggest disadvantage: queries are generated automatically -
**Queries can’t be optimized.
**Queries select more data than needed, things get slower, more latency.
**Compiling queries from ORM code is slow (ORM compiler written in PHP).
**SQL is more powerful than ORM query languages.
**Database abstraction forbids vendor specific optimizations.

=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_Fall_2010/ch3_3j_KS Object-relational mapping Fall 2010] 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.Also, a detailed study of alternatives to ORM like the NoSQL databases and Document-oriented approach can be included.
=References=

# [http://en.wikipedia.org/wiki/Object-relational_mapping Wikipedia, Object-relational mapping (ORM)]
# [http://docforge.com/wiki/Object-relational_mapping Object-relational mapping]
# [http://en.wikipedia.org/wiki/Object-relational_impedance_mismatch Object-Relational Impedance Matching Problem]
# [http://www.hibernate.org/about/orm The Object-Relational Impedance Mismatch]
# [http://edgeguides.rubyonrails.org/active_record_basics.html#object-relational-mapping Active Record]
# [http://loianegroner.com/2011/02/introduction-to-ibatis-mybatis-an-alternative-to-hibernate-and-jdbc/ MyBatis/iBatis]
# [http://rubydoc.info/gems/squeel/1.1.1/frames Squeel]

CSC/ECE 517 Fall 2013/ch1 1w43 sm

2013-10-07T20:43:53Z

Mrsreena: /* Squeel */

=Object Relational Mapping=

__TOC__

=Introduction=

[http://en.wikipedia.org/wiki/Object-relational_mapping Object-relational mapping (ORM)], or ORM, is a programming technique which associates data stored in a relational database with application objects. The ORM layer populates business objects on demand and persists them back into the relational database when updated.
ORM basically creates 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.In this wiki, we concenterate mainly on the top Ruby ORM's like Active Record,Sequel and DataMapper.Also, it includes a comparison of various ORM techniques and the advantages and disadvantages of various styles of ORM mapping.

=Need For ORM=
Need for ORM arose due to a major problem called the Object-Relational Impedance MisMatch Problem.
[http://en.wikipedia.org/wiki/Object-relational_impedance_mismatch Object-Relational Impedance MisMatch Problem] is a set of conceptual and technical difficulties, encountered when a relational database management system (RDBMS) is being used by an object-oriented program particularly when object/class definitions are mapped directly to database tables or schema.It implies that object models don't work together with relational models, i.e RDBMS represents data in tabular format while Object oriented languages represent data in the form of interconnected graph of objects.
The Mismatches that occur in Object-Oriented concepts are as follows:
*Encapsulation:
Mapping of private object representation to database tables is difficult due to availability of fewer constraints for the design of private representation as opposed to public data in RDBMS.
*Interface, Class, Inheritance and polymorphism:
Under an object-oriented paradigm, objects have interfaces that together provide the only access to the internals of that object. The relational model, on the other hand, utilizes derived relation variables (views) to provide varying perspectives and constraints to ensure integrity. Similarly, essential OOP concepts for classes of objects, inheritance and polymorphism are not supported by relational database systems.
*Identity:
RDBMS defines exactly one notion of 'sameness': the primary key. However, Object-oriented languages, for example Java, defines both object identity (a==b) and object equality (a.equals(b)).
*Associations:
Associations are represented as unidirectional references in Object Oriented languages whereas RDBMS uses the notion of foreign keys. For example, If you need bidirectional relationships in Java, you must define the association twice.Likewise, you cannot determine the multiplicity of a relationship by looking at the object domain model.
*Data navigation:
The way you access data in object-oriented languages is fundamentally different than the way you do it in a relational database. Like in Java, you navigate from one association to another walking the object network. This is not an efficient way of retrieving data from a relational database. You typically want to minimize the number of SQL queries and thus load several entities via JOINs and select the targeted entities before you start walking the object network.

=Overview=

Data management tasks in object-oriented (OO) programming are typically implemented by manipulating objects that are almost always non-scalar values. Like for example, Consider a Geometric object, an entity which can have shape and color.In the object oriented implementation, this entity would be modeled as a geometric object with shape and color as its attributes.Shape itself can contain objects like for triangles(equilateral or isosceles) and so on.Here each geometric object can be treated as a single object by any programming language and its attributes can be also accessed by various object methods.However, many popular database products such as structured query language database management systems (SQL DBMS) can only store and manipulate scalar values such as integers and strings organized within tables.

Hence, the programmer must either convert the object values into groups of simpler values for storage in the database (and convert them back upon retrieval), or only use simple scalar values within the program. Object-relational mapping is used to implement the first approach.The key is to translate the logical representation of the objects into an atomized form that is capable of being stored in the database, while somehow preserving the properties of the objects and their relationships so that they can be reloaded as an object whenever required. If this storage and retrieval functionality is implemented, the objects are then said to be persistent.

Object-Relational Mapping, commonly referred to as its abbreviation ORM, is a technique that connects the rich objects of an application to tables in a relational database management system. Using ORM, the properties and relationships of the objects in an application can be easily stored and retrieved from a database without writing SQL statements directly and with less overall database access code.

=Features=

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 makes access to database through the application extremely easy, as it provides connection from model of the program to the database.Treating database rows as objects, Program can easily access the information in more consistent manner.Also it gives flexibility to the programmers to manipulate the data with the language itself rather than working on the attributes retrieved from the database.

When applied to Ruby, implementations of ORM often leverage the language’s Meta-programming 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 needs to be extracted from the model and the database, and 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.

=Active Record=
[http://ar.rubyonrails.org/ ActiveRecord] insulates you from the need to use raw SQL to find database records.Active Record facilitates the creation and use of business objects whose data requires persistent storage to a database.

ActiveRecord is the default ‘model’ component of the model-view-controller web-application framework Ruby on Rails, and is also a stand-alone ORM package for other Ruby applications. In both forms, it was conceived of by David Heinemeier Hansson, and has been improved upon by a number of contributors.

Other, less popular ORMs have been released since ActiveRecord first took the stage. For example, DataMapper and Sequel show major improvements over the original ActiveRecord framework.[neutrality is disputed] As a response to their release and adoption by the Rails community, Ruby on Rails v3.0 is independent of an ORM system, so Rails users can easily plug in DataMapper or Sequel to use as their ORM of choice.[wiki]

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>

Note in the preceding example, that 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 whose 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]]

Active Record will perform queries on the database for you and is compatible with most database systems (MySQL, PostgreSQL and SQLite to name a few). Regardless of which database system you are using, the ActiveRecord method format will always be the same.
To retrieve objects from the database, Active Record provides several finder methods. Each finder method allows you to pass arguments into it to perform certain queries on your database without writing raw SQL.

'''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.

=Sequel=
[http://sequel.rubyforge.org Sequel] is designed to take the hassle away from connecting to databases and manipulating them. Sequel deals with all the boring stuff like maintaining connections, formatting SQL correctly and fetching records so you can concentrate on your application.
Sequel uses the concept of datasets to retrieve data. A Dataset object encapsulates an SQL query and supports chainability, letting you fetch data using a convenient Ruby DSL that is both concise and flexible.The current sequel version is 4.2.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.

Sequel::Model is an object relational mapper built on top of Sequel core. Each model class is backed by a dataset instance, and many dataset methods can be called directly on the class. Model datasets return rows as model instances, which have fairly standard ORM instance behavior.

Sequel::Model is built completely out of plugins. Plugins can override any class, instance, or dataset method defined by a previous plugin and call super to get the default behavior

'''Features''' -
*Sequel provides thread safety, connection pooling and a concise DSL for constructing SQL *queries and table schemas.
*Sequel includes a comprehensive ORM layer for mapping records to Ruby objects and handling associated records.
*Sequel supports advanced database features such as prepared statements, bound variables, stored procedures, savepoints, two-phase commit, transaction isolation, master/slave configurations, and database sharding.
*Sequel currently has adapters for ADO, Amalgalite, CUBRID, DataObjects, DB2, DBI, Firebird, IBM_DB, Informix, JDBC, MySQL, Mysql2, ODBC, OpenBase, Oracle, PostgreSQL, SQLite3, Swift, and TinyTDS.

<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 ActiveRecord. 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.

=DataMapper=
DataMapper is an Object Relational Mapper written in Ruby. The goal is to create an ORM which is fast, thread-safe and feature rich.
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 even some popular webservices.[datamapper.org]

'''Features'''-
*Eager loading of child associations to avoid (N+1) queries
*Lazy loading of select properties, e.g., larger fields
*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.[2] As a result, DataMapper adapters have been built for other non-SQL databases, such as CouchDB,[3] Apache Solr,[4] and web services such as Salesforce.[wikipedia]

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.

=Squeel=
[https://www.ruby-toolbox.com/categories/orm Squeel] unlocks the power of Arel in your Rails 3 application with a handy block-based syntax. You can write subqueries, access named functions provided by your RDBMS, and more, all without writing SQL strings. Squeel acts as an add on to Active Record and makes it easier to write queries with fewer strings.
A simple example is as follows:
Squeel lets you rewrite
<pre>
Article.where ['created_at >= ?', 2.weeks.ago]
</pre>
as
<pre>
Article.where{created_at >= 2.weeks.ago}
</pre>

=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. Follows below a MyBatis mapper, that consist on 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>

=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
|}

=NonSQL databases=
Instead of ORM we can also use 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 user from retrieving 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 in XML file.

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.

NoSQL 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

=Advantages of ORM=

*Facilitates implementing the Domain Model pattern that allows you to model entities based on real business concepts rather than based on our database structure. ORM tools provide this functionality through mapping between the logical business model and the physical storage model.

*Huge reduction in code. Ease of use, faster development, increased productivity.

*ORM tools provide a host of services thereby allowing developers to focus on the business logic of the application rather than repetitive CRUD (Create Read Update Delete) logic.

*Changes to the object model are made in one place. One you update your object definitions, the ORM will automatically use the updated structure for retrievals and updates. There are no SQL Update, Delete and Insert statements strewn throughout different layers of the application that need modification.

*Rich query capability. ORM tools provide an object oriented query language. This allows application developers to focus on the object model and not to have to be concerned with the database structure or SQL semantics. The ORM tool itself will translate the query language into the appropriate syntax for the database.

*Navigation. You can navigate object relationships transparently. Related objects are automatically loaded as needed. For example if you load a Post and you want to access it's Comment, you can simply access Post.Comment and the ORM will take care of loading the data for you without any effort on your part.

*Data loads are completely configurable allowing you to load the data appropriate for each scenario. For example in one scenario you might want to load a list of objects without any of it's child / related objects, while in other scenarios you can specify to load an object, with all it's children etc.

*Concurrency support. Support for multiple users updating the same data simultaneously.

*Cache management. Entities are cached in memory thereby reducing load on the database.

*Transaction management and Isolation. All object changes occur scoped to a transaction. The entire transaction can either be committed or rolled back. Multiple transactions can be active in memory in the same time, and each transactions changes are isolated form on another.

*Making data access more abstract and portable. ORM implementation classes know how to write vendor-specific SQL, so you don't have to.

=Disadvantages of ORM=

*High level of abstraction obscures as to what is actually happening in the code implementation.
*Loss in developer productivity whilst they learn to program with ORM.Developers lose understanding of what the code is actually doing - the developer is more in control using SQL.
*Heavy reliance on ORM also leads to poorly designed databases.
*Data and behaviour are not separated.
**Façade needs to be built if the data model is to be made available in a distributed architecture.
**Each ORM technology/product has a different set of APIs and porting code between them is not easy.
*The biggest advantage of ORM is also the biggest disadvantage: queries are generated automatically -
**Queries can’t be optimized.
**Queries select more data than needed, things get slower, more latency.
**Compiling queries from ORM code is slow (ORM compiler written in PHP).
**SQL is more powerful than ORM query languages.
**Database abstraction forbids vendor specific optimizations.

=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_Fall_2010/ch3_3j_KS Object-relational mapping Fall 2010] 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.Also, a detailed study of alternatives to ORM like the NoSQL databases and Document-oriented approach can be included.
=References=

# [http://en.wikipedia.org/wiki/Object-relational_mapping Wikipedia, Object-relational mapping (ORM)]
# [http://docforge.com/wiki/Object-relational_mapping Object-relational mapping]
# [http://en.wikipedia.org/wiki/Object-relational_impedance_mismatch Object-Relational Impedance Matching Problem]
# [http://www.hibernate.org/about/orm The Object-Relational Impedance Mismatch]
# [http://edgeguides.rubyonrails.org/active_record_basics.html#object-relational-mapping Active Record]
# [http://loianegroner.com/2011/02/introduction-to-ibatis-mybatis-an-alternative-to-hibernate-and-jdbc/ MyBatis/iBatis]
# [http://rubydoc.info/gems/squeel/1.1.1/frames Squeel]

CSC/ECE 517 Fall 2013/ch1 1w43 sm

2013-10-07T20:43:28Z

Mrsreena: /* References */

=Object Relational Mapping=

__TOC__

=Introduction=

[http://en.wikipedia.org/wiki/Object-relational_mapping Object-relational mapping (ORM)], or ORM, is a programming technique which associates data stored in a relational database with application objects. The ORM layer populates business objects on demand and persists them back into the relational database when updated.
ORM basically creates 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.In this wiki, we concenterate mainly on the top Ruby ORM's like Active Record,Sequel and DataMapper.Also, it includes a comparison of various ORM techniques and the advantages and disadvantages of various styles of ORM mapping.

=Need For ORM=
Need for ORM arose due to a major problem called the Object-Relational Impedance MisMatch Problem.
[http://en.wikipedia.org/wiki/Object-relational_impedance_mismatch Object-Relational Impedance MisMatch Problem] is a set of conceptual and technical difficulties, encountered when a relational database management system (RDBMS) is being used by an object-oriented program particularly when object/class definitions are mapped directly to database tables or schema.It implies that object models don't work together with relational models, i.e RDBMS represents data in tabular format while Object oriented languages represent data in the form of interconnected graph of objects.
The Mismatches that occur in Object-Oriented concepts are as follows:
*Encapsulation:
Mapping of private object representation to database tables is difficult due to availability of fewer constraints for the design of private representation as opposed to public data in RDBMS.
*Interface, Class, Inheritance and polymorphism:
Under an object-oriented paradigm, objects have interfaces that together provide the only access to the internals of that object. The relational model, on the other hand, utilizes derived relation variables (views) to provide varying perspectives and constraints to ensure integrity. Similarly, essential OOP concepts for classes of objects, inheritance and polymorphism are not supported by relational database systems.
*Identity:
RDBMS defines exactly one notion of 'sameness': the primary key. However, Object-oriented languages, for example Java, defines both object identity (a==b) and object equality (a.equals(b)).
*Associations:
Associations are represented as unidirectional references in Object Oriented languages whereas RDBMS uses the notion of foreign keys. For example, If you need bidirectional relationships in Java, you must define the association twice.Likewise, you cannot determine the multiplicity of a relationship by looking at the object domain model.
*Data navigation:
The way you access data in object-oriented languages is fundamentally different than the way you do it in a relational database. Like in Java, you navigate from one association to another walking the object network. This is not an efficient way of retrieving data from a relational database. You typically want to minimize the number of SQL queries and thus load several entities via JOINs and select the targeted entities before you start walking the object network.

=Overview=

Data management tasks in object-oriented (OO) programming are typically implemented by manipulating objects that are almost always non-scalar values. Like for example, Consider a Geometric object, an entity which can have shape and color.In the object oriented implementation, this entity would be modeled as a geometric object with shape and color as its attributes.Shape itself can contain objects like for triangles(equilateral or isosceles) and so on.Here each geometric object can be treated as a single object by any programming language and its attributes can be also accessed by various object methods.However, many popular database products such as structured query language database management systems (SQL DBMS) can only store and manipulate scalar values such as integers and strings organized within tables.

Hence, the programmer must either convert the object values into groups of simpler values for storage in the database (and convert them back upon retrieval), or only use simple scalar values within the program. Object-relational mapping is used to implement the first approach.The key is to translate the logical representation of the objects into an atomized form that is capable of being stored in the database, while somehow preserving the properties of the objects and their relationships so that they can be reloaded as an object whenever required. If this storage and retrieval functionality is implemented, the objects are then said to be persistent.

Object-Relational Mapping, commonly referred to as its abbreviation ORM, is a technique that connects the rich objects of an application to tables in a relational database management system. Using ORM, the properties and relationships of the objects in an application can be easily stored and retrieved from a database without writing SQL statements directly and with less overall database access code.

=Features=

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 makes access to database through the application extremely easy, as it provides connection from model of the program to the database.Treating database rows as objects, Program can easily access the information in more consistent manner.Also it gives flexibility to the programmers to manipulate the data with the language itself rather than working on the attributes retrieved from the database.

When applied to Ruby, implementations of ORM often leverage the language’s Meta-programming 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 needs to be extracted from the model and the database, and 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.

=Active Record=
[http://ar.rubyonrails.org/ ActiveRecord] insulates you from the need to use raw SQL to find database records.Active Record facilitates the creation and use of business objects whose data requires persistent storage to a database.

ActiveRecord is the default ‘model’ component of the model-view-controller web-application framework Ruby on Rails, and is also a stand-alone ORM package for other Ruby applications. In both forms, it was conceived of by David Heinemeier Hansson, and has been improved upon by a number of contributors.

Other, less popular ORMs have been released since ActiveRecord first took the stage. For example, DataMapper and Sequel show major improvements over the original ActiveRecord framework.[neutrality is disputed] As a response to their release and adoption by the Rails community, Ruby on Rails v3.0 is independent of an ORM system, so Rails users can easily plug in DataMapper or Sequel to use as their ORM of choice.[wiki]

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>

Note in the preceding example, that 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 whose 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]]

Active Record will perform queries on the database for you and is compatible with most database systems (MySQL, PostgreSQL and SQLite to name a few). Regardless of which database system you are using, the ActiveRecord method format will always be the same.
To retrieve objects from the database, Active Record provides several finder methods. Each finder method allows you to pass arguments into it to perform certain queries on your database without writing raw SQL.

'''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.

=Sequel=
[http://sequel.rubyforge.org Sequel] is designed to take the hassle away from connecting to databases and manipulating them. Sequel deals with all the boring stuff like maintaining connections, formatting SQL correctly and fetching records so you can concentrate on your application.
Sequel uses the concept of datasets to retrieve data. A Dataset object encapsulates an SQL query and supports chainability, letting you fetch data using a convenient Ruby DSL that is both concise and flexible.The current sequel version is 4.2.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.

Sequel::Model is an object relational mapper built on top of Sequel core. Each model class is backed by a dataset instance, and many dataset methods can be called directly on the class. Model datasets return rows as model instances, which have fairly standard ORM instance behavior.

Sequel::Model is built completely out of plugins. Plugins can override any class, instance, or dataset method defined by a previous plugin and call super to get the default behavior

'''Features''' -
*Sequel provides thread safety, connection pooling and a concise DSL for constructing SQL *queries and table schemas.
*Sequel includes a comprehensive ORM layer for mapping records to Ruby objects and handling associated records.
*Sequel supports advanced database features such as prepared statements, bound variables, stored procedures, savepoints, two-phase commit, transaction isolation, master/slave configurations, and database sharding.
*Sequel currently has adapters for ADO, Amalgalite, CUBRID, DataObjects, DB2, DBI, Firebird, IBM_DB, Informix, JDBC, MySQL, Mysql2, ODBC, OpenBase, Oracle, PostgreSQL, SQLite3, Swift, and TinyTDS.

<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 ActiveRecord. 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.

=DataMapper=
DataMapper is an Object Relational Mapper written in Ruby. The goal is to create an ORM which is fast, thread-safe and feature rich.
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 even some popular webservices.[datamapper.org]

'''Features'''-
*Eager loading of child associations to avoid (N+1) queries
*Lazy loading of select properties, e.g., larger fields
*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.[2] As a result, DataMapper adapters have been built for other non-SQL databases, such as CouchDB,[3] Apache Solr,[4] and web services such as Salesforce.[wikipedia]

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.

=Squeel=
Squeel unlocks the power of Arel in your Rails 3 application with a handy block-based syntax. You can write subqueries, access named functions provided by your RDBMS, and more, all without writing SQL strings. Squeel acts as an add on to Active Record and makes it easier to write queries with fewer strings.
A simple example is as follows:
Squeel lets you rewrite
<pre>
Article.where ['created_at >= ?', 2.weeks.ago]
</pre>
as
<pre>
Article.where{created_at >= 2.weeks.ago}
</pre>

=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. Follows below a MyBatis mapper, that consist on 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>

=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
|}

=NonSQL databases=
Instead of ORM we can also use 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 user from retrieving 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 in XML file.

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.

NoSQL 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

=Advantages of ORM=

*Facilitates implementing the Domain Model pattern that allows you to model entities based on real business concepts rather than based on our database structure. ORM tools provide this functionality through mapping between the logical business model and the physical storage model.

*Huge reduction in code. Ease of use, faster development, increased productivity.

*ORM tools provide a host of services thereby allowing developers to focus on the business logic of the application rather than repetitive CRUD (Create Read Update Delete) logic.

*Changes to the object model are made in one place. One you update your object definitions, the ORM will automatically use the updated structure for retrievals and updates. There are no SQL Update, Delete and Insert statements strewn throughout different layers of the application that need modification.

*Rich query capability. ORM tools provide an object oriented query language. This allows application developers to focus on the object model and not to have to be concerned with the database structure or SQL semantics. The ORM tool itself will translate the query language into the appropriate syntax for the database.

*Navigation. You can navigate object relationships transparently. Related objects are automatically loaded as needed. For example if you load a Post and you want to access it's Comment, you can simply access Post.Comment and the ORM will take care of loading the data for you without any effort on your part.

*Data loads are completely configurable allowing you to load the data appropriate for each scenario. For example in one scenario you might want to load a list of objects without any of it's child / related objects, while in other scenarios you can specify to load an object, with all it's children etc.

*Concurrency support. Support for multiple users updating the same data simultaneously.

*Cache management. Entities are cached in memory thereby reducing load on the database.

*Transaction management and Isolation. All object changes occur scoped to a transaction. The entire transaction can either be committed or rolled back. Multiple transactions can be active in memory in the same time, and each transactions changes are isolated form on another.

*Making data access more abstract and portable. ORM implementation classes know how to write vendor-specific SQL, so you don't have to.

=Disadvantages of ORM=

*High level of abstraction obscures as to what is actually happening in the code implementation.
*Loss in developer productivity whilst they learn to program with ORM.Developers lose understanding of what the code is actually doing - the developer is more in control using SQL.
*Heavy reliance on ORM also leads to poorly designed databases.
*Data and behaviour are not separated.
**Façade needs to be built if the data model is to be made available in a distributed architecture.
**Each ORM technology/product has a different set of APIs and porting code between them is not easy.
*The biggest advantage of ORM is also the biggest disadvantage: queries are generated automatically -
**Queries can’t be optimized.
**Queries select more data than needed, things get slower, more latency.
**Compiling queries from ORM code is slow (ORM compiler written in PHP).
**SQL is more powerful than ORM query languages.
**Database abstraction forbids vendor specific optimizations.

=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_Fall_2010/ch3_3j_KS Object-relational mapping Fall 2010] 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.Also, a detailed study of alternatives to ORM like the NoSQL databases and Document-oriented approach can be included.
=References=

# [http://en.wikipedia.org/wiki/Object-relational_mapping Wikipedia, Object-relational mapping (ORM)]
# [http://docforge.com/wiki/Object-relational_mapping Object-relational mapping]
# [http://en.wikipedia.org/wiki/Object-relational_impedance_mismatch Object-Relational Impedance Matching Problem]
# [http://www.hibernate.org/about/orm The Object-Relational Impedance Mismatch]
# [http://edgeguides.rubyonrails.org/active_record_basics.html#object-relational-mapping Active Record]
# [http://loianegroner.com/2011/02/introduction-to-ibatis-mybatis-an-alternative-to-hibernate-and-jdbc/ MyBatis/iBatis]
# [http://rubydoc.info/gems/squeel/1.1.1/frames Squeel]

CSC/ECE 517 Fall 2013/ch1 1w43 sm

2013-10-07T20:42:48Z

Mrsreena: /* MyBatis/iBatis */

=Object Relational Mapping=

__TOC__

=Introduction=

[http://en.wikipedia.org/wiki/Object-relational_mapping Object-relational mapping (ORM)], or ORM, is a programming technique which associates data stored in a relational database with application objects. The ORM layer populates business objects on demand and persists them back into the relational database when updated.
ORM basically creates 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.In this wiki, we concenterate mainly on the top Ruby ORM's like Active Record,Sequel and DataMapper.Also, it includes a comparison of various ORM techniques and the advantages and disadvantages of various styles of ORM mapping.

=Need For ORM=
Need for ORM arose due to a major problem called the Object-Relational Impedance MisMatch Problem.
[http://en.wikipedia.org/wiki/Object-relational_impedance_mismatch Object-Relational Impedance MisMatch Problem] is a set of conceptual and technical difficulties, encountered when a relational database management system (RDBMS) is being used by an object-oriented program particularly when object/class definitions are mapped directly to database tables or schema.It implies that object models don't work together with relational models, i.e RDBMS represents data in tabular format while Object oriented languages represent data in the form of interconnected graph of objects.
The Mismatches that occur in Object-Oriented concepts are as follows:
*Encapsulation:
Mapping of private object representation to database tables is difficult due to availability of fewer constraints for the design of private representation as opposed to public data in RDBMS.
*Interface, Class, Inheritance and polymorphism:
Under an object-oriented paradigm, objects have interfaces that together provide the only access to the internals of that object. The relational model, on the other hand, utilizes derived relation variables (views) to provide varying perspectives and constraints to ensure integrity. Similarly, essential OOP concepts for classes of objects, inheritance and polymorphism are not supported by relational database systems.
*Identity:
RDBMS defines exactly one notion of 'sameness': the primary key. However, Object-oriented languages, for example Java, defines both object identity (a==b) and object equality (a.equals(b)).
*Associations:
Associations are represented as unidirectional references in Object Oriented languages whereas RDBMS uses the notion of foreign keys. For example, If you need bidirectional relationships in Java, you must define the association twice.Likewise, you cannot determine the multiplicity of a relationship by looking at the object domain model.
*Data navigation:
The way you access data in object-oriented languages is fundamentally different than the way you do it in a relational database. Like in Java, you navigate from one association to another walking the object network. This is not an efficient way of retrieving data from a relational database. You typically want to minimize the number of SQL queries and thus load several entities via JOINs and select the targeted entities before you start walking the object network.

=Overview=

Data management tasks in object-oriented (OO) programming are typically implemented by manipulating objects that are almost always non-scalar values. Like for example, Consider a Geometric object, an entity which can have shape and color.In the object oriented implementation, this entity would be modeled as a geometric object with shape and color as its attributes.Shape itself can contain objects like for triangles(equilateral or isosceles) and so on.Here each geometric object can be treated as a single object by any programming language and its attributes can be also accessed by various object methods.However, many popular database products such as structured query language database management systems (SQL DBMS) can only store and manipulate scalar values such as integers and strings organized within tables.

Hence, the programmer must either convert the object values into groups of simpler values for storage in the database (and convert them back upon retrieval), or only use simple scalar values within the program. Object-relational mapping is used to implement the first approach.The key is to translate the logical representation of the objects into an atomized form that is capable of being stored in the database, while somehow preserving the properties of the objects and their relationships so that they can be reloaded as an object whenever required. If this storage and retrieval functionality is implemented, the objects are then said to be persistent.

Object-Relational Mapping, commonly referred to as its abbreviation ORM, is a technique that connects the rich objects of an application to tables in a relational database management system. Using ORM, the properties and relationships of the objects in an application can be easily stored and retrieved from a database without writing SQL statements directly and with less overall database access code.

=Features=

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 makes access to database through the application extremely easy, as it provides connection from model of the program to the database.Treating database rows as objects, Program can easily access the information in more consistent manner.Also it gives flexibility to the programmers to manipulate the data with the language itself rather than working on the attributes retrieved from the database.

When applied to Ruby, implementations of ORM often leverage the language’s Meta-programming 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 needs to be extracted from the model and the database, and 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.

=Active Record=
[http://ar.rubyonrails.org/ ActiveRecord] insulates you from the need to use raw SQL to find database records.Active Record facilitates the creation and use of business objects whose data requires persistent storage to a database.

ActiveRecord is the default ‘model’ component of the model-view-controller web-application framework Ruby on Rails, and is also a stand-alone ORM package for other Ruby applications. In both forms, it was conceived of by David Heinemeier Hansson, and has been improved upon by a number of contributors.

Other, less popular ORMs have been released since ActiveRecord first took the stage. For example, DataMapper and Sequel show major improvements over the original ActiveRecord framework.[neutrality is disputed] As a response to their release and adoption by the Rails community, Ruby on Rails v3.0 is independent of an ORM system, so Rails users can easily plug in DataMapper or Sequel to use as their ORM of choice.[wiki]

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>

Note in the preceding example, that 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 whose 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]]

Active Record will perform queries on the database for you and is compatible with most database systems (MySQL, PostgreSQL and SQLite to name a few). Regardless of which database system you are using, the ActiveRecord method format will always be the same.
To retrieve objects from the database, Active Record provides several finder methods. Each finder method allows you to pass arguments into it to perform certain queries on your database without writing raw SQL.

'''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.

=Sequel=
[http://sequel.rubyforge.org Sequel] is designed to take the hassle away from connecting to databases and manipulating them. Sequel deals with all the boring stuff like maintaining connections, formatting SQL correctly and fetching records so you can concentrate on your application.
Sequel uses the concept of datasets to retrieve data. A Dataset object encapsulates an SQL query and supports chainability, letting you fetch data using a convenient Ruby DSL that is both concise and flexible.The current sequel version is 4.2.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.

Sequel::Model is an object relational mapper built on top of Sequel core. Each model class is backed by a dataset instance, and many dataset methods can be called directly on the class. Model datasets return rows as model instances, which have fairly standard ORM instance behavior.

Sequel::Model is built completely out of plugins. Plugins can override any class, instance, or dataset method defined by a previous plugin and call super to get the default behavior

'''Features''' -
*Sequel provides thread safety, connection pooling and a concise DSL for constructing SQL *queries and table schemas.
*Sequel includes a comprehensive ORM layer for mapping records to Ruby objects and handling associated records.
*Sequel supports advanced database features such as prepared statements, bound variables, stored procedures, savepoints, two-phase commit, transaction isolation, master/slave configurations, and database sharding.
*Sequel currently has adapters for ADO, Amalgalite, CUBRID, DataObjects, DB2, DBI, Firebird, IBM_DB, Informix, JDBC, MySQL, Mysql2, ODBC, OpenBase, Oracle, PostgreSQL, SQLite3, Swift, and TinyTDS.

<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 ActiveRecord. 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.

=DataMapper=
DataMapper is an Object Relational Mapper written in Ruby. The goal is to create an ORM which is fast, thread-safe and feature rich.
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 even some popular webservices.[datamapper.org]

'''Features'''-
*Eager loading of child associations to avoid (N+1) queries
*Lazy loading of select properties, e.g., larger fields
*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.[2] As a result, DataMapper adapters have been built for other non-SQL databases, such as CouchDB,[3] Apache Solr,[4] and web services such as Salesforce.[wikipedia]

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.

=Squeel=
Squeel unlocks the power of Arel in your Rails 3 application with a handy block-based syntax. You can write subqueries, access named functions provided by your RDBMS, and more, all without writing SQL strings. Squeel acts as an add on to Active Record and makes it easier to write queries with fewer strings.
A simple example is as follows:
Squeel lets you rewrite
<pre>
Article.where ['created_at >= ?', 2.weeks.ago]
</pre>
as
<pre>
Article.where{created_at >= 2.weeks.ago}
</pre>

=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. Follows below a MyBatis mapper, that consist on 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>

=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
|}

=NonSQL databases=
Instead of ORM we can also use 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 user from retrieving 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 in XML file.

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.

NoSQL 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

=Advantages of ORM=

*Facilitates implementing the Domain Model pattern that allows you to model entities based on real business concepts rather than based on our database structure. ORM tools provide this functionality through mapping between the logical business model and the physical storage model.

*Huge reduction in code. Ease of use, faster development, increased productivity.

*ORM tools provide a host of services thereby allowing developers to focus on the business logic of the application rather than repetitive CRUD (Create Read Update Delete) logic.

*Changes to the object model are made in one place. One you update your object definitions, the ORM will automatically use the updated structure for retrievals and updates. There are no SQL Update, Delete and Insert statements strewn throughout different layers of the application that need modification.

*Rich query capability. ORM tools provide an object oriented query language. This allows application developers to focus on the object model and not to have to be concerned with the database structure or SQL semantics. The ORM tool itself will translate the query language into the appropriate syntax for the database.

*Navigation. You can navigate object relationships transparently. Related objects are automatically loaded as needed. For example if you load a Post and you want to access it's Comment, you can simply access Post.Comment and the ORM will take care of loading the data for you without any effort on your part.

*Data loads are completely configurable allowing you to load the data appropriate for each scenario. For example in one scenario you might want to load a list of objects without any of it's child / related objects, while in other scenarios you can specify to load an object, with all it's children etc.

*Concurrency support. Support for multiple users updating the same data simultaneously.

*Cache management. Entities are cached in memory thereby reducing load on the database.

*Transaction management and Isolation. All object changes occur scoped to a transaction. The entire transaction can either be committed or rolled back. Multiple transactions can be active in memory in the same time, and each transactions changes are isolated form on another.

*Making data access more abstract and portable. ORM implementation classes know how to write vendor-specific SQL, so you don't have to.

=Disadvantages of ORM=

*High level of abstraction obscures as to what is actually happening in the code implementation.
*Loss in developer productivity whilst they learn to program with ORM.Developers lose understanding of what the code is actually doing - the developer is more in control using SQL.
*Heavy reliance on ORM also leads to poorly designed databases.
*Data and behaviour are not separated.
**Façade needs to be built if the data model is to be made available in a distributed architecture.
**Each ORM technology/product has a different set of APIs and porting code between them is not easy.
*The biggest advantage of ORM is also the biggest disadvantage: queries are generated automatically -
**Queries can’t be optimized.
**Queries select more data than needed, things get slower, more latency.
**Compiling queries from ORM code is slow (ORM compiler written in PHP).
**SQL is more powerful than ORM query languages.
**Database abstraction forbids vendor specific optimizations.

=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_Fall_2010/ch3_3j_KS Object-relational mapping Fall 2010] 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.Also, a detailed study of alternatives to ORM like the NoSQL databases and Document-oriented approach can be included.
=References=

# [http://en.wikipedia.org/wiki/Object-relational_mapping Wikipedia, Object-relational mapping (ORM)]
# [http://docforge.com/wiki/Object-relational_mapping Object-relational mapping]
# [http://en.wikipedia.org/wiki/Object-relational_impedance_mismatch Object-Relational Impedance Matching Problem]
# [http://www.hibernate.org/about/orm The Object-Relational Impedance Mismatch]
# [http://edgeguides.rubyonrails.org/active_record_basics.html#object-relational-mapping Active Record]
# [http://loianegroner.com/2011/02/introduction-to-ibatis-mybatis-an-alternative-to-hibernate-and-jdbc/ MyBatis/iBatis]
# [https://www.ruby-toolbox.com/categories/orm Squeel]
# [http://rubydoc.info/gems/squeel/1.1.1/frames Squeel]

CSC/ECE 517 Fall 2013/ch1 1w43 sm

2013-10-07T20:42:20Z

Mrsreena: /* References */

=Object Relational Mapping=

__TOC__

=Introduction=

[http://en.wikipedia.org/wiki/Object-relational_mapping Object-relational mapping (ORM)], or ORM, is a programming technique which associates data stored in a relational database with application objects. The ORM layer populates business objects on demand and persists them back into the relational database when updated.
ORM basically creates 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.In this wiki, we concenterate mainly on the top Ruby ORM's like Active Record,Sequel and DataMapper.Also, it includes a comparison of various ORM techniques and the advantages and disadvantages of various styles of ORM mapping.

=Need For ORM=
Need for ORM arose due to a major problem called the Object-Relational Impedance MisMatch Problem.
[http://en.wikipedia.org/wiki/Object-relational_impedance_mismatch Object-Relational Impedance MisMatch Problem] is a set of conceptual and technical difficulties, encountered when a relational database management system (RDBMS) is being used by an object-oriented program particularly when object/class definitions are mapped directly to database tables or schema.It implies that object models don't work together with relational models, i.e RDBMS represents data in tabular format while Object oriented languages represent data in the form of interconnected graph of objects.
The Mismatches that occur in Object-Oriented concepts are as follows:
*Encapsulation:
Mapping of private object representation to database tables is difficult due to availability of fewer constraints for the design of private representation as opposed to public data in RDBMS.
*Interface, Class, Inheritance and polymorphism:
Under an object-oriented paradigm, objects have interfaces that together provide the only access to the internals of that object. The relational model, on the other hand, utilizes derived relation variables (views) to provide varying perspectives and constraints to ensure integrity. Similarly, essential OOP concepts for classes of objects, inheritance and polymorphism are not supported by relational database systems.
*Identity:
RDBMS defines exactly one notion of 'sameness': the primary key. However, Object-oriented languages, for example Java, defines both object identity (a==b) and object equality (a.equals(b)).
*Associations:
Associations are represented as unidirectional references in Object Oriented languages whereas RDBMS uses the notion of foreign keys. For example, If you need bidirectional relationships in Java, you must define the association twice.Likewise, you cannot determine the multiplicity of a relationship by looking at the object domain model.
*Data navigation:
The way you access data in object-oriented languages is fundamentally different than the way you do it in a relational database. Like in Java, you navigate from one association to another walking the object network. This is not an efficient way of retrieving data from a relational database. You typically want to minimize the number of SQL queries and thus load several entities via JOINs and select the targeted entities before you start walking the object network.

=Overview=

Data management tasks in object-oriented (OO) programming are typically implemented by manipulating objects that are almost always non-scalar values. Like for example, Consider a Geometric object, an entity which can have shape and color.In the object oriented implementation, this entity would be modeled as a geometric object with shape and color as its attributes.Shape itself can contain objects like for triangles(equilateral or isosceles) and so on.Here each geometric object can be treated as a single object by any programming language and its attributes can be also accessed by various object methods.However, many popular database products such as structured query language database management systems (SQL DBMS) can only store and manipulate scalar values such as integers and strings organized within tables.

Hence, the programmer must either convert the object values into groups of simpler values for storage in the database (and convert them back upon retrieval), or only use simple scalar values within the program. Object-relational mapping is used to implement the first approach.The key is to translate the logical representation of the objects into an atomized form that is capable of being stored in the database, while somehow preserving the properties of the objects and their relationships so that they can be reloaded as an object whenever required. If this storage and retrieval functionality is implemented, the objects are then said to be persistent.

Object-Relational Mapping, commonly referred to as its abbreviation ORM, is a technique that connects the rich objects of an application to tables in a relational database management system. Using ORM, the properties and relationships of the objects in an application can be easily stored and retrieved from a database without writing SQL statements directly and with less overall database access code.

=Features=

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 makes access to database through the application extremely easy, as it provides connection from model of the program to the database.Treating database rows as objects, Program can easily access the information in more consistent manner.Also it gives flexibility to the programmers to manipulate the data with the language itself rather than working on the attributes retrieved from the database.

When applied to Ruby, implementations of ORM often leverage the language’s Meta-programming 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 needs to be extracted from the model and the database, and 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.

=Active Record=
[http://ar.rubyonrails.org/ ActiveRecord] insulates you from the need to use raw SQL to find database records.Active Record facilitates the creation and use of business objects whose data requires persistent storage to a database.

ActiveRecord is the default ‘model’ component of the model-view-controller web-application framework Ruby on Rails, and is also a stand-alone ORM package for other Ruby applications. In both forms, it was conceived of by David Heinemeier Hansson, and has been improved upon by a number of contributors.

Other, less popular ORMs have been released since ActiveRecord first took the stage. For example, DataMapper and Sequel show major improvements over the original ActiveRecord framework.[neutrality is disputed] As a response to their release and adoption by the Rails community, Ruby on Rails v3.0 is independent of an ORM system, so Rails users can easily plug in DataMapper or Sequel to use as their ORM of choice.[wiki]

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>

Note in the preceding example, that 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 whose 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]]

Active Record will perform queries on the database for you and is compatible with most database systems (MySQL, PostgreSQL and SQLite to name a few). Regardless of which database system you are using, the ActiveRecord method format will always be the same.
To retrieve objects from the database, Active Record provides several finder methods. Each finder method allows you to pass arguments into it to perform certain queries on your database without writing raw SQL.

'''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.

=Sequel=
[http://sequel.rubyforge.org Sequel] is designed to take the hassle away from connecting to databases and manipulating them. Sequel deals with all the boring stuff like maintaining connections, formatting SQL correctly and fetching records so you can concentrate on your application.
Sequel uses the concept of datasets to retrieve data. A Dataset object encapsulates an SQL query and supports chainability, letting you fetch data using a convenient Ruby DSL that is both concise and flexible.The current sequel version is 4.2.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.

Sequel::Model is an object relational mapper built on top of Sequel core. Each model class is backed by a dataset instance, and many dataset methods can be called directly on the class. Model datasets return rows as model instances, which have fairly standard ORM instance behavior.

Sequel::Model is built completely out of plugins. Plugins can override any class, instance, or dataset method defined by a previous plugin and call super to get the default behavior

'''Features''' -
*Sequel provides thread safety, connection pooling and a concise DSL for constructing SQL *queries and table schemas.
*Sequel includes a comprehensive ORM layer for mapping records to Ruby objects and handling associated records.
*Sequel supports advanced database features such as prepared statements, bound variables, stored procedures, savepoints, two-phase commit, transaction isolation, master/slave configurations, and database sharding.
*Sequel currently has adapters for ADO, Amalgalite, CUBRID, DataObjects, DB2, DBI, Firebird, IBM_DB, Informix, JDBC, MySQL, Mysql2, ODBC, OpenBase, Oracle, PostgreSQL, SQLite3, Swift, and TinyTDS.

<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 ActiveRecord. 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.

=DataMapper=
DataMapper is an Object Relational Mapper written in Ruby. The goal is to create an ORM which is fast, thread-safe and feature rich.
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 even some popular webservices.[datamapper.org]

'''Features'''-
*Eager loading of child associations to avoid (N+1) queries
*Lazy loading of select properties, e.g., larger fields
*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.[2] As a result, DataMapper adapters have been built for other non-SQL databases, such as CouchDB,[3] Apache Solr,[4] and web services such as Salesforce.[wikipedia]

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.

=Squeel=
Squeel unlocks the power of Arel in your Rails 3 application with a handy block-based syntax. You can write subqueries, access named functions provided by your RDBMS, and more, all without writing SQL strings. Squeel acts as an add on to Active Record and makes it easier to write queries with fewer strings.
A simple example is as follows:
Squeel lets you rewrite
<pre>
Article.where ['created_at >= ?', 2.weeks.ago]
</pre>
as
<pre>
Article.where{created_at >= 2.weeks.ago}
</pre>

=MyBatis/iBatis=
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. Follows below a MyBatis mapper, that consist on 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>
=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
|}

=NonSQL databases=
Instead of ORM we can also use 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 user from retrieving 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 in XML file.

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.

NoSQL 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

=Advantages of ORM=

*Facilitates implementing the Domain Model pattern that allows you to model entities based on real business concepts rather than based on our database structure. ORM tools provide this functionality through mapping between the logical business model and the physical storage model.

*Huge reduction in code. Ease of use, faster development, increased productivity.

*ORM tools provide a host of services thereby allowing developers to focus on the business logic of the application rather than repetitive CRUD (Create Read Update Delete) logic.

*Changes to the object model are made in one place. One you update your object definitions, the ORM will automatically use the updated structure for retrievals and updates. There are no SQL Update, Delete and Insert statements strewn throughout different layers of the application that need modification.

*Rich query capability. ORM tools provide an object oriented query language. This allows application developers to focus on the object model and not to have to be concerned with the database structure or SQL semantics. The ORM tool itself will translate the query language into the appropriate syntax for the database.

*Navigation. You can navigate object relationships transparently. Related objects are automatically loaded as needed. For example if you load a Post and you want to access it's Comment, you can simply access Post.Comment and the ORM will take care of loading the data for you without any effort on your part.

*Data loads are completely configurable allowing you to load the data appropriate for each scenario. For example in one scenario you might want to load a list of objects without any of it's child / related objects, while in other scenarios you can specify to load an object, with all it's children etc.

*Concurrency support. Support for multiple users updating the same data simultaneously.

*Cache management. Entities are cached in memory thereby reducing load on the database.

*Transaction management and Isolation. All object changes occur scoped to a transaction. The entire transaction can either be committed or rolled back. Multiple transactions can be active in memory in the same time, and each transactions changes are isolated form on another.

*Making data access more abstract and portable. ORM implementation classes know how to write vendor-specific SQL, so you don't have to.

=Disadvantages of ORM=

*High level of abstraction obscures as to what is actually happening in the code implementation.
*Loss in developer productivity whilst they learn to program with ORM.Developers lose understanding of what the code is actually doing - the developer is more in control using SQL.
*Heavy reliance on ORM also leads to poorly designed databases.
*Data and behaviour are not separated.
**Façade needs to be built if the data model is to be made available in a distributed architecture.
**Each ORM technology/product has a different set of APIs and porting code between them is not easy.
*The biggest advantage of ORM is also the biggest disadvantage: queries are generated automatically -
**Queries can’t be optimized.
**Queries select more data than needed, things get slower, more latency.
**Compiling queries from ORM code is slow (ORM compiler written in PHP).
**SQL is more powerful than ORM query languages.
**Database abstraction forbids vendor specific optimizations.

=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_Fall_2010/ch3_3j_KS Object-relational mapping Fall 2010] 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.Also, a detailed study of alternatives to ORM like the NoSQL databases and Document-oriented approach can be included.
=References=

# [http://en.wikipedia.org/wiki/Object-relational_mapping Wikipedia, Object-relational mapping (ORM)]
# [http://docforge.com/wiki/Object-relational_mapping Object-relational mapping]
# [http://en.wikipedia.org/wiki/Object-relational_impedance_mismatch Object-Relational Impedance Matching Problem]
# [http://www.hibernate.org/about/orm The Object-Relational Impedance Mismatch]
# [http://edgeguides.rubyonrails.org/active_record_basics.html#object-relational-mapping Active Record]
# [http://loianegroner.com/2011/02/introduction-to-ibatis-mybatis-an-alternative-to-hibernate-and-jdbc/ MyBatis/iBatis]
# [https://www.ruby-toolbox.com/categories/orm Squeel]
# [http://rubydoc.info/gems/squeel/1.1.1/frames Squeel]

CSC/ECE 517 Fall 2013/ch1 1w43 sm

2013-10-07T20:41:53Z

Mrsreena: /* References */

=Object Relational Mapping=

__TOC__

=Introduction=

[http://en.wikipedia.org/wiki/Object-relational_mapping Object-relational mapping (ORM)], or ORM, is a programming technique which associates data stored in a relational database with application objects. The ORM layer populates business objects on demand and persists them back into the relational database when updated.
ORM basically creates 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.In this wiki, we concenterate mainly on the top Ruby ORM's like Active Record,Sequel and DataMapper.Also, it includes a comparison of various ORM techniques and the advantages and disadvantages of various styles of ORM mapping.

=Need For ORM=
Need for ORM arose due to a major problem called the Object-Relational Impedance MisMatch Problem.
[http://en.wikipedia.org/wiki/Object-relational_impedance_mismatch Object-Relational Impedance MisMatch Problem] is a set of conceptual and technical difficulties, encountered when a relational database management system (RDBMS) is being used by an object-oriented program particularly when object/class definitions are mapped directly to database tables or schema.It implies that object models don't work together with relational models, i.e RDBMS represents data in tabular format while Object oriented languages represent data in the form of interconnected graph of objects.
The Mismatches that occur in Object-Oriented concepts are as follows:
*Encapsulation:
Mapping of private object representation to database tables is difficult due to availability of fewer constraints for the design of private representation as opposed to public data in RDBMS.
*Interface, Class, Inheritance and polymorphism:
Under an object-oriented paradigm, objects have interfaces that together provide the only access to the internals of that object. The relational model, on the other hand, utilizes derived relation variables (views) to provide varying perspectives and constraints to ensure integrity. Similarly, essential OOP concepts for classes of objects, inheritance and polymorphism are not supported by relational database systems.
*Identity:
RDBMS defines exactly one notion of 'sameness': the primary key. However, Object-oriented languages, for example Java, defines both object identity (a==b) and object equality (a.equals(b)).
*Associations:
Associations are represented as unidirectional references in Object Oriented languages whereas RDBMS uses the notion of foreign keys. For example, If you need bidirectional relationships in Java, you must define the association twice.Likewise, you cannot determine the multiplicity of a relationship by looking at the object domain model.
*Data navigation:
The way you access data in object-oriented languages is fundamentally different than the way you do it in a relational database. Like in Java, you navigate from one association to another walking the object network. This is not an efficient way of retrieving data from a relational database. You typically want to minimize the number of SQL queries and thus load several entities via JOINs and select the targeted entities before you start walking the object network.

=Overview=

Data management tasks in object-oriented (OO) programming are typically implemented by manipulating objects that are almost always non-scalar values. Like for example, Consider a Geometric object, an entity which can have shape and color.In the object oriented implementation, this entity would be modeled as a geometric object with shape and color as its attributes.Shape itself can contain objects like for triangles(equilateral or isosceles) and so on.Here each geometric object can be treated as a single object by any programming language and its attributes can be also accessed by various object methods.However, many popular database products such as structured query language database management systems (SQL DBMS) can only store and manipulate scalar values such as integers and strings organized within tables.

Hence, the programmer must either convert the object values into groups of simpler values for storage in the database (and convert them back upon retrieval), or only use simple scalar values within the program. Object-relational mapping is used to implement the first approach.The key is to translate the logical representation of the objects into an atomized form that is capable of being stored in the database, while somehow preserving the properties of the objects and their relationships so that they can be reloaded as an object whenever required. If this storage and retrieval functionality is implemented, the objects are then said to be persistent.

Object-Relational Mapping, commonly referred to as its abbreviation ORM, is a technique that connects the rich objects of an application to tables in a relational database management system. Using ORM, the properties and relationships of the objects in an application can be easily stored and retrieved from a database without writing SQL statements directly and with less overall database access code.

=Features=

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 makes access to database through the application extremely easy, as it provides connection from model of the program to the database.Treating database rows as objects, Program can easily access the information in more consistent manner.Also it gives flexibility to the programmers to manipulate the data with the language itself rather than working on the attributes retrieved from the database.

When applied to Ruby, implementations of ORM often leverage the language’s Meta-programming 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 needs to be extracted from the model and the database, and 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.

=Active Record=
[http://ar.rubyonrails.org/ ActiveRecord] insulates you from the need to use raw SQL to find database records.Active Record facilitates the creation and use of business objects whose data requires persistent storage to a database.

ActiveRecord is the default ‘model’ component of the model-view-controller web-application framework Ruby on Rails, and is also a stand-alone ORM package for other Ruby applications. In both forms, it was conceived of by David Heinemeier Hansson, and has been improved upon by a number of contributors.

Other, less popular ORMs have been released since ActiveRecord first took the stage. For example, DataMapper and Sequel show major improvements over the original ActiveRecord framework.[neutrality is disputed] As a response to their release and adoption by the Rails community, Ruby on Rails v3.0 is independent of an ORM system, so Rails users can easily plug in DataMapper or Sequel to use as their ORM of choice.[wiki]

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>

Note in the preceding example, that 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 whose 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]]

Active Record will perform queries on the database for you and is compatible with most database systems (MySQL, PostgreSQL and SQLite to name a few). Regardless of which database system you are using, the ActiveRecord method format will always be the same.
To retrieve objects from the database, Active Record provides several finder methods. Each finder method allows you to pass arguments into it to perform certain queries on your database without writing raw SQL.

'''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.

=Sequel=
[http://sequel.rubyforge.org Sequel] is designed to take the hassle away from connecting to databases and manipulating them. Sequel deals with all the boring stuff like maintaining connections, formatting SQL correctly and fetching records so you can concentrate on your application.
Sequel uses the concept of datasets to retrieve data. A Dataset object encapsulates an SQL query and supports chainability, letting you fetch data using a convenient Ruby DSL that is both concise and flexible.The current sequel version is 4.2.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.

Sequel::Model is an object relational mapper built on top of Sequel core. Each model class is backed by a dataset instance, and many dataset methods can be called directly on the class. Model datasets return rows as model instances, which have fairly standard ORM instance behavior.

Sequel::Model is built completely out of plugins. Plugins can override any class, instance, or dataset method defined by a previous plugin and call super to get the default behavior

'''Features''' -
*Sequel provides thread safety, connection pooling and a concise DSL for constructing SQL *queries and table schemas.
*Sequel includes a comprehensive ORM layer for mapping records to Ruby objects and handling associated records.
*Sequel supports advanced database features such as prepared statements, bound variables, stored procedures, savepoints, two-phase commit, transaction isolation, master/slave configurations, and database sharding.
*Sequel currently has adapters for ADO, Amalgalite, CUBRID, DataObjects, DB2, DBI, Firebird, IBM_DB, Informix, JDBC, MySQL, Mysql2, ODBC, OpenBase, Oracle, PostgreSQL, SQLite3, Swift, and TinyTDS.

<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 ActiveRecord. 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.

=DataMapper=
DataMapper is an Object Relational Mapper written in Ruby. The goal is to create an ORM which is fast, thread-safe and feature rich.
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 even some popular webservices.[datamapper.org]

'''Features'''-
*Eager loading of child associations to avoid (N+1) queries
*Lazy loading of select properties, e.g., larger fields
*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.[2] As a result, DataMapper adapters have been built for other non-SQL databases, such as CouchDB,[3] Apache Solr,[4] and web services such as Salesforce.[wikipedia]

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.

=Squeel=
Squeel unlocks the power of Arel in your Rails 3 application with a handy block-based syntax. You can write subqueries, access named functions provided by your RDBMS, and more, all without writing SQL strings. Squeel acts as an add on to Active Record and makes it easier to write queries with fewer strings.
A simple example is as follows:
Squeel lets you rewrite
<pre>
Article.where ['created_at >= ?', 2.weeks.ago]
</pre>
as
<pre>
Article.where{created_at >= 2.weeks.ago}
</pre>

=MyBatis/iBatis=
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. Follows below a MyBatis mapper, that consist on 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>
=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
|}

=NonSQL databases=
Instead of ORM we can also use 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 user from retrieving 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 in XML file.

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.

NoSQL 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

=Advantages of ORM=

*Facilitates implementing the Domain Model pattern that allows you to model entities based on real business concepts rather than based on our database structure. ORM tools provide this functionality through mapping between the logical business model and the physical storage model.

*Huge reduction in code. Ease of use, faster development, increased productivity.

*ORM tools provide a host of services thereby allowing developers to focus on the business logic of the application rather than repetitive CRUD (Create Read Update Delete) logic.

*Changes to the object model are made in one place. One you update your object definitions, the ORM will automatically use the updated structure for retrievals and updates. There are no SQL Update, Delete and Insert statements strewn throughout different layers of the application that need modification.

*Rich query capability. ORM tools provide an object oriented query language. This allows application developers to focus on the object model and not to have to be concerned with the database structure or SQL semantics. The ORM tool itself will translate the query language into the appropriate syntax for the database.

*Navigation. You can navigate object relationships transparently. Related objects are automatically loaded as needed. For example if you load a Post and you want to access it's Comment, you can simply access Post.Comment and the ORM will take care of loading the data for you without any effort on your part.

*Data loads are completely configurable allowing you to load the data appropriate for each scenario. For example in one scenario you might want to load a list of objects without any of it's child / related objects, while in other scenarios you can specify to load an object, with all it's children etc.

*Concurrency support. Support for multiple users updating the same data simultaneously.

*Cache management. Entities are cached in memory thereby reducing load on the database.

*Transaction management and Isolation. All object changes occur scoped to a transaction. The entire transaction can either be committed or rolled back. Multiple transactions can be active in memory in the same time, and each transactions changes are isolated form on another.

*Making data access more abstract and portable. ORM implementation classes know how to write vendor-specific SQL, so you don't have to.

=Disadvantages of ORM=

*High level of abstraction obscures as to what is actually happening in the code implementation.
*Loss in developer productivity whilst they learn to program with ORM.Developers lose understanding of what the code is actually doing - the developer is more in control using SQL.
*Heavy reliance on ORM also leads to poorly designed databases.
*Data and behaviour are not separated.
**Façade needs to be built if the data model is to be made available in a distributed architecture.
**Each ORM technology/product has a different set of APIs and porting code between them is not easy.
*The biggest advantage of ORM is also the biggest disadvantage: queries are generated automatically -
**Queries can’t be optimized.
**Queries select more data than needed, things get slower, more latency.
**Compiling queries from ORM code is slow (ORM compiler written in PHP).
**SQL is more powerful than ORM query languages.
**Database abstraction forbids vendor specific optimizations.

=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_Fall_2010/ch3_3j_KS Object-relational mapping Fall 2010] 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.Also, a detailed study of alternatives to ORM like the NoSQL databases and Document-oriented approach can be included.
=References=

# [http://en.wikipedia.org/wiki/Object-relational_mapping Wikipedia, Object-relational mapping (ORM)]
# [http://docforge.com/wiki/Object-relational_mapping Object-relational mapping]
# [http://en.wikipedia.org/wiki/Object-relational_impedance_mismatch Object-Relational Impedance Matching Problem]
# [http://www.hibernate.org/about/orm The Object-Relational Impedance Mismatch]
# [http://edgeguides.rubyonrails.org/active_record_basics.html#object-relational-mapping Active Record]
# [http://loianegroner.com/2011/02/introduction-to-ibatis-mybatis-an-alternative-to-hibernate-and-jdbc/ MyBatis/iBatis]
# [http://en.wikipedia.org/wiki/MyBatis MyBatis/iBatis]
# [https://www.ruby-toolbox.com/categories/orm Squeel]
# [http://rubydoc.info/gems/squeel/1.1.1/frames Squeel]

CSC/ECE 517 Fall 2013/ch1 1w43 sm

2013-10-07T20:40:49Z

Mrsreena: /* References */

=Object Relational Mapping=

__TOC__

=Introduction=

[http://en.wikipedia.org/wiki/Object-relational_mapping Object-relational mapping (ORM)], or ORM, is a programming technique which associates data stored in a relational database with application objects. The ORM layer populates business objects on demand and persists them back into the relational database when updated.
ORM basically creates 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.In this wiki, we concenterate mainly on the top Ruby ORM's like Active Record,Sequel and DataMapper.Also, it includes a comparison of various ORM techniques and the advantages and disadvantages of various styles of ORM mapping.

=Need For ORM=
Need for ORM arose due to a major problem called the Object-Relational Impedance MisMatch Problem.
[http://en.wikipedia.org/wiki/Object-relational_impedance_mismatch Object-Relational Impedance MisMatch Problem] is a set of conceptual and technical difficulties, encountered when a relational database management system (RDBMS) is being used by an object-oriented program particularly when object/class definitions are mapped directly to database tables or schema.It implies that object models don't work together with relational models, i.e RDBMS represents data in tabular format while Object oriented languages represent data in the form of interconnected graph of objects.
The Mismatches that occur in Object-Oriented concepts are as follows:
*Encapsulation:
Mapping of private object representation to database tables is difficult due to availability of fewer constraints for the design of private representation as opposed to public data in RDBMS.
*Interface, Class, Inheritance and polymorphism:
Under an object-oriented paradigm, objects have interfaces that together provide the only access to the internals of that object. The relational model, on the other hand, utilizes derived relation variables (views) to provide varying perspectives and constraints to ensure integrity. Similarly, essential OOP concepts for classes of objects, inheritance and polymorphism are not supported by relational database systems.
*Identity:
RDBMS defines exactly one notion of 'sameness': the primary key. However, Object-oriented languages, for example Java, defines both object identity (a==b) and object equality (a.equals(b)).
*Associations:
Associations are represented as unidirectional references in Object Oriented languages whereas RDBMS uses the notion of foreign keys. For example, If you need bidirectional relationships in Java, you must define the association twice.Likewise, you cannot determine the multiplicity of a relationship by looking at the object domain model.
*Data navigation:
The way you access data in object-oriented languages is fundamentally different than the way you do it in a relational database. Like in Java, you navigate from one association to another walking the object network. This is not an efficient way of retrieving data from a relational database. You typically want to minimize the number of SQL queries and thus load several entities via JOINs and select the targeted entities before you start walking the object network.

=Overview=

Data management tasks in object-oriented (OO) programming are typically implemented by manipulating objects that are almost always non-scalar values. Like for example, Consider a Geometric object, an entity which can have shape and color.In the object oriented implementation, this entity would be modeled as a geometric object with shape and color as its attributes.Shape itself can contain objects like for triangles(equilateral or isosceles) and so on.Here each geometric object can be treated as a single object by any programming language and its attributes can be also accessed by various object methods.However, many popular database products such as structured query language database management systems (SQL DBMS) can only store and manipulate scalar values such as integers and strings organized within tables.

Hence, the programmer must either convert the object values into groups of simpler values for storage in the database (and convert them back upon retrieval), or only use simple scalar values within the program. Object-relational mapping is used to implement the first approach.The key is to translate the logical representation of the objects into an atomized form that is capable of being stored in the database, while somehow preserving the properties of the objects and their relationships so that they can be reloaded as an object whenever required. If this storage and retrieval functionality is implemented, the objects are then said to be persistent.

Object-Relational Mapping, commonly referred to as its abbreviation ORM, is a technique that connects the rich objects of an application to tables in a relational database management system. Using ORM, the properties and relationships of the objects in an application can be easily stored and retrieved from a database without writing SQL statements directly and with less overall database access code.

=Features=

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 makes access to database through the application extremely easy, as it provides connection from model of the program to the database.Treating database rows as objects, Program can easily access the information in more consistent manner.Also it gives flexibility to the programmers to manipulate the data with the language itself rather than working on the attributes retrieved from the database.

When applied to Ruby, implementations of ORM often leverage the language’s Meta-programming 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 needs to be extracted from the model and the database, and 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.

=Active Record=
[http://ar.rubyonrails.org/ ActiveRecord] insulates you from the need to use raw SQL to find database records.Active Record facilitates the creation and use of business objects whose data requires persistent storage to a database.

ActiveRecord is the default ‘model’ component of the model-view-controller web-application framework Ruby on Rails, and is also a stand-alone ORM package for other Ruby applications. In both forms, it was conceived of by David Heinemeier Hansson, and has been improved upon by a number of contributors.

Other, less popular ORMs have been released since ActiveRecord first took the stage. For example, DataMapper and Sequel show major improvements over the original ActiveRecord framework.[neutrality is disputed] As a response to their release and adoption by the Rails community, Ruby on Rails v3.0 is independent of an ORM system, so Rails users can easily plug in DataMapper or Sequel to use as their ORM of choice.[wiki]

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>

Note in the preceding example, that 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 whose 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]]

Active Record will perform queries on the database for you and is compatible with most database systems (MySQL, PostgreSQL and SQLite to name a few). Regardless of which database system you are using, the ActiveRecord method format will always be the same.
To retrieve objects from the database, Active Record provides several finder methods. Each finder method allows you to pass arguments into it to perform certain queries on your database without writing raw SQL.

'''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.

=Sequel=
[http://sequel.rubyforge.org Sequel] is designed to take the hassle away from connecting to databases and manipulating them. Sequel deals with all the boring stuff like maintaining connections, formatting SQL correctly and fetching records so you can concentrate on your application.
Sequel uses the concept of datasets to retrieve data. A Dataset object encapsulates an SQL query and supports chainability, letting you fetch data using a convenient Ruby DSL that is both concise and flexible.The current sequel version is 4.2.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.

Sequel::Model is an object relational mapper built on top of Sequel core. Each model class is backed by a dataset instance, and many dataset methods can be called directly on the class. Model datasets return rows as model instances, which have fairly standard ORM instance behavior.

Sequel::Model is built completely out of plugins. Plugins can override any class, instance, or dataset method defined by a previous plugin and call super to get the default behavior

'''Features''' -
*Sequel provides thread safety, connection pooling and a concise DSL for constructing SQL *queries and table schemas.
*Sequel includes a comprehensive ORM layer for mapping records to Ruby objects and handling associated records.
*Sequel supports advanced database features such as prepared statements, bound variables, stored procedures, savepoints, two-phase commit, transaction isolation, master/slave configurations, and database sharding.
*Sequel currently has adapters for ADO, Amalgalite, CUBRID, DataObjects, DB2, DBI, Firebird, IBM_DB, Informix, JDBC, MySQL, Mysql2, ODBC, OpenBase, Oracle, PostgreSQL, SQLite3, Swift, and TinyTDS.[sequel.rubyforge]

<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.

=DataMapper=
DataMapper is an Object Relational Mapper written in Ruby. The goal is to create an ORM which is fast, thread-safe and feature rich.
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 even some popular webservices.[datamapper.org]

'''Features'''-
*Eager loading of child associations to avoid (N+1) queries
*Lazy loading of select properties, e.g., larger fields
*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.[2] As a result, DataMapper adapters have been built for other non-SQL databases, such as CouchDB,[3] Apache Solr,[4] and web services such as Salesforce.[wikipedia]

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.

=Squeel=
Squeel unlocks the power of Arel in your Rails 3 application with a handy block-based syntax. You can write subqueries, access named functions provided by your RDBMS, and more, all without writing SQL strings. Squeel acts as an add on to Active Record and makes it easier to write queries with fewer strings.
A simple example is as follows:
Squeel lets you rewrite
<pre>
Article.where ['created_at >= ?', 2.weeks.ago]
</pre>
as
<pre>
Article.where{created_at >= 2.weeks.ago}
</pre>

=MyBatis/iBatis=
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. Follows below a MyBatis mapper, that consist on 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>
=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
|}

=NonSQL databases=
Instead of ORM we can also use 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 user from retrieving 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 in XML file.

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.

NoSQL 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

=Advantages of ORM=

*Facilitates implementing the Domain Model pattern that allows you to model entities based on real business concepts rather than based on our database structure. ORM tools provide this functionality through mapping between the logical business model and the physical storage model.

*Huge reduction in code. Ease of use, faster development, increased productivity.

*ORM tools provide a host of services thereby allowing developers to focus on the business logic of the application rather than repetitive CRUD (Create Read Update Delete) logic.

*Changes to the object model are made in one place. One you update your object definitions, the ORM will automatically use the updated structure for retrievals and updates. There are no SQL Update, Delete and Insert statements strewn throughout different layers of the application that need modification.

*Rich query capability. ORM tools provide an object oriented query language. This allows application developers to focus on the object model and not to have to be concerned with the database structure or SQL semantics. The ORM tool itself will translate the query language into the appropriate syntax for the database.

*Navigation. You can navigate object relationships transparently. Related objects are automatically loaded as needed. For example if you load a Post and you want to access it's Comment, you can simply access Post.Comment and the ORM will take care of loading the data for you without any effort on your part.

*Data loads are completely configurable allowing you to load the data appropriate for each scenario. For example in one scenario you might want to load a list of objects without any of it's child / related objects, while in other scenarios you can specify to load an object, with all it's children etc.

*Concurrency support. Support for multiple users updating the same data simultaneously.

*Cache management. Entities are cached in memory thereby reducing load on the database.

*Transaction management and Isolation. All object changes occur scoped to a transaction. The entire transaction can either be committed or rolled back. Multiple transactions can be active in memory in the same time, and each transactions changes are isolated form on another.

*Making data access more abstract and portable. ORM implementation classes know how to write vendor-specific SQL, so you don't have to.

=Disadvantages of ORM=

*High level of abstraction obscures as to what is actually happening in the code implementation.
*Loss in developer productivity whilst they learn to program with ORM.Developers lose understanding of what the code is actually doing - the developer is more in control using SQL.
*Heavy reliance on ORM also leads to poorly designed databases.
*Data and behaviour are not separated.
**Façade needs to be built if the data model is to be made available in a distributed architecture.
**Each ORM technology/product has a different set of APIs and porting code between them is not easy.
*The biggest advantage of ORM is also the biggest disadvantage: queries are generated automatically -
**Queries can’t be optimized.
**Queries select more data than needed, things get slower, more latency.
**Compiling queries from ORM code is slow (ORM compiler written in PHP).
**SQL is more powerful than ORM query languages.
**Database abstraction forbids vendor specific optimizations.

=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_Fall_2010/ch3_3j_KS Object-relational mapping Fall 2010] 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.Also, a detailed study of alternatives to ORM like the NoSQL databases and Document-oriented approach can be included.
=References=

# [http://en.wikipedia.org/wiki/Object-relational_mapping Wikipedia, Object-relational mapping (ORM)]
# [http://docforge.com/wiki/Object-relational_mapping Object-relational mapping]
# [http://en.wikipedia.org/wiki/Object-relational_impedance_mismatch Object-Relational Impedance Matching Problem]
# [http://www.hibernate.org/about/orm The Object-Relational Impedance Mismatch]
# [http://edgeguides.rubyonrails.org/active_record_basics.html#object-relational-mapping Active Record]
# [http://loianegroner.com/2011/02/introduction-to-ibatis-mybatis-an-alternative-to-hibernate-and-jdbc/]
# [http://en.wikipedia.org/wiki/MyBatis]
# [https://www.ruby-toolbox.com/categories/orm]
# [http://rubydoc.info/gems/squeel/1.1.1/frames]

CSC/ECE 517 Fall 2013/ch1 1w43 sm

2013-10-07T20:39:04Z

Mrsreena: /* Disadvantages of ORM */

=Object Relational Mapping=

__TOC__

=Introduction=

[http://en.wikipedia.org/wiki/Object-relational_mapping Object-relational mapping (ORM)], or ORM, is a programming technique which associates data stored in a relational database with application objects. The ORM layer populates business objects on demand and persists them back into the relational database when updated.
ORM basically creates 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.In this wiki, we concenterate mainly on the top Ruby ORM's like Active Record,Sequel and DataMapper.Also, it includes a comparison of various ORM techniques and the advantages and disadvantages of various styles of ORM mapping.

=Need For ORM=
Need for ORM arose due to a major problem called the Object-Relational Impedance MisMatch Problem.
[http://en.wikipedia.org/wiki/Object-relational_impedance_mismatch Object-Relational Impedance MisMatch Problem] is a set of conceptual and technical difficulties, encountered when a relational database management system (RDBMS) is being used by an object-oriented program particularly when object/class definitions are mapped directly to database tables or schema.It implies that object models don't work together with relational models, i.e RDBMS represents data in tabular format while Object oriented languages represent data in the form of interconnected graph of objects.
The Mismatches that occur in Object-Oriented concepts are as follows:
*Encapsulation:
Mapping of private object representation to database tables is difficult due to availability of fewer constraints for the design of private representation as opposed to public data in RDBMS.
*Interface, Class, Inheritance and polymorphism:
Under an object-oriented paradigm, objects have interfaces that together provide the only access to the internals of that object. The relational model, on the other hand, utilizes derived relation variables (views) to provide varying perspectives and constraints to ensure integrity. Similarly, essential OOP concepts for classes of objects, inheritance and polymorphism are not supported by relational database systems.
*Identity:
RDBMS defines exactly one notion of 'sameness': the primary key. However, Object-oriented languages, for example Java, defines both object identity (a==b) and object equality (a.equals(b)).
*Associations:
Associations are represented as unidirectional references in Object Oriented languages whereas RDBMS uses the notion of foreign keys. For example, If you need bidirectional relationships in Java, you must define the association twice.Likewise, you cannot determine the multiplicity of a relationship by looking at the object domain model.
*Data navigation:
The way you access data in object-oriented languages is fundamentally different than the way you do it in a relational database. Like in Java, you navigate from one association to another walking the object network. This is not an efficient way of retrieving data from a relational database. You typically want to minimize the number of SQL queries and thus load several entities via JOINs and select the targeted entities before you start walking the object network.

=Overview=

Data management tasks in object-oriented (OO) programming are typically implemented by manipulating objects that are almost always non-scalar values. Like for example, Consider a Geometric object, an entity which can have shape and color.In the object oriented implementation, this entity would be modeled as a geometric object with shape and color as its attributes.Shape itself can contain objects like for triangles(equilateral or isosceles) and so on.Here each geometric object can be treated as a single object by any programming language and its attributes can be also accessed by various object methods.However, many popular database products such as structured query language database management systems (SQL DBMS) can only store and manipulate scalar values such as integers and strings organized within tables.

Hence, the programmer must either convert the object values into groups of simpler values for storage in the database (and convert them back upon retrieval), or only use simple scalar values within the program. Object-relational mapping is used to implement the first approach.The key is to translate the logical representation of the objects into an atomized form that is capable of being stored in the database, while somehow preserving the properties of the objects and their relationships so that they can be reloaded as an object whenever required. If this storage and retrieval functionality is implemented, the objects are then said to be persistent.

Object-Relational Mapping, commonly referred to as its abbreviation ORM, is a technique that connects the rich objects of an application to tables in a relational database management system. Using ORM, the properties and relationships of the objects in an application can be easily stored and retrieved from a database without writing SQL statements directly and with less overall database access code.

=Features=

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 makes access to database through the application extremely easy, as it provides connection from model of the program to the database.Treating database rows as objects, Program can easily access the information in more consistent manner.Also it gives flexibility to the programmers to manipulate the data with the language itself rather than working on the attributes retrieved from the database.

When applied to Ruby, implementations of ORM often leverage the language’s Meta-programming 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 needs to be extracted from the model and the database, and 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.

=Active Record=
[http://ar.rubyonrails.org/ ActiveRecord] insulates you from the need to use raw SQL to find database records.Active Record facilitates the creation and use of business objects whose data requires persistent storage to a database.

ActiveRecord is the default ‘model’ component of the model-view-controller web-application framework Ruby on Rails, and is also a stand-alone ORM package for other Ruby applications. In both forms, it was conceived of by David Heinemeier Hansson, and has been improved upon by a number of contributors.

Other, less popular ORMs have been released since ActiveRecord first took the stage. For example, DataMapper and Sequel show major improvements over the original ActiveRecord framework.[neutrality is disputed] As a response to their release and adoption by the Rails community, Ruby on Rails v3.0 is independent of an ORM system, so Rails users can easily plug in DataMapper or Sequel to use as their ORM of choice.[wiki]

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>

Note in the preceding example, that 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 whose 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]]

Active Record will perform queries on the database for you and is compatible with most database systems (MySQL, PostgreSQL and SQLite to name a few). Regardless of which database system you are using, the ActiveRecord method format will always be the same.
To retrieve objects from the database, Active Record provides several finder methods. Each finder method allows you to pass arguments into it to perform certain queries on your database without writing raw SQL.

'''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.

=Sequel=
[http://sequel.rubyforge.org Sequel] is designed to take the hassle away from connecting to databases and manipulating them. Sequel deals with all the boring stuff like maintaining connections, formatting SQL correctly and fetching records so you can concentrate on your application.
Sequel uses the concept of datasets to retrieve data. A Dataset object encapsulates an SQL query and supports chainability, letting you fetch data using a convenient Ruby DSL that is both concise and flexible.The current sequel version is 4.2.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.

Sequel::Model is an object relational mapper built on top of Sequel core. Each model class is backed by a dataset instance, and many dataset methods can be called directly on the class. Model datasets return rows as model instances, which have fairly standard ORM instance behavior.

Sequel::Model is built completely out of plugins. Plugins can override any class, instance, or dataset method defined by a previous plugin and call super to get the default behavior

'''Features''' -

*Sequel provides thread safety, connection pooling and a concise DSL for constructing SQL *queries and table schemas.
*Sequel includes a comprehensive ORM layer for mapping records to Ruby objects and handling associated records.
*Sequel supports advanced database features such as prepared statements, bound variables, stored procedures, savepoints, two-phase commit, transaction isolation, master/slave configurations, and database sharding.
*Sequel currently has adapters for ADO, Amalgalite, CUBRID, DataObjects, DB2, DBI, Firebird, IBM_DB, Informix, JDBC, MySQL, Mysql2, ODBC, OpenBase, Oracle, PostgreSQL, SQLite3, Swift, and TinyTDS.[sequel.rubyforge]

<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.

=DataMapper=
DataMapper is an Object Relational Mapper written in Ruby. The goal is to create an ORM which is fast, thread-safe and feature rich.
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 even some popular webservices.[datamapper.org]

'''Features'''-
*Eager loading of child associations to avoid (N+1) queries
*Lazy loading of select properties, e.g., larger fields
*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.[2] As a result, DataMapper adapters have been built for other non-SQL databases, such as CouchDB,[3] Apache Solr,[4] and web services such as Salesforce.[wikipedia]

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.

=Squeel=
Squeel unlocks the power of Arel in your Rails 3 application with a handy block-based syntax. You can write subqueries, access named functions provided by your RDBMS, and more, all without writing SQL strings. Squeel acts as an add on to Active Record and makes it easier to write queries with fewer strings.
A simple example is as follows:
Squeel lets you rewrite
<pre>
Article.where ['created_at >= ?', 2.weeks.ago]
</pre>
as
<pre>
Article.where{created_at >= 2.weeks.ago}
</pre>

=MyBatis/iBatis=
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. Follows below a MyBatis mapper, that consist on 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>
=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
|}

=NonSQL databases=
Instead of ORM we can also use 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 user from retrieving 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 in XML file.

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.

NoSQL 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

=Advantages of ORM=

*Facilitates implementing the Domain Model pattern that allows you to model entities based on real business concepts rather than based on our database structure. ORM tools provide this functionality through mapping between the logical business model and the physical storage model.

*Huge reduction in code. Ease of use, faster development, increased productivity.

*ORM tools provide a host of services thereby allowing developers to focus on the business logic of the application rather than repetitive CRUD (Create Read Update Delete) logic.

*Changes to the object model are made in one place. One you update your object definitions, the ORM will automatically use the updated structure for retrievals and updates. There are no SQL Update, Delete and Insert statements strewn throughout different layers of the application that need modification.

*Rich query capability. ORM tools provide an object oriented query language. This allows application developers to focus on the object model and not to have to be concerned with the database structure or SQL semantics. The ORM tool itself will translate the query language into the appropriate syntax for the database.

*Navigation. You can navigate object relationships transparently. Related objects are automatically loaded as needed. For example if you load a Post and you want to access it's Comment, you can simply access Post.Comment and the ORM will take care of loading the data for you without any effort on your part.

*Data loads are completely configurable allowing you to load the data appropriate for each scenario. For example in one scenario you might want to load a list of objects without any of it's child / related objects, while in other scenarios you can specify to load an object, with all it's children etc.

*Concurrency support. Support for multiple users updating the same data simultaneously.

*Cache management. Entities are cached in memory thereby reducing load on the database.

*Transaction management and Isolation. All object changes occur scoped to a transaction. The entire transaction can either be committed or rolled back. Multiple transactions can be active in memory in the same time, and each transactions changes are isolated form on another.

*Making data access more abstract and portable. ORM implementation classes know how to write vendor-specific SQL, so you don't have to.

=Disadvantages of ORM=

*High level of abstraction obscures as to what is actually happening in the code implementation.
*Loss in developer productivity whilst they learn to program with ORM.Developers lose understanding of what the code is actually doing - the developer is more in control using SQL.
*Heavy reliance on ORM also leads to poorly designed databases.
*Data and behaviour are not separated.
**Façade needs to be built if the data model is to be made available in a distributed architecture.
**Each ORM technology/product has a different set of APIs and porting code between them is not easy.
*The biggest advantage of ORM is also the biggest disadvantage: queries are generated automatically -
**Queries can’t be optimized.
**Queries select more data than needed, things get slower, more latency.
**Compiling queries from ORM code is slow (ORM compiler written in PHP).
**SQL is more powerful than ORM query languages.
**Database abstraction forbids vendor specific optimizations.

=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_Fall_2010/ch3_3j_KS Object-relational mapping Fall 2010] 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.Also, a detailed study of alternatives to ORM like the NoSQL databases and Document-oriented approach can be included.
=References=

# [http://en.wikipedia.org/wiki/Object-relational_mapping Wikipedia, Object-relational mapping (ORM)]
# [http://docforge.com/wiki/Object-relational_mapping Object-relational mapping]
# [http://en.wikipedia.org/wiki/Object-relational_impedance_mismatch Object-Relational Impedance Matching Problem]
# [http://www.hibernate.org/about/orm The Object-Relational Impedance Mismatch]
# [http://edgeguides.rubyonrails.org/active_record_basics.html#object-relational-mapping Active Record]

CSC/ECE 517 Fall 2013/ch1 1w43 sm

2013-10-07T20:32:00Z

Mrsreena: /* Disadvantages */

=Object Relational Mapping=

__TOC__

=Introduction=

[http://en.wikipedia.org/wiki/Object-relational_mapping Object-relational mapping (ORM)], or ORM, is a programming technique which associates data stored in a relational database with application objects. The ORM layer populates business objects on demand and persists them back into the relational database when updated.
ORM basically creates 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.In this wiki, we concenterate mainly on the top Ruby ORM's like Active Record,Sequel and DataMapper.Also, it includes a comparison of various ORM techniques and the advantages and disadvantages of various styles of ORM mapping.

=Need For ORM=
Need for ORM arose due to a major problem called the Object-Relational Impedance MisMatch Problem.
[http://en.wikipedia.org/wiki/Object-relational_impedance_mismatch Object-Relational Impedance MisMatch Problem] is a set of conceptual and technical difficulties, encountered when a relational database management system (RDBMS) is being used by an object-oriented program particularly when object/class definitions are mapped directly to database tables or schema.It implies that object models don't work together with relational models, i.e RDBMS represents data in tabular format while Object oriented languages represent data in the form of interconnected graph of objects.
The Mismatches that occur in Object-Oriented concepts are as follows:
*Encapsulation:
Mapping of private object representation to database tables is difficult due to availability of fewer constraints for the design of private representation as opposed to public data in RDBMS.
*Interface, Class, Inheritance and polymorphism:
Under an object-oriented paradigm, objects have interfaces that together provide the only access to the internals of that object. The relational model, on the other hand, utilizes derived relation variables (views) to provide varying perspectives and constraints to ensure integrity. Similarly, essential OOP concepts for classes of objects, inheritance and polymorphism are not supported by relational database systems.
*Identity:
RDBMS defines exactly one notion of 'sameness': the primary key. However, Object-oriented languages, for example Java, defines both object identity (a==b) and object equality (a.equals(b)).
*Associations:
Associations are represented as unidirectional references in Object Oriented languages whereas RDBMS uses the notion of foreign keys. For example, If you need bidirectional relationships in Java, you must define the association twice.Likewise, you cannot determine the multiplicity of a relationship by looking at the object domain model.
*Data navigation:
The way you access data in object-oriented languages is fundamentally different than the way you do it in a relational database. Like in Java, you navigate from one association to another walking the object network. This is not an efficient way of retrieving data from a relational database. You typically want to minimize the number of SQL queries and thus load several entities via JOINs and select the targeted entities before you start walking the object network.

=Overview=

Data management tasks in object-oriented (OO) programming are typically implemented by manipulating objects that are almost always non-scalar values. Like for example, Consider a Geometric object, an entity which can have shape and color.In the object oriented implementation, this entity would be modeled as a geometric object with shape and color as its attributes.Shape itself can contain objects like for triangles(equilateral or isosceles) and so on.Here each geometric object can be treated as a single object by any programming language and its attributes can be also accessed by various object methods.However, many popular database products such as structured query language database management systems (SQL DBMS) can only store and manipulate scalar values such as integers and strings organized within tables.

Hence, the programmer must either convert the object values into groups of simpler values for storage in the database (and convert them back upon retrieval), or only use simple scalar values within the program. Object-relational mapping is used to implement the first approach.The key is to translate the logical representation of the objects into an atomized form that is capable of being stored in the database, while somehow preserving the properties of the objects and their relationships so that they can be reloaded as an object whenever required. If this storage and retrieval functionality is implemented, the objects are then said to be persistent.

Object-Relational Mapping, commonly referred to as its abbreviation ORM, is a technique that connects the rich objects of an application to tables in a relational database management system. Using ORM, the properties and relationships of the objects in an application can be easily stored and retrieved from a database without writing SQL statements directly and with less overall database access code.

=Features=

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 makes access to database through the application extremely easy, as it provides connection from model of the program to the database.Treating database rows as objects, Program can easily access the information in more consistent manner.Also it gives flexibility to the programmers to manipulate the data with the language itself rather than working on the attributes retrieved from the database.

When applied to Ruby, implementations of ORM often leverage the language’s Meta-programming 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 needs to be extracted from the model and the database, and 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.

=Active Record=
[http://ar.rubyonrails.org/ ActiveRecord] insulates you from the need to use raw SQL to find database records.Active Record facilitates the creation and use of business objects whose data requires persistent storage to a database.[edgeguides]

ActiveRecord is the default ‘model’ component of the model-view-controller web-application framework Ruby on Rails, and is also a stand-alone ORM package for other Ruby applications. In both forms, it was conceived of by David Heinemeier Hansson, and has been improved upon by a number of contributors.[2]

Other, less popular ORMs have been released since ActiveRecord first took the stage. For example, DataMapper and Sequel show major improvements over the original ActiveRecord framework.[neutrality is disputed] As a response to their release and adoption by the Rails community, Ruby on Rails v3.0 is independent of an ORM system, so Rails users can easily plug in DataMapper or Sequel to use as their ORM of choice.[wiki]

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>

Note in the preceding example, that 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 whose 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]]

Active Record will perform queries on the database for you and is compatible with most database systems (MySQL, PostgreSQL and SQLite to name a few). Regardless of which database system you're using, the ActiveRecord method format will always be the same.
To retrieve objects from the database, Active Record provides several finder methods. Each finder method allows you to pass arguments into it to perform certain queries on your database without writing raw SQL.[guide.rubyonrails]

'''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.

=Sequel=
[http://sequel.rubyforge.org Sequel] is designed to take the hassle away from connecting to databases and manipulating them. Sequel deals with all the boring stuff like maintaining connections, formatting SQL correctly and fetching records so you can concentrate on your application.
Sequel uses the concept of datasets to retrieve data. A Dataset object encapsulates an SQL query and supports chainability, letting you fetch data using a convenient Ruby DSL that is both concise and flexible.The current sequel version is 4.2.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.

Sequel::Model is an object relational mapper built on top of Sequel core. Each model class is backed by a dataset instance, and many dataset methods can be called directly on the class. Model datasets return rows as model instances, which have fairly standard ORM instance behavior.

Sequel::Model is built completely out of plugins. Plugins can override any class, instance, or dataset method defined by a previous plugin and call super to get the default behavior

=Features=

*Sequel provides thread safety, connection pooling and a concise DSL for constructing SQL *queries and table schemas.
*Sequel includes a comprehensive ORM layer for mapping records to Ruby objects and handling associated records.
*Sequel supports advanced database features such as prepared statements, bound variables, stored procedures, savepoints, two-phase commit, transaction isolation, master/slave configurations, and database sharding.
*Sequel currently has adapters for ADO, Amalgalite, CUBRID, DataObjects, DB2, DBI, Firebird, IBM_DB, Informix, JDBC, MySQL, Mysql2, ODBC, OpenBase, Oracle, PostgreSQL, SQLite3, Swift, and TinyTDS.[sequel.rubyforge]

<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.

=DataMapper=
DataMapper is an Object Relational Mapper written in Ruby. The goal is to create an ORM which is fast, thread-safe and feature rich.
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 even some popular webservices.[datamapper.org]

=Features=
*Eager loading of child associations to avoid (N+1) queries
*Lazy loading of select properties, e.g., larger fields
*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.[2] As a result, DataMapper adapters have been built for other non-SQL databases, such as CouchDB,[3] Apache Solr,[4] and web services such as Salesforce.[wikipedia]

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.

=Squeel=
Squeel unlocks the power of Arel in your Rails 3 application with a handy block-based syntax. You can write subqueries, access named functions provided by your RDBMS, and more, all without writing SQL strings. Squeel acts as an add on to Active Record and makes it easier to write queries with fewer strings.
A simple example is as follows:
Squeel lets you rewrite
<pre>
Article.where ['created_at >= ?', 2.weeks.ago]
</pre>
as
<pre>
Article.where{created_at >= 2.weeks.ago}
</pre>

=MyBatis/iBatis=
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. Follows below a MyBatis mapper, that consist on 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>
=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
|}

=NonSQL databases=
Instead of ORM we can also use 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 user from retrieving 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 in XML file.

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.

NoSQL 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

=Advantages of ORM=

*Facilitates implementing the Domain Model pattern that allows you to model entities based on real business concepts rather than based on our database structure. ORM tools provide this functionality through mapping between the logical business model and the physical storage model.

*Huge reduction in code. Ease of use, faster development, increased productivity.

*ORM tools provide a host of services thereby allowing developers to focus on the business logic of the application rather than repetitive CRUD (Create Read Update Delete) logic.

*Changes to the object model are made in one place. One you update your object definitions, the ORM will automatically use the updated structure for retrievals and updates. There are no SQL Update, Delete and Insert statements strewn throughout different layers of the application that need modification.

*Rich query capability. ORM tools provide an object oriented query language. This allows application developers to focus on the object model and not to have to be concerned with the database structure or SQL semantics. The ORM tool itself will translate the query language into the appropriate syntax for the database.

*Navigation. You can navigate object relationships transparently. Related objects are automatically loaded as needed. For example if you load a Post and you want to access it's Comment, you can simply access Post.Comment and the ORM will take care of loading the data for you without any effort on your part.

*Data loads are completely configurable allowing you to load the data appropriate for each scenario. For example in one scenario you might want to load a list of objects without any of it's child / related objects, while in other scenarios you can specify to load an object, with all it's children etc.

*Concurrency support. Support for multiple users updating the same data simultaneously.

*Cache management. Entities are cached in memory thereby reducing load on the database.

*Transaction management and Isolation. All object changes occur scoped to a transaction. The entire transaction can either be committed or rolled back. Multiple transactions can be active in memory in the same time, and each transactions changes are isolated form on another.

*Making data access more abstract and portable. ORM implementation classes know how to write vendor-specific SQL, so you don't have to.

=Disadvantages of ORM=

*High level of abstraction obscures as to what is actually happening in the code implementation.
*Loss in developer productivity whilst they learn to program with ORM.Developers lose understanding of what the code is actually doing - the developer is more in control using SQL.
*Heavy reliance on ORM also leads to poorly designed databases.
*Data and behaviour are not separated.
**Façade needs to be built if the data model is to be made available in a distributed architecture.
**Each ORM technology/product has a different set of APIs and porting code between them is not easy.
*The biggest advantage of ORM is also the biggest disadvantage: queries are generated automatically -
**queries can’t be optimized.
**queries select more data than needed, things get slower, more latency.
**compiling queries from ORM code is slow (ORM compiler written in PHP).
**SQL is more powerful than ORM query languages.
**database abstraction forbids vendor specific optimizations.

=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_Fall_2010/ch3_3j_KS Object-relational mapping Fall 2010] 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.Also, a detailed study of alternatives to ORM like the NoSQL databases and Document-oriented approach can be included.
=References=

# [http://en.wikipedia.org/wiki/Object-relational_mapping Wikipedia, Object-relational mapping (ORM)]
# [http://docforge.com/wiki/Object-relational_mapping Object-relational mapping]
# [http://en.wikipedia.org/wiki/Object-relational_impedance_mismatch Object-Relational Impedance Matching Problem]
# [http://www.hibernate.org/about/orm The Object-Relational Impedance Mismatch]
# [http://edgeguides.rubyonrails.org/active_record_basics.html#object-relational-mapping Active Record]

CSC/ECE 517 Fall 2013/ch1 1w43 sm

2013-10-07T20:31:46Z

Mrsreena: /* Advantages */

=Object Relational Mapping=

__TOC__

=Introduction=

[http://en.wikipedia.org/wiki/Object-relational_mapping Object-relational mapping (ORM)], or ORM, is a programming technique which associates data stored in a relational database with application objects. The ORM layer populates business objects on demand and persists them back into the relational database when updated.
ORM basically creates 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.In this wiki, we concenterate mainly on the top Ruby ORM's like Active Record,Sequel and DataMapper.Also, it includes a comparison of various ORM techniques and the advantages and disadvantages of various styles of ORM mapping.

=Need For ORM=
Need for ORM arose due to a major problem called the Object-Relational Impedance MisMatch Problem.
[http://en.wikipedia.org/wiki/Object-relational_impedance_mismatch Object-Relational Impedance MisMatch Problem] is a set of conceptual and technical difficulties, encountered when a relational database management system (RDBMS) is being used by an object-oriented program particularly when object/class definitions are mapped directly to database tables or schema.It implies that object models don't work together with relational models, i.e RDBMS represents data in tabular format while Object oriented languages represent data in the form of interconnected graph of objects.
The Mismatches that occur in Object-Oriented concepts are as follows:
*Encapsulation:
Mapping of private object representation to database tables is difficult due to availability of fewer constraints for the design of private representation as opposed to public data in RDBMS.
*Interface, Class, Inheritance and polymorphism:
Under an object-oriented paradigm, objects have interfaces that together provide the only access to the internals of that object. The relational model, on the other hand, utilizes derived relation variables (views) to provide varying perspectives and constraints to ensure integrity. Similarly, essential OOP concepts for classes of objects, inheritance and polymorphism are not supported by relational database systems.
*Identity:
RDBMS defines exactly one notion of 'sameness': the primary key. However, Object-oriented languages, for example Java, defines both object identity (a==b) and object equality (a.equals(b)).
*Associations:
Associations are represented as unidirectional references in Object Oriented languages whereas RDBMS uses the notion of foreign keys. For example, If you need bidirectional relationships in Java, you must define the association twice.Likewise, you cannot determine the multiplicity of a relationship by looking at the object domain model.
*Data navigation:
The way you access data in object-oriented languages is fundamentally different than the way you do it in a relational database. Like in Java, you navigate from one association to another walking the object network. This is not an efficient way of retrieving data from a relational database. You typically want to minimize the number of SQL queries and thus load several entities via JOINs and select the targeted entities before you start walking the object network.

=Overview=

Data management tasks in object-oriented (OO) programming are typically implemented by manipulating objects that are almost always non-scalar values. Like for example, Consider a Geometric object, an entity which can have shape and color.In the object oriented implementation, this entity would be modeled as a geometric object with shape and color as its attributes.Shape itself can contain objects like for triangles(equilateral or isosceles) and so on.Here each geometric object can be treated as a single object by any programming language and its attributes can be also accessed by various object methods.However, many popular database products such as structured query language database management systems (SQL DBMS) can only store and manipulate scalar values such as integers and strings organized within tables.

Hence, the programmer must either convert the object values into groups of simpler values for storage in the database (and convert them back upon retrieval), or only use simple scalar values within the program. Object-relational mapping is used to implement the first approach.The key is to translate the logical representation of the objects into an atomized form that is capable of being stored in the database, while somehow preserving the properties of the objects and their relationships so that they can be reloaded as an object whenever required. If this storage and retrieval functionality is implemented, the objects are then said to be persistent.

Object-Relational Mapping, commonly referred to as its abbreviation ORM, is a technique that connects the rich objects of an application to tables in a relational database management system. Using ORM, the properties and relationships of the objects in an application can be easily stored and retrieved from a database without writing SQL statements directly and with less overall database access code.

=Features=

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 makes access to database through the application extremely easy, as it provides connection from model of the program to the database.Treating database rows as objects, Program can easily access the information in more consistent manner.Also it gives flexibility to the programmers to manipulate the data with the language itself rather than working on the attributes retrieved from the database.

When applied to Ruby, implementations of ORM often leverage the language’s Meta-programming 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 needs to be extracted from the model and the database, and 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.

=Active Record=
[http://ar.rubyonrails.org/ ActiveRecord] insulates you from the need to use raw SQL to find database records.Active Record facilitates the creation and use of business objects whose data requires persistent storage to a database.[edgeguides]

ActiveRecord is the default ‘model’ component of the model-view-controller web-application framework Ruby on Rails, and is also a stand-alone ORM package for other Ruby applications. In both forms, it was conceived of by David Heinemeier Hansson, and has been improved upon by a number of contributors.[2]

Other, less popular ORMs have been released since ActiveRecord first took the stage. For example, DataMapper and Sequel show major improvements over the original ActiveRecord framework.[neutrality is disputed] As a response to their release and adoption by the Rails community, Ruby on Rails v3.0 is independent of an ORM system, so Rails users can easily plug in DataMapper or Sequel to use as their ORM of choice.[wiki]

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>

Note in the preceding example, that 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 whose 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]]

Active Record will perform queries on the database for you and is compatible with most database systems (MySQL, PostgreSQL and SQLite to name a few). Regardless of which database system you're using, the ActiveRecord method format will always be the same.
To retrieve objects from the database, Active Record provides several finder methods. Each finder method allows you to pass arguments into it to perform certain queries on your database without writing raw SQL.[guide.rubyonrails]

'''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.

=Sequel=
[http://sequel.rubyforge.org Sequel] is designed to take the hassle away from connecting to databases and manipulating them. Sequel deals with all the boring stuff like maintaining connections, formatting SQL correctly and fetching records so you can concentrate on your application.
Sequel uses the concept of datasets to retrieve data. A Dataset object encapsulates an SQL query and supports chainability, letting you fetch data using a convenient Ruby DSL that is both concise and flexible.The current sequel version is 4.2.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.

Sequel::Model is an object relational mapper built on top of Sequel core. Each model class is backed by a dataset instance, and many dataset methods can be called directly on the class. Model datasets return rows as model instances, which have fairly standard ORM instance behavior.

Sequel::Model is built completely out of plugins. Plugins can override any class, instance, or dataset method defined by a previous plugin and call super to get the default behavior

=Features=

*Sequel provides thread safety, connection pooling and a concise DSL for constructing SQL *queries and table schemas.
*Sequel includes a comprehensive ORM layer for mapping records to Ruby objects and handling associated records.
*Sequel supports advanced database features such as prepared statements, bound variables, stored procedures, savepoints, two-phase commit, transaction isolation, master/slave configurations, and database sharding.
*Sequel currently has adapters for ADO, Amalgalite, CUBRID, DataObjects, DB2, DBI, Firebird, IBM_DB, Informix, JDBC, MySQL, Mysql2, ODBC, OpenBase, Oracle, PostgreSQL, SQLite3, Swift, and TinyTDS.[sequel.rubyforge]

<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.

=DataMapper=
DataMapper is an Object Relational Mapper written in Ruby. The goal is to create an ORM which is fast, thread-safe and feature rich.
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 even some popular webservices.[datamapper.org]

=Features=
*Eager loading of child associations to avoid (N+1) queries
*Lazy loading of select properties, e.g., larger fields
*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.[2] As a result, DataMapper adapters have been built for other non-SQL databases, such as CouchDB,[3] Apache Solr,[4] and web services such as Salesforce.[wikipedia]

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.

=Squeel=
Squeel unlocks the power of Arel in your Rails 3 application with a handy block-based syntax. You can write subqueries, access named functions provided by your RDBMS, and more, all without writing SQL strings. Squeel acts as an add on to Active Record and makes it easier to write queries with fewer strings.
A simple example is as follows:
Squeel lets you rewrite
<pre>
Article.where ['created_at >= ?', 2.weeks.ago]
</pre>
as
<pre>
Article.where{created_at >= 2.weeks.ago}
</pre>

=MyBatis/iBatis=
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. Follows below a MyBatis mapper, that consist on 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>
=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
|}

=NonSQL databases=
Instead of ORM we can also use 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 user from retrieving 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 in XML file.

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.

NoSQL 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

=Advantages of ORM=

*Facilitates implementing the Domain Model pattern that allows you to model entities based on real business concepts rather than based on our database structure. ORM tools provide this functionality through mapping between the logical business model and the physical storage model.

*Huge reduction in code. Ease of use, faster development, increased productivity.

*ORM tools provide a host of services thereby allowing developers to focus on the business logic of the application rather than repetitive CRUD (Create Read Update Delete) logic.

*Changes to the object model are made in one place. One you update your object definitions, the ORM will automatically use the updated structure for retrievals and updates. There are no SQL Update, Delete and Insert statements strewn throughout different layers of the application that need modification.

*Rich query capability. ORM tools provide an object oriented query language. This allows application developers to focus on the object model and not to have to be concerned with the database structure or SQL semantics. The ORM tool itself will translate the query language into the appropriate syntax for the database.

*Navigation. You can navigate object relationships transparently. Related objects are automatically loaded as needed. For example if you load a Post and you want to access it's Comment, you can simply access Post.Comment and the ORM will take care of loading the data for you without any effort on your part.

*Data loads are completely configurable allowing you to load the data appropriate for each scenario. For example in one scenario you might want to load a list of objects without any of it's child / related objects, while in other scenarios you can specify to load an object, with all it's children etc.

*Concurrency support. Support for multiple users updating the same data simultaneously.

*Cache management. Entities are cached in memory thereby reducing load on the database.

*Transaction management and Isolation. All object changes occur scoped to a transaction. The entire transaction can either be committed or rolled back. Multiple transactions can be active in memory in the same time, and each transactions changes are isolated form on another.

*Making data access more abstract and portable. ORM implementation classes know how to write vendor-specific SQL, so you don't have to.

=Disadvantages=

*High level of abstraction obscures as to what is actually happening in the code implementation.
*Loss in developer productivity whilst they learn to program with ORM.Developers lose understanding of what the code is actually doing - the developer is more in control using SQL.
*Heavy reliance on ORM also leads to poorly designed databases.
*Data and behaviour are not separated.
**Façade needs to be built if the data model is to be made available in a distributed architecture.
**Each ORM technology/product has a different set of APIs and porting code between them is not easy.
*The biggest advantage of ORM is also the biggest disadvantage: queries are generated automatically -
**queries can’t be optimized.
**queries select more data than needed, things get slower, more latency.
**compiling queries from ORM code is slow (ORM compiler written in PHP).
**SQL is more powerful than ORM query languages.
**database abstraction forbids vendor specific optimizations.

=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_Fall_2010/ch3_3j_KS Object-relational mapping Fall 2010] 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.Also, a detailed study of alternatives to ORM like the NoSQL databases and Document-oriented approach can be included.
=References=

# [http://en.wikipedia.org/wiki/Object-relational_mapping Wikipedia, Object-relational mapping (ORM)]
# [http://docforge.com/wiki/Object-relational_mapping Object-relational mapping]
# [http://en.wikipedia.org/wiki/Object-relational_impedance_mismatch Object-Relational Impedance Matching Problem]
# [http://www.hibernate.org/about/orm The Object-Relational Impedance Mismatch]
# [http://edgeguides.rubyonrails.org/active_record_basics.html#object-relational-mapping Active Record]

CSC/ECE 517 Fall 2013/ch1 1w43 sm

2013-10-07T20:31:19Z

Mrsreena: /* NonSQL databases: */

=Object Relational Mapping=

__TOC__

=Introduction=

[http://en.wikipedia.org/wiki/Object-relational_mapping Object-relational mapping (ORM)], or ORM, is a programming technique which associates data stored in a relational database with application objects. The ORM layer populates business objects on demand and persists them back into the relational database when updated.
ORM basically creates 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.In this wiki, we concenterate mainly on the top Ruby ORM's like Active Record,Sequel and DataMapper.Also, it includes a comparison of various ORM techniques and the advantages and disadvantages of various styles of ORM mapping.

=Need For ORM=
Need for ORM arose due to a major problem called the Object-Relational Impedance MisMatch Problem.
[http://en.wikipedia.org/wiki/Object-relational_impedance_mismatch Object-Relational Impedance MisMatch Problem] is a set of conceptual and technical difficulties, encountered when a relational database management system (RDBMS) is being used by an object-oriented program particularly when object/class definitions are mapped directly to database tables or schema.It implies that object models don't work together with relational models, i.e RDBMS represents data in tabular format while Object oriented languages represent data in the form of interconnected graph of objects.
The Mismatches that occur in Object-Oriented concepts are as follows:
*Encapsulation:
Mapping of private object representation to database tables is difficult due to availability of fewer constraints for the design of private representation as opposed to public data in RDBMS.
*Interface, Class, Inheritance and polymorphism:
Under an object-oriented paradigm, objects have interfaces that together provide the only access to the internals of that object. The relational model, on the other hand, utilizes derived relation variables (views) to provide varying perspectives and constraints to ensure integrity. Similarly, essential OOP concepts for classes of objects, inheritance and polymorphism are not supported by relational database systems.
*Identity:
RDBMS defines exactly one notion of 'sameness': the primary key. However, Object-oriented languages, for example Java, defines both object identity (a==b) and object equality (a.equals(b)).
*Associations:
Associations are represented as unidirectional references in Object Oriented languages whereas RDBMS uses the notion of foreign keys. For example, If you need bidirectional relationships in Java, you must define the association twice.Likewise, you cannot determine the multiplicity of a relationship by looking at the object domain model.
*Data navigation:
The way you access data in object-oriented languages is fundamentally different than the way you do it in a relational database. Like in Java, you navigate from one association to another walking the object network. This is not an efficient way of retrieving data from a relational database. You typically want to minimize the number of SQL queries and thus load several entities via JOINs and select the targeted entities before you start walking the object network.

=Overview=

Data management tasks in object-oriented (OO) programming are typically implemented by manipulating objects that are almost always non-scalar values. Like for example, Consider a Geometric object, an entity which can have shape and color.In the object oriented implementation, this entity would be modeled as a geometric object with shape and color as its attributes.Shape itself can contain objects like for triangles(equilateral or isosceles) and so on.Here each geometric object can be treated as a single object by any programming language and its attributes can be also accessed by various object methods.However, many popular database products such as structured query language database management systems (SQL DBMS) can only store and manipulate scalar values such as integers and strings organized within tables.

Hence, the programmer must either convert the object values into groups of simpler values for storage in the database (and convert them back upon retrieval), or only use simple scalar values within the program. Object-relational mapping is used to implement the first approach.The key is to translate the logical representation of the objects into an atomized form that is capable of being stored in the database, while somehow preserving the properties of the objects and their relationships so that they can be reloaded as an object whenever required. If this storage and retrieval functionality is implemented, the objects are then said to be persistent.

Object-Relational Mapping, commonly referred to as its abbreviation ORM, is a technique that connects the rich objects of an application to tables in a relational database management system. Using ORM, the properties and relationships of the objects in an application can be easily stored and retrieved from a database without writing SQL statements directly and with less overall database access code.

=Features=

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 makes access to database through the application extremely easy, as it provides connection from model of the program to the database.Treating database rows as objects, Program can easily access the information in more consistent manner.Also it gives flexibility to the programmers to manipulate the data with the language itself rather than working on the attributes retrieved from the database.

When applied to Ruby, implementations of ORM often leverage the language’s Meta-programming 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 needs to be extracted from the model and the database, and 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.

=Active Record=
[http://ar.rubyonrails.org/ ActiveRecord] insulates you from the need to use raw SQL to find database records.Active Record facilitates the creation and use of business objects whose data requires persistent storage to a database.[edgeguides]

ActiveRecord is the default ‘model’ component of the model-view-controller web-application framework Ruby on Rails, and is also a stand-alone ORM package for other Ruby applications. In both forms, it was conceived of by David Heinemeier Hansson, and has been improved upon by a number of contributors.[2]

Other, less popular ORMs have been released since ActiveRecord first took the stage. For example, DataMapper and Sequel show major improvements over the original ActiveRecord framework.[neutrality is disputed] As a response to their release and adoption by the Rails community, Ruby on Rails v3.0 is independent of an ORM system, so Rails users can easily plug in DataMapper or Sequel to use as their ORM of choice.[wiki]

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>

Note in the preceding example, that 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 whose 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]]

Active Record will perform queries on the database for you and is compatible with most database systems (MySQL, PostgreSQL and SQLite to name a few). Regardless of which database system you're using, the ActiveRecord method format will always be the same.
To retrieve objects from the database, Active Record provides several finder methods. Each finder method allows you to pass arguments into it to perform certain queries on your database without writing raw SQL.[guide.rubyonrails]

'''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.

=Sequel=
[http://sequel.rubyforge.org Sequel] is designed to take the hassle away from connecting to databases and manipulating them. Sequel deals with all the boring stuff like maintaining connections, formatting SQL correctly and fetching records so you can concentrate on your application.
Sequel uses the concept of datasets to retrieve data. A Dataset object encapsulates an SQL query and supports chainability, letting you fetch data using a convenient Ruby DSL that is both concise and flexible.The current sequel version is 4.2.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.

Sequel::Model is an object relational mapper built on top of Sequel core. Each model class is backed by a dataset instance, and many dataset methods can be called directly on the class. Model datasets return rows as model instances, which have fairly standard ORM instance behavior.

Sequel::Model is built completely out of plugins. Plugins can override any class, instance, or dataset method defined by a previous plugin and call super to get the default behavior

=Features=

*Sequel provides thread safety, connection pooling and a concise DSL for constructing SQL *queries and table schemas.
*Sequel includes a comprehensive ORM layer for mapping records to Ruby objects and handling associated records.
*Sequel supports advanced database features such as prepared statements, bound variables, stored procedures, savepoints, two-phase commit, transaction isolation, master/slave configurations, and database sharding.
*Sequel currently has adapters for ADO, Amalgalite, CUBRID, DataObjects, DB2, DBI, Firebird, IBM_DB, Informix, JDBC, MySQL, Mysql2, ODBC, OpenBase, Oracle, PostgreSQL, SQLite3, Swift, and TinyTDS.[sequel.rubyforge]

<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.

=DataMapper=
DataMapper is an Object Relational Mapper written in Ruby. The goal is to create an ORM which is fast, thread-safe and feature rich.
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 even some popular webservices.[datamapper.org]

=Features=
*Eager loading of child associations to avoid (N+1) queries
*Lazy loading of select properties, e.g., larger fields
*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.[2] As a result, DataMapper adapters have been built for other non-SQL databases, such as CouchDB,[3] Apache Solr,[4] and web services such as Salesforce.[wikipedia]

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.

=Squeel=
Squeel unlocks the power of Arel in your Rails 3 application with a handy block-based syntax. You can write subqueries, access named functions provided by your RDBMS, and more, all without writing SQL strings. Squeel acts as an add on to Active Record and makes it easier to write queries with fewer strings.
A simple example is as follows:
Squeel lets you rewrite
<pre>
Article.where ['created_at >= ?', 2.weeks.ago]
</pre>
as
<pre>
Article.where{created_at >= 2.weeks.ago}
</pre>

=MyBatis/iBatis=
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. Follows below a MyBatis mapper, that consist on 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>
=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
|}

=NonSQL databases=
Instead of ORM we can also use 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 user from retrieving 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 in XML file.

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.

NoSQL 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

=Advantages=

*Facilitates implementing the Domain Model pattern that allows you to model entities based on real business concepts rather than based on our database structure. ORM tools provide this functionality through mapping between the logical business model and the physical storage model.

*Huge reduction in code. Ease of use, faster development, increased productivity.

*ORM tools provide a host of services thereby allowing developers to focus on the business logic of the application rather than repetitive CRUD (Create Read Update Delete) logic.

*Changes to the object model are made in one place. One you update your object definitions, the ORM will automatically use the updated structure for retrievals and updates. There are no SQL Update, Delete and Insert statements strewn throughout different layers of the application that need modification.

*Rich query capability. ORM tools provide an object oriented query language. This allows application developers to focus on the object model and not to have to be concerned with the database structure or SQL semantics. The ORM tool itself will translate the query language into the appropriate syntax for the database.

*Navigation. You can navigate object relationships transparently. Related objects are automatically loaded as needed. For example if you load a Post and you want to access it's Comment, you can simply access Post.Comment and the ORM will take care of loading the data for you without any effort on your part.

*Data loads are completely configurable allowing you to load the data appropriate for each scenario. For example in one scenario you might want to load a list of objects without any of it's child / related objects, while in other scenarios you can specify to load an object, with all it's children etc.

*Concurrency support. Support for multiple users updating the same data simultaneously.

*Cache management. Entities are cached in memory thereby reducing load on the database.

*Transaction management and Isolation. All object changes occur scoped to a transaction. The entire transaction can either be committed or rolled back. Multiple transactions can be active in memory in the same time, and each transactions changes are isolated form on another.

*Making data access more abstract and portable. ORM implementation classes know how to write vendor-specific SQL, so you don't have to.

=Disadvantages=

*High level of abstraction obscures as to what is actually happening in the code implementation.
*Loss in developer productivity whilst they learn to program with ORM.Developers lose understanding of what the code is actually doing - the developer is more in control using SQL.
*Heavy reliance on ORM also leads to poorly designed databases.
*Data and behaviour are not separated.
**Façade needs to be built if the data model is to be made available in a distributed architecture.
**Each ORM technology/product has a different set of APIs and porting code between them is not easy.
*The biggest advantage of ORM is also the biggest disadvantage: queries are generated automatically -
**queries can’t be optimized.
**queries select more data than needed, things get slower, more latency.
**compiling queries from ORM code is slow (ORM compiler written in PHP).
**SQL is more powerful than ORM query languages.
**database abstraction forbids vendor specific optimizations.

=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_Fall_2010/ch3_3j_KS Object-relational mapping Fall 2010] 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.Also, a detailed study of alternatives to ORM like the NoSQL databases and Document-oriented approach can be included.
=References=

# [http://en.wikipedia.org/wiki/Object-relational_mapping Wikipedia, Object-relational mapping (ORM)]
# [http://docforge.com/wiki/Object-relational_mapping Object-relational mapping]
# [http://en.wikipedia.org/wiki/Object-relational_impedance_mismatch Object-Relational Impedance Matching Problem]
# [http://www.hibernate.org/about/orm The Object-Relational Impedance Mismatch]
# [http://edgeguides.rubyonrails.org/active_record_basics.html#object-relational-mapping Active Record]

CSC/ECE 517 Fall 2013/ch1 1w43 sm

2013-10-07T20:30:37Z

Mrsreena: /* References */

=Object Relational Mapping=

__TOC__

=Introduction=

[http://en.wikipedia.org/wiki/Object-relational_mapping Object-relational mapping (ORM)], or ORM, is a programming technique which associates data stored in a relational database with application objects. The ORM layer populates business objects on demand and persists them back into the relational database when updated.
ORM basically creates 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.In this wiki, we concenterate mainly on the top Ruby ORM's like Active Record,Sequel and DataMapper.Also, it includes a comparison of various ORM techniques and the advantages and disadvantages of various styles of ORM mapping.

=Need For ORM=
Need for ORM arose due to a major problem called the Object-Relational Impedance MisMatch Problem.
[http://en.wikipedia.org/wiki/Object-relational_impedance_mismatch Object-Relational Impedance MisMatch Problem] is a set of conceptual and technical difficulties, encountered when a relational database management system (RDBMS) is being used by an object-oriented program particularly when object/class definitions are mapped directly to database tables or schema.It implies that object models don't work together with relational models, i.e RDBMS represents data in tabular format while Object oriented languages represent data in the form of interconnected graph of objects.
The Mismatches that occur in Object-Oriented concepts are as follows:
*Encapsulation:
Mapping of private object representation to database tables is difficult due to availability of fewer constraints for the design of private representation as opposed to public data in RDBMS.
*Interface, Class, Inheritance and polymorphism:
Under an object-oriented paradigm, objects have interfaces that together provide the only access to the internals of that object. The relational model, on the other hand, utilizes derived relation variables (views) to provide varying perspectives and constraints to ensure integrity. Similarly, essential OOP concepts for classes of objects, inheritance and polymorphism are not supported by relational database systems.
*Identity:
RDBMS defines exactly one notion of 'sameness': the primary key. However, Object-oriented languages, for example Java, defines both object identity (a==b) and object equality (a.equals(b)).
*Associations:
Associations are represented as unidirectional references in Object Oriented languages whereas RDBMS uses the notion of foreign keys. For example, If you need bidirectional relationships in Java, you must define the association twice.Likewise, you cannot determine the multiplicity of a relationship by looking at the object domain model.
*Data navigation:
The way you access data in object-oriented languages is fundamentally different than the way you do it in a relational database. Like in Java, you navigate from one association to another walking the object network. This is not an efficient way of retrieving data from a relational database. You typically want to minimize the number of SQL queries and thus load several entities via JOINs and select the targeted entities before you start walking the object network.

=Overview=

Data management tasks in object-oriented (OO) programming are typically implemented by manipulating objects that are almost always non-scalar values. Like for example, Consider a Geometric object, an entity which can have shape and color.In the object oriented implementation, this entity would be modeled as a geometric object with shape and color as its attributes.Shape itself can contain objects like for triangles(equilateral or isosceles) and so on.Here each geometric object can be treated as a single object by any programming language and its attributes can be also accessed by various object methods.However, many popular database products such as structured query language database management systems (SQL DBMS) can only store and manipulate scalar values such as integers and strings organized within tables.

Hence, the programmer must either convert the object values into groups of simpler values for storage in the database (and convert them back upon retrieval), or only use simple scalar values within the program. Object-relational mapping is used to implement the first approach.The key is to translate the logical representation of the objects into an atomized form that is capable of being stored in the database, while somehow preserving the properties of the objects and their relationships so that they can be reloaded as an object whenever required. If this storage and retrieval functionality is implemented, the objects are then said to be persistent.

Object-Relational Mapping, commonly referred to as its abbreviation ORM, is a technique that connects the rich objects of an application to tables in a relational database management system. Using ORM, the properties and relationships of the objects in an application can be easily stored and retrieved from a database without writing SQL statements directly and with less overall database access code.

=Features=

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 makes access to database through the application extremely easy, as it provides connection from model of the program to the database.Treating database rows as objects, Program can easily access the information in more consistent manner.Also it gives flexibility to the programmers to manipulate the data with the language itself rather than working on the attributes retrieved from the database.

When applied to Ruby, implementations of ORM often leverage the language’s Meta-programming 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 needs to be extracted from the model and the database, and 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.

=Active Record=
[http://ar.rubyonrails.org/ ActiveRecord] insulates you from the need to use raw SQL to find database records.Active Record facilitates the creation and use of business objects whose data requires persistent storage to a database.[edgeguides]

ActiveRecord is the default ‘model’ component of the model-view-controller web-application framework Ruby on Rails, and is also a stand-alone ORM package for other Ruby applications. In both forms, it was conceived of by David Heinemeier Hansson, and has been improved upon by a number of contributors.[2]

Other, less popular ORMs have been released since ActiveRecord first took the stage. For example, DataMapper and Sequel show major improvements over the original ActiveRecord framework.[neutrality is disputed] As a response to their release and adoption by the Rails community, Ruby on Rails v3.0 is independent of an ORM system, so Rails users can easily plug in DataMapper or Sequel to use as their ORM of choice.[wiki]

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>

Note in the preceding example, that 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 whose 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]]

Active Record will perform queries on the database for you and is compatible with most database systems (MySQL, PostgreSQL and SQLite to name a few). Regardless of which database system you're using, the ActiveRecord method format will always be the same.
To retrieve objects from the database, Active Record provides several finder methods. Each finder method allows you to pass arguments into it to perform certain queries on your database without writing raw SQL.[guide.rubyonrails]

'''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.

=Sequel=
[http://sequel.rubyforge.org Sequel] is designed to take the hassle away from connecting to databases and manipulating them. Sequel deals with all the boring stuff like maintaining connections, formatting SQL correctly and fetching records so you can concentrate on your application.
Sequel uses the concept of datasets to retrieve data. A Dataset object encapsulates an SQL query and supports chainability, letting you fetch data using a convenient Ruby DSL that is both concise and flexible.The current sequel version is 4.2.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.

Sequel::Model is an object relational mapper built on top of Sequel core. Each model class is backed by a dataset instance, and many dataset methods can be called directly on the class. Model datasets return rows as model instances, which have fairly standard ORM instance behavior.

Sequel::Model is built completely out of plugins. Plugins can override any class, instance, or dataset method defined by a previous plugin and call super to get the default behavior

=Features=

*Sequel provides thread safety, connection pooling and a concise DSL for constructing SQL *queries and table schemas.
*Sequel includes a comprehensive ORM layer for mapping records to Ruby objects and handling associated records.
*Sequel supports advanced database features such as prepared statements, bound variables, stored procedures, savepoints, two-phase commit, transaction isolation, master/slave configurations, and database sharding.
*Sequel currently has adapters for ADO, Amalgalite, CUBRID, DataObjects, DB2, DBI, Firebird, IBM_DB, Informix, JDBC, MySQL, Mysql2, ODBC, OpenBase, Oracle, PostgreSQL, SQLite3, Swift, and TinyTDS.[sequel.rubyforge]

<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.

=DataMapper=
DataMapper is an Object Relational Mapper written in Ruby. The goal is to create an ORM which is fast, thread-safe and feature rich.
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 even some popular webservices.[datamapper.org]

=Features=
*Eager loading of child associations to avoid (N+1) queries
*Lazy loading of select properties, e.g., larger fields
*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.[2] As a result, DataMapper adapters have been built for other non-SQL databases, such as CouchDB,[3] Apache Solr,[4] and web services such as Salesforce.[wikipedia]

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.

=Squeel=
Squeel unlocks the power of Arel in your Rails 3 application with a handy block-based syntax. You can write subqueries, access named functions provided by your RDBMS, and more, all without writing SQL strings. Squeel acts as an add on to Active Record and makes it easier to write queries with fewer strings.
A simple example is as follows:
Squeel lets you rewrite
<pre>
Article.where ['created_at >= ?', 2.weeks.ago]
</pre>
as
<pre>
Article.where{created_at >= 2.weeks.ago}
</pre>

=MyBatis/iBatis=
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. Follows below a MyBatis mapper, that consist on 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>
=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
|}

=NonSQL databases:=
Instead of ORM we can also use 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 user from retrieving 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 in XML file.

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.

NoSQL 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

=Advantages=

*Facilitates implementing the Domain Model pattern that allows you to model entities based on real business concepts rather than based on our database structure. ORM tools provide this functionality through mapping between the logical business model and the physical storage model.

*Huge reduction in code. Ease of use, faster development, increased productivity.

*ORM tools provide a host of services thereby allowing developers to focus on the business logic of the application rather than repetitive CRUD (Create Read Update Delete) logic.

*Changes to the object model are made in one place. One you update your object definitions, the ORM will automatically use the updated structure for retrievals and updates. There are no SQL Update, Delete and Insert statements strewn throughout different layers of the application that need modification.

*Rich query capability. ORM tools provide an object oriented query language. This allows application developers to focus on the object model and not to have to be concerned with the database structure or SQL semantics. The ORM tool itself will translate the query language into the appropriate syntax for the database.

*Navigation. You can navigate object relationships transparently. Related objects are automatically loaded as needed. For example if you load a Post and you want to access it's Comment, you can simply access Post.Comment and the ORM will take care of loading the data for you without any effort on your part.

*Data loads are completely configurable allowing you to load the data appropriate for each scenario. For example in one scenario you might want to load a list of objects without any of it's child / related objects, while in other scenarios you can specify to load an object, with all it's children etc.

*Concurrency support. Support for multiple users updating the same data simultaneously.

*Cache management. Entities are cached in memory thereby reducing load on the database.

*Transaction management and Isolation. All object changes occur scoped to a transaction. The entire transaction can either be committed or rolled back. Multiple transactions can be active in memory in the same time, and each transactions changes are isolated form on another.

*Making data access more abstract and portable. ORM implementation classes know how to write vendor-specific SQL, so you don't have to.

=Disadvantages=

*High level of abstraction obscures as to what is actually happening in the code implementation.
*Loss in developer productivity whilst they learn to program with ORM.Developers lose understanding of what the code is actually doing - the developer is more in control using SQL.
*Heavy reliance on ORM also leads to poorly designed databases.
*Data and behaviour are not separated.
**Façade needs to be built if the data model is to be made available in a distributed architecture.
**Each ORM technology/product has a different set of APIs and porting code between them is not easy.
*The biggest advantage of ORM is also the biggest disadvantage: queries are generated automatically -
**queries can’t be optimized.
**queries select more data than needed, things get slower, more latency.
**compiling queries from ORM code is slow (ORM compiler written in PHP).
**SQL is more powerful than ORM query languages.
**database abstraction forbids vendor specific optimizations.

=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_Fall_2010/ch3_3j_KS Object-relational mapping Fall 2010] 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.Also, a detailed study of alternatives to ORM like the NoSQL databases and Document-oriented approach can be included.
=References=

# [http://en.wikipedia.org/wiki/Object-relational_mapping Wikipedia, Object-relational mapping (ORM)]
# [http://docforge.com/wiki/Object-relational_mapping Object-relational mapping]
# [http://en.wikipedia.org/wiki/Object-relational_impedance_mismatch Object-Relational Impedance Matching Problem]
# [http://www.hibernate.org/about/orm The Object-Relational Impedance Mismatch]
# [http://edgeguides.rubyonrails.org/active_record_basics.html#object-relational-mapping Active Record]

CSC/ECE 517 Fall 2013/ch1 1w43 sm

2013-10-07T20:30:10Z

Mrsreena: /* References */

=Object Relational Mapping=

__TOC__

=Introduction=

[http://en.wikipedia.org/wiki/Object-relational_mapping Object-relational mapping (ORM)], or ORM, is a programming technique which associates data stored in a relational database with application objects. The ORM layer populates business objects on demand and persists them back into the relational database when updated.
ORM basically creates 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.In this wiki, we concenterate mainly on the top Ruby ORM's like Active Record,Sequel and DataMapper.Also, it includes a comparison of various ORM techniques and the advantages and disadvantages of various styles of ORM mapping.

=Need For ORM=
Need for ORM arose due to a major problem called the Object-Relational Impedance MisMatch Problem.
[http://en.wikipedia.org/wiki/Object-relational_impedance_mismatch Object-Relational Impedance MisMatch Problem] is a set of conceptual and technical difficulties, encountered when a relational database management system (RDBMS) is being used by an object-oriented program particularly when object/class definitions are mapped directly to database tables or schema.It implies that object models don't work together with relational models, i.e RDBMS represents data in tabular format while Object oriented languages represent data in the form of interconnected graph of objects.
The Mismatches that occur in Object-Oriented concepts are as follows:
*Encapsulation:
Mapping of private object representation to database tables is difficult due to availability of fewer constraints for the design of private representation as opposed to public data in RDBMS.
*Interface, Class, Inheritance and polymorphism:
Under an object-oriented paradigm, objects have interfaces that together provide the only access to the internals of that object. The relational model, on the other hand, utilizes derived relation variables (views) to provide varying perspectives and constraints to ensure integrity. Similarly, essential OOP concepts for classes of objects, inheritance and polymorphism are not supported by relational database systems.
*Identity:
RDBMS defines exactly one notion of 'sameness': the primary key. However, Object-oriented languages, for example Java, defines both object identity (a==b) and object equality (a.equals(b)).
*Associations:
Associations are represented as unidirectional references in Object Oriented languages whereas RDBMS uses the notion of foreign keys. For example, If you need bidirectional relationships in Java, you must define the association twice.Likewise, you cannot determine the multiplicity of a relationship by looking at the object domain model.
*Data navigation:
The way you access data in object-oriented languages is fundamentally different than the way you do it in a relational database. Like in Java, you navigate from one association to another walking the object network. This is not an efficient way of retrieving data from a relational database. You typically want to minimize the number of SQL queries and thus load several entities via JOINs and select the targeted entities before you start walking the object network.

=Overview=

Data management tasks in object-oriented (OO) programming are typically implemented by manipulating objects that are almost always non-scalar values. Like for example, Consider a Geometric object, an entity which can have shape and color.In the object oriented implementation, this entity would be modeled as a geometric object with shape and color as its attributes.Shape itself can contain objects like for triangles(equilateral or isosceles) and so on.Here each geometric object can be treated as a single object by any programming language and its attributes can be also accessed by various object methods.However, many popular database products such as structured query language database management systems (SQL DBMS) can only store and manipulate scalar values such as integers and strings organized within tables.

Hence, the programmer must either convert the object values into groups of simpler values for storage in the database (and convert them back upon retrieval), or only use simple scalar values within the program. Object-relational mapping is used to implement the first approach.The key is to translate the logical representation of the objects into an atomized form that is capable of being stored in the database, while somehow preserving the properties of the objects and their relationships so that they can be reloaded as an object whenever required. If this storage and retrieval functionality is implemented, the objects are then said to be persistent.

Object-Relational Mapping, commonly referred to as its abbreviation ORM, is a technique that connects the rich objects of an application to tables in a relational database management system. Using ORM, the properties and relationships of the objects in an application can be easily stored and retrieved from a database without writing SQL statements directly and with less overall database access code.

=Features=

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 makes access to database through the application extremely easy, as it provides connection from model of the program to the database.Treating database rows as objects, Program can easily access the information in more consistent manner.Also it gives flexibility to the programmers to manipulate the data with the language itself rather than working on the attributes retrieved from the database.

When applied to Ruby, implementations of ORM often leverage the language’s Meta-programming 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 needs to be extracted from the model and the database, and 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.

=Active Record=
[http://ar.rubyonrails.org/ ActiveRecord] insulates you from the need to use raw SQL to find database records.Active Record facilitates the creation and use of business objects whose data requires persistent storage to a database.[edgeguides]

ActiveRecord is the default ‘model’ component of the model-view-controller web-application framework Ruby on Rails, and is also a stand-alone ORM package for other Ruby applications. In both forms, it was conceived of by David Heinemeier Hansson, and has been improved upon by a number of contributors.[2]

Other, less popular ORMs have been released since ActiveRecord first took the stage. For example, DataMapper and Sequel show major improvements over the original ActiveRecord framework.[neutrality is disputed] As a response to their release and adoption by the Rails community, Ruby on Rails v3.0 is independent of an ORM system, so Rails users can easily plug in DataMapper or Sequel to use as their ORM of choice.[wiki]

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>

Note in the preceding example, that 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 whose 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]]

Active Record will perform queries on the database for you and is compatible with most database systems (MySQL, PostgreSQL and SQLite to name a few). Regardless of which database system you're using, the ActiveRecord method format will always be the same.
To retrieve objects from the database, Active Record provides several finder methods. Each finder method allows you to pass arguments into it to perform certain queries on your database without writing raw SQL.[guide.rubyonrails]

'''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.

=Sequel=
[http://sequel.rubyforge.org Sequel] is designed to take the hassle away from connecting to databases and manipulating them. Sequel deals with all the boring stuff like maintaining connections, formatting SQL correctly and fetching records so you can concentrate on your application.
Sequel uses the concept of datasets to retrieve data. A Dataset object encapsulates an SQL query and supports chainability, letting you fetch data using a convenient Ruby DSL that is both concise and flexible.The current sequel version is 4.2.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.

Sequel::Model is an object relational mapper built on top of Sequel core. Each model class is backed by a dataset instance, and many dataset methods can be called directly on the class. Model datasets return rows as model instances, which have fairly standard ORM instance behavior.

Sequel::Model is built completely out of plugins. Plugins can override any class, instance, or dataset method defined by a previous plugin and call super to get the default behavior

=Features=

*Sequel provides thread safety, connection pooling and a concise DSL for constructing SQL *queries and table schemas.
*Sequel includes a comprehensive ORM layer for mapping records to Ruby objects and handling associated records.
*Sequel supports advanced database features such as prepared statements, bound variables, stored procedures, savepoints, two-phase commit, transaction isolation, master/slave configurations, and database sharding.
*Sequel currently has adapters for ADO, Amalgalite, CUBRID, DataObjects, DB2, DBI, Firebird, IBM_DB, Informix, JDBC, MySQL, Mysql2, ODBC, OpenBase, Oracle, PostgreSQL, SQLite3, Swift, and TinyTDS.[sequel.rubyforge]

<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.

=DataMapper=
DataMapper is an Object Relational Mapper written in Ruby. The goal is to create an ORM which is fast, thread-safe and feature rich.
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 even some popular webservices.[datamapper.org]

=Features=
*Eager loading of child associations to avoid (N+1) queries
*Lazy loading of select properties, e.g., larger fields
*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.[2] As a result, DataMapper adapters have been built for other non-SQL databases, such as CouchDB,[3] Apache Solr,[4] and web services such as Salesforce.[wikipedia]

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.

=Squeel=
Squeel unlocks the power of Arel in your Rails 3 application with a handy block-based syntax. You can write subqueries, access named functions provided by your RDBMS, and more, all without writing SQL strings. Squeel acts as an add on to Active Record and makes it easier to write queries with fewer strings.
A simple example is as follows:
Squeel lets you rewrite
<pre>
Article.where ['created_at >= ?', 2.weeks.ago]
</pre>
as
<pre>
Article.where{created_at >= 2.weeks.ago}
</pre>

=MyBatis/iBatis=
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. Follows below a MyBatis mapper, that consist on 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>
=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
|}

=NonSQL databases:=
Instead of ORM we can also use 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 user from retrieving 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 in XML file.

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.

NoSQL 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

=Advantages=

*Facilitates implementing the Domain Model pattern that allows you to model entities based on real business concepts rather than based on our database structure. ORM tools provide this functionality through mapping between the logical business model and the physical storage model.

*Huge reduction in code. Ease of use, faster development, increased productivity.

*ORM tools provide a host of services thereby allowing developers to focus on the business logic of the application rather than repetitive CRUD (Create Read Update Delete) logic.

*Changes to the object model are made in one place. One you update your object definitions, the ORM will automatically use the updated structure for retrievals and updates. There are no SQL Update, Delete and Insert statements strewn throughout different layers of the application that need modification.

*Rich query capability. ORM tools provide an object oriented query language. This allows application developers to focus on the object model and not to have to be concerned with the database structure or SQL semantics. The ORM tool itself will translate the query language into the appropriate syntax for the database.

*Navigation. You can navigate object relationships transparently. Related objects are automatically loaded as needed. For example if you load a Post and you want to access it's Comment, you can simply access Post.Comment and the ORM will take care of loading the data for you without any effort on your part.

*Data loads are completely configurable allowing you to load the data appropriate for each scenario. For example in one scenario you might want to load a list of objects without any of it's child / related objects, while in other scenarios you can specify to load an object, with all it's children etc.

*Concurrency support. Support for multiple users updating the same data simultaneously.

*Cache management. Entities are cached in memory thereby reducing load on the database.

*Transaction management and Isolation. All object changes occur scoped to a transaction. The entire transaction can either be committed or rolled back. Multiple transactions can be active in memory in the same time, and each transactions changes are isolated form on another.

*Making data access more abstract and portable. ORM implementation classes know how to write vendor-specific SQL, so you don't have to.

=Disadvantages=

*High level of abstraction obscures as to what is actually happening in the code implementation.
*Loss in developer productivity whilst they learn to program with ORM.Developers lose understanding of what the code is actually doing - the developer is more in control using SQL.
*Heavy reliance on ORM also leads to poorly designed databases.
*Data and behaviour are not separated.
**Façade needs to be built if the data model is to be made available in a distributed architecture.
**Each ORM technology/product has a different set of APIs and porting code between them is not easy.
*The biggest advantage of ORM is also the biggest disadvantage: queries are generated automatically -
**queries can’t be optimized.
**queries select more data than needed, things get slower, more latency.
**compiling queries from ORM code is slow (ORM compiler written in PHP).
**SQL is more powerful than ORM query languages.
**database abstraction forbids vendor specific optimizations.

=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_Fall_2010/ch3_3j_KS Object-relational mapping Fall 2010] 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.Also, a detailed study of alternatives to ORM like the NoSQL databases and Document-oriented approach can be included.
=References=

# [http://en.wikipedia.org/wiki/Object-relational_mapping Wikipedia, Object-relational mapping (ORM)]
# [http://docforge.com/wiki/Object-relational_mapping , Object-relational mapping]
# [http://en.wikipedia.org/wiki/Object-relational_impedance_mismatch Object-Relational Impedance Matching Problem]
# [http://www.hibernate.org/about/orm , The Object-Relational Impedance Mismatch]
# [http://edgeguides.rubyonrails.org/active_record_basics.html#object-relational-mapping , Active Record]

CSC/ECE 517 Fall 2013/ch1 1w43 sm

2013-10-07T20:29:40Z

Mrsreena: /* Disadvantages */

=Object Relational Mapping=

__TOC__

=Introduction=

[http://en.wikipedia.org/wiki/Object-relational_mapping Object-relational mapping (ORM)], or ORM, is a programming technique which associates data stored in a relational database with application objects. The ORM layer populates business objects on demand and persists them back into the relational database when updated.
ORM basically creates 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.In this wiki, we concenterate mainly on the top Ruby ORM's like Active Record,Sequel and DataMapper.Also, it includes a comparison of various ORM techniques and the advantages and disadvantages of various styles of ORM mapping.

=Need For ORM=
Need for ORM arose due to a major problem called the Object-Relational Impedance MisMatch Problem.
[http://en.wikipedia.org/wiki/Object-relational_impedance_mismatch Object-Relational Impedance MisMatch Problem] is a set of conceptual and technical difficulties, encountered when a relational database management system (RDBMS) is being used by an object-oriented program particularly when object/class definitions are mapped directly to database tables or schema.It implies that object models don't work together with relational models, i.e RDBMS represents data in tabular format while Object oriented languages represent data in the form of interconnected graph of objects.
The Mismatches that occur in Object-Oriented concepts are as follows:
*Encapsulation:
Mapping of private object representation to database tables is difficult due to availability of fewer constraints for the design of private representation as opposed to public data in RDBMS.
*Interface, Class, Inheritance and polymorphism:
Under an object-oriented paradigm, objects have interfaces that together provide the only access to the internals of that object. The relational model, on the other hand, utilizes derived relation variables (views) to provide varying perspectives and constraints to ensure integrity. Similarly, essential OOP concepts for classes of objects, inheritance and polymorphism are not supported by relational database systems.
*Identity:
RDBMS defines exactly one notion of 'sameness': the primary key. However, Object-oriented languages, for example Java, defines both object identity (a==b) and object equality (a.equals(b)).
*Associations:
Associations are represented as unidirectional references in Object Oriented languages whereas RDBMS uses the notion of foreign keys. For example, If you need bidirectional relationships in Java, you must define the association twice.Likewise, you cannot determine the multiplicity of a relationship by looking at the object domain model.
*Data navigation:
The way you access data in object-oriented languages is fundamentally different than the way you do it in a relational database. Like in Java, you navigate from one association to another walking the object network. This is not an efficient way of retrieving data from a relational database. You typically want to minimize the number of SQL queries and thus load several entities via JOINs and select the targeted entities before you start walking the object network.

=Overview=

Data management tasks in object-oriented (OO) programming are typically implemented by manipulating objects that are almost always non-scalar values. Like for example, Consider a Geometric object, an entity which can have shape and color.In the object oriented implementation, this entity would be modeled as a geometric object with shape and color as its attributes.Shape itself can contain objects like for triangles(equilateral or isosceles) and so on.Here each geometric object can be treated as a single object by any programming language and its attributes can be also accessed by various object methods.However, many popular database products such as structured query language database management systems (SQL DBMS) can only store and manipulate scalar values such as integers and strings organized within tables.

Hence, the programmer must either convert the object values into groups of simpler values for storage in the database (and convert them back upon retrieval), or only use simple scalar values within the program. Object-relational mapping is used to implement the first approach.The key is to translate the logical representation of the objects into an atomized form that is capable of being stored in the database, while somehow preserving the properties of the objects and their relationships so that they can be reloaded as an object whenever required. If this storage and retrieval functionality is implemented, the objects are then said to be persistent.

Object-Relational Mapping, commonly referred to as its abbreviation ORM, is a technique that connects the rich objects of an application to tables in a relational database management system. Using ORM, the properties and relationships of the objects in an application can be easily stored and retrieved from a database without writing SQL statements directly and with less overall database access code.

=Features=

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 makes access to database through the application extremely easy, as it provides connection from model of the program to the database.Treating database rows as objects, Program can easily access the information in more consistent manner.Also it gives flexibility to the programmers to manipulate the data with the language itself rather than working on the attributes retrieved from the database.

When applied to Ruby, implementations of ORM often leverage the language’s Meta-programming 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 needs to be extracted from the model and the database, and 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.

=Active Record=
[http://ar.rubyonrails.org/ ActiveRecord] insulates you from the need to use raw SQL to find database records.Active Record facilitates the creation and use of business objects whose data requires persistent storage to a database.[edgeguides]

ActiveRecord is the default ‘model’ component of the model-view-controller web-application framework Ruby on Rails, and is also a stand-alone ORM package for other Ruby applications. In both forms, it was conceived of by David Heinemeier Hansson, and has been improved upon by a number of contributors.[2]

Other, less popular ORMs have been released since ActiveRecord first took the stage. For example, DataMapper and Sequel show major improvements over the original ActiveRecord framework.[neutrality is disputed] As a response to their release and adoption by the Rails community, Ruby on Rails v3.0 is independent of an ORM system, so Rails users can easily plug in DataMapper or Sequel to use as their ORM of choice.[wiki]

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>

Note in the preceding example, that 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 whose 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]]

Active Record will perform queries on the database for you and is compatible with most database systems (MySQL, PostgreSQL and SQLite to name a few). Regardless of which database system you're using, the ActiveRecord method format will always be the same.
To retrieve objects from the database, Active Record provides several finder methods. Each finder method allows you to pass arguments into it to perform certain queries on your database without writing raw SQL.[guide.rubyonrails]

'''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.

=Sequel=
[http://sequel.rubyforge.org Sequel] is designed to take the hassle away from connecting to databases and manipulating them. Sequel deals with all the boring stuff like maintaining connections, formatting SQL correctly and fetching records so you can concentrate on your application.
Sequel uses the concept of datasets to retrieve data. A Dataset object encapsulates an SQL query and supports chainability, letting you fetch data using a convenient Ruby DSL that is both concise and flexible.The current sequel version is 4.2.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.

Sequel::Model is an object relational mapper built on top of Sequel core. Each model class is backed by a dataset instance, and many dataset methods can be called directly on the class. Model datasets return rows as model instances, which have fairly standard ORM instance behavior.

Sequel::Model is built completely out of plugins. Plugins can override any class, instance, or dataset method defined by a previous plugin and call super to get the default behavior

=Features=

*Sequel provides thread safety, connection pooling and a concise DSL for constructing SQL *queries and table schemas.
*Sequel includes a comprehensive ORM layer for mapping records to Ruby objects and handling associated records.
*Sequel supports advanced database features such as prepared statements, bound variables, stored procedures, savepoints, two-phase commit, transaction isolation, master/slave configurations, and database sharding.
*Sequel currently has adapters for ADO, Amalgalite, CUBRID, DataObjects, DB2, DBI, Firebird, IBM_DB, Informix, JDBC, MySQL, Mysql2, ODBC, OpenBase, Oracle, PostgreSQL, SQLite3, Swift, and TinyTDS.[sequel.rubyforge]

<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.

=DataMapper=
DataMapper is an Object Relational Mapper written in Ruby. The goal is to create an ORM which is fast, thread-safe and feature rich.
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 even some popular webservices.[datamapper.org]

=Features=
*Eager loading of child associations to avoid (N+1) queries
*Lazy loading of select properties, e.g., larger fields
*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.[2] As a result, DataMapper adapters have been built for other non-SQL databases, such as CouchDB,[3] Apache Solr,[4] and web services such as Salesforce.[wikipedia]

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.

=Squeel=
Squeel unlocks the power of Arel in your Rails 3 application with a handy block-based syntax. You can write subqueries, access named functions provided by your RDBMS, and more, all without writing SQL strings. Squeel acts as an add on to Active Record and makes it easier to write queries with fewer strings.
A simple example is as follows:
Squeel lets you rewrite
<pre>
Article.where ['created_at >= ?', 2.weeks.ago]
</pre>
as
<pre>
Article.where{created_at >= 2.weeks.ago}
</pre>

=MyBatis/iBatis=
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. Follows below a MyBatis mapper, that consist on 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>
=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
|}

=NonSQL databases:=
Instead of ORM we can also use 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 user from retrieving 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 in XML file.

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.

NoSQL 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

=Advantages=

*Facilitates implementing the Domain Model pattern that allows you to model entities based on real business concepts rather than based on our database structure. ORM tools provide this functionality through mapping between the logical business model and the physical storage model.

*Huge reduction in code. Ease of use, faster development, increased productivity.

*ORM tools provide a host of services thereby allowing developers to focus on the business logic of the application rather than repetitive CRUD (Create Read Update Delete) logic.

*Changes to the object model are made in one place. One you update your object definitions, the ORM will automatically use the updated structure for retrievals and updates. There are no SQL Update, Delete and Insert statements strewn throughout different layers of the application that need modification.

*Rich query capability. ORM tools provide an object oriented query language. This allows application developers to focus on the object model and not to have to be concerned with the database structure or SQL semantics. The ORM tool itself will translate the query language into the appropriate syntax for the database.

*Navigation. You can navigate object relationships transparently. Related objects are automatically loaded as needed. For example if you load a Post and you want to access it's Comment, you can simply access Post.Comment and the ORM will take care of loading the data for you without any effort on your part.

*Data loads are completely configurable allowing you to load the data appropriate for each scenario. For example in one scenario you might want to load a list of objects without any of it's child / related objects, while in other scenarios you can specify to load an object, with all it's children etc.

*Concurrency support. Support for multiple users updating the same data simultaneously.

*Cache management. Entities are cached in memory thereby reducing load on the database.

*Transaction management and Isolation. All object changes occur scoped to a transaction. The entire transaction can either be committed or rolled back. Multiple transactions can be active in memory in the same time, and each transactions changes are isolated form on another.

*Making data access more abstract and portable. ORM implementation classes know how to write vendor-specific SQL, so you don't have to.

=Disadvantages=

*High level of abstraction obscures as to what is actually happening in the code implementation.
*Loss in developer productivity whilst they learn to program with ORM.Developers lose understanding of what the code is actually doing - the developer is more in control using SQL.
*Heavy reliance on ORM also leads to poorly designed databases.
*Data and behaviour are not separated.
**Façade needs to be built if the data model is to be made available in a distributed architecture.
**Each ORM technology/product has a different set of APIs and porting code between them is not easy.
*The biggest advantage of ORM is also the biggest disadvantage: queries are generated automatically -
**queries can’t be optimized.
**queries select more data than needed, things get slower, more latency.
**compiling queries from ORM code is slow (ORM compiler written in PHP).
**SQL is more powerful than ORM query languages.
**database abstraction forbids vendor specific optimizations.

=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_Fall_2010/ch3_3j_KS Object-relational mapping Fall 2010] 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.Also, a detailed study of alternatives to ORM like the NoSQL databases and Document-oriented approach can be included.
=References=

# [http://en.wikipedia.org/wiki/Object-relational_mapping Wikipedia, Object-relational mapping (ORM)]
# [http://docforge.com/wiki/Object-relational_mapping , Object-relational mapping]
# [http://en.wikipedia.org/wiki/Object-relational_impedance_mismatch Object-Relational Impedance
Matching Problem]
# [http://www.hibernate.org/about/orm , The Object-Relational Impedance Mismatch]
# [http://edgeguides.rubyonrails.org/active_record_basics.html#object-relational-mapping , Active Record]

CSC/ECE 517 Fall 2013/ch1 1w43 sm

2013-10-07T20:26:33Z

Mrsreena: /* Advantages */

=Object Relational Mapping=

__TOC__

=Introduction=

[http://en.wikipedia.org/wiki/Object-relational_mapping Object-relational mapping (ORM)], or ORM, is a programming technique which associates data stored in a relational database with application objects. The ORM layer populates business objects on demand and persists them back into the relational database when updated.
ORM basically creates 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.In this wiki, we concenterate mainly on the top Ruby ORM's like Active Record,Sequel and DataMapper.Also, it includes a comparison of various ORM techniques and the advantages and disadvantages of various styles of ORM mapping.

=Need For ORM=
Need for ORM arose due to a major problem called the Object-Relational Impedance MisMatch Problem.
[http://en.wikipedia.org/wiki/Object-relational_impedance_mismatch Object-Relational Impedance MisMatch Problem] is a set of conceptual and technical difficulties, encountered when a relational database management system (RDBMS) is being used by an object-oriented program particularly when object/class definitions are mapped directly to database tables or schema.It implies that object models don't work together with relational models, i.e RDBMS represents data in tabular format while Object oriented languages represent data in the form of interconnected graph of objects.
The Mismatches that occur in Object-Oriented concepts are as follows:
*Encapsulation:
Mapping of private object representation to database tables is difficult due to availability of fewer constraints for the design of private representation as opposed to public data in RDBMS.
*Interface, Class, Inheritance and polymorphism:
Under an object-oriented paradigm, objects have interfaces that together provide the only access to the internals of that object. The relational model, on the other hand, utilizes derived relation variables (views) to provide varying perspectives and constraints to ensure integrity. Similarly, essential OOP concepts for classes of objects, inheritance and polymorphism are not supported by relational database systems.
*Identity:
RDBMS defines exactly one notion of 'sameness': the primary key. However, Object-oriented languages, for example Java, defines both object identity (a==b) and object equality (a.equals(b)).
*Associations:
Associations are represented as unidirectional references in Object Oriented languages whereas RDBMS uses the notion of foreign keys. For example, If you need bidirectional relationships in Java, you must define the association twice.Likewise, you cannot determine the multiplicity of a relationship by looking at the object domain model.
*Data navigation:
The way you access data in object-oriented languages is fundamentally different than the way you do it in a relational database. Like in Java, you navigate from one association to another walking the object network. This is not an efficient way of retrieving data from a relational database. You typically want to minimize the number of SQL queries and thus load several entities via JOINs and select the targeted entities before you start walking the object network.

=Overview=

Data management tasks in object-oriented (OO) programming are typically implemented by manipulating objects that are almost always non-scalar values. Like for example, Consider a Geometric object, an entity which can have shape and color.In the object oriented implementation, this entity would be modeled as a geometric object with shape and color as its attributes.Shape itself can contain objects like for triangles(equilateral or isosceles) and so on.Here each geometric object can be treated as a single object by any programming language and its attributes can be also accessed by various object methods.However, many popular database products such as structured query language database management systems (SQL DBMS) can only store and manipulate scalar values such as integers and strings organized within tables.

Hence, the programmer must either convert the object values into groups of simpler values for storage in the database (and convert them back upon retrieval), or only use simple scalar values within the program. Object-relational mapping is used to implement the first approach.The key is to translate the logical representation of the objects into an atomized form that is capable of being stored in the database, while somehow preserving the properties of the objects and their relationships so that they can be reloaded as an object whenever required. If this storage and retrieval functionality is implemented, the objects are then said to be persistent.

Object-Relational Mapping, commonly referred to as its abbreviation ORM, is a technique that connects the rich objects of an application to tables in a relational database management system. Using ORM, the properties and relationships of the objects in an application can be easily stored and retrieved from a database without writing SQL statements directly and with less overall database access code.

=Features=

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 makes access to database through the application extremely easy, as it provides connection from model of the program to the database.Treating database rows as objects, Program can easily access the information in more consistent manner.Also it gives flexibility to the programmers to manipulate the data with the language itself rather than working on the attributes retrieved from the database.

When applied to Ruby, implementations of ORM often leverage the language’s Meta-programming 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 needs to be extracted from the model and the database, and 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.

=Active Record=
[http://ar.rubyonrails.org/ ActiveRecord] insulates you from the need to use raw SQL to find database records.Active Record facilitates the creation and use of business objects whose data requires persistent storage to a database.[edgeguides]

ActiveRecord is the default ‘model’ component of the model-view-controller web-application framework Ruby on Rails, and is also a stand-alone ORM package for other Ruby applications. In both forms, it was conceived of by David Heinemeier Hansson, and has been improved upon by a number of contributors.[2]

Other, less popular ORMs have been released since ActiveRecord first took the stage. For example, DataMapper and Sequel show major improvements over the original ActiveRecord framework.[neutrality is disputed] As a response to their release and adoption by the Rails community, Ruby on Rails v3.0 is independent of an ORM system, so Rails users can easily plug in DataMapper or Sequel to use as their ORM of choice.[wiki]

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>

Note in the preceding example, that 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 whose 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]]

Active Record will perform queries on the database for you and is compatible with most database systems (MySQL, PostgreSQL and SQLite to name a few). Regardless of which database system you're using, the ActiveRecord method format will always be the same.
To retrieve objects from the database, Active Record provides several finder methods. Each finder method allows you to pass arguments into it to perform certain queries on your database without writing raw SQL.[guide.rubyonrails]

'''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.

=Sequel=
[http://sequel.rubyforge.org Sequel] is designed to take the hassle away from connecting to databases and manipulating them. Sequel deals with all the boring stuff like maintaining connections, formatting SQL correctly and fetching records so you can concentrate on your application.
Sequel uses the concept of datasets to retrieve data. A Dataset object encapsulates an SQL query and supports chainability, letting you fetch data using a convenient Ruby DSL that is both concise and flexible.The current sequel version is 4.2.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.

Sequel::Model is an object relational mapper built on top of Sequel core. Each model class is backed by a dataset instance, and many dataset methods can be called directly on the class. Model datasets return rows as model instances, which have fairly standard ORM instance behavior.

Sequel::Model is built completely out of plugins. Plugins can override any class, instance, or dataset method defined by a previous plugin and call super to get the default behavior

=Features=

*Sequel provides thread safety, connection pooling and a concise DSL for constructing SQL *queries and table schemas.
*Sequel includes a comprehensive ORM layer for mapping records to Ruby objects and handling associated records.
*Sequel supports advanced database features such as prepared statements, bound variables, stored procedures, savepoints, two-phase commit, transaction isolation, master/slave configurations, and database sharding.
*Sequel currently has adapters for ADO, Amalgalite, CUBRID, DataObjects, DB2, DBI, Firebird, IBM_DB, Informix, JDBC, MySQL, Mysql2, ODBC, OpenBase, Oracle, PostgreSQL, SQLite3, Swift, and TinyTDS.[sequel.rubyforge]

<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.

=DataMapper=
DataMapper is an Object Relational Mapper written in Ruby. The goal is to create an ORM which is fast, thread-safe and feature rich.
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 even some popular webservices.[datamapper.org]

=Features=
*Eager loading of child associations to avoid (N+1) queries
*Lazy loading of select properties, e.g., larger fields
*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.[2] As a result, DataMapper adapters have been built for other non-SQL databases, such as CouchDB,[3] Apache Solr,[4] and web services such as Salesforce.[wikipedia]

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.

=Squeel=
Squeel unlocks the power of Arel in your Rails 3 application with a handy block-based syntax. You can write subqueries, access named functions provided by your RDBMS, and more, all without writing SQL strings. Squeel acts as an add on to Active Record and makes it easier to write queries with fewer strings.
A simple example is as follows:
Squeel lets you rewrite
<pre>
Article.where ['created_at >= ?', 2.weeks.ago]
</pre>
as
<pre>
Article.where{created_at >= 2.weeks.ago}
</pre>

=MyBatis/iBatis=
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. Follows below a MyBatis mapper, that consist on 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>
=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
|}

=NonSQL databases:=
Instead of ORM we can also use 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 user from retrieving 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 in XML file.

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.

NoSQL 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

=Advantages=

*Facilitates implementing the Domain Model pattern that allows you to model entities based on real business concepts rather than based on our database structure. ORM tools provide this functionality through mapping between the logical business model and the physical storage model.

*Huge reduction in code. Ease of use, faster development, increased productivity.

*ORM tools provide a host of services thereby allowing developers to focus on the business logic of the application rather than repetitive CRUD (Create Read Update Delete) logic.

*Changes to the object model are made in one place. One you update your object definitions, the ORM will automatically use the updated structure for retrievals and updates. There are no SQL Update, Delete and Insert statements strewn throughout different layers of the application that need modification.

*Rich query capability. ORM tools provide an object oriented query language. This allows application developers to focus on the object model and not to have to be concerned with the database structure or SQL semantics. The ORM tool itself will translate the query language into the appropriate syntax for the database.

*Navigation. You can navigate object relationships transparently. Related objects are automatically loaded as needed. For example if you load a Post and you want to access it's Comment, you can simply access Post.Comment and the ORM will take care of loading the data for you without any effort on your part.

*Data loads are completely configurable allowing you to load the data appropriate for each scenario. For example in one scenario you might want to load a list of objects without any of it's child / related objects, while in other scenarios you can specify to load an object, with all it's children etc.

*Concurrency support. Support for multiple users updating the same data simultaneously.

*Cache management. Entities are cached in memory thereby reducing load on the database.

*Transaction management and Isolation. All object changes occur scoped to a transaction. The entire transaction can either be committed or rolled back. Multiple transactions can be active in memory in the same time, and each transactions changes are isolated form on another.

*Making data access more abstract and portable. ORM implementation classes know how to write vendor-specific SQL, so you don't have to.

=Disadvantages=
[http://www.codefutures.com/weblog/andygrove/archives/2005/02/data_access_obj.html][wikipedia]
*High level of abstraction obscures as to what is actually happening in the code implementation.
*Loss in developer productivity whilst they learn to program with ORM.Developers lose understanding of what the code is actually doing - the developer is more in control using SQL.
*Heavy reliance on ORM also leads to poorly designed databases.
*Data and behaviour are not separated.
**Façade needs to be built if the data model is to be made available in a distributed architecture.
**Each ORM technology/product has a different set of APIs and porting code between them is not easy.
*The biggest advantage of ORM is also the biggest disadvantage: queries are generated automatically -
**queries can’t be optimized.
**queries select more data than needed, things get slower, more latency.
**compiling queries from ORM code is slow (ORM compiler written in PHP).
**SQL is more powerful than ORM query languages.
**database abstraction forbids vendor specific optimizations.
=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_Fall_2010/ch3_3j_KS Object-relational mapping Fall 2010] 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.Also, a detailed study of alternatives to ORM like the NoSQL databases and Document-oriented approach can be included.
=References=

# [http://en.wikipedia.org/wiki/Object-relational_mapping Wikipedia, Object-relational mapping (ORM)]
# [http://docforge.com/wiki/Object-relational_mapping , Object-relational mapping]
# [http://en.wikipedia.org/wiki/Object-relational_impedance_mismatch Object-Relational Impedance
Matching Problem]
# [http://www.hibernate.org/about/orm , The Object-Relational Impedance Mismatch]
# [http://edgeguides.rubyonrails.org/active_record_basics.html#object-relational-mapping , Active Record]

CSC/ECE 517 Fall 2013/ch1 1w43 sm

2013-10-07T20:25:20Z

Mrsreena: /* NonSQL databases: */

=Object Relational Mapping=

__TOC__

=Introduction=

[http://en.wikipedia.org/wiki/Object-relational_mapping Object-relational mapping (ORM)], or ORM, is a programming technique which associates data stored in a relational database with application objects. The ORM layer populates business objects on demand and persists them back into the relational database when updated.
ORM basically creates 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.In this wiki, we concenterate mainly on the top Ruby ORM's like Active Record,Sequel and DataMapper.Also, it includes a comparison of various ORM techniques and the advantages and disadvantages of various styles of ORM mapping.

=Need For ORM=
Need for ORM arose due to a major problem called the Object-Relational Impedance MisMatch Problem.
[http://en.wikipedia.org/wiki/Object-relational_impedance_mismatch Object-Relational Impedance MisMatch Problem] is a set of conceptual and technical difficulties, encountered when a relational database management system (RDBMS) is being used by an object-oriented program particularly when object/class definitions are mapped directly to database tables or schema.It implies that object models don't work together with relational models, i.e RDBMS represents data in tabular format while Object oriented languages represent data in the form of interconnected graph of objects.
The Mismatches that occur in Object-Oriented concepts are as follows:
*Encapsulation:
Mapping of private object representation to database tables is difficult due to availability of fewer constraints for the design of private representation as opposed to public data in RDBMS.
*Interface, Class, Inheritance and polymorphism:
Under an object-oriented paradigm, objects have interfaces that together provide the only access to the internals of that object. The relational model, on the other hand, utilizes derived relation variables (views) to provide varying perspectives and constraints to ensure integrity. Similarly, essential OOP concepts for classes of objects, inheritance and polymorphism are not supported by relational database systems.
*Identity:
RDBMS defines exactly one notion of 'sameness': the primary key. However, Object-oriented languages, for example Java, defines both object identity (a==b) and object equality (a.equals(b)).
*Associations:
Associations are represented as unidirectional references in Object Oriented languages whereas RDBMS uses the notion of foreign keys. For example, If you need bidirectional relationships in Java, you must define the association twice.Likewise, you cannot determine the multiplicity of a relationship by looking at the object domain model.
*Data navigation:
The way you access data in object-oriented languages is fundamentally different than the way you do it in a relational database. Like in Java, you navigate from one association to another walking the object network. This is not an efficient way of retrieving data from a relational database. You typically want to minimize the number of SQL queries and thus load several entities via JOINs and select the targeted entities before you start walking the object network.

=Overview=

Data management tasks in object-oriented (OO) programming are typically implemented by manipulating objects that are almost always non-scalar values. Like for example, Consider a Geometric object, an entity which can have shape and color.In the object oriented implementation, this entity would be modeled as a geometric object with shape and color as its attributes.Shape itself can contain objects like for triangles(equilateral or isosceles) and so on.Here each geometric object can be treated as a single object by any programming language and its attributes can be also accessed by various object methods.However, many popular database products such as structured query language database management systems (SQL DBMS) can only store and manipulate scalar values such as integers and strings organized within tables.

Hence, the programmer must either convert the object values into groups of simpler values for storage in the database (and convert them back upon retrieval), or only use simple scalar values within the program. Object-relational mapping is used to implement the first approach.The key is to translate the logical representation of the objects into an atomized form that is capable of being stored in the database, while somehow preserving the properties of the objects and their relationships so that they can be reloaded as an object whenever required. If this storage and retrieval functionality is implemented, the objects are then said to be persistent.

Object-Relational Mapping, commonly referred to as its abbreviation ORM, is a technique that connects the rich objects of an application to tables in a relational database management system. Using ORM, the properties and relationships of the objects in an application can be easily stored and retrieved from a database without writing SQL statements directly and with less overall database access code.

=Features=

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 makes access to database through the application extremely easy, as it provides connection from model of the program to the database.Treating database rows as objects, Program can easily access the information in more consistent manner.Also it gives flexibility to the programmers to manipulate the data with the language itself rather than working on the attributes retrieved from the database.

When applied to Ruby, implementations of ORM often leverage the language’s Meta-programming 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 needs to be extracted from the model and the database, and 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.

=Active Record=
[http://ar.rubyonrails.org/ ActiveRecord] insulates you from the need to use raw SQL to find database records.Active Record facilitates the creation and use of business objects whose data requires persistent storage to a database.[edgeguides]

ActiveRecord is the default ‘model’ component of the model-view-controller web-application framework Ruby on Rails, and is also a stand-alone ORM package for other Ruby applications. In both forms, it was conceived of by David Heinemeier Hansson, and has been improved upon by a number of contributors.[2]

Other, less popular ORMs have been released since ActiveRecord first took the stage. For example, DataMapper and Sequel show major improvements over the original ActiveRecord framework.[neutrality is disputed] As a response to their release and adoption by the Rails community, Ruby on Rails v3.0 is independent of an ORM system, so Rails users can easily plug in DataMapper or Sequel to use as their ORM of choice.[wiki]

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>

Note in the preceding example, that 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 whose 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]]

Active Record will perform queries on the database for you and is compatible with most database systems (MySQL, PostgreSQL and SQLite to name a few). Regardless of which database system you're using, the ActiveRecord method format will always be the same.
To retrieve objects from the database, Active Record provides several finder methods. Each finder method allows you to pass arguments into it to perform certain queries on your database without writing raw SQL.[guide.rubyonrails]

'''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.

=Sequel=
[http://sequel.rubyforge.org Sequel] is designed to take the hassle away from connecting to databases and manipulating them. Sequel deals with all the boring stuff like maintaining connections, formatting SQL correctly and fetching records so you can concentrate on your application.
Sequel uses the concept of datasets to retrieve data. A Dataset object encapsulates an SQL query and supports chainability, letting you fetch data using a convenient Ruby DSL that is both concise and flexible.The current sequel version is 4.2.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.

Sequel::Model is an object relational mapper built on top of Sequel core. Each model class is backed by a dataset instance, and many dataset methods can be called directly on the class. Model datasets return rows as model instances, which have fairly standard ORM instance behavior.

Sequel::Model is built completely out of plugins. Plugins can override any class, instance, or dataset method defined by a previous plugin and call super to get the default behavior

=Features=

*Sequel provides thread safety, connection pooling and a concise DSL for constructing SQL *queries and table schemas.
*Sequel includes a comprehensive ORM layer for mapping records to Ruby objects and handling associated records.
*Sequel supports advanced database features such as prepared statements, bound variables, stored procedures, savepoints, two-phase commit, transaction isolation, master/slave configurations, and database sharding.
*Sequel currently has adapters for ADO, Amalgalite, CUBRID, DataObjects, DB2, DBI, Firebird, IBM_DB, Informix, JDBC, MySQL, Mysql2, ODBC, OpenBase, Oracle, PostgreSQL, SQLite3, Swift, and TinyTDS.[sequel.rubyforge]

<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.

=DataMapper=
DataMapper is an Object Relational Mapper written in Ruby. The goal is to create an ORM which is fast, thread-safe and feature rich.
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 even some popular webservices.[datamapper.org]

=Features=
*Eager loading of child associations to avoid (N+1) queries
*Lazy loading of select properties, e.g., larger fields
*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.[2] As a result, DataMapper adapters have been built for other non-SQL databases, such as CouchDB,[3] Apache Solr,[4] and web services such as Salesforce.[wikipedia]

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.

=Squeel=
Squeel unlocks the power of Arel in your Rails 3 application with a handy block-based syntax. You can write subqueries, access named functions provided by your RDBMS, and more, all without writing SQL strings. Squeel acts as an add on to Active Record and makes it easier to write queries with fewer strings.
A simple example is as follows:
Squeel lets you rewrite
<pre>
Article.where ['created_at >= ?', 2.weeks.ago]
</pre>
as
<pre>
Article.where{created_at >= 2.weeks.ago}
</pre>

=MyBatis/iBatis=
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. Follows below a MyBatis mapper, that consist on 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>
=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
|}

=NonSQL databases:=
Instead of ORM we can also use 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 user from retrieving 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 in XML file.

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.

NoSQL 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

=Advantages=
[http://blogs.msdn.com/b/gblock/archive/2006/10/26/ten-advantages-of-an-orm.aspx]
*Facilitates implementing the Domain Model pattern that allows you to model entities based on real business concepts rather than based on our database structure. ORM tools provide this functionality through mapping between the logical business model and the physical storage model.

*Huge reduction in code. Ease of use, faster development, increased productivity.
ORM tools provide a host of services thereby allowing developers to focus on the business logic of the application rather than repetitive CRUD (Create Read Update Delete) logic.

*Changes to the object model are made in one place. One you update your object definitions, the ORM will automatically use the updated structure for retrievals and updates. There are no SQL Update, Delete and Insert statements strewn throughout different layers of the application that need modification.

*Rich query capability. ORM tools provide an object oriented query language. This allows application developers to focus on the object model and not to have to be concerned with the database structure or SQL semantics. The ORM tool itself will translate the query language into the appropriate syntax for the database.

*Navigation. You can navigate object relationships transparently. Related objects are automatically loaded as needed. For example if you load a Post and you want to access it's Comment, you can simply access Post.Comment and the ORM will take care of loading the data for you without any effort on your part.

*Data loads are completely configurable allowing you to load the data appropriate for each scenario. For example in one scenario you might want to load a list of objects without any of it's child / related objects, while in other scenarios you can specify to load an object, with all it's children etc.

*Concurrency support. Support for multiple users updating the same data simultaneously.

*Cache management. Entities are cached in memory thereby reducing load on the database.

*Transaction management and Isolation. All object changes occur scoped to a transaction. The entire transaction can either be committed or rolled back. Multiple transactions can be active in memory in the same time, and each transactions changes are isolated form on another.

*Making data access more abstract and portable. ORM implementation classes know how to write vendor-specific SQL, so you don't have to.

=Disadvantages=
[http://www.codefutures.com/weblog/andygrove/archives/2005/02/data_access_obj.html][wikipedia]
*High level of abstraction obscures as to what is actually happening in the code implementation.
*Loss in developer productivity whilst they learn to program with ORM.Developers lose understanding of what the code is actually doing - the developer is more in control using SQL.
*Heavy reliance on ORM also leads to poorly designed databases.
*Data and behaviour are not separated.
**Façade needs to be built if the data model is to be made available in a distributed architecture.
**Each ORM technology/product has a different set of APIs and porting code between them is not easy.
*The biggest advantage of ORM is also the biggest disadvantage: queries are generated automatically -
**queries can’t be optimized.
**queries select more data than needed, things get slower, more latency.
**compiling queries from ORM code is slow (ORM compiler written in PHP).
**SQL is more powerful than ORM query languages.
**database abstraction forbids vendor specific optimizations.
=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_Fall_2010/ch3_3j_KS Object-relational mapping Fall 2010] 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.Also, a detailed study of alternatives to ORM like the NoSQL databases and Document-oriented approach can be included.
=References=

# [http://en.wikipedia.org/wiki/Object-relational_mapping Wikipedia, Object-relational mapping (ORM)]
# [http://docforge.com/wiki/Object-relational_mapping , Object-relational mapping]
# [http://en.wikipedia.org/wiki/Object-relational_impedance_mismatch Object-Relational Impedance
Matching Problem]
# [http://www.hibernate.org/about/orm , The Object-Relational Impedance Mismatch]
# [http://edgeguides.rubyonrails.org/active_record_basics.html#object-relational-mapping , Active Record]

CSC/ECE 517 Fall 2013/ch1 1w43 sm

2013-10-07T20:22:43Z

Mrsreena: /* Squeel */

=Object Relational Mapping=

__TOC__

=Introduction=

[http://en.wikipedia.org/wiki/Object-relational_mapping Object-relational mapping (ORM)], or ORM, is a programming technique which associates data stored in a relational database with application objects. The ORM layer populates business objects on demand and persists them back into the relational database when updated.
ORM basically creates 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.In this wiki, we concenterate mainly on the top Ruby ORM's like Active Record,Sequel and DataMapper.Also, it includes a comparison of various ORM techniques and the advantages and disadvantages of various styles of ORM mapping.

=Need For ORM=
Need for ORM arose due to a major problem called the Object-Relational Impedance MisMatch Problem.
[http://en.wikipedia.org/wiki/Object-relational_impedance_mismatch Object-Relational Impedance MisMatch Problem] is a set of conceptual and technical difficulties, encountered when a relational database management system (RDBMS) is being used by an object-oriented program particularly when object/class definitions are mapped directly to database tables or schema.It implies that object models don't work together with relational models, i.e RDBMS represents data in tabular format while Object oriented languages represent data in the form of interconnected graph of objects.
The Mismatches that occur in Object-Oriented concepts are as follows:
*Encapsulation:
Mapping of private object representation to database tables is difficult due to availability of fewer constraints for the design of private representation as opposed to public data in RDBMS.
*Interface, Class, Inheritance and polymorphism:
Under an object-oriented paradigm, objects have interfaces that together provide the only access to the internals of that object. The relational model, on the other hand, utilizes derived relation variables (views) to provide varying perspectives and constraints to ensure integrity. Similarly, essential OOP concepts for classes of objects, inheritance and polymorphism are not supported by relational database systems.
*Identity:
RDBMS defines exactly one notion of 'sameness': the primary key. However, Object-oriented languages, for example Java, defines both object identity (a==b) and object equality (a.equals(b)).
*Associations:
Associations are represented as unidirectional references in Object Oriented languages whereas RDBMS uses the notion of foreign keys. For example, If you need bidirectional relationships in Java, you must define the association twice.Likewise, you cannot determine the multiplicity of a relationship by looking at the object domain model.
*Data navigation:
The way you access data in object-oriented languages is fundamentally different than the way you do it in a relational database. Like in Java, you navigate from one association to another walking the object network. This is not an efficient way of retrieving data from a relational database. You typically want to minimize the number of SQL queries and thus load several entities via JOINs and select the targeted entities before you start walking the object network.

=Overview=

Data management tasks in object-oriented (OO) programming are typically implemented by manipulating objects that are almost always non-scalar values. Like for example, Consider a Geometric object, an entity which can have shape and color.In the object oriented implementation, this entity would be modeled as a geometric object with shape and color as its attributes.Shape itself can contain objects like for triangles(equilateral or isosceles) and so on.Here each geometric object can be treated as a single object by any programming language and its attributes can be also accessed by various object methods.However, many popular database products such as structured query language database management systems (SQL DBMS) can only store and manipulate scalar values such as integers and strings organized within tables.

Hence, the programmer must either convert the object values into groups of simpler values for storage in the database (and convert them back upon retrieval), or only use simple scalar values within the program. Object-relational mapping is used to implement the first approach.The key is to translate the logical representation of the objects into an atomized form that is capable of being stored in the database, while somehow preserving the properties of the objects and their relationships so that they can be reloaded as an object whenever required. If this storage and retrieval functionality is implemented, the objects are then said to be persistent.

Object-Relational Mapping, commonly referred to as its abbreviation ORM, is a technique that connects the rich objects of an application to tables in a relational database management system. Using ORM, the properties and relationships of the objects in an application can be easily stored and retrieved from a database without writing SQL statements directly and with less overall database access code.

=Features=

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 makes access to database through the application extremely easy, as it provides connection from model of the program to the database.Treating database rows as objects,Program can easily access the information in more consistent manner.Also it gives flexibility to the programmers to manipulate the data with the language itself rather than working on the attributed retrieved from the database.

[When applied to Ruby, implementations of ORM often leverage the language’s 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.]

=Active Record=
[http://ar.rubyonrails.org/ ActiveRecord] insulates you from the need to use raw SQL to find database records.Active Record facilitates the creation and use of business objects whose data requires persistent storage to a database.[edgeguides]

ActiveRecord is the default ‘model’ component of the model-view-controller web-application framework Ruby on Rails, and is also a stand-alone ORM package for other Ruby applications. In both forms, it was conceived of by David Heinemeier Hansson, and has been improved upon by a number of contributors.[2]

Other, less popular ORMs have been released since ActiveRecord first took the stage. For example, DataMapper and Sequel show major improvements over the original ActiveRecord framework.[neutrality is disputed] As a response to their release and adoption by the Rails community, Ruby on Rails v3.0 is independent of an ORM system, so Rails users can easily plug in DataMapper or Sequel to use as their ORM of choice.[wiki]

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>

Note in the preceding example, that 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 whose 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]]

Active Record will perform queries on the database for you and is compatible with most database systems (MySQL, PostgreSQL and SQLite to name a few). Regardless of which database system you're using, the ActiveRecord method format will always be the same.
To retrieve objects from the database, Active Record provides several finder methods. Each finder method allows you to pass arguments into it to perform certain queries on your database without writing raw SQL.[guide.rubyonrails]

'''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.

=Sequel=
[http://sequel.rubyforge.org Sequel] is designed to take the hassle away from connecting to databases and manipulating them. Sequel deals with all the boring stuff like maintaining connections, formatting SQL correctly and fetching records so you can concentrate on your application.
Sequel uses the concept of datasets to retrieve data. A Dataset object encapsulates an SQL query and supports chainability, letting you fetch data using a convenient Ruby DSL that is both concise and flexible.The current sequel version is 4.2.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.

Sequel::Model is an object relational mapper built on top of Sequel core. Each model class is backed by a dataset instance, and many dataset methods can be called directly on the class. Model datasets return rows as model instances, which have fairly standard ORM instance behavior.

Sequel::Model is built completely out of plugins. Plugins can override any class, instance, or dataset method defined by a previous plugin and call super to get the default behavior

=Features=

*Sequel provides thread safety, connection pooling and a concise DSL for constructing SQL *queries and table schemas.
*Sequel includes a comprehensive ORM layer for mapping records to Ruby objects and handling associated records.
*Sequel supports advanced database features such as prepared statements, bound variables, stored procedures, savepoints, two-phase commit, transaction isolation, master/slave configurations, and database sharding.
*Sequel currently has adapters for ADO, Amalgalite, CUBRID, DataObjects, DB2, DBI, Firebird, IBM_DB, Informix, JDBC, MySQL, Mysql2, ODBC, OpenBase, Oracle, PostgreSQL, SQLite3, Swift, and TinyTDS.[sequel.rubyforge]

<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.

=DataMapper=
DataMapper is an Object Relational Mapper written in Ruby. The goal is to create an ORM which is fast, thread-safe and feature rich.
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 even some popular webservices.[datamapper.org]

=Features=
*Eager loading of child associations to avoid (N+1) queries
*Lazy loading of select properties, e.g., larger fields
*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.[2] As a result, DataMapper adapters have been built for other non-SQL databases, such as CouchDB,[3] Apache Solr,[4] and web services such as Salesforce.[wikipedia]

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.

=Squeel=
Squeel unlocks the power of Arel in your Rails 3 application with a handy block-based syntax. You can write subqueries, access named functions provided by your RDBMS, and more, all without writing SQL strings. Squeel acts as an add on to Active Record and makes it easier to write queries with fewer strings.
A simple example is as follows:
Squeel lets you rewrite
<pre>
Article.where ['created_at >= ?', 2.weeks.ago]
</pre>
as
<pre>
Article.where{created_at >= 2.weeks.ago}
</pre>

=MyBatis/iBatis=
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. Follows below a MyBatis mapper, that consist on 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>
=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
|}

=NonSQL databases:=
Instead of ORM we can also use 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 user from retrieving 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 in XML file. [http://programmers.stackexchange.com/questions/124976/why-are-sql-databases-still-used-with-orm]

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.[wikipedia]

NoSQL 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

=Advantages=
[http://blogs.msdn.com/b/gblock/archive/2006/10/26/ten-advantages-of-an-orm.aspx]
*Facilitates implementing the Domain Model pattern that allows you to model entities based on real business concepts rather than based on our database structure. ORM tools provide this functionality through mapping between the logical business model and the physical storage model.

*Huge reduction in code. Ease of use, faster development, increased productivity.
ORM tools provide a host of services thereby allowing developers to focus on the business logic of the application rather than repetitive CRUD (Create Read Update Delete) logic.

*Changes to the object model are made in one place. One you update your object definitions, the ORM will automatically use the updated structure for retrievals and updates. There are no SQL Update, Delete and Insert statements strewn throughout different layers of the application that need modification.

*Rich query capability. ORM tools provide an object oriented query language. This allows application developers to focus on the object model and not to have to be concerned with the database structure or SQL semantics. The ORM tool itself will translate the query language into the appropriate syntax for the database.

*Navigation. You can navigate object relationships transparently. Related objects are automatically loaded as needed. For example if you load a Post and you want to access it's Comment, you can simply access Post.Comment and the ORM will take care of loading the data for you without any effort on your part.

*Data loads are completely configurable allowing you to load the data appropriate for each scenario. For example in one scenario you might want to load a list of objects without any of it's child / related objects, while in other scenarios you can specify to load an object, with all it's children etc.

*Concurrency support. Support for multiple users updating the same data simultaneously.

*Cache management. Entities are cached in memory thereby reducing load on the database.

*Transaction management and Isolation. All object changes occur scoped to a transaction. The entire transaction can either be committed or rolled back. Multiple transactions can be active in memory in the same time, and each transactions changes are isolated form on another.

*Making data access more abstract and portable. ORM implementation classes know how to write vendor-specific SQL, so you don't have to.

=Disadvantages=
[http://www.codefutures.com/weblog/andygrove/archives/2005/02/data_access_obj.html][wikipedia]
*High level of abstraction obscures as to what is actually happening in the code implementation.
*Loss in developer productivity whilst they learn to program with ORM.Developers lose understanding of what the code is actually doing - the developer is more in control using SQL.
*Heavy reliance on ORM also leads to poorly designed databases.
*Data and behaviour are not separated.
**Façade needs to be built if the data model is to be made available in a distributed architecture.
**Each ORM technology/product has a different set of APIs and porting code between them is not easy.
*The biggest advantage of ORM is also the biggest disadvantage: queries are generated automatically -
**queries can’t be optimized.
**queries select more data than needed, things get slower, more latency.
**compiling queries from ORM code is slow (ORM compiler written in PHP).
**SQL is more powerful than ORM query languages.
**database abstraction forbids vendor specific optimizations.
=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_Fall_2010/ch3_3j_KS Object-relational mapping Fall 2010] 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.Also, a detailed study of alternatives to ORM like the NoSQL databases and Document-oriented approach can be included.
=References=

# [http://en.wikipedia.org/wiki/Object-relational_mapping Wikipedia, Object-relational mapping (ORM)]
# [http://docforge.com/wiki/Object-relational_mapping , Object-relational mapping]
# [http://en.wikipedia.org/wiki/Object-relational_impedance_mismatch Object-Relational Impedance
Matching Problem]
# [http://www.hibernate.org/about/orm , The Object-Relational Impedance Mismatch]
# [http://edgeguides.rubyonrails.org/active_record_basics.html#object-relational-mapping , Active Record]