How it was
A while ago, the company I currently work for used an adapted version of the resource reservations database for Domino 6.5. You know how it works: users wanted extras like checkbox-room-has-a-projector or checkbox-we-want-coffee-with-the-room or checkbox-send-a-mail-to-the-guard. The programmer says yes to every question and bingo, you have a RR database that’s not so standard any more.
One day, there was the decision to upgrade to version 8. Everything was upgraded, only the RR remained the “old version”. Although on the outside it doesn’t look that different, there must have been changes underneath, because lots of stuff suddenly went wrong.
So we had to upgrade the database to version 8 as well. Downside: the changes that were built in over the years had to be sacrificed for now. But take away functionality and Unhappy Customers is what you get. We’re now in the process of listing up the features they want, but I’m not willing to work the same way anymore.
How we would work
The initial idea was to simply adapt the new Resource Reservations database again, and keep track of every single small change. Of course, that would mean we have to implement these changes all over again in a next version of the RR database.
After some research, we came to the conclusion that others walked this route before us: they use a database, separate from the RR database, in which they do the reservations, then “publish” to the RR database.
In this database all possible requests from the users can be developed, without infecting the original RR database. After an upgrade, the only thing you need to check is if the “publish” code still functions. Of course, this doesn’t change the way people book rooms via their calendars.
What about you?
What’s your approach? Do you work the same way? Any downsides to this approach? Any example code on publishing? Remarks? According to me, this is a problem faced by a lot of companies, but there’s no real existing solution for this.
Update: some extra clues in the forums