Loading ...
Sorry, an error occurred while loading the content.

130Re: [extremeperl] refactoring databases

Expand Messages
  • Matthew Albright
    Feb 18, 2005
    • 0 Attachment
      --- Rob Nagler <nagler@...> wrote:
      > This doesn't work with Oracle as mentioned by Johan below.

      Yeah, we're on postgresql.

      > This is simply not an option we offer our customers. We could do
      > this, I guess, but I don't believe in multiple versions in the field
      > running wild. At most two: test and prod.

      We are actually shipping a software product, and we make the new releases
      available to our customers, but they don't have to upgrade every time we
      release. We're an XP shop, so we release often, which means we have a wide
      variety of versions in the field.

      > This is why it is extremely important for developers to be dbas and
      > sysadmins, too.

      I couldn't agree more with this. When whoever it was started talking about
      DBA's changing the database structure, my eyes glazed over, because I've never
      been in an organization that had a DBA. We have people who are stronger and
      weaker in certain areas, but really, anyone can modify anything... that's what
      pair programming is for.

      > > If anyone is interested, I can share some additional thoughts on
      > > data migration landmines to watch out for...
      > Please do.

      Like most relational database-backed applications, we've coded up a
      object-relational mapping layer that follows the "Active Record" pattern
      (http://www.martinfowler.com/eaaCatalog/activeRecord.html). The problems come
      in when you call too much of that mapping code from your update_db.pl script.
      At the time the update_db.pl code is run, it's running against the newest
      production code. If your migration code calls methods in the "real" code, that
      code may change, and your migration code might cease to work in the future.

      To avoid this rather subtle problem (which I suspect I've not explained very
      lucidly), we do 2 things:

      - Avoid the use of "real" code in the migration code, even if it means
      - Test to make sure it is possible to upgrade from the oldest customer
      version to the new version

      Sometimes, the use of real code is unavoidable, and we've had to reorder things
      in the update_db.pl file... that's something to be avoided.

    • Show all 11 messages in this topic