4 ms·

If a tool can do something automatically (type checking, other constraints) then it is often nicer to let the tool do it for you, instead of doing it manually.

If a tool can do something automatically (type checking, other constraints) then it is often nicer to let the tool do it for you, instead of doing it manually. Sqlite is very unusual in that it uses static type declarations, but it doesn't actually enforce them. That can be quite unexpected. See also: "Why wouldn't you check the type of your variable before passing it to a function?"

nojito 6y ago
This doesn't make any sense. Why do you want to fail on insertion and not fail during the acquisition step itself? You have to write tons of wrappers and boilerplate to handle those insertion failures instead of cleaning up your data during acquisition. >See also: "Why wouldn't you check the type of your variable before passing it to a function?" Completely different workflow. The types of data is known during acquisition.
- LunaSea 6y ago
  But programming language types are different than SQLite types so that's already a mismatch that could introduce errors. Also, there is much more boilerplate in man-in-the-middle-ing each database query to validate data rather than have a single entry point which validate the data types which is the database. Also, using any in-database feature like functions or triggers should also have this security baked in but won't due to SQLite's missing validation.
  - nojito 6y ago
    >But programming language types are different than SQLite types so that's already a mismatch that could introduce errors. No...because they can be boiled down to the sqlite types and again it doesn't matter if you properly validate the data on insertion which you should be doing. >Also, there is much more boilerplate in man-in-the-middle-ing each database query to validate data rather than have a single entry point which validate the data types which is the database. No...you don't validate queries..you validate insertion >Also, using any in-database feature like functions or triggers should also have this security baked in but won't due to SQLite's missing validation. You don't need to depend on it...because you validated on insertion.

nojito 6y ago

This doesn't make any sense. Why do you want to fail on insertion and not fail during the acquisition step itself? You have to write tons of wrappers and boilerplate to handle those insertion failures instead of cleaning up your data during acquisition. >See also: "Why wouldn't you check the type of your variable before passing it to a function?" Completely different workflow. The types of data is known during acquisition.

LunaSea 6y ago
But programming language types are different than SQLite types so that's already a mismatch that could introduce errors. Also, there is much more boilerplate in man-in-the-middle-ing each database query to validate data rather than have a single entry point which validate the data types which is the database. Also, using any in-database feature like functions or triggers should also have this security baked in but won't due to SQLite's missing validation.
- nojito 6y ago
  >But programming language types are different than SQLite types so that's already a mismatch that could introduce errors. No...because they can be boiled down to the sqlite types and again it doesn't matter if you properly validate the data on insertion which you should be doing. >Also, there is much more boilerplate in man-in-the-middle-ing each database query to validate data rather than have a single entry point which validate the data types which is the database. No...you don't validate queries..you validate insertion >Also, using any in-database feature like functions or triggers should also have this security baked in but won't due to SQLite's missing validation. You don't need to depend on it...because you validated on insertion.