> Bob wrote:
> Affinity is only a hint and not an assurance of anything.
> I solve the problem by bloating the schema with checks like this:
>
> foo integer default 1234
> check (typeof(foo) == 'integer'),
>
> This enforces that someone can't put "Hello world" where an integer
> belongs.
I don't get to control others schema in providing a generic gui
for users.
> Simon wrote:
> The problem, as far as SQLite is concerned, is that the column
> should have been declared "TEXT' not STRING. Then it works correctly:
> SQLite version 3.22.0 2017-12-05 15:00:17 [...]
> sqlite> CREATE TABLE a (col1 STRING);
> sqlite> INSERT INTO a (col1) VALUES ("3.0");
> sqlite> SELECT * from a;
> 3
> sqlite> DROP TABLE a;
> sqlite> CREATE TABLE a (col1 TEXT);
> sqlite> INSERT INTO a (col1) VALUES ("3.0");
> sqlite> SELECT * from a;
> 3.0
> But course the dev team cannot correct the understanding of 'STRING'
> for backward compatibility reasons. And using affinities rather than
> types means that feeding a string into a numeric column does not
> generate an error. So the programmer never figured out that using
> 'STRING' as a type didn't do the right thing.
> It's a problem with multiple causes. And it cannot be fixed in SQLite3.
Nor should it! Ryan provided ample argument for a light DB engine that
SQLite seems to satisfy for millions with FLEXIBILITY! If you wish a
more constrained light RDBMS then H2, HSQL, and others are available.
I'm just happy at least I get a column affinity for type checking to
give some sanity. Thank you.
danap.
_______________________________________________
sqlite-users mailing list
sqlite-users@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
