51–60 of 63 posts
I sometimes wonder if the database would be more widely used if they had picked a different name.
So probably if you would be turned off enough by the name not to use the software, you don't actually need a distributed SQL database and are not the target customer.
Earlier quoted context omitted.
> If `UPDATE player SET level = 'AA' WHERE team = 'Gophers';` is executed before the player swap, then why should "Stonebreaker" be upgraded to "AA"? I'd be pretty mad at my database if I sent those 2 queries in sequence and my DB decided to re-order them. It’s easy to miss but in the swap query the levels also get swapped. Because — and it’s harder to miss but easy to skip over — given what constraint 2 says the lev…
> given what constraint 2 says the level is actually a team level, not a player level. Then it's bad unnormalized data design that is the problem here. If that is a team level, it should be in the team table, not the player table.
It's all contrived, of course, but the reason I would consider skill level to be a player attribute rather than a team attribute is that there could be free agents with a skill level but no team:
INSERT INTO player VALUES (10, 'Pavlo', 'AAA', NULL);
Then with enough free agents, you could imagine building a new team out of free agents that are all at the same skill level:
UPDATE player SET team = 'Otters' WHERE level = 'AAA' AND team IS NULL ORDER BY id LIMIT 3;
I sometimes wonder if the database would be more widely used if they had picked a different name.
My guess is orgs that have a real need for a distributed SQL database (which are rare in the space of orgs) will make their choices based on requirements analysis rather than naming. So probably if you would be turned off enough by the name not to use the software, you don't actually need a distributed SQL database and are not the target customer.
UPDATE player set name = 'Stonebraker' where name = 'Stonebreaker'
I sometimes wonder if the database would be more widely used if they had picked a different name.
My guess is orgs that have a real need for a distributed SQL database (which are rare in the space of orgs) will make their choices based on requirements analysis rather than naming. So probably if you would be turned off enough by the name not to use the software, you don't actually need a distributed SQL database and are not the target customer.
Gyms know that people that sign up on Jan 2 don’t need annual (or any) membership. They take their money anyway. The more honorable ones allow cancellation or something but I don’t think anyone expects them to actively turn these folks away.
Earlier quoted context omitted.
I couldn’t imagine suggesting cockroachDB in a planning meeting for a new product. Especially when over half the room isn’t engineering. Just won’t happen.
Why are you wasting the time of half the room talking about technical decisions they wouldn't understand
Author here. We've spent the past year adding read committed isolation to CockroachDB. There were many interesting design decisions, such as: - whether to use multiple snapshots or a single snapshot per statement - how to handle read uncertainty intervals - how to incorporate SELECT FOR UPDATE locking into Raft - how to handle SELECT FOR UPDATE subqueries - how to prevent lost update anomalies between two UPDATEs Som…
Maybe as an option with a new syntax (UPDATE .. WHERE .. RETRYING) or something like this.