 | |
SQL deferred constraints (a bit O/T, I know)
comp.databases.theory comp.databases.theory
 |
| | Thread Tools | Display Modes |
#11
 
| |||
| |||
|
Re: SQL deferred constraints (a bit O/T, I know) -
04-04-2011
, 12:38 AM
|
This has been documented before. MVCC and database constraint checking do not fit together. |
versions so MVCC doesn't upset constraint checking at all.
#12
| |||
| |||
|
|
On 31 mrt, 21:42, Roy Hann <specia... (AT) processed (DOT) almost.meat> wrote: This is probably not the proper place to pose a question about how SQL "should" work, but I don't know of a better one. *Any suggestions? * I am curious to know the moment to which a deferred constraint should be understood to be deferred. *I assume it should be after the last update in a transaction (signalled by a COMMIT) but before the transaction surrenders read consistency. *But if that's the case, one can construct a pair of concurrent transactions that severally satisfy all constraints yet jointly leave the database inconsistent. * So what's the defined behaviour? *(At this moment I'm not interested in what we'd like it to be; I want to know what the standards define it to be.) -- Roy Roy, I am curious to know what kind of concurrent transactions you are thinking of fabricating. Are you thinking of scenario's in which the concurrency control mechanism is MVCC, and the constraint checking too happens under MVCC ? |
requires constraint checking to done using serializable isolation
*regardless* of the isolation level of the updating transaction.
Obviously if you insist on serializable isolation a lot of
easy-to-contrive violations are impossible.
--
Roy
#13
| |||
| |||
|
|
On Apr 2, 11:28 pm, Erwin <e.sm... (AT) myonline (DOT) be> wrote: TWO : the goal is NOT that "at the end of the session, all constraints must be _TRUE_", the goal is that at the end of the session, all constraints must be _SATISFIED_. Are you saying that because you don't regard a constraint as a boolean valued expression or function, or because you would never use terminology that ignores the distinction between an expression and what it evaluates to? |
Wouldn't you agree that "ignoring the distinction that you mention" is
indeed sloppy language (or sloppy use thereof) ?
#14
| |||
| |||
|
|
On Apr 2, 11:21 pm, Erwin <e.sm... (AT) myonline (DOT) be> wrote: This has been documented before. *MVCC and database constraint checking do not fit together. I thought in normal practice only read only transactions access old versions so MVCC doesn't upset constraint checking at all. |
problem.
The OP, however, didn't seem to be (as also evidenced by his own
reply).
#15
| |||
| |||
|
|
On 4 apr, 04:12, David BL <davi... (AT) iinet (DOT) net.au> wrote: On Apr 2, 11:28 pm, Erwin <e.sm... (AT) myonline (DOT) be> wrote: TWO : the goal is NOT that "at the end of the session, all constraints must be _TRUE_", the goal is that at the end of the session, all constraints must be _SATISFIED_. Are you saying that because you don't regard a constraint as a boolean valued expression or function, or because you would never use terminology that ignores the distinction between an expression and what it evaluates to? The latter. I was complaining about sloppiness in the language. Wouldn't you agree that "ignoring the distinction that you mention" is indeed sloppy language (or sloppy use thereof) ? |
we should expect everyone to clarify that distinction in natural
language because it's not normally a source of confusion. E.g. it is
quite common to make statements like
"x > 10 is true"
rather than
"x > 10 evaluates to true".
or
"the circumference of the circle with radius r is 2*PI*r"
rather than
"2*PI*r evaluates to the circumference of the circle with radius
r"
|
« Previous Thread
|
Next Thread »
| Thread Tools | |
| Display Modes | |
Linear Mode
| |
Powered by vBulletin Version 3.5.3
Copyright ©2000 - 2012, Jelsoft Enterprises Ltd.
Copyright ©2000 - 2012, Jelsoft Enterprises Ltd.