You can also already pull limited time blocks using wildcards on created: http://127.0.0.1:5001/packets?created=2023-04% returns packets in April 2023.
To close #27, is it easier to query on timestamp or by the text version of created?
I added LIKE instead of =, which will let you do wildcards with % as in:
http://127.0.0.1:5001/packets?created=2023-04% or http://127.0.0.1:5001/packets?from=%UND%.
Excited about the latest commit, which allows you to query on any field in the frames table.
I'm not sure if you can do wildcards or not.
{'raw': 'K0UND-2>APDW16,WIDE1-1,WIDE2-1:}WLNK-1>APWLK,TCPIP,K0UND-2*::W1CDN-13 :ack1', 'from': 'K0UND-2', 'to': 'APDW16', 'path': ['WIDE1-1', 'WIDE2-1'], 'via': '', 'format': 'thirdparty',…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.