101–110 of 127 posts
Earlier quoted context omitted.
If you don't think sqlite is reliable, don't ride in an airbus a350 ;) https://sqlite.org/famous.html
I have a certain amount of difficulty believing this, and the only reference is that page. Anyone know more details? Edit: ok, I believe it now: https://www.sqlite.org/th3.html
Earlier quoted context omitted.
Sure you can do that, but if your app needs to use other services (Redis, for example) you can easily throw that in the compose file as well, and then it's easy to maintain versions and have every developer be on the same page. This is especially helpful if some developers use OS X or Windows. I don't understand the "all of that" phrasing, as if what I just described was a large amount of work.
How many people run webwpps with changing version requirements for their _database_? Docker is useful for running components of your own code or for isolation, not for managing versions of core applications like a database or a mail server for most people deploying ready-made apps.
All our "system software" — Postgres, Redis, Memcached, RabbitMQ, Elasticsearch, etc. — run as containers on Kubernetes. Doing so allows us to start new versions without considering the host OS. For example, we can upgrade Postgres to a new release the moment it's out, without having to wait for Debian or Ubuntu or whatever.
It also allows us to run different versions (e.g. a new one for testing in our "staging" environment) concurrently without any concerns about which node is running what. In fact, almost nothing needs to be configured with information about "nodes"; everything is routed to the right place, and the client only needs a name to connect to.
Sometimes we start temporary instances of software, e.g. to experiment with. Bring the container up, do the testing, bring container down; nothing ever got installed on the host OS.
SQLite is one of the best pieces of software I have used in my career as a developer. It is performant, reliable, simple and consistent. There is a reason sqlite3 is deployed in so many places.
Eh. Definitely not reliable in my experience. I don't use SQLite directly, but I use apps that save stuff in it. I've had issues of losing data because the SQLite DB became corrupt. Although to be fair, I have no idea if this is any less common with other DB's.
Earlier quoted context omitted.
Your version is denormalized. It is faster, but also more likely to have misspellings and duplicates. It really depends what is more important.
The JSON example that it was compared to was also denormalized.
Earlier quoted context omitted.
> queue those up in a list (in the code) That won't work in the language that most server-side website code is written in. PHP processes are created and destroyed per HTTP request, and even the FastCGI implementation won't let one share data across requests. PHP does have a sessions feature, but that data is written to either the filesystem (by default) or a database on every request!
Just add Kafka in between
I just don't understand why people can't see the logic behind using something operationally simple like SQLite.
Earlier quoted context omitted.
Just add Kafka in between
Exactly. When my 10 visitors a day start writing too many comments, I usually jump to containerizing everything, deploying kubernetes, and installing a queuing system w/ workers to handle the load. A zookeeper cluster with Kakfa could definitely work too, and has the added benefit that you can replay history if your SQLite comment database ever got corrupted. I just don't understand why people can't see the logic beh…
On the other hand, you seem to know all the buzzwords, so I bet you’re pretty good at getting your ass hired.
Earlier quoted context omitted.
Yep, I can write an INNER JOIN faster than I can remember jq's arcane syntax. If you needed it all in one flat table for some reason, SQLite supports views.
Speaking of which, I've not grokked jq's functional approach to composing queries. Can anyone suggest a good approach to understanding jq please?
Earlier quoted context omitted.
For me, using PostgreSQL is like using static typing: a bit more work, but it catches a lot of bugs. SQLite favours a very permissive approach, while PostgreSQL favours locking everything down with strict types and strong integrity checks, and it's very easy to verify lots of details of your data before it's accepted into the database. That takes work to set up properly and maintain, but it catches bugs early and red…
Strictly speaking, SQLite is dynamically typed in a sense, because the database does not enforce the values in the rows match what the columns claim about the type. But from a developer experience point of view, the main difference between dynamic and static typing is the following: Dynamic typing requires a lot of extra checks to ensure everything is what you expect it to be, and a lot of annotations to document wha…
Earlier quoted context omitted.
The instructions on the link I gave are clear about using volumes to persist data. It is a very quick read and definitely worth your time. Ease of postgres deploy is what made me a docker fan.
Do you understand what it does? Do you understand the common ways it can fail? When it does eventually fail, can you figure out how to fix it?
Why do you ask?
Earlier quoted context omitted.
So I'm actually doing this right now, I write about it on my blog. None of the apps I've written have hitten any kind of crazy traffic peak, so I started wondering why the hell I was using postgres or other database types after reading https://www.sqlite.org/whentouse.html . Seeing how simple SQLite has been for me to use has inspired me to write a bunch of dead-simple good-enough approximations for other tools that…
FTFY: https://sqlite.org/fts5.html