schooltool-developers team mailing list archive

[Tom Hoffman <tom.hoffman@xxxxxxxxx>]

My comments on the below: anyone using a pre-2008.04 database has to
be doing something fairly simple with it, and even most of that data
isn't particularly important.  You don't *really* care what time a
class met two years ago (but it makes more sense to me to generally
keep stuff around than try to figure out exactly what can and can't be
safely deleted -- disc space is cheap).

So it seems to me that just exporting the person records, courses, and
section enrollments should get us the data that people really need.  I
don't think we were storing any grades at this point.  Just outputting
csv and letting people import those into spreadsheets to arrange for
importing seems like the best route, considering there is no
particular reason to think more than one person has this problem.

Also, I'm totally ok with a very hacky solution to this, like,
download these files, copy them into this directory, go to this url
and save the output in your browser.  I am also pretty much OK with
just doing nothing if this will take more than two days.

But *going forward* we need to do this right, so pay attention to
Justas's observations below.

--Tom

---------- Forwarded message ----------
From: Justas Sadzevicius <justas@xxxxxx>
Date: Fri, Jul 16, 2010 at 5:46 AM
Subject: On upgrading pre 2008.04 databases
To: Tom Hoffman <tom.hoffman@xxxxxxxxx>


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi Tom,

 I took a short look on the current situation.  This email came out a
bit long, so I'm not sure where to send it.  Is it suitable for
schooltool developers mailing list?  It should be interesting for at
least our team...


Conclusion
- ----------

 2008.04 released in Hardy LTS was the major evolution checkpoint,
after that 25 evolution scripts were obsoleted and old classes required
to read unevolved databases were removed.

 Users with very old databases (predating 2008.04) now are stuck.  They
cannot evolve without development on our side.  As ancient ST does not
have export, users best bet is to retrieve information via REST or
manually.  Or somebody invests in few weeks of dev time.


Evolving through PPA installation
- ---------------------------------

 Unfortunately, ST 1.0 series were released to Hardy in 2009-2010, so
the 2008.04 release that is requirement to evolve older databases is now
non-existent in .deb form (as far as I know).  Due to amount of changes,
it is no longer trivial to reintroduce evolution support to Hardy
(though probably not *that* hard).

 Also, users can *only* upgrade from Hardy LTS to Lucid LTS if they
updated their Hardy installations in 2009-2010.


Evolving through bzr checkout
- -----------------------------

 Another option - bzr checkout + eggs is also not working at the moment.

 Some of the eggs needed by ST are no longer in PyPI.  Namely -
hurry.query (and probably respective zope.catalog and zope.intid).  The
upside of it is that it's not needed for evolution, only for certain ST
views.  We can create an egg that is usable only for evolution.

 Release tagging practice started on 2009.04, but we can pick
reasonable revisions of gradebook, journal and schooltool itself, close
to the original 2008.04 release.

 To make this work, we'd need to make correct branches and eggs + short
user instructions.

 The plus side of evolving through bzr checkout, that it can be done in
Ubuntu Hardy-Karmic.


General issues
- --------------

 When evolving, assigned timetables get broken, they have
TimetablesAdapter as __parent__ - and it is not persistent.  Most
visible result - all views that show links to those timetables raise
tracebacks, there are other functionality problems with that.  A bug in
some old evolution script.


 Gradebook also breaks schooltool's evolution: when adding sections it
wants to deploy worksheets, but until gradebook's own evolutions are
run, there's no place to deploy them to.  Simple two-line workaround in
the gradebook is sufficient.

 This exposes a design flaw in our evolutions mechanism: when
developers write evolution, they think that *everything* will be evolved
to ST 1.0, then 1.1, 1.2, and so on;  when in reality, first schooltool
core is updated 1.0->1.1->..., then gradebook 1.0->1.1->...

 The flaw can manifest itself again in the next LTS -> LTS upgrade.
I'd say odds of this happening in normal Ubuntu upgrade are low.  With
decent amount of manual testing we can reduce the risks even further.


 There are also problems with person records.  If I got that correctly,
ST has had 3 active implementations over the last few years
(person.Person, demographics.Person, basicperson.Person).  Currently it
functions properly only with basicperson.Person (or customizations
derived from it).  Old evolution scripts only update person records to
demographics.Person.


Regards,
Justas


P.S.:  On a personal note, there's much to learn from the old ST code.
We're at the point of reinventing some wheels and looking at problems
caused by former experiments is very beneficial.  Enrolment statuses.
Levels.  Timetables.  Person records.


-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)

iEYEARECAAYFAkxAKnMACgkQaCT+W0+kcjRHcwCcCx2tgmKx2abuRnT9PSZQ/EEW
4R8AoIAkrjlD/ibsWo7yi+hGqDmRbakV
=qupv
-----END PGP SIGNATURE-----