When you're having to work with someone else's godawful convoluted database schema you're sometimes really happy not to have to write the query yourself. Giving the LLM context with previously written queries can be quite effective.
The writing SQL experience is a product of both SQL's syntax, the structure of the database you're querying over and the complexity of your query.
When things get hairy, and you have a good number of representative queries already written that you can use as context, LLMs can be really nice tool.
Agreed, but maybe the step change there is refactoring the data model, not continuing to author “hairy” sql via LLM that’s all fine until it breaks… and you end having to mend the nastiness back into compliance the ol’ fashion way
You could definitely load your billions of records with millions of relationships into memory, denormalize, restructure and rewrite the data (flawlessly) a lot cheaper (computationally) than running a large LLM on all that hardware.
I've been having a bad time with email of late. It's been the method of communication between us and another company (a pretty creaky old product). I thought they were replying strangely and ignoring my questions "did they even read what I said!?". It turns out for whatever reason they hadn't been getting some of my emails.
Now I can't trust that anything has been received unless I get an acknowledgement, so I have to keep pestering for replies. Basically lost trust in the protocol because it's dependent on the the other person's mailserver behaving they way you expect it to.
Well, E-Mail is inherently async and allows a sequence of relays with no back channel to confirm delivery.
With other protocols (except snail mail) I get a confirmation that recipient was valid and the message for delivered. With some I even get a marker it was read.
With e-mail, with luck, I get a cryptic not standardized response mail, if something went wrong. Sometimes even only a lot later as delivery is retried for a few days in some cases.
The core technologies may be simple, but email really is an entire stack of protocols, mechanisms, and conventions. And therein lies the problem. It's not one well designed solution but one workaround layered on top of each other to make it work reasonably well.
sqlc always seemed like a really neat concept to me. I love the idea of being able to write my queries as raw SQL in separate files, would make everything so much more interoperable with other tools. Having your queries defined as strings inside some other programming language always struck me as not so awesome.
I'd love to see something like this for Typescript and Effect's SQL integration with schemas.
Maybe, depending on where you are in the world, you could make some kind of GDPR request to get access to your data, even if you don't recover your account?
Thanks for recommending mailpace, £7.50/month for 10,000 emails is very reasonable, _and_ they support idempotency! Definitely makes me consider switching to them..
Please tell me this supports some kind of idempotency.. I fear it wont.
The kind of hoops I've had to jump through to achieve DIY idempotency with Postmark would make you cringe, a shared lock to avoid race conditions, and then using the API to check if an email with the unique id (manually added to the metadata when sending) has not already been sent before sending an email.
Being safe in the knowledge that an email with some unique key will only be delivered once regardless of bugs, processes dying mid task, network issues etc. just makes life so much simpler. The risk of sending duplicate emails or at worst spamming your users due to some more nefarious bug is something that you really want to guard against at as low a level as possible. Sure this might not be quite as consequential as duplicate charges through the Stripe API for example (Stripe have always seemed to lead the way with good API design in this regard).. doThing(data) is _not_ good enough for executing tasks over a network that are effectful, have a cost, and potentially risk your reputation if things go wrong. Idempotency keys should far more widely supported!
Maybe one approach would be to pin all dependencies, and not use any new version of a package until it reaches a certain age. That would hopefully be enough time for any issues to be discovered?
I doubt that would help much. People should clear their clipboard, and copy & paste, then double check the whole thing, or at least the first and last few characters.
The writing SQL experience is a product of both SQL's syntax, the structure of the database you're querying over and the complexity of your query.
When things get hairy, and you have a good number of representative queries already written that you can use as context, LLMs can be really nice tool.