One of the challenges in upgrading WriteTrack was a limitation of APEX's automatic row fetch process–it only accepts two columns for the primary keys of the table or view it's pulling from. Generally, this is fine; most of the time, you only have one column for your primary key, and for cross-reference tables, you're likely to only have two.
But, in WriteTrack's case, I've got a view that needs three columns to identify a record: user, challenge, and date. This view is what drives the date-edit window, which opens when you click on a specific date in the calendar so you can edit that day's weight and/or word count. In the initial release, I took the quick route and made it work by forcing the challenge ID (since everyone was working on the same challenge).
For the upgrade, I needed to fix this. My solution was to replace most of my views with user-specific ones, eliminating the user ID from the list of possibilities. (Note when doing this: the value in v('APP_USER') is always in upper case. Serious “duh” moment when I realized why my views were returning 0 rows.) This allows me to use the challenge ID and date ID as the two primary key columns, and get on with life. Oh, and it's got a nice security side benefit: no user can ever see any other user's data, short of breaking through the views and querying the underlying tables directly. I'm protected from my own mistakes (in that aspect, at least), as well as most minor hacking attacks. Win!