Convert robust Python lapper to Java about telraam HOT 7 CLOSED

eac0798

from telraam.

Ziet er goed uit, merci!

from telraam.

On second thought, it might not be ideal to delete all laps and then save them again: this does a lot of writes to the database, and will keep increasing lap ids. Do you have a suggestion for a better approach? I think maybe you can compare the laps by their timestamp (if they lie in a 5 second interval, they are the same, so you can just edit their timestamp), and only insert new laps and delete unneeded laps?

Additionally, if any laps other than the last one is edited, a lap is deleted or there's an insertion between already existing laps, maybe log this, since this would be strange (will happen in the case of a station getting disconnected and reconnected later)

from telraam.

(Also, pls werk met pull requests, dat maakt het makkelijker om comments toe te voegen op een specifieke lijn)

from telraam.

I meant to work with a pull request but because of an oversight it immediately got pushed to the development branch my bad.

The save method is indeed not ideal.
I'm working on a new version that only fetches the new detections instead of going through all the detections. Since it only calculates the new laps it'll only add those to the db.

from telraam.

Yeah no worries about the accidental push :) I've enabled branch protection, this was misconfigured.

The version that only fetches new detection sounds more efficient :) There are however some pitfalls/edge cases:

• Telraam may be restarted during the event
• If there are two detections, A and B, and A has a higher detection id then B, then this does not mean that A's timestamp is after B.
  • common case: the fetcher that fetches the detections from the stations does not run at the same time for every station, so detections from one station may be inserted later than detections from another station, even if the detections happened earlier
  • less common case: some stations can become temporarily disconnected, for example by the Ethernet cable getting driven over, while the detections from other stations are still getting inserted. After the connection is restored, the detections from the disconnected stations will be pulled in, maybe leading to different behaviour of the lapper. If the algorithm runs only with the newly inserted detections, so without the detections that are in time around the newly inserted detections, strange things will happen.

from telraam.

This was done, thanks @Topvennie

from telraam.