-
Notifications
You must be signed in to change notification settings - Fork 47
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
implement deferred constraints #310
Comments
C.J. Date in "Database In Depth" around page 126 discusses his multiple assignment operator (the comma) and how is differs from deferred execution, allowing various whole statement optimizations to still apply while not requiring constraints deferred all the way to commit time. It's worth considering. |
A constraint is a |
Indeed, the current constraint optimizer uses such information to determine which constraint checks can be skipped (if the update expression mentions relvar x and the constraint does not, then the constraint can be skipped), so that part of the implementation is covered. |
Is this issue about implementing deferred constraints or multiple assignment operator? |
Ultimately, deferred constraints and the comma operator serve the same purpose. The advantage of the comma operator is that it doesn't actually defer constraint-checking. Date explains:
Unlike deferred constraints (often checked at commit-time), the comma operator allows the user to have more fine-grained control over specifically where constraint-checking happens. The comma operator could be implemented in Project:M36 without any special state (such as holding onto which constraints should be validated at commit-time). |
Thanks! I did read page 126 but wasn't sure which direction Project:M36 would take. This would also allow for true 1:1 relationships between tables instead of 1:[0,1] at best without deferred constraints. |
Indeed, the solution also appeals to me because it's a feature which doesn't exist in any other database and seems to be a slick solution to a common problem. SQL just doesn't have relational assignment or equality as concepts, but these are fundamental to the algebra. |
Discussed in #307
Originally posted by farzadbekran October 19, 2021
I was thinking it might be a good idea to have some way to delay constraint checks until
commit
. Here is an example scenario:Imagine I have RelVar
a
andb
, now RelVarb
has an attribute that is foreign key froma
. Now if I want to make a change to the attributes ofa
, I need toundefine
a
, make changes to the attribs and update the tuples accordingly and redefine it. But sinceb
depends ona
existing, this fails as I can't simplyundefine
a
, which means I have toundefine
constaints forb
to be able to changea
, and if we have a RelVarc
which depends onb
, we have a nightmare on our hands! I assume the is no easy way to determine what constraints referencea
, so that it can be somewhat automated or something.But if I can disable constraint checks temporarily, I can make my changes to
a
without having toundefine
constraints forb
andc
in the process. Hope this makes sense!This would come in handy specially if I need to make a quick change in production.
The text was updated successfully, but these errors were encountered: