3 ms·

>It can validate against a previous version of the list of cities, but there's always the possibility of a delete happening in parallel. If a "city" is a) requ

>It can validate against a previous version of the list of cities, but there's always the possibility of a delete happening in parallel. If a "city" is a) required attribute of an entity and b) required to exist as an entity itself, then deleting a city would require deleting all other entities that refer to that city. If city is a nullable attribute, then your validation issue you raised earlier is voided - an invalid "city" can just be replaced with null. Assuming you're wanting to delete cities, then your client side shouldn't be firing off data and assuming success. > It can validate against a previous version of the list of cities, but there's always the possibility of a delete happening in parallel. Yep, caching is hard, but your argument that "RDBMS aren't that great" is predicated on a very... ...convoluted system.

lmm 5y ago
> If a "city" is a) required attribute of an entity and b) required to exist as an entity itself, then deleting a city would require deleting all other entities that refer to that city. Right, so usually what people implement (and what the database enforces by default) is that you can't delete a city if there are any customers in that city. But they don't think about what happens when two people try to make changes in parallel, because the whole point of ACID is that each query runs in its own transaction. > Yep, caching is hard, but your argument that "RDBMS aren't that great" is predicated on a very... ...convoluted system. All the use cases for referential integrity - and transactionality - are like this though. You can't actually use them for anything, not with a web app where the client can't hold a transaction open.
- EdwardDiego 5y ago
  > All the use cases for referential integrity - and transactionality - are like this though. You can't actually use them for anything, not with a web app where the client can't hold a transaction open. You should probably tell the millions of companies actually using them for things that they're wrong. I'm sure they'll feel very silly.
  - lmm 5y ago
    The actual businesses generally don't. It's funny how RDBMS fans always say "businesses x, y and z were built on MySQL" and forget to mention that they were actually using MyISAM-based versions of MySQL that had no ACID and barely any referential integrity constraints. Most of the "mongodb is web scale" crowd is coming from the same ideology as the people who were hating on MySQL 10 years ago.
- kaba0 5y ago
  > But they don't think about what happens when two people try to make changes in parallel, because the whole point of ACID is that each query runs in its own transaction. You do know that the D in ACID stands for consistency? That is in case a transaction try to modify something that was already changed in a parallel transaction that was already committed, it will fail and will be rolled back (given proper transaction levels). So I really don’t understand your point. Also, you can hold a transaction open for a client..
  - lmm 5y ago
    > That is in case a transaction try to modify something that was already changed in a parallel transaction that was already committed, it will fail and will be rolled back (given proper transaction levels). It will fail and be rolled back and you will lose the user's data that was written in it, unless you effectively build your own datastore on top of what the database offers. > Also, you can hold a transaction open for a client.. For a client that's potentially gone offline for an indefinite period? Certainly not. Even if you're heartbeating that the client still has the form open somehow, that seems like a very suspect architecture.
    - kaba0 5y ago
      What does the form have to do with anything? That’s just part of an application, nothing special. What about storing the results in memory until you can make sure it is successfully stored? Like, this has nothing to do with databases, that’s just application architecture. Also, what language/framework have you been using because these things are routinely handled by any that worth anything.
      - lmm 5y ago
        > What does the form have to do with anything? That’s just part of an application, nothing special. To be able to actually use database transactions you'd need them to extend across the form's lifetime. You can do that with a local application, but not with a webapp with the web request cycle. > What about storing the results in memory until you can make sure it is successfully stored? That has all the same problems as storing your data in memory and not using a datastore. In this scenario the data can never be stored because it now violates referential integrity. > Also, what language/framework have you been using because these things are routinely handled by any that worth anything. Many of the big-name Python or JVM-based ones, but it's a fundamental problem that can't be solved at that level. Which language/framework are you claiming handles this well?

lmm 5y ago

> If a "city" is a) required attribute of an entity and b) required to exist as an entity itself, then deleting a city would require deleting all other entities that refer to that city. Right, so usually what people implement (and what the database enforces by default) is that you can't delete a city if there are any customers in that city. But they don't think about what happens when two people try to make changes in parallel, because the whole point of ACID is that each query runs in its own transaction. > Yep, caching is hard, but your argument that "RDBMS aren't that great" is predicated on a very... ...convoluted system. All the use cases for referential integrity - and transactionality - are like this though. You can't actually use them for anything, not with a web app where the client can't hold a transaction open.

EdwardDiego 5y ago
> All the use cases for referential integrity - and transactionality - are like this though. You can't actually use them for anything, not with a web app where the client can't hold a transaction open. You should probably tell the millions of companies actually using them for things that they're wrong. I'm sure they'll feel very silly.
- lmm 5y ago
  The actual businesses generally don't. It's funny how RDBMS fans always say "businesses x, y and z were built on MySQL" and forget to mention that they were actually using MyISAM-based versions of MySQL that had no ACID and barely any referential integrity constraints. Most of the "mongodb is web scale" crowd is coming from the same ideology as the people who were hating on MySQL 10 years ago.
kaba0 5y ago
> But they don't think about what happens when two people try to make changes in parallel, because the whole point of ACID is that each query runs in its own transaction. You do know that the D in ACID stands for consistency? That is in case a transaction try to modify something that was already changed in a parallel transaction that was already committed, it will fail and will be rolled back (given proper transaction levels). So I really don’t understand your point. Also, you can hold a transaction open for a client..
- lmm 5y ago
  > That is in case a transaction try to modify something that was already changed in a parallel transaction that was already committed, it will fail and will be rolled back (given proper transaction levels). It will fail and be rolled back and you will lose the user's data that was written in it, unless you effectively build your own datastore on top of what the database offers. > Also, you can hold a transaction open for a client.. For a client that's potentially gone offline for an indefinite period? Certainly not. Even if you're heartbeating that the client still has the form open somehow, that seems like a very suspect architecture.
  - kaba0 5y ago
    What does the form have to do with anything? That’s just part of an application, nothing special. What about storing the results in memory until you can make sure it is successfully stored? Like, this has nothing to do with databases, that’s just application architecture. Also, what language/framework have you been using because these things are routinely handled by any that worth anything.
    - lmm 5y ago
      > What does the form have to do with anything? That’s just part of an application, nothing special. To be able to actually use database transactions you'd need them to extend across the form's lifetime. You can do that with a local application, but not with a webapp with the web request cycle. > What about storing the results in memory until you can make sure it is successfully stored? That has all the same problems as storing your data in memory and not using a datastore. In this scenario the data can never be stored because it now violates referential integrity. > Also, what language/framework have you been using because these things are routinely handled by any that worth anything. Many of the big-name Python or JVM-based ones, but it's a fundamental problem that can't be solved at that level. Which language/framework are you claiming handles this well?