Expertiza_Wiki - User contributions [en]

CSC/ECE 517 Spring 2013/OSS E605A

2013-03-18T19:45:15Z

Eblumpki2: Added references

=Expertiza Questionnaire Refactoring=

__TOC__

=Introduction=

This project involved refactoring the questionnaire portion of Expertiza. This part of the Expertiza project deals with the creation and management of questionnaires that are used during project review and feedback. It also allows for the creation of advice on what each score in a question should represent (a 5 being excellent, 3 being average, etc.). The majority of the refactoring took place in the file questionnaire_controller.rb, as it contains the CRUD functionality for questionnaires. Some refactoring also took place on the questionnaire.rb model, along with various different kinds of questionnaires that were represented as subclasses of questionnaire.rb.

=List of Changes=

Following is a list of the changes made during refactoring, along with the design principles and patterns that were upheld by making these changes.

==Pulled up get_weighted_score==

Each of the questionnaire subclasses had a get_weighted_score method that tallied up the points for a completed questionnaire. These methods were all identical, so we pulled the method up to the questionnaire superclass (questionnaire.rb). The following subclasses had the method and were refactored accordingly:

* author_feedback_questionnaire.rb
* metareview_questionnaire.rb
* review_questionnaire.rb
* teammate_review_questionnaire.rb
* questionnaire.rb (superclass that the method was moved to)

The main design principle that influenced this refactor was DRY. As the same functionality was used in multiple places, moving it to the superclass made the code easier to understand by showing that all of the subclasses were able to use the function in the same way.

==Renamed create_questionnaire and save_questionnaire==

The questionnaire_controller (questionnaire_controller.rb) contained CRUD functionality for several types of objects. Naturally, one of these objects was a questionnaire. For clarity, its methods had been named create_questionnaire and save_questionnaire. However, proper Ruby design emphasizes convention over configuration. Since the methods were in the questionnaire controller, the convention is to name them create and save, as the fact that they affect a questionnaire is implied. Therefore create_questionnaire (on line 156) was changed to create and save_questionnaire (on line 214) was changed to save.

==Pulled methods from edit==

The edit method in questionnaire_controller.rb did not need to be renamed, but it had another problem; the method was too long. Keeping methods short (around 25 lines or less) is another design principle that increases the readability of code. Therefore, we looked for chunks of the method that would make sense if pulled out as a separate method. Part of the edit method involved exporting and importing questionnaires. These chunks of code were well contained, with clear start and stop points, so we pulled them into separate methods. This resulted in creating an export method from lines 102-108 of the old edit method, and an import method from lines 110-125 of the old method. By doing this, the edit method was shortened to an acceptable length.

==Created advice_controller==

As mentioned above, the questionnaire controller contained some CRUD methods that dealt with another type of object besides questionnaires. This was the advice object, which is used to type notes regarding what score should be given on a question. Again, this violated the Ruby principle of convention over configuration, since these advice methods were in the questionnaire controller. Therefore, a new advice controller (advice_controller.rb) was created, and the edit_advice and save_advice methods were moved from the questionnaire controller to it.

==Removed delete_question_type==

The questionnaire_controller had a delete_question_type method that was only used when destroying the questions of a questionnaire. As it only consisted of two lines, and was only used in one place, we felt that having it in a separate method caused a minor, but unnecessary, case of the Ping-Pong effect. Since the code of the method was rather self-explanatory (simply finding the question type of the question to be deleted and destroying it), moving the functionality back into the delete_questions method and removing the delete_question_type method reduced the complexity of the code without affecting its readability or DRYness.

=References=

