Thanks for all the responses - I seem to have opened up a can of worms!
Looking into his further, I see differences in how constraint failures are
reported. In the case of a NOT NULL constraint, I got an error
". may not be NULL". In the case of a UNIQUE constraint,
the error was "column is not
On Mar 1, 2012, at 4:08 PM, Marc L. Allen wrote:
>> I don't understand why you need to have constraint declaration. Do you
>> have some kind of parser of table definition and your application
>> relies on it to find all constraints that SQLite enforces?
>
> I believe it irks him that he cannot,
On Mar 1, 2012, at 3:13 PM, Igor Tandetnik wrote:
>> I would if I could. Unfortunately, in SQLite, in the case of unique
>> constraints, this cannot be done as far as I know. Or?
>
> Just create a unique index, in lieu of unique constraint.
I would rather see SQLite support some sort of USING
> I don't understand why you need to have constraint declaration. Do you
> have some kind of parser of table definition and your application
> relies on it to find all constraints that SQLite enforces?
I believe it irks him that he cannot, in his own mind, provide a complete table
definition. I
On Thu, Mar 1, 2012 at 9:01 AM, Petite Abeille wrote:
> On Mar 1, 2012, at 2:51 PM, Pavel Ivanov wrote:
>
>>> (2) If one create an unique, named index, one cannot use an unique
>>> constraint as there is no way to add constraints after the table creation
>>> (i.e. no alter add constraint …).
>>
Petite Abeille wrote:
> On Mar 1, 2012, at 2:27 PM, Igor Tandetnik wrote:
>
>> If you want to refer to an index by name, I suggest you explicitly create
>> this index with the name of your choosing.
>
> I would if I could. Unfortunately, in SQLite, in the case of unique
> constraints, this can
On Mar 1, 2012, at 2:51 PM, Pavel Ivanov wrote:
>> (2) If one create an unique, named index, one cannot use an unique
>> constraint as there is no way to add constraints after the table creation
>> (i.e. no alter add constraint …).
>
> You don't need to create a unique constraint when you crea
> (2) If one create an unique, named index, one cannot use an unique constraint
> as there is no way to add constraints after the table creation (i.e. no alter
> add constraint …).
You don't need to create a unique constraint when you created a unique
index. Unique index implies that you can't i
On Mar 1, 2012, at 2:27 PM, Igor Tandetnik wrote:
> If you want to refer to an index by name, I suggest you explicitly create
> this index with the name of your choosing.
I would if I could. Unfortunately, in SQLite, in the case of unique
constraints, this cannot be done as far as I know. Or?
Petite Abeille wrote:
> For example, one can define a named unique key constraint:
>
> constraint header_uk unique( name ),
>
> This will result in SQLite automagically creating an unique index to support
> the constraint. What's the name of that index? No
> one knows for sure, as it's aut
On Feb 29, 2012, at 10:28 PM, Richard Hipp wrote:
> But that would require a lot of
> extra code space, which is not "lite".
There is a fine line between being parsimonious and cutting corners.
For example, one can define a named unique key constraint:
constraint header_uk unique( name )
On Mar 1, 2012, at 12:20 AM, Roger Binns wrote:
> There is a reason developers have gone to the trouble of naming their
> constraints!
Indeed. All these constraint names are meant to convey information. They are
not decorative.
___
sqlite-users maili
Me too. Either as a new standard way of working, or as something
which can be turned on and off with a PRAGMA. I accept that SQLite is
meant to be fast, but having SQLite spit out which check was violated
will result in my app running faster and more dependably than when I
build the same lo
On 1 Mar 2012, at 12:38am, Mario Becroft wrote:
> Just adding my voice to the choir. The constraints are of limited value
> if you can't tell which one failed, and the system is not much more
> 'lite' if the constraints have to be duplicated using CHECK clauses
> anyway.
Me too. Either as a ne
Just adding my voice to the choir. The constraints are of limited value
if you can't tell which one failed, and the system is not much more
'lite' if the constraints have to be duplicated using CHECK clauses
anyway.
--
Mario Becroft
___
sqlite-users ma
On 01/03/2012, at 8:28 AM, Richard Hipp wrote:
> SQLite implements CHECK constraints by concatenating all expressions from all
> CHECK constraints on the table using AND and then evaluating the resulting
> boolean to see if it is false. If it is false, an SQLITE_CONSTRAINT error is
> raised.
>
I've also tried also using it in an SQL transaction (eg a batch import script),
but SQLite doesn't allow it. So, in a transaction, one approach I've used is to
create a temp table, a temp trigger and then insert some test data just to be
able to use the raise function to abort the transaction an
On 01/03/2012, at 4:22 AM, Pete wrote:
> I would like to include as much error checking as possible in my database
> schema.
That's an admirable aim. The whole point of constraints is to bring the error
checking as close to the data model as possible.
> The problem I have is that the error mes
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 29/02/12 13:28, Richard Hipp wrote:
>> We *could* keep track of each separate CHECK expression and remember
>> the constraint name and evaluate each expression separately and
>> output a customized error message for each failure. But that would
>>
On Wed, Feb 29, 2012 at 2:25 PM, Roger Binns wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> On 29/02/12 09:22, Pete wrote:
> > The problem I have is that the error messages that come back from
> > constraint violations are extremely generic (e.g. "constraint failed")
> > and would m
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 29/02/12 09:22, Pete wrote:
> The problem I have is that the error messages that come back from
> constraint violations are extremely generic (e.g. "constraint failed")
> and would mean nothing to a user.
An issue first reported in 2006:
http:/
21 matches
Mail list logo
