MaxGabriel

Any chance the first result was an ad? Those are definitely a popular phishing distribution mechanism, so getting your parents an adblocker could help

We have a similar check in our Haskell codebase, after running into two issues:

1. Nested database transactions could exhaust the transaction pool and deadlock 2. Same as you described with doing eg HTTP during transactions

We now have a compile time guarantee that no IO can be done outside of whitelisted things, like logging or getting the current time. It’s worked great! Definitely a good amount of work though.

One thing to add about performance: it's also pretty easy in Postgres to index only non-soft deleted data.

I think this is likely unnecessary for most use cases and is mostly a RAM saving measure, but could help in some cases.

This might stem from the domain I work in (banking), but I have the opposite take. Soft delete pros to me:

* It's obvious from the schema: If there's a `deleted_at` column, I know how to query the table correctly (vs thinking rows aren't DELETEd, or knowing where to look in another table)

* One way to do things: Analytics queries, admin pages, it all can look at the same set of data, vs having separate handling for historical data.

* DELETEs are likely fairly rare by volume for many use cases

* I haven't found soft-deleted rows to be a big performance issue. Intuitively this should be true, since queries should be O log(N)

* Undoing is really easy, because all the relationships stay in place, vs data already being moved elsewhere (In practice, I haven't found much need for this kind of undo).

In most cases, I've really enjoyed going even further and making rows fully immutable, using a new row to handle updates. This makes it really easy to reference historical data.

If I was doing the logging approach described in the article, I'd use database triggers that keep a copy of every INSERT/UPDATE/DELETEd row in a duplicate table. This way it all stays in the same database—easy to query and replicate elsewhere.

I’m the author of this post and a co-founder of Mercury. Let me know if you have any questions!

> 6-10 digit numeric or alphanumeric code that could be copied out of the email message into a form field on the signin screen.

To be clear this is what we're trying to avoid. An easily typeable code like that can be typed into a phisher's website.

Oh good find, the link going through Mailgun as a redirect is a recent regression. We have a PR to fix that going live soon.

That said, our security team and I agree there is no security issue here. Mailgun already can see the text of the emails we send.

I think database schema docs are really valuable, so much so that I added tests that require docs for each table and column. But I still got asks that the docs needed more information, mostly from data science people (who otherwise need to go bug engineers, or end up writing bugs in their own SQL). So I wrote internal guidelines for documenting database tables, and eventually that became this blog post

Lemme know if you have any questions!

> Kener is a Open-Source

Should this be “an” in the page header?