The gimmicky episodes were highly entertaining to my decidedly non-Trekkie wife. She loved the Star Trek Muppet episode ("Star Trek in Spaaaaaace") and the soap-opera episode.
As for taking the show seriously, I don't take any of it seriously. It's a telenovela, or maybe we should say Stellanovela. Most episodes build a fairly cohesive story, then break loose, and those old scientists have fun with the Star Trek universe. It's not like they're acting in a Chekhov play.
re: taking it seriously, I meant more in terms of whether it is "good art" vs disposable entertainment. On the whole, I felt that TNG and DS9 both eventually found the right balance of drama and humor, often with an intelligent underlying message about aspects of our society and culture. The modern Star Trek shows are sorely lacking in that area!
Eh, I mean TNG, which is probably the best-regarded series, had its fair share of duds, and not just in the not-very-good first season. In particular, I am thinking of the episode where Data's cat turned into a lizard.
> A transporter malfunction turns most of the crew into puppets while Spock fights to reclaim the ship.
The difference is the sheer number of gimmick episodes: so far half the episodes this season fall into that category. Did you actually watch that puppet episode you're quoting? Gimmick aside, it had one of the dumbest endings of any Star Trek episode I can think of.
Nope; haven’t seen any of this series. The streaming situation for it, at least in this country, is a bit of a mess. But it sounds from the description like a do-over of the cat lizard episode, more or less.
Ehh, maybe that notion times ten. These recent episodes are far goofier and more nonsensical than that TNG episode. (and again, my view on them is far less harsh than many of the reviews I've seen online...)
At least the TNG duds attempted some kind of sci fi technobabble explanation for whatever hijinks were occurring. With this season of SNW, we're getting plot devices like "missing resistance leader just happened to look identical to Enterprise's first officer by complete coincidence!" and "spooky derelict ship is haunted, no explanation even attempted!" ... there are worse ones I could reference but they're spoilers. I'm genuinely starting to wonder if an LLM is writing these scripts.
In this specific case (Tailwind Labs) I don't understand this sentiment at all. It was a completely bootstrapped company! Its entire existence is due to the many years of difficult work by its founders.
What exact outcome would correctly align with "good leadership" in your view? It sounds like you think the CEO/cofounder should have "gone down with the ship" here -- how does that help anyone if it means the entire company would have failed?
No, the binlog format is actually irrelevant here; the post author was just incorrect about that part. ALTER TABLE always gets replicated as a statement, regardless of the binlog format.
Auto_increment only has broken replication semantics in the very specific situation the author encountered: a table has data, but no primary key (and also no alternative unique index which could serve as the clustered index key) and then an attempt is made to alter the table to add an auto_increment primary key.
Basically that form of ALTER TABLE statement is telling the database to add a sequential ID to each existing row, but without providing any deterministic way that those numbers should be assigned. So each replica may choose a different numbering, causing the problem experienced by the author.
It's a foot gun, but not a common one in production at any real scale where you'd have a replica in the first place. InnoDB tables really should always have primary keys, and there are various ways to ensure that happens (sql_require_primary_key option, generated invisible primary key option, external linters, etc).
Author here. I didn't make it clear in the article but the table in question did have a primary key, which was migrated to an unique key, and then the new auto-incremental primary key was added.
As I mentioned in the article, the old ID field was then used in the update statement for the other tables.
I'm updating the article now to make that part clear.
Interesting, I wouldn't have expected that auto_increment replication problem to occur for InnoDB tables that have a clustered index key (the old PK converted to UNIQUE), that is indeed surprising. Maybe the SQL layer does something dumb here and thinks the table doesn't have a defined ordering because it has no explicit PK -- even though internally in the storage engine it would still have the table organized by the old PK if it was a UNIQUE KEY over non-NULLable columns.
But even that aside, I still say the binlog_format is irrelevant and the core problem here is 100% the ALTER to add the auto_increment: it resulted in different IDs on the replica than on the primary. That's a problem if you refer to IDs externally anywhere, regardless of whether it's 6 child tables or an external cache or logging etc. As soon as you promote a replica for any reason (not just an upgrade, any failover reason whatsoever) this would be a massive problem as all the IDs would now refer to different rows. And even before a failover event, if you do any reads from the replica for any purpose (read scaling, backups, OLAP queries), the data is going to be wrong.
Essentially for the 6 child tables, it wouldn't have mattered if their UPDATEs had all used ROW or all used STATEMENT; either way you would have still had a fundamental data inconsistency between primary and replica here for the parent table. If these 6 tables' UPDATEs all used ROW, they would refer to the IDs from the primary which are locally "wrong" on the replica. Or if they all used STATEMENT then the data on the replica would be consistent locally but completely different than what's on the primary.
yeah, now that you mention it i remember a similar issue for us on postgres where we transitioned tables without primary key to being primary key serial.
I agree the root cause here is the lack of a primary key to begin with. But as far as I know, DDL is always replicated as just a statement, regardless of session binlog_format. So I believe the only real fix here is the general approach suggested in the manual [1], i.e. create a new empty table that has the auto_increment PK added and then populate it from the old table.
Yeah, looking back at my first reply I did get the order wrong: first the alter, then the empty noop. But once you run the alter and have a primary key (though the author clarified the table did have a PK already), I’d just use pt-osc to run the empty noop as that would basically do what the manual says.
Huh, if the table effectively already had a clustered index key (from the old PK) then I'm surprised that the auto_inc values would be assigned non-deterministically. I would have naively assumed that the values would be assigned in clustered index key order. Maybe this is one of those cases where too much logic is handled outside the storage engine?
Anyway yes nice to see you here too Fernando! Good call on the noop pt-osc, I always forget about all the cool tricks that tool can do when applied in non-obvious ways.
That's largely a fantasy in the NYC metro area as well. Unless you're talking about a tiny condo, and/or your office is extremely close to a major transit hub.
NATURAL JOIN is actually in the SQL standard; it's not specific to MySQL.
I'm not aware of any databases that allow UNION to take table names directly, although in many cases you can use the TABLE keyword as a shortcut for "SELECT * FROM".
My sense is that a lot of this activity isn't even legitimate use. As one example: my company has a GitHub app, and last night some bot added my app to 1700 repos. Then the bot immediately started rapid-firing commits which each affected hundreds of files, triggering a deluge of GitHub webhooks to my servers.
The repo names all matched other GitHub apps, so my sense is this bot had added 1700 GitHub apps to 1700 repos, with that number rapidly increasing at the upper bound of whatever GitHub's rate limit is.
My systems caught it quickly and auto-booted the bot, but the whole situation is ridiculous.
The GitHub bot situation is so frustrating! A good ~50% of community traffic on our repos is spam and bots and to report them I have to fill out a lengthy form and MAYBE GitHub will ban them six weeks later. And I also can't tell whether our repos are being used (and thus worth investing in): GitHib only shows two weeks of traffic data and what they do have is completely useless because they can't filter out bot traffic.
there's this attack on youtube where people who dont want their real names known will autoblock comments with their real names; bots will spam comments with every word and note the ones that were not visible.
kinda reminds me of it. not my most valuable contribution to forensics, admittedly.
Yeah I think that's really important. The average value of each commit, action, or hook has become significantly lower, and that necessarily means that they can't spend on quality. If you set the quality bar to cater to the top 10% of value-creating users (us) the amount you'd pay for quality at times when quality matters none would truly and completely sink you
Unless I'm missing something, your linked comments seem to be responding only to the title of the article, without addressing any of the actual points being made in the body of the article?
Actually, Zuckerberg's Facemash site was online for less than 3 days. It's worth mentioning that the events depicted in The Social Network regarding Facemash's traffic level supposedly crashing the Harvard FAS network were fictional. Administrative staff from FASCS (arts+sciences IT department) were alerted because the site content severely violated student privacy, not due to the network traffic.
If it helps, I regard early Facebook as Version 2.0 of the original Stalk That Girl and an example of asocial media that should have been culled at an early stage.
I can't speak to events depicted in films I haven't watched, so that's The Social Network and An Inconvenient Truth off the board :/
Personally I didn't hate the gimmick episodes, but enjoying them sort of requires no longer taking the show seriously at all.
reply