I250 -Clarify SQLite / MySQL Instructions for local generation #251

paulj · 2025-01-27T10:58:33Z

paulj commented

2025-01-27 10:58:33 +00:00

Remove the mySQL instructions from README.md. This makes both README.md and GETTING_STARTED.md consistent. I have also followed the instructions and successfully completed generation of the website locally, so can confirm they are good.

paulj added 1 commit 2025-01-27 10:58:33 +00:00

I250 - remove mySQL instructions from README.md 713c2e6394

paulj added 1 commit 2025-01-28 09:37:27 +00:00

I250 - Clarify local SQL database setup. d617cf01d3

- Add MySQL information to GETTING_STARTED.md.
- Recommend SQLite over MySQL for local processing.

ken_fallon commented

2025-01-28 12:32:32 +00:00

Should we not be removing the mySQL instructions - I still see it included ?

rho_n commented

2025-01-29 03:03:36 +00:00

For most people, only SQLite is needed, but if you are developing for hub you will need MySQL. Plus I wasn't sure if the main website was generated from MySQL or SQLite. I suggested we go the other direction and the MySQL directions where they were missing.

paulj changed title from ~~I250 - remove mySQL instructions from README.md~~ to I250 -Clarify SQLite / MySQL Instructions for local generation

2025-01-29 08:45:21 +00:00

paulj commented

2025-01-29 08:47:33 +00:00

I suggested we go the other direction and the MySQL directions where they were missing.

This is now the case with the code included in this pull request:

Instructions for MySQL and SQLite are included in both README.md and GETTING_STARTED.md
I have made it clear that both can be used, but SQLite is the recommended option for local generation

> I suggested we go the other direction and the MySQL directions where they were missing. This is now the case with the code included in this pull request: - Instructions for MySQL and SQLite are included in both README.md and GETTING_STARTED.md - I have made it clear that both can be used, but SQLite is the recommended option for local generation

ken_fallon commented

2025-01-29 09:20:14 +00:00

We use a RMDBS on the Hub in order to handle the concurrency issues needed for the usecase of managing reservations. We can't use sqlite for this. We use MariaDB as it's the successor to MySQL and was traditionally widely available for affordable hosting. Going forward I expect we will need to migrate to PostgreSQL.

We do not need to support database concurrency when processing hpr_generator so there is no reason for to use anything other than sqlite. This remains the case even when we have multiple static domains to push to. Either we do them from one source (eg admin server borg), or each mirror admin run their own version of hpr_generator. I don't ever expect run hpr_generator on the hub (although if we did, it could use sqlite as well). The whole point is that when the main server may be taken offline, we can continue operating by switching admin server to point to some other provider.

Our goal is to share knowledge. We cannot assume our successors will have a clue about how all this works, and so it's critical we make as little code as possible. It's very likely sqlite will be maintained in the future given it's code base, the same cannot be said for MySQL.

If someone wants to take the sql and import it into another database then that's fine, but I'd suggest not as part of the Hacker Public Radio maintained code. Obviously I'm happy to offer help but not to the extent of maintaining two code bases.

We use a RMDBS on the Hub in order to handle the concurrency issues needed for the usecase of managing reservations. We can't use [sqlite](https://sqlite.org/useovernet.html) for this. We use [MariaDB](https://en.wikipedia.org/wiki/MariaDB) as it's the successor to [MySQL](https://en.wikipedia.org/wiki/MySQL) and was traditionally widely available for affordable hosting. Going forward I expect we will need to migrate to [PostgreSQL](https://en.wikipedia.org/wiki/PostgreSQL). We do not need to support database concurrency when processing `hpr_generator` so there is no reason for to use anything other than sqlite. This remains the case even when we have multiple static domains to push to. Either we do them from one source (eg admin server `borg`), or each mirror admin run their own version of `hpr_generator`. I don't ever expect run `hpr_generator` on the hub (although if we did, it could use sqlite as well). The whole point is that when the main server may be taken offline, we can continue operating by switching admin server to point to some other provider. Our goal is to share knowledge. We cannot assume our successors will have a clue about how all this works, and so it's critical we make as little code as possible. It's very likely sqlite will be maintained in the future given it's code base, the same cannot be said for MySQL. If someone wants to take the sql and import it into another database then that's fine, but I'd suggest not as part of the Hacker Public Radio maintained code. Obviously I'm happy to offer help but not to the extent of maintaining two code bases.

ken_fallon referenced this pull request

2025-01-29 09:51:05 +00:00

Suggestion - have a file with a list of tool version numbers needed to process shows etc. #245

rho_n commented

2025-01-29 12:24:15 +00:00

If someone wants to take the sql and import it into another database then that's fine, but I'd suggest not as part of the Hacker Public Radio maintained code. Obviously I'm happy to offer help but not to the extent of maintaining two code bases.

So my reading of this means we can also delete the references to MySQL/MariaDB in site.cfg comments and also delete the MySQL/MariaDB related code in the templates.

> If someone wants to take the sql and import it into another database then that's fine, but I'd suggest not as part of the Hacker Public Radio maintained code. Obviously I'm happy to offer help but not to the extent of maintaining two code bases. So my reading of this means we can also delete the references to MySQL/MariaDB in site.cfg comments and also delete the MySQL/MariaDB related code in the templates.

ken_fallon commented

2025-01-29 18:36:31 +00:00

If you agree to the statements - then yes.

paulj commented

2025-01-29 19:00:06 +00:00

@rho_n - If you agree with Ken's direction, I will fix the documentation accordingly, so that can be merged. With your blessing, I will make another pull request to pull the code, so you can review it easily and confirm I have understood it properly. That will be a good learning opportunity for me. Of course if you would rather do the code removal yourself, that's also fine!

rho_n commented

2025-01-29 20:12:51 +00:00

@rho_n - If you agree with Ken's direction, I will fix the documentation accordingly, so that can be merged. With your blessing, I will make another pull request to pull the code, so you can review it easily and confirm I have understood it properly. That will be a good learning opportunity for me. Of course if you would rather do the code removal yourself, that's also fine!

@paulj Yes that sounds good. I am fine with removing the MySQL references from both documentation and code in two PRs. Thanks for jumping in and helping on this.

> @rho_n - If you agree with Ken's direction, I will fix the documentation accordingly, so that can be merged. With your blessing, I will make another pull request to pull the code, so you can review it easily and confirm I have understood it properly. That will be a good learning opportunity for me. Of course if you would rather do the code removal yourself, that's also fine! @paulj Yes that sounds good. I am fine with removing the MySQL references from both documentation and code in two PRs. Thanks for jumping in and helping on this.

👍 1

paulj added 1 commit 2025-01-30 23:01:43 +00:00

WIP - working on README.md 01a1e72f6a

ken_fallon commented

2025-02-13 11:32:54 +00:00

@paulj What is the status of this now ?

This pull request can be merged automatically.

This branch is out-of-date with the base branch

You are not authorized to merge this pull request.

View command line instructions.