.. select which kind of intervals we want
.. makes it faster and also reduces the size of
the rideDB.json file quite dramatically which
may be useful for some users.
For single ride use sport specific base metric
For date range use sport specific base metric if filtered activity
list is homogeneous or combined otherwise.
.. Route segments are found during interval refresh
.. Config/routes.xml only holds config now
.. The fingerprint for a rideitem includes the route
fingerprint now so it will refresh automatically
when the routes config changes
.. if no routes are defined then no work is done, so the
amount of work is really defined by the user
NOTE: RouteWindow, and now, RouteItem will need to
be reworked and fixed up for v4.0
.. we are taking a different approach for v3.2
.. the auto discovery will augment rides and maintain a cache
of all intervals across all rides
.. the discovered intervals will be selectable alongside ride
intervals in the sidebar
.. new interval views will be developed in v4.0
... shift plot if start date is earlier than any Power Estimates exist
... enhance grouping (calculation of averages for month/years/all
grouping)
... adjust estimates calculation
... to calculate non-overlapping weeks data
... to not create any "infinite" data for weeks before the first Power
based actitivity exists
.. use a simple free text search against the ridecache now we
have all the texts available and in memory
.. no need to maintain an index, no dependency on a horrid lib
with nasty dependencies and its faster too
.. the free text search is very simple, will need to bolster it
over time e.g. it matches text not words
... for RideImport and RideDownload the created .JSON files are firstly
stored in /tempActivities and only moved to /activities after
successfull updating RideCache (with this files with "bad data" cause
RideCache calculations to crash can be identified when starting GC again
... in GC CrashDialog the /tempActivities are documented in the Crash
Log and moved to /quarantine for further analysis
... small addition - the existence of the new directory structure is
verified when opening an Athlete - missing directories are added to
ensure a consistent structure being in place at all times
.. the "bak" directory was added during the development cycle
and will not be present for users that worked with an early
development build
.. when deleting rides the "bak" rename will fail due to the missing
directory
.. the error message has been changed to provide the details of the
directory where the failure is occurring to help signpost users
to the problem
.. notify if Athlete weight or height were changed by
the user during the config dialog
.. no longer included in zones fingerprint
.. ridecache now picks up on specific config changes
.. when downloading withings data the cache is refreshed
.. when the cache refreshes it notifies the *current* ride
changes if it is refreshed
.. ridesummary has been updated to process rideChanged() signals.
.. to let charts etc know that the *current* ride has
changed and will need to be replotted
.. the editor / dataprocessor functions have also been
integrated into the RideItem to notify the change
.. there is a qDebug() in RideCache in lieu of updating
all the charts to refresh on this signal.
.. introduce concept of configChanged(what) to
pass details of what config has been changed
.. fixed zones changes to re-read after write
to correct the save twice to get changes to
zones bug.
.. next parts need to spot changes (part 2) and
then action appropriately (part 3)
.. rather than check if lucene index contains every ride
upon startup just force a rebuild of the index is missing.
.. if the index gets out of sync its because people are copying
data and so they should delete the index when they do so
to make sure it stays in sync
.. when using '*' for values we autocomplete based upon
previously entered values for the field, but we didn't
take into account ranking.
.. now the autocomplete list is ranked to most popular values
complete first.
.. removes across the code base
.. need to fixup RideFileCache and Lucene refresh
within the RideItem/RideCache framework, they will
NOT be refreshed at present
.. need to look at how charts get refreshed on data
changes now RideItem provides a more granular
mechanism (look for XXXREFRESH in code)
.. New Intervals code will definitely NOT compile
and needs to be redesigned/reimplemented to fit
in with the ride cache
.. getting the model in and integrated with the
ride list and diary
.. next steps to connect up to ridecache methods
::addRide and ::removeCurrentRide.
.. then fix up nits/bugs with diary view etc
.. also uses a copy to avoid delete/insert issues when adding
and deleting rides during a refresh
.. but still need to consider the delete operation and marking
items as in process or something
.. the clunky old way of using a 2 month rolling window has
been reworked to use a 12 week rolling window making the
code less susceptible to jumping around esp. on 1st of the month!
.. so ONLY change version number of a refresh is going
to be needed !!!
.. I updated rideDB version to 1.1 to ensure present gets
refreshed as it is used by the PD model estimate code
.. from DBAccess to RideCache
.. and also SummaryMetrics::getForSymbol() now available in
RideItem to access the precomputed metrics for a single
ride.
