[Cobalt-developers] Changing the academic year in BOSS

[Harri <har...@tu...>]

Hello,

I hope this information will be useful.

We've had problems in changing the year_of_study from 2005-2006 to=20
2006-2007. There doesn't seem to be any clean mechanism for that.

The idea behind the year_of_study in BOSS is probably to have a=20
mechanism where past years' data could be archived so that it won't=20
interfere with new registrations, marks, changed assessments and mark=20
categories etc.

There are currently a few problems in this though.

- It's not easy to change year_of_study. this_year table in the database
  needs to be directly manipulated.

- There's no easy way to copy (delivered_)modules, assessments and mark=20
  categories (, markers, moderators and managers) from a previous year
  - This is usually what is wanted when the course and it's assignments
    have not changed dramatically and the old ones are good starting=20
    point for the new academic year.
  - It can be partly done by the sql statments further below

- After the year_of_study has been changed, the new class library in
  an assessment will overwrite the old one because it's name is always
  lib.zip.

There are too possible solutions to these problems:

1. The year_of_study or it's id is prefixed to each filename in the=20
   assessment's test file directory. The files will have names like=20
   2005-2006-lib.zip, 2005-2006-C91G28HPG7.nts etc.

2. The year_of_study is added to the directory hierarchy of test files.
   The hierarchy would look like:
   boss/data/tests/2005-2006/A/uds/cw1/p1/
   where A is the delivery and uds is the course name. cw1 and p1 are
   ids of assessment and problem.

Both solutions have their own advantages.

The first one keeps each course's data in one place (except when=20
deliveries are used), so they are easy to look at and find by an=20
administrator when working on the filesystem level.

The second solutions makes it easy to backup or get rid of a whole=20
academic year on a filesystem level without a need of a special tool.
The data in the database has to be backed up also of course.

The second solution would be in line with the decision to have delivery=20
in the early part of the hierarchy.

In both cases the backing up of an academic year could be accomplished=20
by a special written tool in BOSS that accesses both the database and
the filesystem parts of the data.

Also it should be made easier to copy modules, assessments and mark=20
categories between and inside an academic year.

There is a minor problem in both of the approaches
- In some example I've seen year_of_study has an example value of
  04/05 or similar, which has a slash in it, which is a common
  file path separator.
  - Slash shouldn't be allowed in year_of_study and if it appears
    in previous installations, it should be converted in the upgrade
    process by the administrator or an upgrade script run by the
    administrator.


As a side note, in BOSS it is currently not possible to look at any=20
data (including marks) from previous academic years or another delivery=20
without shutting down the server. Changing the contents of this_year=20
table and delivery table in the database and starting up again. Fixing=20
of this problem will need extensive planning and some big changes in=20
BOSS.

Also it is impossible to work with two deliveries that overlap in time.

Here are the sql statements can be used to copy all modules,=20
assessments, problems, managers, moderators and markers from
academic year 2005-2006 to 2006-2007 in the database.

Mark category files (*.nts) will be shared, so changes to the academic=20
year's mark categories will change the old ones as well. Solutions for=20
this is discussed above.

INSERT INTO year_of_study VALUES ('2006-2007','Lukuvuosi 2006-2007');

DELETE FROM this_year;

INSERT INTO this_year VALUES ('2006-2007');

INSERT INTO delivered_module SELECT=20
module_code,'2006-2007',delivery_code FROM delivered_module WHERE=20
year_of_study_code=3D'2005-2006';

INSERT INTO assessment SELECT=20
code,module_code,'2006-2007',delivery_code,name,maxmark,min_mark_assessme=
nt,start_date,deadline,end_date=20
FROM assessment WHERE year_of_study_code=3D'2005-2006';

%% Insert components in an order where base components are first, so=20
%% that the constraint on parent_component_code will not be violated
INSERT INTO component SELECT=20
code,assessment_code,module_code,'2006-2007',delivery_code,parent_compone=
nt_code,maxmark,min_pass_mark,attempts,description,should_compile,allow_s=
tudents_metrics,feedback,valid_exts,exts_strict,auto_feedback,auto_test_f=
eedback=20
FROM component WHERE year_of_study_code=3D'2005-2006' ORDER BY=20
parent_component_code ASC;

INSERT INTO mark_category SELECT=20
code,problem_code,assessment_code,module_code,'2006-2007',delivery_code,d=
escription,student_use,auto_use,maxmark,priority=20
FROM mark_category WHERE year_of_study_code=3D'2005-2006';

INSERT INTO submission_policy SELECT=20
assessment_code,module_code,'2006-2007',delivery_code,max_submits,restric=
t_students,allow_submission,penalty,cpu_time,file_size,time_limit,select_=
submission_always,min_mark_submission,min_mark_assessment=20
FROM submission_policy WHERE year_of_study_code=3D'2005-2006';

INSERT INTO manager SELECT=20
module_code,'2006-2007',delivery_code,staff_id FROM manager WHERE=20
year_of_study_code=3D'2005-2006';

INSERT INTO moderator SELECT=20
assessment_code,module_code,'2006-2007',delivery_code,staff_id FROM=20
moderator WHERE year_of_study_code=3D'2005-2006';

INSERT INTO marker SELECT=20
assessment_code,module_code,'2006-2007',delivery_code,marker_id FROM=20
marker WHERE year_of_study_code=3D'2005-2006';




There are currently no major problems with how student submissions are=20
handled. The submissions of student X in problem p1 are stored in the=20
same directory no matter what academic year it is. Each submission=20
file has a timestamp in it's name so clashes won't happen. By looking at=20
the timestamps (seconds after epoch) or filesystem modification times=20
one can deduce which submission belongs to which academic year. The same
information can be reliably found in the database of course.

It would be good for symmetry to make the same decision with the=20
submission files that will be made to the tests-directory. It will=20
have some of the same advantages as well.


Yours,
Harri J=E4rvi