3 ms·

Within pure paths, you just don't have this problem. You only have this problem at the boundary with the storage system (where, indeed, you might have to retry

Within pure paths, you just don't have this problem. You only have this problem at the boundary with the storage system (where, indeed, you might have to retry, e.g., if you have SERIALIZABLE transaction semantics). So FP gains composability if you can express your program as purely as possible as compared to an OOP w/ ORM system. And if you have transactions, you can compose FP programs that construct them because transactions compose. But if your ORM deprives you of transactions, you won't have that composability in your ORM.

AnimalMuppet 7y ago
OK, that's fine for "within pure paths". But even in FP, you have to take the lock somewhere, right? And now it's not pure, right? And now you have to pay attention to lock order, right? If your ORM doesn't give you transactions, then you don't have transactions. But FP needs some kind of layer to talk to a database, too, doesn't it? And if that layer doesn't give you transactions, you're in the same place, aren't you? Am I missing something? Or are you missing my point?
- cryptonector 7y ago
  You're assuming that transactions require locks. That's not necessarily the case with MVCC and SERIALIZABLE semantics, but you may have to retry the transaction (from scratch) if it fails. This looks a lot like what you'd get if you were using locks. Somewhere, though, there will be locks, indeed. Pushing the locking to the edges of the system helps keep the core composable. There's no panacea, of course. Also, an RDBMS can order locks because once you've decided what INSERTs/UPDATEs/DELETEs you're doing, they can be sorted and run in a different order than they were requested (after all, if the transaction is atomic, then the internal order doesn't matter). You can absolutely build all of that (transactions, lock ordering, ...) in any OOP (or FP or other) language of your choice. But that's essentially recreating part of an RDBS -- if you're after reuse, just use an RDBMS so you don't have to recreate its functionality. Using an RDBMS w/o an ORM helps you avoid all the issues raised by TFA. Further, using an EAV design gives you many benfits as outlined in TFA and elsewhere in the commentary here and on the web.
  - AnimalMuppet 7y ago
    Well, TFA was a video, so I've just been going off of the comments here. So, if I understand you correctly, the issue is with ORM, rather than with OOP or with the RDBMS. And you wouldn't use an ORM in FP, so you don't have the problem there.
    - cryptonector 7y ago
      TFA also had slides. I'm not going to say TFV... :) > So, if I understand you correctly, the issue is with ORM, rather than with OOP Well, there is certainly an issue with ORM. But OOP even absent databases and persistence, when used as originally intended (with objects abstracting state and behavior), has concurrency issues.

AnimalMuppet 7y ago

OK, that's fine for "within pure paths". But even in FP, you have to take the lock somewhere, right? And now it's not pure, right? And now you have to pay attention to lock order, right? If your ORM doesn't give you transactions, then you don't have transactions. But FP needs some kind of layer to talk to a database, too, doesn't it? And if that layer doesn't give you transactions, you're in the same place, aren't you? Am I missing something? Or are you missing my point?

cryptonector 7y ago
You're assuming that transactions require locks. That's not necessarily the case with MVCC and SERIALIZABLE semantics, but you may have to retry the transaction (from scratch) if it fails. This looks a lot like what you'd get if you were using locks. Somewhere, though, there will be locks, indeed. Pushing the locking to the edges of the system helps keep the core composable. There's no panacea, of course. Also, an RDBMS can order locks because once you've decided what INSERTs/UPDATEs/DELETEs you're doing, they can be sorted and run in a different order than they were requested (after all, if the transaction is atomic, then the internal order doesn't matter). You can absolutely build all of that (transactions, lock ordering, ...) in any OOP (or FP or other) language of your choice. But that's essentially recreating part of an RDBS -- if you're after reuse, just use an RDBMS so you don't have to recreate its functionality. Using an RDBMS w/o an ORM helps you avoid all the issues raised by TFA. Further, using an EAV design gives you many benfits as outlined in TFA and elsewhere in the commentary here and on the web.
- AnimalMuppet 7y ago
  Well, TFA was a video, so I've just been going off of the comments here. So, if I understand you correctly, the issue is with ORM, rather than with OOP or with the RDBMS. And you wouldn't use an ORM in FP, so you don't have the problem there.
  - cryptonector 7y ago
    TFA also had slides. I'm not going to say TFV... :) > So, if I understand you correctly, the issue is with ORM, rather than with OOP Well, there is certainly an issue with ORM. But OOP even absent databases and persistence, when used as originally intended (with objects abstracting state and behavior), has concurrency issues.