More Information on Recent Maintenance & Upgrades
5 February 2007On Feb 3, 2007, we performed a large database upgrade. This included moving the database to a new, faster server, as well as a change to the fundamental architecture of the database itself. This was a 4 month process that will provide us with a foundation to build enhanced functionality as well as new products and features to serve you better.
This post is meant to provide some insight and suggestions regarding the key changes to the system.
The primary change affected both planned and actual distances within the database. We did not previously have a way to mix units when logging data (for example: log a bike workout in miles and a swim workout in meters). Because we manipulated the 16 million plus workouts in the system, we recommend all users to review their past data to check for any issues. With the new system, we have much better control over the actual distance and distance unit as we have standardized how we store the distance information, allowing, among other things as mentioned above, a coach to view and prescribe data in metric units, but allow the client athlete to view data accurately in metric or english units. Ultimately, we will have much better data integrity. In the near future, these changes will also allow us to see unit conversions to any distance for a workout, or switching to English/Metric easily, anytime.
What we did:
We analyzed all users’ settings and adjusted the stored and planned distances based on their current user settings. We had to make assumptions that if a user had chosen metric units, then the old distances were stored in metric units. Likewise, if the user had chosen English units, then we assumed the stored distances were in miles or yards (for swimming).
Obviously, this could be a problem for users that were using English settings, but stored your swims in meters. We have prepared for this condition, and you can simply contact us at http://www.trainingpeaks.com/support to notify us if this is the case for you. We can re-adjust your historical data so that it is accurate if this was the case.
The change also affects how data is stored for workouts that used to have multiple distances per workout, like a Brick or X-train workout. We analyzed these workouts and combined totals for the overall workout, but noted the specific run or bike distance in the workout’s comments section. Note that we only allow a single distance to be stored per workout.
Going forward, our suggested method for logging data for a Brick workout is to either:
Store the total distance of the Bike and Run within the Brick workout itself, thus combining the overall distances of the two separate workouts.
or
Create a separate Bike and a separate Run workout, and log data for each leg of the Brick separately. This is our suggested and preferred method. This leads to showing 3 workouts for the day: 1) the planned Brick 2) the actual bike 3) the actual run. This method provides the most accurate and fine-grained recording of data. For people that use a training device like a GPS or HRM or Power Meter, it’s simply a matter of uploading the data file and the Bike and Run workout will be created automatically showing the results.
Planning a Brick workout remains unchanged, but we encourage coaches to consider simply planning a Bike and a separate Run, but noting in the workout description these are intended to be performed back-to-back, as a Brick.
In summary, take a look at some reports, like the Weekly Summary report or do a Search & Filter report and just confirm that your historical data looks correct. We took a lot of care to ensure this process would go smoothly, but as with any large data migration and upgrade project, we are prepared to handle any problems this has created.
Thanks for your patience and understanding.
For a bit more information on this project, you can checkout a recent Message Board post.
No comments yet
