On 1 Dec 2015, at 12:55am, Yuri wrote:
> On 11/23/2015 07:55, James K. Lowden wrote:
>> As a matter of fact, violation of UNIQUE & PK constraints is enforced
>> rather too strictly in SQLite. Any UPDATE statement that modifie more
>> than one row of a UNIQUE column can fail because two rows
On 11/23/2015 07:55, James K. Lowden wrote:
> As a matter of fact, violation of UNIQUE & PK constraints is enforced
> rather too strictly in SQLite. Any UPDATE statement that modifie more
> than one row of a UNIQUE column can fail because two rows may
> *transiently* have the same value. SQLite
On Tue, 17 Nov 2015 22:29:10 -0500
Richard Hipp wrote:
> With CHECK, and UNIQUE, and NOT NULL constraints, you do know that the
> constraint has failed right away. And for those constraints, SQLite
> does provide more detail about exactly which constraint failed. But
> for FK constraints, you
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" behalf of rolf at pointsman.de> wrote:
>
>
>> Richard Hipp writes:
>>> On 11/17/15, Yuri wrote:
This message always leaves the user
On 11/18/2015 15:33, Scott Hess wrote:
> What do you plan to use the error message for? There is generally no
> interface contract with error messages, so you can't generally depend on
> them being readable by code. They are helpful to the developer, but
> usually they just save you a few
On 11/17/15, 3:35 PM, "sqlite-users-bounces at mailinglists.sqlite.org on
behalf of Rolf Ade" wrote:
>
>Richard Hipp writes:
>> On 11/17/15, Yuri wrote:
>>> This message always leaves the user wondering: "Which constraint?"
>>>
>>> How hard is it to add this information to the message? Is
On Wed, Nov 18, 2015 at 3:20 AM, Keith Medcalf wrote:
> A little off topic, this reminds me of a feature of the PL/1 F compiler.
> The PL/1 compiler was a huge monstrous beast that had both syntactical and
> semantic analyzer paths so it could "correct" a number of common
> programming errors,
On Wed, Nov 18, 2015 at 3:22 PM, Yuri wrote:
> On 11/18/2015 09:55, R Smith wrote:
>
>> 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
On 11/18/2015 09:55, R Smith wrote:
> 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
On Wed, Nov 18, 2015 at 10:58 AM, Darren Duncan
wrote:
> On 2015-11-18 1:27 AM, Yuri wrote:
>
>> On 11/18/2015 01:17, Darren Duncan wrote:
>>>
>>> Deferred constraints are definitely a benefit.
>>>
>> I agree they can be beneficial, but not in all cases. Depends on what you
>> do. It
>> would
On Wed, Nov 18, 2015 at 10:17 AM, Darren Duncan
wrote:
> On 2015-11-18 12:50 AM, Yuri wrote:
>
>> On 11/18/2015 00:45, Dominique Devienne wrote:
>>
>>> True. But that's in the case where FK constraints validation is deferred
>>> to
>>> the transaction end.
>>>
>>
>> Why does SQLite defer
On 18 Nov 2015, at 10:05am, Dominique Devienne wrote:
> Given this pragma, then showing the FK name on immediate
> mode is possible, no?
Unfortunately not. [following explanation is, I suspect, simplified]
When the table schema is read from the file the table's constraints are
'compiled'
On Wed, Nov 18, 2015 at 4:29 AM, Richard Hipp wrote:
> On 11/17/15, Yuri wrote:
> > Don't keep the bag, keep only one integer ID of the first failed
> > constraint.
>
> Therein lays the rub: there is no way to tell which (if any) FK
> constraint has failed until you have run the operation to
Examining the VDBE code generated from some simulated operations explains how
it works with stark clarity.
There are two constraint violation counters. One has a "statement" scope (for
immediate constraints), and the other a "transaction" scope (for deferred
constraints).
Basically when the
On Tuesday, 17 November, 2015 20:29, Richard Hipp said:
> On 11/17/15, Yuri wrote:
> > Don't keep the bag, keep only one integer ID of the first failed
> > constraint.
> Therein lays the rub: there is no way to tell which (if any) FK
> constraint has failed until you have run the operation to
On 2015-11-18 2:05 AM, Dominique Devienne wrote:
> On Wed, Nov 18, 2015 at 10:58 AM, Darren Duncan
> wrote:
>
>> On 2015-11-18 1:27 AM, Yuri wrote:
>>> I agree they can be beneficial, but not in all cases. Depends on what you
>>> do. It
>>> would have been great if it was an option, ex.
Replying to myself...
Often there is a single command available where one can say create a file on
this particular filesystem path, and the system will go and create any
nonexistent directories it needs to on the way. So from the user's point of
view creating the multiple things is a single
On 2015-11-18 1:58 AM, Dominique Devienne wrote:
> On Wed, Nov 18, 2015 at 10:17 AM, Darren Duncan
> wrote:
>
>> Deferred constraints are definitely a benefit.
>
>> They allow you to express constraints otherwise not possible, for example
>> that a record may exist in table X if and only if a
On 17 Nov 2015, at 11:35pm, Rolf Ade wrote:
> Although, the plea stays. Obviously, the name of the constraint would
> add value to the message.
Since SQLite4 works differently to SQLite3 it's possible that adding this
feature to SQLite4 would be 'cheaper' than adding it to SQLite3. We'll
On 2015-11-18 1:27 AM, Yuri wrote:
> On 11/18/2015 01:17, Darren Duncan wrote:
>>
>> Deferred constraints are definitely a benefit.
>>
>> They allow you to express constraints otherwise not possible, for example
>> that
>> a record may exist in table X if and only if a counterpart exists in table
On 11/18/2015 01:17, Darren Duncan wrote:
>
> Deferred constraints are definitely a benefit.
>
> They allow you to express constraints otherwise not possible, for
> example that a record may exist in table X if and only if a
> counterpart exists in table Y, such as balancing records in a
>
On 2015-11-18 12:50 AM, Yuri wrote:
> On 11/18/2015 00:45, Dominique Devienne wrote:
>> True. But that's in the case where FK constraints validation is deferred to
>> the transaction end.
>
> Why does SQLite defer constraint violation errors? Is there a benefit?
> This only complicates things, I
Am 11/17/2015 11:32 PM, Richard Hipp wrote:
> On 11/17/15, Yuri 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
>>
On 11/18/2015 00:45, Dominique Devienne wrote:
> True. But that's in the case where FK constraints validation is deferred to
> the transaction end.
Why does SQLite defer constraint violation errors? Is there a benefit?
This only complicates things, I would rather see the statement fail
Why not a pragma option that toggles the option to the bag populated? If
the pragma is not set, things run as expected. If the pragma is set, keep
the bag.
Another option for those that link directly to the engine is at each
violation counter up, and another for each violation counter down, add
On Wed, Nov 18, 2015 at 12:00 AM, Simon Slavin wrote:
>
>
> Since SQLite4 works differently to SQLite3 it's possible that adding this
> feature to SQLite4 would be 'cheaper' than adding it to SQLite3. We'll have
> to wait and see.
>
> Simon.
Yes. Maybe it can be shipped into SQLite 4.
--
If there was a vote, I would also vote for better message. But I don't
think there is one. The impact may be significant for applications
that have already been written. Updating your dependency and seeing it
slower is not something any developer likes to do. I would understand
if this just ends
On 11/17/15, Yuri wrote:
>
> Don't keep the bag, keep only one integer ID of the first failed
> constraint.
Therein lays the rub: there is no way to tell which (if any) FK
constraint has failed until you have run the operation to the end and
checked them all. Remember, an FK constraint is
> It is a substantial change (basically a complete rewrite of the entire
> foreign key constraint mechanism) which would negatively impact both
> space and performance.
I think the argument is fallacious.
Don't keep the bag, keep only one integer ID of the first failed
constraint. That's all
I think there's a solution for this, which is, loosely, to run the constraint
tests twice, conditionally. That is, run it the current fast way as usual, and
then only if there is a failure, run the tests again the slower way that keeps
track of things so we know where the failure is. Since we
On 11/17/15, Yuri 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?
>
It is a substantial change (basically
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?
Yuri
32 matches
Mail list logo
