Hi Arnd,
>>> If you get this error, then
>>> pytrainer/upgrade/versions/010_default_upgrade.sql has not been
>>> successfully executed. Can you please check ~/.pytrainer/log.out log
>>> file to see if any related error has been reported there?
>>
>> Any news from your side, Arnd?
>
> Sorry David, my fault, I actually overread your reply (was hidden behind
> my longer traceback ;).
No worries ;)
> Anyway: I repeated the whole procedure (my 1.8.0 productive data are
> well backuped), but don't see anything interesting:
>
> 2011-10-30 08:59:10,937|DEBUG|base|__init__|Loading script
> /home/arnd/bin/pytrainer/lib/python2.7/site-packages/pytrainer/upgrade/versions/010_default_upgrade.sql...
> 2011-10-30 08:59:10,937|DEBUG|base|__init__|Script
> /home/arnd/bin/pytrainer/lib/python2.7/site-packages/pytrainer/upgrade/versions/010_default_upgrade.sql
> loaded successfully
This means that mentioned file has been loaded, but it does not say
that it has been executed...
I expected to see something like the following:
2011-10-29 18:48:12,489|DEBUG|repository|__init__|Repository
/usr/lib/python2.7/site-packages/pytrainer/upgrade loaded successfully
2011-10-29 18:48:12,489|DEBUG|repository|__init__|Config:
OrderedDict([('db_settings', OrderedDict([('__name__', 'db_settings'),
('repository_id', 'pytrainer'), ('version_table', 'migrate_version'),
('required_dbs', '[]')]))])
2011-10-29 18:48:12,496|INFO|api|_migrate|9 -> 10...
2011-10-29 18:48:12,749|INFO|api|_migrate|done
2011-10-29 18:48:12,750|INFO|api|_migrate|10 -> 11...
2011-10-29 18:48:12,752|INFO|011_populate_lap_details|upgrade|Populating
laps details columns
... retrieving data ...
2011-10-29
18:48:13,227|INFO|011_populate_lap_details|populate_laps_from_gpx|Populating
laps from GPX for record 1
... retrieving lap details ...
2011-10-29
18:48:13,238|INFO|011_populate_lap_details|populate_lap_from_gpx|Populating
lap details from GPX for lap 1
...
2011-10-29
18:48:13,864|INFO|011_populate_lap_details|populate_lap_from_gpx|Populating
lap details from GPX for lap 15
2011-10-29 18:48:13,956|INFO|api|_migrate|done
2011-10-29 18:48:13,957|INFO|api|_migrate|11 -> 12...
2011-10-29 18:48:14,056|INFO|api|_migrate|done
2011-10-29 18:48:14,056|INFO|api|_migrate|12 -> 13...
2011-10-29 18:48:14,104|INFO|api|_migrate|done
2011-10-29 18:48:14,105|INFO|api|_migrate|13 -> 14...
> (whole log attached)
>
> But this isn't the migration itself, or?
It doesn't look like. What I understand from log file provided is that
upgrade process checked database status and stated that data status
matches current (latest) one and therefore it executes no migration
action. Can you please check ~/.pytrainer/log.out.1[2,3,4,5]? Logs are
rotated and maybe there is useful info still there.
> Is it possible to enforce it explicitely?
As far as I understood, the upgrade process is triggered every time
you start pytrainer (correct me please Nathan if I am wrong), so I am
not aware of how to launch it explicitely.
> As already said, my data is everything I recorded with pytrainer,
> therfore *rather* inhomogenous: pre-1.8.0 data, gpx-less data,
> splitted/paused records etc ;)
There is no best way to challenge upgrade process ;)
Regards,
David
------------------------------------------------------------------------------
Get your Android app more play: Bring it to the BlackBerry PlayBook
in minutes. BlackBerry App World™ now supports Android™ Apps
for the BlackBerry® PlayBook™. Discover just how easy and simple
it is! http://p.sf.net/sfu/android-dev2dev
_______________________________________________
Pytrainer-devel mailing list
Pytrainer-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/pytrainer-devel
