CREATE INDEX idx_status_gin
ON my_table
USING gin ((data->'status'));
ref: https://www.crunchydata.com/blog/indexing-jsonb-in-postgres CREATE INDEX idx_status_gin
ON my_table
USING gin ((data->'status'));
ref: https://www.crunchydata.com/blog/indexing-jsonb-in-postgresNot sure "code" belongs here. Even less sure about "illusion".
Take those away and what is left is "dismantled... by capital". Nothing new, really.
Of course “code” belongs here.
Looking for performance issues on a machine with different baseline IO and CPU load, buffer state, query plans, cardinality, etc. is just theater and will lead to a false sense of security. RegreSQL is approaching a stateful problem as if it were stateless and deterministic. A linter like https://squawkhq.com is a good partial solution but only addresses DDL problems.
RegreSQL would be better served by focusing only on the aspects of correctness that tools like SQLx and sqlc fundamentally cannot address. This is a real need that too few tools try to address.
I don't get this mindset. I'd much rather have the new guy spend a few months getting used to a new language, than have an organization where everyone uses different languages. It's a nightmare a few years down the road when you have 20 different projects in 15 different languages and the people who built them are mostly gone.
People are way too lenient with this stuff IMO. The goal of an organization should be to have one solution to each problem. For example we use .NET for backend and React for frontend. You don't need anything else. People love to talk about the right tool for the job, it's all BS. You can make pretty much any kind of website using react and pretty much any kind of backend using C#. The only reason to choose anything else is preference.
And sure maybe you have some data science people who need python, thats fine. Just don't have one guy using Py, another using R and yet others using Matlab. That's just asking for trouble. Pick one, stick to it. If you're going to make a change then migrate everything. If it's not worth that then the new tool probably isn't such a big deal after all.
Before, there was no problem using Instagram or Twitter while not logged in. Now there is a dark pattern that forces you to create an account, or log in.
It wasn't anything like the radical change to how CI works that you seem to be envisioning. It was just deleting a lot of Python environment setup and management code that has a history of being obnoxious to maintain, and replacing it with a one-liner that, at least thus far, has given us zero fuss.
Does that mean they aren't running unit tests _at all_ in CI yet, or they just use a totally different, newer system in production than they do for CI? Either way, brave of them to admit that in public.
For example, if you want to store settings as JSON, you first have to parse it through e.g. Zod, hope that it isn't failing due to schema changes (or write migrations and hope that succeeds).
When a simple key/value row just works fine, and you can even do partial fetches / updates