Feature Request #411: Favorite Workouts

[Joachim Kohlhammer]

Dear all,

for the next release after 3.6, I would like to contribute to https://github.com/GoldenCheetah/GoldenCheetah/issues/411 (Feature request - Favorite workouts).
Based on the current TrainDB, I have a prototype for filtering workouts (see attached gif) that proved useful to me and could serve as a starting point for this feature request.
Since the trainDB is global to all athletes of a Golden Cheetah instance, the datamodel of the TrainDB has to be changed for #411.

My plan to implement #411 is as follows:
1. Refactor the TrainDB (see proposal below)
2. Implement a information widget for the currently selected workout
3. Implement a rating-widget (1-n stars) within the information widget
4. Implement a filter for workouts
5. Implement a migration from TrainDB schema version 1 to version 2


TrainDB: Proposed datamodel

```mermaid
erDiagram
    version {
        text table_name PK "Name of the table"
        integer schema_version "Version of the table"
        integer creation_date "Creation date of the table"
    }
   
    video {
        text filepath PK "Path of the video-file, relative to the TrainDB"
        integer creation_date "Timestamp when this video was imported"
        text displayname "Name of this video, this is shown to the user"
    }
   
    videosync {
        text filepath PK "Path of the videosync-file, relative to the TrainDB"
        integer creation_date "Timestamp when this videosync was imported"
        text source "Origin of this videosync"
        text displayname "Name of this videosync, this is shown to the user"
    }

    workout {
        text filepath PK "Path of the workout-file, relative to the TrainDB"
        text type "Type of the workout (code|slp|erg)"
        integer creation_date "Timestamp when this workout was imported"
        text source "Origin of this workout"
        text source_id "Id of this workout as defined by the source (if available)"
        text displayname "Name of this workout, this is shown to the user"
        text description "Additional description of this workout"
        text erg_subtype "Subtype if the workout is of type erg (abs|rel)"
        integer erg_duration "Duration of this workout"
        integer erg_rel_min_power "Minimum power of this workout [% CP]"
        integer erg_rel_max_power "Maximum power of this workout [% CP]"
        integer erg_rel_avg_power "Average power of this workout [% CP]"
        integer erg_rel_dominant_zone "Dominant power zone of this workout (1-7)"
        real erg_rel_duration_z1 "Duration in power zone 1 [% Duration]"
        real erg_rel_duration_z2 "Duration in power zone 2 [% Duration]"
        real erg_rel_duration_z3 "Duration in power zone 3 [% Duration]"
        real erg_rel_duration_z4 "Duration in power zone 4 [% Duration]"
        real erg_rel_duration_z5 "Duration in power zone 5 [% Duration]"
        real erg_rel_duration_z6 "Duration in power zone 6 [% Duration]"
        real erg_rel_duration_z7 "Duration in power zone 7 [% Duration]"
        real erg_bikestress "Bikestress of this workout"
        real erg_if "IF of this workout"
        integer erg_abs_min_power "Minimum power of this workout [Watt]"
        integer erg_abs_max_power "Maximum power of this workout [Watt]"
        integer erg_abs_avg_power "Average power of this workout [Watt]"
        real slp_distance "Distance [km]"
        integer slp_elevation "Elevation Gain [m]"
        real slp_avg_grade "Average Grade [%]"
    }

    workout_athleteinfo {
        integer workout_filepath FK "<PK> References workout.filepath"
        text athlete_id PK "<PK> ID of the athlete as given by Golden Cheetah (see <athleteDir>/config/athlete-general.ini/[General]/Id)"

        integer rating "User rating of this workout (1-n, NULL means unrated)"
        datetime last_run "Last execution of this workout by this user"
    }

  workout ||--o{ workout_athleteinfo : filepath
```

Attributes prefixed with one of the types (allowed values: `code`, `slp`, `erg`) are only available when the value of attribute `type` is matching. If the type is `erg`, the attributes with extended prefix as given in `erg_subtype` (allowed values: `abs`, `rel`) are also relevant.

All table names are in singular, resulting in foreign keys named *tablename_key* (e.g. *workout_filepath*). Using plural would result in awkward foreign key names like *workout**s**_filepath*. Additionally this change to the status quo helps for parallel existence of both versions (current and future tables) and therefore ease the migration. The table *version* is already in singular and therefore remains as is.

Timestamps are always stored as *unixepoch* in fields of type *integer*.


1. Provide all data required for finding workouts
2. Support athlete-specific data like ratings - while keeping the global approach of the TrainDB
3. Reduce dependencies from the TrainDB-class to other code within Golden Cheetah as much as possible
   1. To achieve this I moved most datafields from ErgFile / VideoSyncFile to a new base-class (including getters and setters)
   2. Increased typesafety by introducing enum-classes
4. Separate file- and display-name


Feedback, concerns, additional usecases are welcome!
Since this is my first "big" attempt to contribute to Golden Cheetah, I would be grateful for hints how to proceed with this topic.

Regards
 Joachim

[Ale Martinez]

El domingo, 19 de marzo de 2023 a la(s) 14:45:23 UTC-3, Joachim Kohlhammer escribió:

Dear all,

