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

133Re: [extremeperl] refactoring databases

Expand Messages
  • Rob Nagler
    Feb 19, 2005
    • 0 Attachment
      Matthew Albright writes:
      > 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.

      Perhaps you should pay them to upgrade. :-) Yes, you've got a
      logistical problem, and it sounds like you have a good solution for

      > 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.

      Interesting you should mention that. I've been a bit turned off to
      "general pair programming" lately. We pair for the same reason. One
      of the things about pair programming that I don't like is that when
      people are alone, they learn from their mistakes at their own speed.
      If they are with another programmer, they not only get the problem
      solved more quickly, but they also don't necessarily assimilate the
      thought process and tools the other programmer brins to the table.
      Experience caused by thousands of wrong paths is a great guide.
      Finding the path right away isn't always the best way. It's certainly
      my experience with kids that they learn much better when they burn
      their hands than when you tell them the iron is hot.

      > 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.

      Excellent point. We see this sometimes when trying to do a current
      upgrade. I would hate to solve this problem for N versions in the

      > 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
      > duplication
      > - 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.

      Great solution. Seems like you have to do a lot of feature-based
      tests. For example, you might add a feature, fix it, then remove it
      (because it wasn't the right solution in the first place). Those
      three upgrades are a no-op after the "remove it" upgrade.

      One issue I don't see how you get around is the collection of new
      types of data. You can never assume that a new data type of data
      exists in the database. This means you probably can't retire
      "deprecated" code that works around the non-existence of the new type
      of data. This may create lots and lots of paths to test. Ugh...

    • Show all 11 messages in this topic