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 <[email protected]> Date: Fri, Jul 16, 2010 at 5:46 AM Subject: On upgrading pre 2008.04 databases To: Tom Hoffman <[email protected]> -----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----- _______________________________________________ Mailing list: https://launchpad.net/~schooltool-developers Post to : [email protected] Unsubscribe : https://launchpad.net/~schooltool-developers More help : https://help.launchpad.net/ListHelp
