Live data from Hacker News

WordPress Core to start using SQLite

make.wordpress.org

31–40 of 71 posts

Re: WordPress Core to start using SQLite

#31
post #18
post #9

Speaking about WordPress, what does anyone do about diffable version control and automated deployment? From my naive perspective, it seems like an opaque database is just a bad idea

My personal blog runs on Django + PostgreSQL, and I got fed up of not having a version history of changes I made to my content there. I solved that by setting up a GitHub repo that mirrors the content from my database to flat files a few times a day and commits any changes. It's worked out really well so far. It wasn't much trouble to setup and it's now been running for nearly three years, capturing 1400+ changes. I'…

That is awesome! Did you consider using the temporal_tables extension? I think it's basically like version history for tables. I haven't used this before personally though. https://pgt.dev/extensions/temporal_tables

Re: WordPress Core to start using SQLite

#32
post #17
post #9

Speaking about WordPress, what does anyone do about diffable version control and automated deployment? From my naive perspective, it seems like an opaque database is just a bad idea

You could ask the same question about any application that uses a database. The answer is you typically don’t do things that way. If all you need is a static site generator with code in git, then go ahead, however the use for Wordpress is an audience who needs a full application to manage a site.

> needs a full application to manage a site.

AFAICT it’s not that. It’s that most shops want the ability to edit content without a developer. But such a requirement doesn’t mandate that data lives in a database vs something like, say, a set of plain-text files, that would be amenable to version control and diffing

Re: WordPress Core to start using SQLite

#33
This is good news. It will allow me to drop MariaDB, only used for a few low traffic websites I manage, making my things more robust, more lightweight and easier to maintain.

I don't care for managing ports / sockets, migrating configurations, doing the creating database (careful not to use the not-really-utf-8 charset), user and granting privileges dance. Overkill for my use case.

Backups will also be easier: a simple rsync call will do, no need to call the specific mysql backup command anymore (of course it's automated but that's one less thing that can fail, less moving parts)

I bet we are many people in this case.

Re: WordPress Core to start using SQLite

#34
post #33

This is good news. It will allow me to drop MariaDB, only used for a few low traffic websites I manage, making my things more robust, more lightweight and easier to maintain. I don't care for managing ports / sockets, migrating configurations, doing the creating database (careful not to use the not-really-utf-8 charset), user and granting privileges dance. Overkill for my use case. Backups will also be easier: a simp…

> Backups will also be easier: a simple rsync call will do, no need to call the specific mysql command anymore (of course it's automated but that's one less thing that can fail, less moving parts)

Technically, that's incorrect way of doing it; practically it rarely fails (as writes are usually much rarer in many cases SQLite is used, especially if you backup in the middle of the night, and format itself is pretty resilient), but you should be doing one of methods here:

https://www.sqlite.org/backup.html

Re: WordPress Core to start using SQLite

#35

wget /wp-content/database Laughing deeply in my whole heart. Also, can't wait to use it (drastically simplify hosting for certain usecases) - hope it will land soon! Long live Wordpres

Really should be in a parent directory that will never be visible by anyone's browser.

Which is not how wordpress install is set up to work, because of both webhost and wordpress developers incompetence

Re: WordPress Core to start using SQLite

#36

This is great. Apps and frameworks should work with the lowest-common denominator of SQL. I get physically ill when I walk into yet another Rails shop to find that they have used every cool feature of Postgres and as a result, the CI must spin up a huge postgres instance and multiple plugins just to run a single unit test. Ugh.

> Apps and frameworks should work with the lowest-common denominator of SQL.

Pointless limitation that will make your app slower and SQL code worse.

> I get physically ill when I walk into yet another Rails shop to find that they have used every cool feature of Postgres and as a result, the CI must spin up a huge postgres instance and multiple plugins just to run a single unit test. Ugh.

shrug. We (not rails shop) just create temporary database, pass it to CI test, remove after. Picking database because your CI is done badly is like one of the worst ways to decide on architecture

Re: WordPress Core to start using SQLite

#37

This is great. Apps and frameworks should work with the lowest-common denominator of SQL. I get physically ill when I walk into yet another Rails shop to find that they have used every cool feature of Postgres and as a result, the CI must spin up a huge postgres instance and multiple plugins just to run a single unit test. Ugh.

Honest question: why would CI only run a single unit test?

Well, if you're currently writing one unit test, and want to test that test...

Re: WordPress Core to start using SQLite

#38
post #16
post #8

Waiting for obligatory comment of "WP sucks. Who still uses PHP in 2023".. On a serious note, this is very interesting. SQLite is just awesome and this will be a welcome addition to the core.

Well... it does suck :) is a surprising amount of infrastructure to operate a mostly static website.

The weight of WordPress is a bummer. On the other hand, it usually covers any use-case, even those you don't know yet, while still remaining usable by non-technical people, which is quite a feat.
Post reply on HN