search

jeffsf / pyDE1

Controller for the Decent Espresso DE1
GNU General Public License v3.0
77 stars 16 forks source link

Historic shot access? #38

Closed a112358132134 closed 1 year ago

a112358132134 commented 1 year ago

A query, not a bug.

In trying to implement a new shot graph display (in a more performant and feature rich library), I've run into a couple of design questions. Can you please advise if there is an existing API or expectation on how these would be addressed? I'd prefer not to "roll my own" unless it's necessary. Thank you!

Historic shot access

I'd like the GUI app to be able to request:

  1. A list of the historic shots that match certain filter criteria (e.g. most recent 10 shots; all shots with profile=x), returning key identifiers (ID, start time, maybe a few other fields)
  2. The full shot data for a nominated ID

From a review of the documentation, it appears this is only available via direct query to the SQLite DB (i.e. independently of the pyDE1 HTTP/MQTT APIs). Is this correct? If so, I'll implement a back-end API to cover this.

Reference shot identification

By reference shots, I'm including "god shots", although I can foresee that this could be more widely used than is currently the case in the Decent app. For example, I could see different reference shots for each coffee / profile combination.

From what I can tell, pyDE1 doesn't have any allowance for tagging or providing reference shots, and it's up to the GUI to sort this out for itself. Is my understanding correct?

If that is the case, the cleanest non-breaking solution will be to store such info in a separate SQLite DB used by the GUI, using the IDs in pyDE1's DB as the linkage mechanism. Grabbing the reference shot data could then happen as per any other historic shot. Again, this could be done in a back-end API.

jeffsf commented 1 year ago

You are correct, there isn't a generic interface to query the SQLite database.

I've got learning GraphQL "somewhere on my list", but not something I expect I'll get to in the short term.

the cleanest non-breaking solution will be to store such info in a separate SQLite DB used by the GUI

Yes, that is the intent. From what I understand, though I haven't tried it, you can join across two databases. See, for example, https://stackoverflow.com/questions/6824717/sqlite-how-do-you-join-tables-from-different-databases

Concurrent access should not be a problem as long as you're using the same user for access. There seem to be some issues if you use a different user account, even for read-only access, with permissions getting set to that second user. I didn't look into it deeply as my "answer" was just to always access with the same user.

a112358132134 commented 1 year ago

Thank you for the quick and clear response.

GraphQL does look like a good fit; will keep it in mind in designing the backend, even though it's going direct for now.

attach will come in handy to maintain separation of data / versioning / ownership without needing to manually sort out merging or sequencing multiple queries from the different sources.