4/7/2023 0 Comments Firebird constraint limit![]() It's not *quite* like running the check constraint inside a read-only read-committed transaction (read-committed can't see limbo, right?) in addition to running it within the transaction itself, but close. But what about check constraints that do equivalent work, or that span more than one row? (Within-table constraints like "no two rows may have overlapping date ranges", or outside-table constraints like "all people must have at least two address") There are two forms of validity: "the changes made by this transaction make sense given their starting conditions" (constraint does not fail within the transaction view) and "the changes made by this transaction, when combined with other already-accepted changes, still make sense" (constraint does not fail within the view that would occur right after commit, when starting a new transaction). The built-in constraint types do this already - primary, foreign, and unique constraints can reject changes even though you can't see the conflicts from within your transaction. I don't know if the SQL spec says this, but in my idealistic opinion constraints ought to be able to see change from the current transaction + changes made by any other committed or limbo (partially committed two-phase) transactions. Commented by: Philip Williams (unordained) ![]()
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |