I've used Knex, ActiveRecord and many other ORM's and query builders. At some point, beyond basic queries you start wasting time coming up with SQL statements and then having to convert them to your ORM/builder's syntax. I've reached the point now where it's just easier to stick with writing SQL and having a library that removes the possibility of sql injections. My current stack is postgres.js and dbmate for migrations.
Knex isn’t an ORM, it’s a query builder. (Though the closely related library Bookshelf.js is an ORM).
I know your pain of translating SQL back to the ORM language, but what similar difficulty do you have for Knex? You have a query, and it’s isomorphic to the Knex query usually. There are a few things Knex doesn’t do, but it has the “raw” get-out-of-jail-free card for making part of the query just a string without sacrificing anything else.
Every project I’ve ever worked on has many closely related complex queries and writing them out as strings (even with placeholders) becomes either perilous as you write complex string building logic, or tediously repetitive.
You're being downvoted, but I completely agree. In the long run I believe most ORMs end up being a time sink. I like to put it that "they make the easy thing easy, and they make the hard stuff much harder". There are tons of operational benefits to using raw SQL.
The author of the slonik library for Postgres wrote this a couple years ago (note the slonik library also makes it trivial to write composable SQL statements): https://gajus.medium.com/stop-using-knex-js-and-earn-30-bf41.... I was working on a project where I had originally started using Knex, read this article and loved it, and ripped out everything to switch to slonik over a weekend. I'm so glad I did, it ended up being a huge benefit.
Slonik does _not_ make it possible (let alone trivial) to write composable queries. You're just doing string concatenation and string concatenation will bite you when things get complex enough.
There is also a big difference between an ORM and a query builder. Knex (and kysely, which is the only thing I'd use these days) allows you to write SQL that's just as complex as anything you'd write raw, complete with escape hatches if you need them. The criticisms of ORMs tend to be spot on, they are nice until they run into a wall, but that same thing simply does not apply to a robust query builder.
> Slonik does _not_ make it possible (let alone trivial) to write composable queries. You're just doing string concatenation and string concatenation will bite you when things get complex enough
In practice, I find this to be potayto/potahto. At the end you need the thing to output SQL that is going to run, and I've had a lot more problems trying to get Knex to output the SQL that I know works vs dealing with any string composition issues in Slonik.
More importantly, at the end of the day, when it comes to DB operations, all of the information you get from the DB is going to be output/logged in SQL. There is no way getting around the fact that you need to know SQL well to manage a DB. Knex just becomes another layer that you need to translate to and from ("the leakiest of abstractions" as I like to say). I'd rather focus my effort on becoming an expert in SQL than yet another popular-library-of-the-month.
1. You certainly need to know SQL
2. Composition is very different than concatenation and the differences become apparent as a project increases in complexity
3. I'd recommend checking out the current SOTA, especially with kysely (or Ecto if you ever get into Elixir projects)
I've used kysely extensively on a project built using sst.dev. I can't paste proprietary code, but I remember my head spinning over a particularly gnarly query (e.g. a bunch of window functions, aggregations, etc.) It was a million times more difficult to grok reading this in kysely's syntax than SQL.
That is incorrect, as per the article Kia ties the VIN number to the car’s functionality. The author used a 3rd party service to convert the license plate number to VIN.
Uhh this seems like a big fact to gloss over, and something I am quite surprised by. Could you point to any examples as I’m having a hard time finding anything available publicly from any DMVs/states
In Michigan anyone can do a in-person plate lookup for about $15 and it comes back with complete registration information including name and address. VIN and car details as well.
The $15 makes this pretty hard to scale too. The link someone posted was $0.05/request. I'd love to see how/where you can get this data in bulk from a primary source.
We don't support S3 event notifications directly, but you achieve similar functionality by using Database Webhooks [1]. You can trigger any HTTP endpoint or a Supabase Edge function by adding a trigger to the objects table [3] in the Storage schema.
"S3 protocol" typically refers to object storage read/write/delete, not additional service APIs. Support in other S3-compatible vendors varies, often with a different payload (though a translation wrapper shouldn't be too difficult to implement)
It’s much more than just generating structured schema. It also understands user intent and assigns the correct functions to solve a query. So for example if we give it two functions getWeather(city) and getTime(city) and ask “what’s the weather in New York?” It will decide on the correct function to use. It will also know to use both functions if we ask it “what’s the time and weather in New York?”.
ATSC is a North American modulation standard for transmission of Transport Streams over RF signals. Transport streams can carry any kind of a payload, including data. When the spec came out it was mandatory to use mpeg-2 for video encoding because that was the popular codec at the time. However there is nothing in the spec preventing broadcasters using other video/audio codecs (many already do). This is what this tv station did. You have approximately 19mbps of bandwidth to pack in as much payload in there as you can fit. ATSC3 brings about other features such as higher bandwidth, improved RF signals transmission efficiency (lower costs), error correction, etc…
For many cases yes. With llm based embeddings you get “semantic search”, so for example if someone searches for “pets” they will most likely get results that include “dogs” and “cats”. This is not the case for regular text search.
