Published May 14th, 2008
in networking and technology.
Google just released a preview of their new Google Friend Connect service.
Google Friend Connect lets you grow traffic by easily adding social features to your website. With just a few snippets of code, you get more people engaging more deeply with your site.
This is not a social network by itself, this is something that enables you to turn your own web site into a social network. I can’t wait to try it myself on this blog and build my own social network…
If you're new here, you may want to subscribe to my RSS feed. Thanks for visiting!
Published May 8th, 2008
in technology.
This is the third post about software compatibility, the previous ones were talking about project management and bugs and this one deals with database schemas compatibility (I will deal with stored procedures in the chapters about code compatibility).
First of all, what do backward compatibility means when talking about the database?
- Being able to retain data stored in one schema into a new one.
- Preserving compatibility with external systems (like report engines) that may be accessing the database directly.
Point #1 is achieved through migration tools that update the database schema, in some cases such tools may be very tricky.
Point #2 is a bigger challenge. Changes that may break the database compatibility are:
- Removing a table or changing its name.
- Removing a column, changing its type (including its precision or length) or changing its name.
- Changing the semantic of a column (e.g. changing the valid values).
- Adding foreign keys.
In case #1 and #2, if such changes cannot be avoided, a good enough solution is to implement database views that mockup the old tables based on the new ones.
The thing is that for #2 you will need to rename the actual table which will force an update of the foreign keys in other tables and surely more code update than what was initially expected. Leaving an unused column in the table may be a better solution. As usual, this is a trade-off that should be discussed at the project level.
Point #3 is more tricky because it really depends on the change and the usage of the column. Most of the time transforming a “change” into a “remove and add new” will enable to refer to #2. Triggers can then be used to update the old column or it can just be left unused.
Point #4 is a problem when there are scripts that delete entries in a table. If all of a sudden there is a new foreign key that depends on this table then the script will fail, thus breaking the compatibility. I actually have no technical solution for this one. I think that only documentation can be given, but if any of you has an idea please share it with us :)
Nevertheless, one should recall to never do any incompatible change without a good enough reason.
