CSC/ECE 517 Fall 2013/oss E806 jlv: Difference between revisions
No edit summary |
No edit summary |
||
Line 46: | Line 46: | ||
===Database=== | ===Database=== | ||
====Existing Design==== | ====Existing Design==== | ||
[[File:E806DBDesignBefore.png]]<br/> | [[File:E806DBDesignBefore.png]]<br/><br/> | ||
In the existing design, there are two tables <code>'''responses'''</code> and <code>'''response_maps'''</code>. However, there is no need to maintain a separate table called <code>'''response_maps'''</code> since there is a 1:1 mapping between a <code>'''responses'''</code> and <code>'''response_maps'''</code> table entry. | In the existing design, there are two tables <code>'''responses'''</code> and <code>'''response_maps'''</code>. However, there is no need to maintain a separate table called <code>'''response_maps'''</code> since there is a 1:1 mapping between a <code>'''responses'''</code> and <code>'''response_maps'''</code> table entry. | ||
;<code>'''responses'''</code> : Maintains the version number, additional comment, created at, updated at and foreign key for <code>'''response_maps'''</code> table. | ;<code>'''responses'''</code> : Maintains the version number, additional comment, created at, updated at and foreign key for <code>'''response_maps'''</code> table. | ||
Line 52: | Line 52: | ||
====New Design==== | ====New Design==== | ||
[[File:E806DBDesignAfter.png]]<br/> | [[File:E806DBDesignAfter.png]]<br/><br/> | ||
In the new design, there is only one table called <code>'''responses'''</code>. Each row in the <code>'''responses'''</code> table now contains the data from the corresponding row of the <code>'''response_maps'''</code> table.<br/> | In the new design, there is only one table called <code>'''responses'''</code>. Each row in the <code>'''responses'''</code> table now contains the data from the corresponding row of the <code>'''response_maps'''</code> table.<br/> | ||
In order to achieve this, we wrote a data migration that does the following: | In order to achieve this, we wrote a data migration that does the following: |
Revision as of 02:58, 31 October 2013
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 | ||||
10/30/2013 | Updated section on testing: - Added link to YouTube demo | ||||
10/29/2013 | Updated section on design: - Added existing and new Database design - Added existing and new Models design | ||||
10/28/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 toresponses
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:
- Altered
responses
table to add the missing columns fromresponse_maps
table - Updated these new columns in the
responses
with data fromresponse_maps
table by performing a join onresponses.map_id
andresponse_maps.id
fields. - 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. The inheritance relationship allows us to localize the impact of the data migration. This was necessary becauase many models, views and controllers are using ResponseMap
model. In this design, ResponseMap
just forwards ActiveRecord
calls to Response
since columns from response_maps
table are now in
responses
table.
Challenges
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:
- Reanaming all sub-classes of
ResponseMap
, for example: FeedbackResponseMap
, so that the names end in Response
, for example: FeedbackResponse
.
- Remove
ResponseMap
model and have it's children inherit from Response
instead.
- 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.