I actually did this work on Friday, but I didn’t have the opportunity to write it up – just took a couple of notes so I could put this out today.
As of Friday, I’ve figured out, at least for now, how I want to store and retrieve dates. When I retrieve dates, I want them to be reverse chronological, so the most recent date can be accessed easily. For now, that means that my retrieval function reads the CSV where the dates are stored into a list, then reverses the list & returns it. Whatever asked for the dates to be retrieved receives a list in reverse chronological order. (My write function appends the date to the CSV, simple enough.)
During the initial working-out-the-kinks phase, the retrieval function actually iterated over the reversed list, printing off the dates rather than returning them. But after that caused some issues with redundancy, that got revised to returning a list.
I also ended up setting up a helper function for the printing which essentially iterates over the list, appends each item to a string with a new line at the end (so, 2022-12-17 \n), and returns that very long string (which gets longer with every update), which can then be printed by whatever requested the dates. This is super inelegant, obviously, so a priority is going to be to figure out a nicer way of handling this.
Another priority is going to be just… figuring out how to denote updates that happen on the same date. Every time I run the program to test it, it’s counted as a separate update and logged to the CSV. This is good! This is what I want! But I ran this program twenty-three times on Friday, so now the datelog reads (reverse chronologically):
2022-12-17
2022-12-17
2022-12-17
2022-12-17
2022-12-17
...… and so on. You see the issue.
I put together some questions to ask myself about how to solve this. Still haven’t answered them yet, but essentially they consist of: how do I denote the number of updates on a particular day? How do I store that information as separate from the date, and access it easily to update it?
One way, which sounds very clunky to me, would be to store the date alongside a number of updates (so, 2022-12-17 for the first update, and then edit that to 2022-12-17 (2) for the second update, and so on. The formatting is still under consideration). The second way, which is even worse, is to store the information as above (every date listed neatly for every time updated, which will get super long very fast), and then every time I would need to return or display a list of previous dates, iterate over the information so that I can return it in a nicer format. No, thank you.
I think the next step might be MySQL, which means that I’ll have to (re-learn) SQL and how to use it in Python. I’ll also have to pick a database, which will probably be MariaDB, mostly because I picked it randomly from the available MySQL databases when I was setting up the Reclaim Cloud environment which I’m hoping to test this on.
Oh, right, I have some Reclaim Cloud environments now. The environment for this project isn’t currently online and won’t be for the foreseeable future, unless it turns out I absolutely require the MariaDB from Reclaim Cloud to store the information. Which I probably will.
For the other environment, I’ve also been poking around a little bit with Ghost — not much yet, as I’m still working on getting it updated to the newest edition from 4.5.0, which is what I’m currently on. Once I do, I’ll be experimenting with the blogging features, as Reclaim is considering using it for our newsletter, which start being released at the end of January 2022. That environment is also offline for now until I figure out what I’m missing trying to update from the command line. Currently I’m dealing with this error:
What that sums up to is mostly “You need to update using Ghost-CLI, but you can’t, because you didn’t install this using Ghost-CLI” (I used a one-click installer). Once I get the answer I’ll be able to write this up better, maybe as an article for our support docs, but in the meantime: still working on it.
