.. 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.
.. loads the cache/rideDB.json back on startup to avoid
any refresh of metrics etc
.. uses a lex/bison JSON parser, not because of performance
since its only run one at startup, but because;
* QtJSON support is only available in QT5
* mvjson uses a DOM model that creates a memory overhead
* the existing bison/lex parser works well and is easy to
use as a template for this
We now have a good mechanism for metrics and metadata refresh,
cache and recovery so can look at using it in the charts and
the ride navigator next !
.. but only refreshes the ride added rather than looking everywhere.
So, when we are importing large numbers of activities it won't
repeatedly run a full refresh (which was bonkers).
.. if we close GC during a background refresh operation
then the refresh is cancelled and cache saved in whatever
state it is in now .. the user clearly didn't want to wait !
