svn, global search/replace and recovery

I started with a nice simple problem: do a global search and replace on the image directory path to save bandwidth (by pointing to a caching server.)  I used this regular expression and then had two problems:

  1. This isn’t easy to read (which isn’t a huge deal since I only have to run it once.)
  2. The find and replace updated the hidden .svn directory too.  Which meant when I went to sync with SVN, it thought it was up to date and didn’t commit anything.
More on both these problems.
Problem 1 – Unreadable regexp

find $path/templates/default -type f | xargs perl -pi -e ‘s/\$\{contextPath\}\/templates\/default\/images/\$\{imagesServedFrom\}\/templates\/default\/images/g’

All right.  What does this do?
  1. Find all files in the templates/default directory or any subdirectories
  2. Do a search for ${contextPath}/templates/default/images and replace with ${imagesServedFrom}/templates/default/images
I’m sure there is a clearer way of writing this.  I didn’t bother once I had something working because I only have to run it once.  (Famous last words, I know.)
Problem 2 – Updating SVN

The bigger problem is that I made a bunch of other changes in my commit and didn’t notice that none of the template/default/image changes got committed.  Eclipse/SVN didn’t commit the changed files because the .svn directory’s base file was changed as well.

I solved this by disconnecting from SVN in Eclipse. (Team disconnect) and deleting the metadata when prompted.  I then reconnected to SVN, Eclipse saw the difference and I committed normally.

If I was doing this again, I’d update the find statement to exclude the .svn directories.

Where’s your database’s ER Diagram?

I was recently training a new software developer, explaining the joys of three-tier architecture and the importance of the proper black-box encapsulation, when the subject switched to database design and ER diagrams. For those unfamiliar with the subject, entity-relationship diagrams, or ER diagrams for short, are a visual technique for modelling entities, aka tables in relational databases, and the relationships between the entities, such as foreign key constraints, 1-to-many relationships, etc. Below is a sample of such a diagram.


I. The Theory

Like many enterprise technologies, ER diagrams can be a bit of an overkill in single-developer projects, but come in handy as soon as you need to explain your design decisions to a room full of people. Since a software application is only as flexible as its underlying database, ER diagrams help define the initial set of business rules for how people will be able to interact with the system. As a software development practice, they are often encouraged, but in medium to large companies, they may be absolutely required. There are enough tools now to create ER diagrams quickly and easily, many of which will generate SQL database creation statements for a variety of platforms directly.

II. The Practice

Due to tight time constraints and ever-expanding scope creep, I find most developers skip creating or maintaining ER diagrams whenever the opportunity arises. One telling example of this is a developer who creates a diagram, starts building the application, and realizes their initial diagram was completely flawed. Given that they are now behind schedule because they made mistakes in modelling the data, they do not have time to go back an update the model, and their ER diagram becomes a distant memory compared to the final database. Most managers would rather see finished software products than accurate diagrams, although will take both if offered.

ER diagrams are incredibly useful in the early stages of designing a new application, but as an experienced software developer, I spend more time enhancing and maintaining databases than I do creating them from scratch. Furthermore, it can be difficult to create an ER diagram for an existing database, especially if you were not involved in its creation. Even when companies do maintain ER diagrams, they tend to be months, often years, out of date, as it can be difficult to motivate each and every software developer to update the database documentation after making a change.

III. Where’s your database’s ER Diagram?

What about your software application? Is there now or was there ever an ER diagram for your company’s database? Is it 100% accurate to the current production database? I’d like to hear from other developers to find out if people are diligently maintaining ER diagrams, or if it is really a common practice to let them fall by the wayside after a database is established.