for the next release after 3.6, I would like to contribute to https://github.com/GoldenCheetah/GoldenCheetah/issues/411 (Feature request - Favorite workouts).
Based on the current TrainDB, I have a prototype for filtering workouts (see attached gif) that proved useful to me and could serve as a starting point for this feature request.
Since the trainDB is global to all athletes of a Golden Cheetah instance, the datamodel of the TrainDB has to be changed for #411.

Hi Joachim, before to discuss the details I think we should clarify the user vs athlete issue.

The way I understand the current status is:

1) All supported platforms have support for (at least sequential) multi user support and GoldenCheetah follows the OS guidelines storing the user data in user specific location, so it is possible to have independent users in the same system using OS facilities.

2) Each user can administer multiple athletes, s.t. their own, others coached, testing, or special uses, but we are talking about just 1 user so TrainDB is unique.

In case more than one person is going to Train in the same machine the recommended setup is to use multiple users as explained in 1), I can't see any advantage to have a TrainDB for each athlete. In fact we went the reverse path with metadata in v3.6: from athlete specific to global at the user level.

Cheers, Ale.

[Joachim Kohlhammer]

Ale Martinez schrieb am Mittwoch, 22. März 2023 um 00:52:14 UTC+1:

Hi Joachim, before to discuss the details I think we should clarify the user vs athlete issue.

The way I understand the current status is:

1) All supported platforms have support for (at least sequential) multi user support and GoldenCheetah follows the OS guidelines storing the user data in user specific location, so it is possible to have independent users in the same system using OS facilities.

2) Each user can administer multiple athletes, s.t. their own, others coached, testing, or special uses, but we are talking about just 1 user so TrainDB is unique.

In case more than one person is going to Train in the same machine the recommended setup is to use multiple users as explained in 1), I can't see any advantage to have a TrainDB for each athlete. In fact we went the reverse path with metadata in v3.6: from athlete specific to global at the user level.

Hi Ale,

thanks for your response, and especially for your explanation on user vs athlete. This simplifies the datamodel since no separate table for user specific information like ratings is required. One of my main goals was to keep one instance of the TrainDB - everything else would have complicated matters unneccessarily.

However, does Golden Cheetah have something like a main or default athlete who is correlated with the user? I am asking because of the power zones I would like to add to the TrainDB - or is it good enough to assume that the user always interacts with the training-functionality with the right athlete activated?

Regards

 Joachim

[Ale Martinez]

El jueves, 23 de marzo de 2023 a la(s) 02:40:55 UTC-3, Joachim Kohlhammer escribió:

Ale Martinez schrieb am Mittwoch, 22. März 2023 um 00:52:14 UTC+1:

Hi Joachim, before to discuss the details I think we should clarify the user vs athlete issue.

The way I understand the current status is:

1) All supported platforms have support for (at least sequential) multi user support and GoldenCheetah follows the OS guidelines storing the user data in user specific location, so it is possible to have independent users in the same system using OS facilities.

2) Each user can administer multiple athletes, s.t. their own, others coached, testing, or special uses, but we are talking about just 1 user so TrainDB is unique.

In case more than one person is going to Train in the same machine the recommended setup is to use multiple users as explained in 1), I can't see any advantage to have a TrainDB for each athlete. In fact we went the reverse path with metadata in v3.6: from athlete specific to global at the user level.

Hi Ale,

thanks for your response, and especially for your explanation on user vs athlete. This simplifies the datamodel since no separate table for user specific information like ratings is required. One of my main goals was to keep one instance of the TrainDB - everything else would have complicated matters unneccessarily.

However, does Golden Cheetah have something like a main or default athlete who is correlated with the user?

No

 

I am asking because of the power zones I would like to add to the TrainDB - or is it good enough to assume that the user always interacts with the training-functionality with the right athlete activated?

Zones are athlete specific and the athlete used for Train is up to the user. 

[Joachim Kohlhammer]

In my opinion it would be reasonable to use the zones of the athlete active while importing the workouts.If this is not valid any more, the database could easily be updated.

Do you agree - or would you skip the zones completely? I as a user would like to filter workouts by zones.

[Joachim Kohlhammer]

Hi Ale,

I continued working on #411, fulfilling at least my requirements:

• Workouts can be filtered (duration, dominantzone, stress, intensity, vi, ri, bikescore, svi, rating, minpower, maxpower, avgpower, xpower, isopower, power, lastrun, created, distance, elevation, grade, time in zone, fulltext (description, tags, type)), rated and tagged
• Detailed infos about each workout can be viewed (and expanded per item, see below)
• Tags can be managed centrally
• The TrainDB is automatically updated when CP / FTP, ... are changed

The change also includes some refactoring like switching some number-based constants to enum-classes for better type safety. But mainly I created base-classes like ErgFileBase for ErgFile. This allowed me to do most of the development outside GoldenCheetah.

If you are interested in a pull request, please let me know. The code is available here: https://github.com/thejockl/GoldenCheetah/tree/411-feature-request---favorite-workouts

Regards

 Joachim

[Ale Martinez]

Hi Joaquim, it looks very nice, but I haven't got the time to review and test your work.

Additionally I am not a regular user of Train since where I live it is possible to ride outside year around and I prefer to avoid the trainer as much as possible.

Perhaps you could get more feedback creating a pull request, once you are happy with your code, and posting at the users forum.

Cheers, Ale.