Basie Blog

A Lightweight Software Development Portal in Django

Database Migration

with one comment

Ian Lienert posted a table last night comparing the schemas of DrProject and Basie databases.  We discussed it this morning, and it looks like translating DrP databases to Basie isn’t going to hurt as much as we feared.  Here are some of the high points.

Tables we just don’t care about:

  • Enum (stored enumerations and their values)
  • SystemProperty and _InstanceSetting (Django does this for us)
  • Session and SessionAttribute (Django does this for us)
  • Preference (now part of the UserProfile)
  • Attachment (we’re not supporting attachments in 0.5)
  • Harvester, DashboardMetric, DashboardValue, and Retriever (our Dashboard is simpler)
  • UnconfirmedEmail (we don’t require users to confirm email addresses in 0.5)
  • DeletedMessage (never really understood why this was separate from Message)
  • Tag (no tagging in 0.5)
  • RoleCapability (Django handles this for us)
  • Milestone and MilestoneChange (no milestones in 0.5)
  • TicketChange (DrProject inherited this sort-of backward diff from Trac, where it was a premature space optmization)

Tables that translate more or less directly:

  • Project
  • User (Basie has User and UserProfile, since Django uses the latter as an auxiliary table for extensions to the former)
  • Role (becomes Group)
  • Membership (Basie’s is more complicated, but the core concepts are the same)
  • Email (becomes UserEmail)
  • WikiPage

Things that require some thought:

  • Message: the obvious translation is to MailMessage, but (a) Basie doesn’t store headers in the same way, so we may have to re-parse stored emails to populare the Basie database, and (b) DrProject has that damn DeletedMessage table, so we have to decide how much of the history of individual mail messages to bring forward.
  • Ticket: Basie’s ticketing system doesn’t provide type, milestone, priority, or comments; we will probably stuff these into the text of the ticket to avoid losing information completely.
  • CachedChangeset and CachedChange: these make up DrProject’s copy of information taken from the Subversion repository.  We haven’t yet decided how much of this to cache in Basie, or where to store it.

So as I said at the outset, it doesn’t look like it’s going to hurt as much as it might.  Stay tuned to see…

Written by gvwilson

June 30th, 2009 at 1:27 pm

Posted in Uncategorized

One Response to 'Database Migration'

Subscribe to comments with RSS or TrackBack to 'Database Migration'.

  1. Re. parsing mail headers: that doesn’t sound too bad to me…

    Just, whatever you do, make sure you put a progress bar on every operation:
    Migrating wiki pages |=========| Done!
    Migrating mail messages |====> | ETA: 3:00

    It’s really, really easy to do (take a look at DrP’s migration scripts) and it makes people very happy: http://www.chrisharrison.net/projects/progressbars/ProgBarHarrison.pdf

    David Wolever

    30 Jun 09 at 2:48 pm

Leave a Reply