#1 mentions keeping a list of stations (from field in frames table) in a separate table and updating the location and timestamp every time a new frame is received.
This issue is for querying that table and exposing results to an endpoint, which should be less work than filtering down from the frames table results.
Rows in the stations table would be kept for much longer than rows in the frames table (months? a year?).
Would objects be stored in a separate table, or included here?
stations have a from callsign-SSID and no name
objects have a from callsign-SSID and a name
messages have a from callsign-SSID and format: 'message'
#1 mentions keeping a list of stations (`from` field in frames table) in a separate table and updating the location and timestamp every time a new frame is received.
This issue is for querying that table and exposing results to an endpoint, which should be less work than filtering down from the frames table results.
Rows in the stations table would be kept for much longer than rows in the frames table (months? a year?).
Would objects be stored in a separate table, or included here?
- stations have a `from` callsign-SSID and no name
- objects have a `from` callsign-SSID and a name
- messages have a `from` callsign-SSID and `format: 'message'`
Like this from current dw logs and frontail. Fields like callsign, count, last heard, location, symbol?
Like this from current dw logs and frontail. Fields like callsign, count, last heard, location, symbol?

No, this will be a different PR. The query right now seems OK, and I turned off autoremove for now in 8f3b2ae707.
No, this will be a different PR. The query right now seems OK, and I turned off autoremove for now in https://amiok.net/gitea/W1CDN/aprs_tool/commit/8f3b2ae7075cc5c2df22ed9e1293e2690e31f4d8.
I set up a query in unique_stations() to show the station list for now, but if frames is cleaned up periodically (#31), the station list may still be useful in the future.
I have this comment in place in tcp_kiss_send_recv.py: # TODO update stations table here
Copied from https://amiok.net/gitea/W1CDN/aprs_tool/pulls/30#issuecomment-947:
-----
Experimenting with new `stations` table.
```
CREATE TABLE "stations" (
"id" INTEGER NOT NULL UNIQUE,
"from" TEXT,
"frames_id" INTEGER,
"last_heard_unix" INTEGER,
"count" INTEGER,
PRIMARY KEY("id" AUTOINCREMENT)
);
```
I set up a query in `unique_stations()` to show the station list for now, but if `frames` is cleaned up periodically (#31), the station list may still be useful in the future.
I have this comment in place in `tcp_kiss_send_recv.py`:
`# TODO update stations table here`
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
#1 mentions keeping a list of stations (
fromfield in frames table) in a separate table and updating the location and timestamp every time a new frame is received.This issue is for querying that table and exposing results to an endpoint, which should be less work than filtering down from the frames table results.
Rows in the stations table would be kept for much longer than rows in the frames table (months? a year?).
Would objects be stored in a separate table, or included here?
fromcallsign-SSID and no namefromcallsign-SSID and a namefromcallsign-SSID andformat: 'message'Like this from current dw logs and frontail. Fields like callsign, count, last heard, location, symbol?
Working on this in #30.
No, this will be a different PR. The query right now seems OK, and I turned off autoremove for now in
8f3b2ae707.Copied from #30 (comment):
Experimenting with new
stationstable.I set up a query in
unique_stations()to show the station list for now, but ifframesis cleaned up periodically (#31), the station list may still be useful in the future.I have this comment in place in
tcp_kiss_send_recv.py:# TODO update stations table hereThis has been completed.