11–20 of 39 posts
Earlier quoted context omitted.
It definitely a scary proposition. But it's worth mentioning that two of the world's biggest money moving platforms (Stripe and Shopify) are written in ruby.
Stripe decided to write a type checker for it though, probably for good reasons: https://sorbet.org/
Earlier quoted context omitted.
Stripe decided to write a type checker for it though, probably for good reasons: https://sorbet.org/
Yup, also being used at Shopify. Types are awesome, but these companies got very far by betting big on the productivity of ruby before this became a concern.
> Looking at our request traffic made choosing optimistic locking fairly easy. We expect the majority of ledger operations to be reads, and we didn't want reads to block writes (and vice versa). I don't get it. If they use an SQL database that supports ACID already, why not just lock all the ledger rows necessary with an exclusive row access when writing and otherwise just with a shared access so that the write waits…
I think the missing context is that the db reads go all the way to an HTTP client, get modified on the client, and are sent back hoping nobody else has edited the row in the meantime. Pessimistic = check row is not locked on READ; Optimistic = check lock_version matches on WRITE. For a table where single row ops are all you can do, this is basically enough to let API users read and update rows concurrently. SQL trans…
And as you say, in this case you couldn't even reliably lock on read because you don't know whether or when a client sends a POST anyways.
Earlier quoted context omitted.
It definitely a scary proposition. But it's worth mentioning that two of the world's biggest money moving platforms (Stripe and Shopify) are written in ruby.
Stripe decided to write a type checker for it though, probably for good reasons: https://sorbet.org/
I think people severely overrate the value of the language when it comes to avoiding bugs. We already know how to minimize bugs: Extensive testing regimes (automated, manual, or both) and a general focus on correctness over “shipping on an artificial deadline”.
Modern Treasury is a Ruby on Rails shop I really wouldn't want to write a service that deals with money in an unsafe language. It's so easy to make a mistake in ruby there's no compiler to help you.
optimistic locking is a useful technique that seems unfamiliar to many - it's worth looking into
Same goes for `git push --force`, always use `git push --force-with-lease` instead.
Earlier quoted context omitted.
Stripe decided to write a type checker for it though, probably for good reasons: https://sorbet.org/
It should be mentioned that their reasons were mainly developer convenience/productivity, and not “correctness”. I think people severely overrate the value of the language when it comes to avoiding bugs. We already know how to minimize bugs: Extensive testing regimes (automated, manual, or both) and a general focus on correctness over “shipping on an artificial deadline”.
optimistic locking is a useful technique that seems unfamiliar to many - it's worth looking into
I thought I didn't know what it was when I heard of them, then realized that it's not a lock at all, it's just a row version column, with the basic rule don't overwrite without having seen what you're about to overwrite. Same goes for `git push --force`, always use `git push --force-with-lease` instead.
Odd choice. There's a standard, but the developers still chose to re-implement w/ specific semantics. There's nothing on the standard saying you have to support ETags for all the resources.
Tom Kyte, he of Oracle fame had a particularly good discussion of the concept in one of his books (Effective Oracle by Design ... IIRC).
IIRC, the Oracle way is to enable rowdependencies for the table(s) in question and then use ora_rowscn.
But in reality, you can use almost anything that changes in a defined fashion (timestamps, version numbers etc.). Then all you need to do is test for it in your database stored procedures (or elsewhere in your middleware if you are not using sprocs).