I thought this was common practice, generated columns for JSON performance. I've even used this (although it was in Postgres) to maintain foreign key constraints where the key is buried in a JSON column. What we were doing was slightly cursed but it worked perfectly.
If you're using postgres, couldn't you just create an index on the field inside the JSONB column directly? What advantage are you getting from extracting it to a separate column?
CREATE INDEX idx_status_gin
ON my_table
USING gin ((data->'status'));
Yes, as far as indices go, GIN indices are very expensive especially on modification. They're worthwhile in cases where you want to do arbitrary querying on JSON data, but you definitely don't want to overuse them.
If you can get away with a regular index on either a generated column or an expression, then you absolutely should.
It works until you realize some of these usages would've been better as individual key/value rows.
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
Doesn't sound very cursed, standard normalized relations for things that need it and jsonb for the big bags of attributes you don't care to split apart
This is the typical practice for most index types in SingleStore as well except with the Multi-Value Hash Index which is defined over a JSON or BSON path
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.
Using the right language for the problem domain is a good thing, but what I can't stand is when people self-identify as the one language they are proficient in. Like, "I'm Staff JavaScript developer" no buddy, you aren't "Staff" anything if you only know one language.
That would be equivalent to demonetizing the entire web. Free content would win out over paid content regardless of quality. As the old adage goes, "when you're getting something for free, you're the product being sold." Only sites making money by, shall we say, "indirect" means would be able to survive. A search engine which prioritizes free content over paid would become nothing but a propaganda engine.
I think I should at least be able to see even a subset of the content that caused the item to be returned in the search result, though. If I try to navigate away or see more content, sure, make me log in. But, if I search something, click on a Twitter/Facebook/Linkedin result, I should at least be able to see something.
The search --> visit --> immediate redirect to login results should be de-ranked.
“Free content would win out over paid content regardless of quality” this doesn’t follow unless we assume the most extreme implementation, the openness of the content is just one factor of many that should count in the contents favor. Further it assumes the only non-shady way to monetize content is put it behind a login which is not true.
A site can be a billboard for a product or service, or provide a social hub, without participating in the surveillance adtech industry. There are plenty of hobby forums, like those for craft brewing, which get supported by brewery suppliers, for example. There are luthier communities which get supported by toolmakers and professionals, and so on. The implicit community networking, reviews by community members, and other interactions reward quality and honesty, and penalize the shady shit.
It's just not scalable into the exploitative cash cows that VCs drool over.
> Free content would win out over paid content regardless of quality.
Quality has never been synonymous with monetization for as long as I can remember. The primary driver of low quality or harmful content is greed. Guess what fuels the most greed in modern society?
> A search engine which prioritizes free content over paid would become nothing but a propaganda engine.
Are you suggesting that including Twitter in search results would mitigate propaganda?
A search engine which prioritizes free content, reviewed intelligently, is curation, and not Goodharted gotcha games. If you can crawl the web and index sites with human level content curation, with a reasonably performant scaffolding, you can prevent SEO style exploitation, and use natural language rules like "does this content contain text attempting to game the ranking of a site or violate policy XYZ?"
Most AIs use bing and google, so the best you can get is a curated list from the already censored and politically filtered results from those sources, funneling commercial traffic toward the highest paying adtech customers - it's just refined, ultra-pure SEO results, unless they use their own index and crawler.
I'd almost rather have a naive raw index that can be interacted with, but custom indices, like xAI and Kagi, are definitely superior to Google and Bing. Google's a dumpster fire and Bing's a tawdry knockoff, and they're both interested in gaming the surveillance data and extracting as much money as possible from their adtech customers.
Paying for a service incentivizes the quality of that service. If that service is honest curation of and effective web search with custom indices and crawlers, then the free and paid distinction don't matter - the highest quality based on the curation criteria is what gets a site surfaced. I want my search engine to return McMaster Carr over Temu or Amazon, or a local flower shop over some corporate slop. Google doesn't get paid by meeting my expectations, it gets paid by exploiting my attention and extracting fractions of profit from commercial interactions, and makes more money by pushing me into business with companies that I'd otherwise want nothing to do with.
Demonetizing the entire web - dismantling the surveillance adtech regime - sounds like an absolute utopic victory to me.
> On GitHub Actions, we’re planning to use uv to quickly build a Python environment and run our unit tests. In production, uv already manages Python for all of our servers.
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.
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.
It seems like you're reading things that people aren't writing.
I don't know how the author's company manages their stack, so I can't speak to how they do their testing. But I do know that in many companies run-time environment management in production is not owned by engineering and it's common for ops and developers to use different methods to install run-time dependencies in the CI environment and in the production environment. In companies that work that way, testing changes to the production runtime environment isn't done in CI; it's done in staging.
If that's at all representative of how they work, then "we didn't test this with the automated tests that Engineering owns as part of their build" does not in any way imply, "we didn't test this at all."
Tangentially, the place I worked that maintained the highest quality and availability standards (by far) did something like this, and it was a deliberate reliability engineering choice. They wanted a separate testing phase and runtime environment management policy that developers couldn't unilaterally control as part of a defense in depth strategy. Jamming everything into a vertically integrated, heavily automated CI/CD pipeline is also a valid choice, but one that has its roots in Silicon Valley culture, and therefore reaches different solutions to the same problems compared to what you might see in older industries and companies.
No, that's pretty rare, and generally means you can't count on any features more sophisticated than VMs and object storage.
On the other hand, it's pretty embarrassing at this point for something as fundamental as Docker to be in a single region. Most cloud providers make inter-region failover reasonably achievable.
reply