Upgrade path
Aha, that was simple and straight-forward. Thank you!
Feedback: I just did it. It took a minute and it worked just fine.
Connecting to the server after the upgrade got stuck in an endless wait. The log shows lots of per-version modifications to the database done in the meanwhile, e.g.
INFO: ChangeSet changelog-5.6::changelog-5.6::author ran successfully in 7642ms
INFO: Columns commandid(INT) added to tc_notifications
INFO: Foreign key constraint added to tc_notifications (commandid)
INFO: ChangeSet changelog-5.7::changelog-5.7::author ran successfully in 1230ms
INFO: Column tc_devices.geofenceids dropped
INFO: Columns geofenceids(VARCHAR(128)) added to tc_positions
INFO: ChangeSet changelog-5.8::changelog-5.8::author ran successfully in 1359ms
INFO: Columns calendarid(INT) added to tc_devices
INFO: Foreign key constraint added to tc_devices (calendarid)
ending with
INFO: UPDATE SUMMARY
INFO: Run: 20
INFO: Previously run: 8
INFO: Filtered out: 0
INFO: -------------------------------
INFO: Total change sets: 28
INFO: Update summary generated
INFO: Update command completed successfully.
INFO: Successfully released change log lock
INFO: Command execution complete
and the server starting. However, my browser that was all along trying to access the server while showing a rotating ring, got stuck there and remained stuck forever. I have an apache proxy in front of traccar. What probably happened was a TCP timeout between httpd and traccar while traccar was updating its database. Nothing to worry about, just restart, reload, everything good. Thank you Anton.
Though I'm not sure I like the modern interface. It will take some getting used to it. And I think I just found a bug.
I have a device showing "Total Distance 189365.85 km". That's almost five times around the earth along the equator. It is a user who travels a lot, but only turns on her traccar client if there's a compelling reason to, like being in a dangerous area and such. So, over time, the server has many short tracks, say between 2 and 150 km long each, from the US, Peru, India, Mexico, Spain. What seems to happen here, is that traccar includes the distance between one track's last point and the next track's first point, so that if the client is switched off at JFK and then reappears 48 hours later in Delhi for a two-kilometre trip, the server counts the distance between New York and Delhi as part of "total distance". It should not. Instead, it should only add up contiguous trips, with the definition of "contiguous" being a (configurable and by default short) time between location updates.
That's not a bug. That's just how total distance works.
OK, let's not call it a bug. Let's just say that "total distance" needs to be defined as the total distance of something. Total distance of what? Total distance tracked seems a reasonable metric. Total distance travelled by the device is an impossible metric, because if the client is switched off in Berlin, then goes to Beijing, then from there to Boston and is switched on again in Boston, traccar will only see Berlin to Boston and will have no idea about Beijing. So it makes no sense to try to track a device while it is not transmitting locations.
Then again, location transmissions are not 100% reliable, so it does make sense to try to fill in some gaps when it is reasonable to do so. If a device disappears at a point X and reappears two minutes later at a point Y one kilometre away from X, it is reasonable to assume that it is still on the same trip and has actually travelled the distance between X and Y. But if a device disappears at a point X and reappears three months later at a point Y, it is unreasonable to assume that it is on the same trip and that it spent three months going from X to Y in a straight line, and that it didn't go to some other point Z in-between points X and Y.
What I'm saying here, is that it would be a good thing to reduce the extent of those assumptions. Not eliminate them completely, but just reduce their scope.
There's no reasonable assumption that can apply to all use cases. I don't see a problem with just having a total accumulated distance.
I'm running a v4.14 server from anno dazumal, which definitely should be upgraded.
I read all the changelogs from 4.15 to 6.8. Things that stuck out are "several security fixes" and the removal of the default admin account somewhere in 5.x. One means I should have upgraded long ago, the other means I risk locking out myself.
Question: is it possible and safe to upgrade directly from 4.14 to 6.8, or should the upgrades be staged? Does the database need to be manipulated in any way?