3 ms·

This is not arbitrary. It may be not intuitive coming from a rdbms background, but it isn't arbitrary. As Johnathon pointed out, it's like properly using synch

This is not arbitrary. It may be not intuitive coming from a rdbms background, but it isn't arbitrary. As Johnathon pointed out, it's like properly using synchronized or volatile half the time. I don't call it sometimes not working as arbitrary. I call it expected for not following the rules of the system.

isoap 10y ago
Let's pretend I'm leading a blind child by telling them which direction they should go, and if they don't step carefully, they could be hurt. If I can't see the child, should I continue to give them direction, or tell them to stop? In this use case, the database makes changes to data without knowing what is correct and what is harmful. That is not the user's fault. It's a code choice.
- hamax 10y ago
  No, it's a users choice to use a DB that has this tradeoff. Like it was said a couple of time already, all of your complaints about C* would work just as well for locking mechanisms in most popular languages.
tremon 10y ago
If I follow your argument correctly, it is basically the same argument as "your C compiler is correct, what you've written is invalid and the standard allows undefined behaviour here". Which may be a technically valid argument against the compiler/database system, but it's not a valid argument for defending the system as a whole: if a standard allows arbitrary execution instead of bailing out on non-standard (ambiguous) input, it is unreliable.
- hamax 10y ago
  Is variable assignment in c/java/... unreliable? It behaves very similar to what C* does. Concurrent access and modification will produce undefined behaviour if you don't explicitly protect it.
  - brianwawok 10y ago
    Exactly. Getting access to things like concurrent locks is HARD to get right. That is why there are so many simple languages that don't let you touch concurrency. Doesn't mean there is no need for it in the world, and no one should be able to use it.
pkolaczk 10y ago
RDBMSes can cause similar inconsistencies if you don't know what you're doing. It is like setting read uncommitted and then complaining about dirty reads.

isoap 10y ago

Let's pretend I'm leading a blind child by telling them which direction they should go, and if they don't step carefully, they could be hurt. If I can't see the child, should I continue to give them direction, or tell them to stop? In this use case, the database makes changes to data without knowing what is correct and what is harmful. That is not the user's fault. It's a code choice.

hamax 10y ago
No, it's a users choice to use a DB that has this tradeoff. Like it was said a couple of time already, all of your complaints about C* would work just as well for locking mechanisms in most popular languages.

tremon 10y ago

If I follow your argument correctly, it is basically the same argument as "your C compiler is correct, what you've written is invalid and the standard allows undefined behaviour here". Which may be a technically valid argument against the compiler/database system, but it's not a valid argument for defending the system as a whole: if a standard allows arbitrary execution instead of bailing out on non-standard (ambiguous) input, it is unreliable.

hamax 10y ago
Is variable assignment in c/java/... unreliable? It behaves very similar to what C* does. Concurrent access and modification will produce undefined behaviour if you don't explicitly protect it.
- brianwawok 10y ago
  Exactly. Getting access to things like concurrent locks is HARD to get right. That is why there are so many simple languages that don't let you touch concurrency. Doesn't mean there is no need for it in the world, and no one should be able to use it.

pkolaczk 10y ago

RDBMSes can cause similar inconsistencies if you don't know what you're doing. It is like setting read uncommitted and then complaining about dirty reads.