On live code, moved the rest of the processing inside the try()...else() at
try: |
{'raw': 'K0UND-2>APDW16,WIDE2-1:!b69Ld5xIC# #UND SARA; undsara.org; 146.865 (-) 123.0', 'from': 'K0UND-2', 'to': 'APDW16', 'path': ['WIDE2-1'], 'via': '', 'messagecapable': False, 'format':…
The query was ordering by row ID by default, I added ORDER BY created DESC.
Now messages don't work (unrelated to recent change):
{'raw': 'W1CDN-2>APQTH1,K0UND-2,WIDE2-2::W1CDN-2 :Test…
The packets are still getting into the db, it's the query that is broken. Will have to rethink this when I have a moment.
So weird. I uploaded the files to the digi machine and now it shows packets from 2023-04-16.
In cases where the location of a digipeater isn't known, skip that digipeater line but add a "?" on the line, indicating there is a hop we can't see the location of.
It might be time to use sqlalchemy or some other way to abstract the database calls. My first pass is pretty ugly.
For example, I should be able to arbitrarily select on ANY field.
I wonder if using aprs_api/packets/<callsign-ssid> works better on the back end than aprs_api/packets/?from=<callsign-ssid>.
This seems to be the path field we get in the current version.