Safely Dropping MySQL Tables(planetscale.com) |
Safely Dropping MySQL Tables(planetscale.com) |
They let me know what the current big companies are doing to improve developer experience and/or devops. Their teams are often bigger than my entire company, so learning from them is a great way to see what we might be able to implement (whether by buying their service or doing a small scale version of it in-house).
Secondarily, they sometimes also show end-user experience improvements that I never thought would be possible at a certain scale/cost. Cloudflare hosting Doom and IRC on serverless is one such example, or Vercel doing multiplayer live editing (Figma style) out of the box with Next.js is another.
For this case of this particular post, the idea of having an external metadata analytics system for Mysql, stored in a separate store and dashboard, is something I've only vaguely seen in DigitalOcean. Seeing it as fully featured as in Planetscale makes me both wonder if we should consider using them instead of a some generic cloud DB, and also whether we can implement something similar on a standard LEMP container. It's one of the more interesting pieces I read on HN today, actually.
For those of us who don't live and breathe infrastructure, big(ger) tech company blog posts is a great way to learn, and I value them!
Let me help you understand it a little bit more in-depth.
First of all, the title used for this submission does not imply an announcement of a new feature. This one[0], however, does. Now, let's look past that. Let's say that the submission warrants front-page treatment fair and square because it has valuable content (a write-up at the very least). Lo and behold - it does not.
This submission[1] announcing Vercel's Build Output API has both a decent submission title (I can instantly tell it's a feature announcement) and fairly decent explanation for the feature, also. In fact, they even provided links to various documentations to help developers get started right away.
I'm still eagerly awaiting for someone to tell me what they learned from this specific submission.
same reason why filesystems are often mounted with noatime attribute !
The next ingredient would be if dropping MySQL tables is a relatively big pain (or known but unmanaged risk) that most of those people have experienced at some point.
Then this feature would be exciting news for that not-so-small cohort and that seems sufficient for HN upvotes?
I don't know if that's what happened today. I've heard about planetscale a few times but never used it. I can attest that dropping tables is always scary.
Don’t get me wrong but clicking on this link I was expecting an actual detailed guide/explanation.
There is nothing anyone can say to justify this being on the front page considering both the submission title and the actual content of the said submission.
also posted by a former github person. not sure if poster is author or works at planetscale but a lot of ex github engg are there
Probably not worth the hassle though.
In this case, RENAME TABLE x TO y, and watch or wait for a process to fail in test/QA/UAT/etc.
Have a DROP ready, but also a RENAME back.
A production quality MySQL or MariaDB installation should have enabled binary logging and maybe delayed replication to handle any issues.
(I just wanted to win the prize for the most HNey comment ever!)
The code change may of landed the day before that disabled accessing that table, but the tool would warn that the table was still in use.
A quarterly cron job may access the table and go undetected if you look purely at the recency.
The rename strategy protects the data and offers easy rollback. This is a false heuristic.
I honestly wonder if you could make a functioning database API that either does not accept strings as arguments, or can detect string concatenation and reject it. Not just a builder pattern to greatly discourage it, but a straight up exception on bad input type. Bind variables or GTFO.
IMO, it is still not safe even we know there are no queries running for this table. You may still meet a scenario that when you type `drop table`, another guy begins to run the query at the same time.
As the maintainer of another database, We have been trying our best to improve this scenario too.
Early on, we have provided a feature called `recover table` to recover table immediately after you wrongly drop the table. But this still can't avoid affecting current running queries on this table.
We call this problem `DDL affects DML`, and now we try to introduce a Table meta lock to guarantee that no any query is running when the DDL executed. We hope we can release this feature in the end of this year.
It is not about getting rid of MySQL as a database.
Now, if your issue was with the article title, I fully agree. I wish the titles here were clearer.
Into the repo method, push up the change, redeploy the projects that depend on the library and wait a while and grep the logs to see if it ever gets used.
Monorepo is easier though.
> Or if customers only use it right before a federal deadline for filing
> forms, or at the end of the quarter when it's time to generate reports.
I personally like to version my APIs, but that is robust insofar as code changes, not for database changes.
In Go, the solution was very tidy: it aliases string to an unexported internal type that consumers cannot instantiate. String literals can be coerced to that type, but variables that already have type information associated with them are rejected at compile time.
The C++ solution was a bit more complicated and involved templates.
However you would also probably want a language with some syntactic sugar that let users use your special string type easily otherwise the burden on users will be too high
In the instance under discussion in that section of the book I'm referencing, allowing the user to instantiate the special string type was precisely the behavior intended to avoid. The idea being that in the following three examples, the first succeeds and the rest fail at compile time:
Query("SELECT * FROM Users WHERE id = ?;")
id := "6"; Query("SELECT * FROM Users WHERE id = " + id + ";")
id := 6; Query(fmt.Sprintf("SELECT * FROM Users WHERE id = %d;", id))But while that prevents people from concatenating strings to form DML queries as a whole, it obviously doesn't prevent the kind of concatenation wereHamster mentioned.
I’m talking about the alternative world where people use tainted strings and have to manually taint or untaint strings explicitly everywhere and that is nuts. You have to do that when your language has nothing to help you with. If you have to resort to that, I think you need to give up.