* [https://www.youtube.com/watch?v=XZzKb_PM07A Project Screencast]
* [https://github.com/expertiza/expertiza Main Expertiza Repository]
* [https://github.com/mlhall3/expertiza Refactored Expertiza Fork]

CSC/ECE 517 Spring 2013/OSS E605A

2013-03-18T19:40:23Z

Eblumpki2:

=Expertiza Questionnaire Refactoring=

__TOC__

=Introduction=

This project involved refactoring the questionnaire portion of Expertiza. This part of the Expertiza project deals with the creation and management of questionnaires that are used during project review and feedback. It also allows for the creation of advice on what each score in a question should represent (a 5 being excellent, 3 being average, etc.). The majority of the refactoring took place in the file questionnaire_controller.rb, as it contains the CRUD functionality for questionnaires. Some refactoring also took place on the questionnaire.rb model, along with various different kinds of questionnaires that were represented as subclasses of questionnaire.rb.

=List of Changes=

Following is a list of the changes made during refactoring, along with the design principles and patterns that were upheld by making these changes.

==Pulled up get_weighted_score==

Each of the questionnaire subclasses had a get_weighted_score method that tallied up the points for a completed questionnaire. These methods were all identical, so we pulled the method up to the questionnaire superclass (questionnaire.rb). The following subclasses had the method and were refactored accordingly:

* author_feedback_questionnaire.rb
* metareview_questionnaire.rb
* review_questionnaire.rb
* teammate_review_questionnaire.rb
* questionnaire.rb (superclass that the method was moved to)

The main design principle that influenced this refactor was DRY. As the same functionality was used in multiple places, moving it to the superclass made the code easier to understand by showing that all of the subclasses were able to use the function in the same way.

==Renamed create_questionnaire and save_questionnaire==

The questionnaire_controller (questionnaire_controller.rb) contained CRUD functionality for several types of objects. Naturally, one of these objects was a questionnaire. For clarity, its methods had been named create_questionnaire and save_questionnaire. However, proper Ruby design emphasizes convention over configuration. Since the methods were in the questionnaire controller, the convention is to name them create and save, as the fact that they affect a questionnaire is implied. Therefore create_questionnaire (on line 156) was changed to create and save_questionnaire (on line 214) was changed to save.

==Pulled methods from edit==

The edit method in questionnaire_controller.rb did not need to be renamed, but it had another problem; the method was too long. Keeping methods short (around 25 lines or less) is another design principle that increases the readability of code. Therefore, we looked for chunks of the method that would make sense if pulled out as a separate method. Part of the edit method involved exporting and importing questionnaires. These chunks of code were well contained, with clear start and stop points, so we pulled them into separate methods. This resulted in creating an export method from lines 102-108 of the old edit method, and an import method from lines 110-125 of the old method. By doing this, the edit method was shortened to an acceptable length.

==Created advice_controller==

As mentioned above, the questionnaire controller contained some CRUD methods that dealt with another type of object besides questionnaires. This was the advice object, which is used to type notes regarding what score should be given on a question. Again, this violated the Ruby principle of convention over configuration, since these advice methods were in the questionnaire controller. Therefore, a new advice controller (advice_controller.rb) was created, and the edit_advice and save_advice methods were moved from the questionnaire controller to it.

==Removed delete_question_type==

The questionnaire_controller had a delete_question_type method that was only used when destroying the questions of a questionnaire. As it only consisted of two lines, and was only used in one place, we felt that having it in a separate method caused a minor, but unnecessary, case of the Ping-Pong effect. Since the code of the method was rather self-explanatory (simply finding the question type of the question to be deleted and destroying it), moving the functionality back into the delete_questions method and removing the delete_question_type method reduced the complexity of the code without affecting its readability or DRYness.

=References=

* [http://www.youtube.com/embed/XZzKb_PM07A Project Screencast]

CSC/ECE 517 Spring 2013/OSS E605A

2013-03-18T19:40:07Z

Eblumpki2:

=Expertiza Questionnaire Refactoring=

__TOC__

=Introduction=

This project involved refactoring the questionnaire portion of Expertiza. This part of the Expertiza project deals with the creation and management of questionnaires that are used during project review and feedback. It also allows for the creation of advice on what each score in a question should represent (a 5 being excellent, 3 being average, etc.). The majority of the refactoring took place in the file questionnaire_controller.rb, as it contains the CRUD functionality for questionnaires. Some refactoring also took place on the questionnaire.rb model, along with various different kinds of questionnaires that were represented as subclasses of questionnaire.rb.

=List of Changes=

Following is a list of the changes made during refactoring, along with the design principles and patterns that were upheld by making these changes.

==Pulled up get_weighted_score==

Each of the questionnaire subclasses had a get_weighted_score method that tallied up the points for a completed questionnaire. These methods were all identical, so we pulled the method up to the questionnaire superclass (questionnaire.rb). The following subclasses had the method and were refactored accordingly:

* author_feedback_questionnaire.rb
* metareview_questionnaire.rb
* review_questionnaire.rb
* teammate_review_questionnaire.rb
* questionnaire.rb (superclass that the method was moved to)

The main design principle that influenced this refactor was DRY. As the same functionality was used in multiple places, moving it to the superclass made the code easier to understand by showing that all of the subclasses were able to use the function in the same way.

==Renamed create_questionnaire and save_questionnaire==

The questionnaire_controller (questionnaire_controller.rb) contained CRUD functionality for several types of objects. Naturally, one of these objects was a questionnaire. For clarity, its methods had been named create_questionnaire and save_questionnaire. However, proper Ruby design emphasizes convention over configuration. Since the methods were in the questionnaire controller, the convention is to name them create and save, as the fact that they affect a questionnaire is implied. Therefore create_questionnaire (on line 156) was changed to create and save_questionnaire (on line 214) was changed to save.

==Pulled methods from edit==

The edit method in questionnaire_controller.rb did not need to be renamed, but it had another problem; the method was too long. Keeping methods short (around 25 lines or less) is another design principle that increases the readability of code. Therefore, we looked for chunks of the method that would make sense if pulled out as a separate method. Part of the edit method involved exporting and importing questionnaires. These chunks of code were well contained, with clear start and stop points, so we pulled them into separate methods. This resulted in creating an export method from lines 102-108 of the old edit method, and an import method from lines 110-125 of the old method. By doing this, the edit method was shortened to an acceptable length.

==Created advice_controller==

As mentioned above, the questionnaire controller contained some CRUD methods that dealt with another type of object besides questionnaires. This was the advice object, which is used to type notes regarding what score should be given on a question. Again, this violated the Ruby principle of convention over configuration, since these advice methods were in the questionnaire controller. Therefore, a new advice controller (advice_controller.rb) was created, and the edit_advice and save_advice methods were moved from the questionnaire controller to it.

==Removed delete_question_type==

The questionnaire_controller had a delete_question_type method that was only used when destroying the questions of a questionnaire. As it only consisted of two lines, and was only used in one place, we felt that having it in a separate method caused a minor, but unnecessary, case of the Ping-Pong effect. Since the code of the method was rather self-explanatory (simply finding the question type of the question to be deleted and destroying it), moving the functionality back into the delete_questions method and removing the delete_question_type method reduced the complexity of the code without affecting its readability or DRYness.

=References=

* [http://www.youtube.com/embed/XZzKb_PM07A | Project Screencast]

CSC/ECE 517 Spring 2013/OSS E605A

2013-03-18T19:39:50Z

Eblumpki2:

=Expertiza Questionnaire Refactoring=

__TOC__

=Introduction=

This project involved refactoring the questionnaire portion of Expertiza. This part of the Expertiza project deals with the creation and management of questionnaires that are used during project review and feedback. It also allows for the creation of advice on what each score in a question should represent (a 5 being excellent, 3 being average, etc.). The majority of the refactoring took place in the file questionnaire_controller.rb, as it contains the CRUD functionality for questionnaires. Some refactoring also took place on the questionnaire.rb model, along with various different kinds of questionnaires that were represented as subclasses of questionnaire.rb.

=List of Changes=

Following is a list of the changes made during refactoring, along with the design principles and patterns that were upheld by making these changes.

==Pulled up get_weighted_score==

Each of the questionnaire subclasses had a get_weighted_score method that tallied up the points for a completed questionnaire. These methods were all identical, so we pulled the method up to the questionnaire superclass (questionnaire.rb). The following subclasses had the method and were refactored accordingly:

* author_feedback_questionnaire.rb
* metareview_questionnaire.rb
* review_questionnaire.rb
* teammate_review_questionnaire.rb
* questionnaire.rb (superclass that the method was moved to)

The main design principle that influenced this refactor was DRY. As the same functionality was used in multiple places, moving it to the superclass made the code easier to understand by showing that all of the subclasses were able to use the function in the same way.

==Renamed create_questionnaire and save_questionnaire==

The questionnaire_controller (questionnaire_controller.rb) contained CRUD functionality for several types of objects. Naturally, one of these objects was a questionnaire. For clarity, its methods had been named create_questionnaire and save_questionnaire. However, proper Ruby design emphasizes convention over configuration. Since the methods were in the questionnaire controller, the convention is to name them create and save, as the fact that they affect a questionnaire is implied. Therefore create_questionnaire (on line 156) was changed to create and save_questionnaire (on line 214) was changed to save.

==Pulled methods from edit==

The edit method in questionnaire_controller.rb did not need to be renamed, but it had another problem; the method was too long. Keeping methods short (around 25 lines or less) is another design principle that increases the readability of code. Therefore, we looked for chunks of the method that would make sense if pulled out as a separate method. Part of the edit method involved exporting and importing questionnaires. These chunks of code were well contained, with clear start and stop points, so we pulled them into separate methods. This resulted in creating an export method from lines 102-108 of the old edit method, and an import method from lines 110-125 of the old method. By doing this, the edit method was shortened to an acceptable length.

==Created advice_controller==

As mentioned above, the questionnaire controller contained some CRUD methods that dealt with another type of object besides questionnaires. This was the advice object, which is used to type notes regarding what score should be given on a question. Again, this violated the Ruby principle of convention over configuration, since these advice methods were in the questionnaire controller. Therefore, a new advice controller (advice_controller.rb) was created, and the edit_advice and save_advice methods were moved from the questionnaire controller to it.

==Removed delete_question_type==

The questionnaire_controller had a delete_question_type method that was only used when destroying the questions of a questionnaire. As it only consisted of two lines, and was only used in one place, we felt that having it in a separate method caused a minor, but unnecessary, case of the Ping-Pong effect. Since the code of the method was rather self-explanatory (simply finding the question type of the question to be deleted and destroying it), moving the functionality back into the delete_questions method and removing the delete_question_type method reduced the complexity of the code without affecting its readability or DRYness.

=References=

* [[http://www.youtube.com/embed/XZzKb_PM07A | Project Screencast]]

CSC/ECE 517 Spring 2013/OSS E605A

2013-03-18T19:35:47Z

Eblumpki2:

=Expertiza Questionnaire Refactoring=

__TOC__

=Introduction=

This project involved refactoring the questionnaire portion of Expertiza. This part of the Expertiza project deals with the creation and management of questionnaires that are used during project review and feedback. It also allows for the creation of advice on what each score in a question should represent (a 5 being excellent, 3 being average, etc.). The majority of the refactoring took place in the file questionnaire_controller.rb, as it contains the CRUD functionality for questionnaires. Some refactoring also took place on the questionnaire.rb model, along with various different kinds of questionnaires that were represented as subclasses of questionnaire.rb.

=List of Changes=

Following is a list of the changes made during refactoring, along with the design principles and patterns that were upheld by making these changes.

==Pulled up get_weighted_score==

Each of the questionnaire subclasses had a get_weighted_score method that tallied up the points for a completed questionnaire. These methods were all identical, so we pulled the method up to the questionnaire superclass (questionnaire.rb). The following subclasses had the method and were refactored accordingly:

* author_feedback_questionnaire.rb
* metareview_questionnaire.rb
* review_questionnaire.rb
* teammate_review_questionnaire.rb
* questionnaire.rb (superclass that the method was moved to)

The main design principle that influenced this refactor was DRY. As the same functionality was used in multiple places, moving it to the superclass made the code easier to understand by showing that all of the subclasses were able to use the function in the same way.

==Renamed create_questionnaire and save_questionnaire==

The questionnaire_controller (questionnaire_controller.rb) contained CRUD functionality for several types of objects. Naturally, one of these objects was a questionnaire. For clarity, its methods had been named create_questionnaire and save_questionnaire. However, proper Ruby design emphasizes convention over configuration. Since the methods were in the questionnaire controller, the convention is to name them create and save, as the fact that they affect a questionnaire is implied. Therefore create_questionnaire (on line 156) was changed to create and save_questionnaire (on line 214) was changed to save.

==Pulled methods from edit==

The edit method in questionnaire_controller.rb did not need to be renamed, but it had another problem; the method was too long. Keeping methods short (around 25 lines or less) is another design principle that increases the readability of code. Therefore, we looked for chunks of the method that would make sense if pulled out as a separate method. Part of the edit method involved exporting and importing questionnaires. These chunks of code were well contained, with clear start and stop points, so we pulled them into separate methods. This resulted in creating an export method from lines 102-108 of the old edit method, and an import method from lines 110-125 of the old method. By doing this, the edit method was shortened to an acceptable length.

==Created advice_controller==

As mentioned above, the questionnaire controller contained some CRUD methods that dealt with another type of object besides questionnaires. This was the advice object, which is used to type notes regarding what score should be given on a question. Again, this violated the Ruby principle of convention over configuration, since these advice methods were in the questionnaire controller. Therefore, a new advice controller (advice_controller.rb) was created, and the edit_advice and save_advice methods were moved from the questionnaire controller to it.

==Removed delete_question_type==

The questionnaire_controller had a delete_question_type method that was only used when destroying the questions of a questionnaire. As it only consisted of two lines, and was only used in one place, we felt that having it in a separate method caused a minor, but unnecessary, case of the Ping-Pong effect. Since the code of the method was rather self-explanatory (simply finding the question type of the question to be deleted and destroying it), moving the functionality back into the delete_questions method and removing the delete_question_type method reduced the complexity of the code without affecting its readability or DRYness.

=Screencast=

<iframe width="420" height="315" src="http://www.youtube.com/embed/XZzKb_PM07A" frameborder="0" allowfullscreen></iframe>

CSC/ECE 517 Spring 2013/OSS E605A

2013-03-18T19:32:18Z

Eblumpki2:

CSC/ECE 517 Spring 2013/OSS E605A

2013-03-18T19:30:36Z

Eblumpki2: Fixed embedded screencast (hopefully)

=Expertiza Questionnaire Refactoring=

__TOC__

=Introduction=

This project involved refactoring the questionnaire portion of Expertiza. This part of the Expertiza project deals with the creation and management of questionnaires that are used during project review and feedback. It also allows for the creation of advice on what each score in a question should represent (a 5 being excellent, 3 being average, etc.). The majority of the refactoring took place in the file questionnaire_controller.rb, as it contains the CRUD functionality for questionnaires. Some refactoring also took place on the questionnaire.rb model, along with various different kinds of questionnaires that were represented as subclasses of questionnaire.rb.

=List of Changes=

Following is a list of the changes made during refactoring, along with the design principles and patterns that were upheld by making these changes.

==Pulled up get_weighted_score==

Each of the questionnaire subclasses had a get_weighted_score method that tallied up the points for a completed questionnaire. These methods were all identical, so we pulled the method up to the questionnaire superclass (questionnaire.rb). The following subclasses had the method and were refactored accordingly:

* author_feedback_questionnaire.rb
* metareview_questionnaire.rb
* review_questionnaire.rb
* teammate_review_questionnaire.rb
* questionnaire.rb (superclass that the method was moved to)

The main design principle that influenced this refactor was DRY. As the same functionality was used in multiple places, moving it to the superclass made the code easier to understand by showing that all of the subclasses were able to use the function in the same way.

==Renamed create_questionnaire and save_questionnaire==

The questionnaire_controller (questionnaire_controller.rb) contained CRUD functionality for several types of objects. Naturally, one of these objects was a questionnaire. For clarity, its methods had been named create_questionnaire and save_questionnaire. However, proper Ruby design emphasizes convention over configuration. Since the methods were in the questionnaire controller, the convention is to name them create and save, as the fact that they affect a questionnaire is implied. Therefore create_questionnaire (on line 156) was changed to create and save_questionnaire (on line 214) was changed to save.

==Pulled methods from edit==

The edit method in questionnaire_controller.rb did not need to be renamed, but it had another problem; the method was too long. Keeping methods short (around 25 lines or less) is another design principle that increases the readability of code. Therefore, we looked for chunks of the method that would make sense if pulled out as a separate method. Part of the edit method involved exporting and importing questionnaires. These chunks of code were well contained, with clear start and stop points, so we pulled them into separate methods. This resulted in creating an export method from lines 102-108 of the old edit method, and an import method from lines 110-125 of the old method. By doing this, the edit method was shortened to an acceptable length.

==Created advice_controller==

As mentioned above, the questionnaire controller contained some CRUD methods that dealt with another type of object besides questionnaires. This was the advice object, which is used to type notes regarding what score should be given on a question. Again, this violated the Ruby principle of convention over configuration, since these advice methods were in the questionnaire controller. Therefore, a new advice controller (advice_controller.rb) was created, and the edit_advice and save_advice methods were moved from the questionnaire controller to it.

==Removed delete_question_type==

The questionnaire_controller had a delete_question_type method that was only used when destroying the questions of a questionnaire. As it only consisted of two lines, and was only used in one place, we felt that having it in a separate method caused a minor, but unnecessary, case of the Ping-Pong effect. Since the code of the method was rather self-explanatory (simply finding the question type of the question to be deleted and destroying it), moving the functionality back into the delete_questions method and removing the delete_question_type method reduced the complexity of the code without affecting its readability or DRYness.

=Screencast=

<code><nowiki><youtube>XZzKb_PM07A</youtube></nowiki></code>

CSC/ECE 517 Spring 2013/OSS E605A

2013-03-18T19:28:35Z

Eblumpki2: Embedded screencast (hopefully)

CSC/ECE 517 Spring 2013/OSS E605A

2013-03-18T19:24:33Z

Eblumpki2: Created the page.

CSC/ECE 517 Spring 2013/ch1 1d zk

2013-02-16T02:58:06Z

Eblumpki2: Added information requested in feedback.

=Object-relational Mapping for Ruby=

__TOC__

=Introduction=

[http://en.wikipedia.org/wiki/Object-relational_mapping Object-relational mapping (ORM)] provides developers with a set of tools that ease management of the relationships between objects and relational databases, thus allowing applications to be easily extended to add data persistence. For Ruby, several object-relational mapping options are available. This wiki concentrates more on the comparison of ORMs and provides a high level overview of the top Ruby ORMs: ActiveRecord ,Sequel and DataMapper. It also includes a minor discussion on alternative frameworks that can be used either in place of or along with ORMs. These include the persistence framework iBATIS (more specifically the Ruby version RBatis), and the stack framework Merb.

=Overview=

Object-relational Mapping (ORM) frameworks unburden the designer of the complex translation between database and object space.

Typical ORM features:
* Automatic mapping from classes to database tables
** Class instance variables to database columns
** Class instances to table rows
* Aggregation and association relationships between mapped classes are managed
** Example, :has_many, :belongs_to associations in ActiveRecord
** Inheritance cases are mapped to tables
* Validation of data prior to table storage
* Class extensions to enable search, as well as creation, read, update, and deletion (CRUD) of instances/records
* Usually abstracts the database from program space in such a way that alternate database types can be easily chosen (SQLite, Oracle, etc)

The diagram below depicts a simple mapping of an object to a database table….

[[Image:3j_ks_pic1.jpg]]

ORMs are crucial to almost any application that needs to access a database, as they provide the connection from the model of the program to the database itself. By enabling database rows to be used as objects, the program can more easily access and use the information in a way that is internally consistent and easy to understand. The ORM gives the programmer to manipulate data with the programming language, instead of having to manipulate each attribute as its data type as obtained by the database management system.

When applied to Ruby, implementations of ORM often leverage the language’s [http://en.wikipedia.org/wiki/Metaprogramming metaprogramming] strengths to create intuitive application-specific methods and otherwise extend classes to support database functionality. With the addition of Rails, the ORM becomes much more important, as it is necessary to have an ORM to connect the models of the MVC (model-view-controller) stack used by Ruby on Rails with the application's database. Since the models are Ruby objects, the ORM allows modifications to the database to be done through changes to these models, independent of the type of database used.

With the release of Rails 3.0, the platform became ORM independent. With this change, it is much easier to use the ORM most preferred by the programmer, rather than being corralled into using one particular one. To allow this, the ORM needed to be extracted from the model and the database, to be a pure mediator between the two. Then any ORM can be used as long as it can successfully understand the model and the database used.

=ActiveRecord=

[http://ar.rubyonrails.org/ ActiveRecord], originally created by David Heinemeier and released in 2003, became the de-facto ORM for Ruby since it was integrated in the widely-used Rails framework, however alternate ORMs for Ruby have been developed and Rails 3.x is ORM independent. ActiveRecord is an implementation of the active record design pattern, where a table is wrapped into a class and this class implements accessor methods for each column in the table.

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 preceeding 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 who's name is Bob, one would use @user = User.find_by_name('Bob'). Then one could find Bob's e-mail by using @user.email. Users can be searched for by any attribute in this way, as find methods are created for every combination of attributes.
While ActiveRecord provides the flexibility to create more sophisticated table relationships to represent class hierarchy, its base scheme is a single table inheritance, which trades some storage efficiency for simplicity in the database design. The following figure illustrates this concept of simplicity over efficiency.

[[Image:3j_ks_pic2.jpg]]

'''Pros''' -
* Integrated with popular Rails development framework
* Dynamically created database search methods (eg: User.find_by_address) ease db queries and make queries database syntax independent
* DB creation/management using the migrate scheme provides a means for backing out unwanted table changes
'''Cons''' -
* DB creation/management is decoupled from the model, requiring a separate utility (rake/migrate) that must be kept in sync with application

=Sequel=

[http://sequel.rubyforge.org Sequel] was originally developed by Sharon Rosner and the first release was in March 2007. It is based on the active record pattern. Sequel and Active Record share a lot of common features , for example association and inheritance. But Sequel handles these features in a much more flexible manner. Currently Sequel is at version 3.44.0. Initially Sequel had three core modules - sequel, sequel_core and sequel_model. Starting from version 1.4 , sequel and sequel_model were merged. Sequel handles validations using a validation plug-in and helpers.

<pre>
class CreateUser < Sequel::Migration
def up
create_table(:user) {
primary_key :id
String :name
String :age
String :email}
end
def down
drop_table(:user)
end
end # CreateUser.apply(DB, :up)
</pre>

Sequel supports associations and validations similar to Active Record. The following example shows how validations and associations can be enforced in the User table that has been created above. It enforces one to many relationships between the user table and the cheers and posts tables. It also validates for the presence , uniqueness and the length of the attribute '''name'''.

<pre>
class User < Sequel::Model
one_to_many :cheers
one_to_many :posts

validates_presence [:name, :age]
validates_unique(:name)
validates_length_range 3..20, :name
end
</pre>

To access the data in Sequel, one can use where clauses. For instance, to find Bob again one would use DB[:items].where(Sequel.like(:name, 'Bob'). While the ability to use SQL-like where clauses is quite flexible, it is not quite as pure an object-oriented approach as Active Record's dynamically created find methods.

Some of the key features of sequel are,
* Connection Pooling
* Thread Safety
* [http://wiki.rubyonrails.org/howtos/db-relationships/eager-loading Eager Loading] / Lazy Loading
* Model Caching

=DataMapper=

[http://datamapper.org/ DataMapper] is an open source ORM for Ruby originally developed by Sam Smoot and first released in 2007. DataMapper provides a very flexible mapping API which allows creation of adapters to a wide variety of datastores beyond traditional SQL-based relational databases – DataMapper adapters have been created to non-standard sources such as the Salesforce API and even Google Video.

Unlike ActiveRecord and Sequel, DataMapper does not rely on a migration scheme to create and manage DB tables. Instead, DataMapper allows table definition as part of the model class definition which keeps the model definition contained to a single file, thus minimizing the effort required to keep the database and model definitions in sync. When required, DataMapper can also support a migration methodology similar to other ORMs.

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.

Some of the key features of DataMapper are:
* API supports a wide variety of databases, including non SQL types
* Thread Safety
* [http://wiki.rubyonrails.org/howtos/db-relationships/eager-loading Eager Loading] of child associations
* Lazy loading
* Works with or without a migration file.

=iBATIS=

[http://ibatis.apache.org/ 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.

RBatis is more lightweight than the other ORMs discussed so far. It provides a wrapper for SQL commands in Ruby, enabling one to call SQL with Ruby methods.

For instance, this code creates methods to find a user by ID and name.

<pre>
Class User < RBatis::Base

statement :select_one, :find do |id|
["SELECT * FROM users WHERE id = ?", id]
end

statement :select_one, :find_by_name do |name|
["SELECT * FROM users WHERE name = ?", name]
end
end
</pre>

These methods can now be used as class methods.

<pre>
User.find(1)
User.find_by_name('Bob')
</pre>

'''Pros''' -
* Enables direct use of SQL functionality within Ruby.
* Is a thinner ORM than the others discussed.
* Allows the programmer to create his or her own custom find methods.
'''Cons''' -
* No longer supported
* Database needs to be created/managed separately.
* Standard find methods are not automatically created.

=Merb=

[http://www.merbivore.com/index.html Merb] was a model-view-controller framework created by Ezra Zygmuntowicz and released on November 7, 2008. It was a full-stack system like Rails, but only consisted of the core needed to create an application, leaving additional functionality to be installed by extra gems.
Merb is at 1.1, and will not have a v2.0 as it was absorbed into Rails 3.0 in 2008.

Merb itself provides only the controller of an MVC model, but this core is easily extended to create a full-stack application environment. In this sense, Merb itself is not an ORM, but it can easily accomodate any of the other ORMs described.

=Comparison of ORM Features=

{|cellspacing="0" border="1"
!style="width:10%"|Features
!style="width:30%"|ActiveRecord
!style="width:30%"|Sequel
!style="width:30%"|DataMapper
|-
! 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
|-
! Migrations 
| Yes
| Yes
| Yes, but optional
|-
! EagerLoading 
| Supported by scanning the SQL fragments
| Supported using eager (preloading) and eager_graph (joins)
| Strategic Eager Loading and by using :summary
|-
! Flexible Overriding 
| No. Overriding is done using alias methods.
| Using methods and by calling 'super'
| Using methods
|-
! Dynamic Finders 
| Yes. Uses 'Method Missing'
| No. Alternative is to use <Model>.FindOrCreate(:name=>"John")
| Yes. Using the dm_ar_finders plugin
|}

 

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

=References=

# [http://en.wikipedia.org/wiki/Object-relational_mapping Wikipedia, Object-relational mapping (ORM)]
# [http://ar.rubyonrails.org/ ActiveRecord]
# [http://en.wikipedia.org/wiki/Active_record_pattern Wikipedia Active record pattern]
# [http://sequel.rubyforge.org/ Sequel]
# [http://jeremyevans-pres.heroku.com/mwrc2009_presentation.html Sequel Presentation - By Jeremy Evans]
# [http://merbist.com/2008/09/29/write-your-own-custom-datamapper-adapter/ Merbist blog on custom DM adapters - By Matt Aimonetti]
# [http://en.wikipedia.org/wiki/Datamapper DataMapper]
# [http://pg-server.csc.ncsu.edu/mediawiki/index.php/CSC/ECE_517_Fall_2007/wiki2_2_22 Object-Relational Mapping Fall 2007]
# [http://ormbattle.net/ ORMBattle.Net]
# [http://wiki.rubyonrails.org/howtos/db-relationships/eager-loading Eager-loading description on Rails Wiki]
# [http://ibatis.apache.org/ iBATIS]
# [http://ibatis.apache.org/docs/ruby/ RBatis - iBATIS for Ruby and Ruby on Rails]
# [http://www.merbivore.com/index.html Merb]

CSC/ECE 517 Spring 2013/ch1 1d zk

2013-02-11T20:11:14Z

Eblumpki2: Created page.

=Object-relational Mapping for Ruby=

__TOC__

=Introduction=

[http://en.wikipedia.org/wiki/Object-relational_mapping Object-relational mapping (ORM)] provides developers with a set of tools that ease management of the relationships between objects and relational databases, thus allowing applications to be easily extended to add data persistence. For Ruby, several object-relational mapping options are available. This wiki concentrates more on the comparison of ORMs and provides a high level overview of the top Ruby ORMs: ActiveRecord ,Sequel and DataMapper. Other products related to Ruby ORM were excluded from this comparison if their scope was limited to a subset of ORM functionality or if support for the product has waned in recent years (eg RBatis, the port of Apache iBatis ORM to Ruby).

=Overview=

Object-relational Mapping (ORM) frameworks unburden the designer of the complex translation between database and object space.

Typical ORM features:
* Automatic mapping from classes to database tables
** Class instance variables to database columns
** Class instances to table rows
* Aggregation and association relationships between mapped classes are managed
** Example, :has_many, :belongs_to associations in ActiveRecord
** Inheritance cases are mapped to tables
* Validation of data prior to table storage
* Class extensions to enable search, as well as creation, read, update, and deletion (CRUD) of instances/records
* Usually abstracts the database from program space in such a way that alternate database types can be easily chosen (SQLite, Oracle, etc)

The diagram below depicts a simple mapping of an object to a database table….

[[Image:3j_ks_pic1.jpg]]

When applied to Ruby, implementations of ORM often leverage the language’s [http://en.wikipedia.org/wiki/Metaprogramming metaprogramming] strengths to create intuitive application-specific methods and otherwise extend classes to support database functionality.

With the 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.

=ActiveRecord=

[http://ar.rubyonrails.org/ ActiveRecord], originally created by David Heinemeier and released in 2003, became the de-facto ORM for Ruby since it was integrated in the widely-used Rails framework, however alternate ORMs for Ruby have been developed and Rails 3.x is ORM independent. ActiveRecord is an implementation of the active record design pattern, where a table is wrapped into a class and this class implements accessor methods for each column in the table.

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 preceeding 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 ‘’to_many’’ association with both the cheers and posts tables. These associations are represented in the migration class with the references operator. Also note ActiveRecord’s integrated support for validation of table information when attempting an update.

<pre>
class User < ActiveRecord::Base
has_many :cheers
has_many :posts

validates_presence_of :name
validates_presence_of :age
validates_uniqueness_of :name
validates_length_of :name, :within => 3..20
end
</pre>

To access the data in the table one calls the class function related to that column. For example, to find the user who's name is Bob, one would use @user = User.find_by_name('Bob'). Then one could find Bob's e-mail by using @user.email.
While ActiveRecord provides the flexibility to create more sophisticated table relationships to represent class hierarchy, its base scheme is a single table inheritance, which trades some storage efficiency for simplicity in the database design. The following figure illustrates this concept of simplicity over efficiency.

[[Image:3j_ks_pic2.jpg]]

'''Pros''' -
* Integrated with popular Rails development framework
* Dynamically created database search methods (eg: User.find_by_address) ease db queries and make queries database syntax independent
* DB creation/management using the migrate scheme provides a means for backing out unwanted table changes
'''Cons''' -
* DB creation/management is decoupled from the model, requiring a separate utility (rake/migrate) that must be kept in sync with application

=Sequel=

[http://sequel.rubyforge.org Sequel] was originally developed by Sharon Rosner and the first release was in March 2007. It is based on the active record pattern. Sequel and Active Record share a lot of common features , for example association and inheritance. But Sequel handles these features in a much more flexible manner. Currently Sequel is at version 3.44.0. Initially Sequel had three core modules - sequel, sequel_core and sequel_model. Starting from version 1.4 , sequel and sequel_model were merged. Sequel handles validations using a validation plug-in and helpers.

<pre>
class CreateUser < Sequel::Migration
def up
create_table(:user) {
primary_key :id
String :name
String :age
String :email}
end
def down
drop_table(:user)
end
end # CreateUser.apply(DB, :up)
</pre>

Sequel supports associations and validations similar to Active Record. The following example shows how validations and associations can be enforced in the User table that has been created above. It enforces one to many relationships between the user table and the cheers and posts tables. It also validates for the presence , uniqueness and the length of the attribute '''name'''.

<pre>
class User < Sequel::Model
one_to_many :cheers
one_to_many :posts

validates_presence [:name, :age]
validates_unique(:name)
validates_length_range 3..20, :name
end
</pre>

To access the data in Sequel, one can use where clauses. For instance, to find Bob again one would use DB[:items].where(Sequel.like(:name, 'Bob').

Some of the key features of sequel are,
* Connection Pooling
* Thread Safety
* [http://wiki.rubyonrails.org/howtos/db-relationships/eager-loading Eager Loading] / Lazy Loading
* Model Caching

=DataMapper=

[http://datamapper.org/ DataMapper] is an open source ORM for Ruby originally developed by Sam Smoot and first released in 2007. DataMapper provides a very flexible mapping API which allows creation of adapters to a wide variety of datastores beyond traditional SQL-based relational databases – DataMapper adapters have been created to non-standard sources such as the Salesforce API and even Google Video.

Unlike ActiveRecord and Sequel, DataMapper does not rely on a migration scheme to create and manage DB tables. Instead, DataMapper allows table definition as part of the model class definition which keeps the model definition contained to a single file, thus minimizing the effort required to keep the database and model definitions in sync. When required, DataMapper can also support a migration methodology similar to other ORMs.

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.

Some of the key features of DataMapper are:
* API supports a wide variety of databases, including non SQL types
* Thread Safety
* [http://wiki.rubyonrails.org/howtos/db-relationships/eager-loading Eager Loading] of child associations
* Lazy loading

=iBATIS=

[http://ibatis.apache.org/ 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.

iBATIS is more lightweight than the other ORMs discussed so far. It provides a wrapper for SQL commands in Ruby, enabling one to call SQL with Ruby methods.

For instance, this code creates methods to find a user by ID and name.

<pre>
Class User < RBatis::Base

statement :select_one, :find do |id|
["SELECT * FROM users WHERE id = ?", id]
end

statement :select_one, :find_by_name do |name|
["SELECT * FROM users WHERE name = ?", name]
end
end
</pre>

These methods can now be used as class methods.

<pre>
User.find(1)
User.find_by_name('Bob')
</pre>

'''Pros''' -
* Enables direct use of SQL functionality within Ruby.
* Is a thinner ORM than the others discussed.
'''Cons''' -
* No longer supported
* Database needs to be created/managed separately.

=Merb=

[http://www.merbivore.com/index.html Merb] was a model-view-controller framework created by Ezra Zygmuntowicz and released on November 7, 2008. It was a full-stack system like Rails, but only consisted of the core needed to create an application, leaving additional functionality to be installed by extra gems.
Merb is at 1.1, and will not have a v2.0 as it was absorbed into Rails 3.0 in 2008.

Merb itself provides only the controller of an MVC model, but this core is easily extended to create a full-stack application environment. In this sense, Merb itself is not an ORM, but it can easily accomodate any of the other ORMs described.

=Comparison of ORM Features=

{|cellspacing="0" border="1"
!style="width:10%"|Features
!style="width:30%"|ActiveRecord
!style="width:30%"|Sequel
!style="width:30%"|DataMapper
|-
! 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
|-
! Migrations 
| Yes
| Yes
| Yes, but optional
|-
! EagerLoading 
| Supported by scanning the SQL fragments
| Supported using eager (preloading) and eager_graph (joins)
| Strategic Eager Loading and by using :summary
|-
! Flexible Overriding 
| No. Overriding is done using alias methods.
| Using methods and by calling 'super'
| Using methods
|-
! Dynamic Finders 
| Yes. Uses 'Method Missing'
| No. Alternative is to use <Model>.FindOrCreate(:name=>"John")
| Yes. Using the dm_ar_finders plugin
|}

 

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

=References=

# [http://en.wikipedia.org/wiki/Object-relational_mapping Wikipedia, Object-relational mapping (ORM)]
# [http://ar.rubyonrails.org/ ActiveRecord]
# [http://en.wikipedia.org/wiki/Active_record_pattern Wikipedia Active record pattern]
# [http://sequel.rubyforge.org/ Sequel]
# [http://jeremyevans-pres.heroku.com/mwrc2009_presentation.html Sequel Presentation - By Jeremy Evans]
# [http://merbist.com/2008/09/29/write-your-own-custom-datamapper-adapter/ Merbist blog on custom DM adapters - By Matt Aimonetti]
# [http://en.wikipedia.org/wiki/Datamapper DataMapper]
# [http://pg-server.csc.ncsu.edu/mediawiki/index.php/CSC/ECE_517_Fall_2007/wiki2_2_22 Object-Relational Mapping Fall 2007]
# [http://ormbattle.net/ ORMBattle.Net]
# [http://wiki.rubyonrails.org/howtos/db-relationships/eager-loading Eager-loading description on Rails Wiki]
# [http://ibatis.apache.org/ iBATIS]
# [http://ibatis.apache.org/docs/ruby/ RBatis - iBATIS for Ruby and Ruby on Rails]
# [http://www.merbivore.com/index.html Merb]