On 2015/11/18 7:23 PM, Duquette, William H (393K) wrote: > On 11/17/15, 3:35 PM, "sqlite-users-bounces at mailinglists.sqlite.org on > behalf of Rolf Ade" <sqlite-users-bounces at mailinglists.sqlite.org on > behalf of rolf at pointsman.de> wrote: > > >> Richard Hipp <drh at sqlite.org> writes: >>> On 11/17/15, Yuri <yuri at rawbw.com> wrote: >>>> This message always leaves the user wondering: "Which constraint?" >>>> >>>> How hard is it to add this information to the message? Is this a matter >>>> of memorizing the ID of the constraint, and then printing its name in >>>> the message? >>>> >>> ... >>> To provide information about which constraint(s) failed, it would be >>> necessary to have a bag (a list or hash table or an associative array) >>> of all the constraints that have been violated and then remove >>> elements from the bag as constraints are resolved. > What if it saved just the first constraint to fail? That would allow the > problem to be fixed one constraint at a time. Or is that still hard to do > given the current implementation?
There is no "first" constraint that can fail. There is a procession of constraints either within a statement or within a transaction (both can have many constraints) and as they are required, they are counted up, and as they become resolved they are counted down. At the end the result is simply either that "some constraint failed" or "All resolved eventually". When we end up with a remainder in this checks-count (indicating that one or more did not resolve), there is no way to know which one of the initial requirements did not come back to indicate itself as resolved - we only know one or more of them didn't. To know which one it was, new code has to be added to keep track of all the constraints that might be required to resolve and which resolved so we can eliminate them from the list as they resolve. It is this tracking list requirement that is no longer "Lite" in both code and execution cost / resources. I hope that makes some sense! Ryan