CSC/ECE 517 Fall 2013/oss E806 jlv

E806 Remove ResponseMaps

The primary aim of this project was to create a data migration that merges all data from response_maps table to responses table.

Revision history
Date	Changes
09/24/2013	Revised based on review comments: - Added OAuth 1.0a and 2.0 guides and comparison to Further reading - Added OAuth official Wiki to Further reading - Added an additional example for Google APIs - Added a video explaining OAuth to Further reading - Added a few more terms to Terminology section - Using thumbnails instead of full size screenshots in Creating an OAuth Provider and Creating an OAuth Provider - Added Conclusion
09/18/2013	Initial version

Introduction

Expertiza

Expertiza is a web application where students can submit and peer-review learning objects (articles, code, web sites, etc). It is used in select courses at NC State and by professors at several other colleges and universities.<ref name='expertizagithub'>Kofink, A. (2013, July). expertiza @ GitHub Retrieved from https://github.com/expertiza/expertiza</ref>

OSS Project

Classses

• response_map.rb (94 lines)
• feedback_response_map.rb (29 lines)
• metareview_response_map.rb (107 lines)
• participant_review_response_map.rb (5 lines)
• review_response_map.rb (97 lines)
• team_review_response_map.rb (5 lines)
• teammate_review_response_map.rb (104 lines)
• response.rb (171 lines)

What they do?

Responses (all kinds) are instances of filled-out rubrics. When someone responds to a rubric, a response is created. There are different kind of responses for different kinds of rubrics. A response_map keeps track of who the reviewer and who the reviewee are. ResponseMaps are in 1:1 correspondence with Responses.

What we did?

The following activities were carried out as part of the project:

New data migration

Since Responses are in 1:1 correspondence with ResponseMaps, we migrated the data from response_maps table to responses table.

Removing table

After the above migration was complete, we removed the response_maps table from the database.

Refactoring

We had to refactor the above listed classes to ensure that they continue to operate as expected after removal of the response_maps table.

Design & Implementation

Database

Existing Design

In the existing design, there are two tables responses and response_maps. However, there is no need to maintain a separate table called response_maps since there is a 1:1 mapping between a responses and response_maps table entry.

responses

Maintains the version number, additional comment, created at, updated at and foreign key for response_maps table.

response_maps

Maintains the mapping to reviewed object, reviewer and reviewee. It also maintains the type of the review - Feedback, Team Review, Meta Review, etc.

New Design

In the new design, there is only one table called responses. Each row in the responses table now contains the data from the corresponding row of the response_maps table.
In order to achieve this, we wrote a data migration that does the following:

1. Altered responses table to add the missing columns from response_maps table
2. Updated these new columns in the responses with data from response_maps table by performing a join on responses.map_id and response_maps.id fields.
3. Dropped the response_maps table

Models

Existing Design

In the existing design, there is a 1:1 composition relationship between Response and ResponseMap model i.e. Response has-a ResponseMap.

New Design

In the new design, since there is only one database table representing Response and ResponseMap models - we have an inheritance relationship as follows.
This inheritance relationship allows us to localize the changes due to the database migration to the models - without having to touch the entire Expertiza code base.

Testing

We have created a YouTube video that can help reviewers verify that this project works as expected.
OSS Project Demo - Removing ResponseMaps

Future work

The future work for this project involves:

1. Reanaming all sub-classes of ResponseMap, for example: FeedbackResponseMap, so that the names end in Response, for example: FeedbackResponse.
2. Remove ResponseMap model and have it's children inherit from Response instead.
3. Refactor all models, controllers and views that use ResponseMap to use Response.

References

<references />

Notes

• All references and further reading links are in the APA style
• All the content on this page is from websites that have a Attribution-NonCommercial-NoDerivs 3.0 or similar license that allows us to use their content.