Earlier quoted context omitted.
Well, I would also like a proper datetime/timestamp datatype that isn't just a string.
Someone should fork it in Rust using Claude and rename it SQRite. Strict type all the things.
Why not ~Zoidberg~ Zig?
Prefer strict tables in SQLite
61–70 of 188 posts
Re: Prefer strict tables in SQLite
#62Earlier quoted context omitted.
Which seems reasonable. And those who care deeply will have no problem configuring it the specific way they want on their own project. Win-win.
Unless you don't know it exists of course
Is it better to learn that it exists through surprise, by way of an engine upgrade suddenly changing the behavior of the software you wrote while in the bliss of your ignorance?
Re: Prefer strict tables in SQLite
#63Earlier quoted context omitted.
Well, I would also like a proper datetime/timestamp datatype that isn't just a string.
Someone should fork it in Rust using Claude and rename it SQRite. Strict type all the things.
A large portion of the tests are closed source unfortunately which would make it tough to create a port.
Re: Prefer strict tables in SQLite
#64Earlier quoted context omitted.
Which seems reasonable. And those who care deeply will have no problem configuring it the specific way they want on their own project. Win-win.
Well no, the software should be configured in its best state by default. Otherwise you run into the case where the user has to read the documentation like a legal contract to find all the footguns that need disabling. If STRICT is strictly better, than that should be the default. The correct approach here would be for the user to pass along a "compatibility version" tag when first connecting, which would set the defa…
I didn’t get the sense from TFA that STRICT is strictly better, only that it’s how this person prefers to operate in their time and context and experience.
At some level, shouldn’t choices where one option is strictly better not surface as configurable choices at all?
If I have to memorize sets of behaviors by “compatibility version,” don’t I now have to remember lots of sets of particular footguns, across time and across systems that I work on (or parachute into)?
Re: Prefer strict tables in SQLite
#65Re: Prefer strict tables in SQLite
#66I had a UUID (partly?) mis-converted to a number if the UUID started w (from memory) something like 08123… which was parsed as octal. Confusing, annoying, fixed w “strict” and a complete table rebuild.
That was your language's driver "helping" you. There is no SQLite octal type.
I'll see if i can find the case - my description was a bit hand-wavy because it was a while ago, and just drawing on memory -- not that your explanation couldn't be true, but I thought I exercised that possibility. For your part, you'll remain sceptical it wasn't the driving language when I tell you it was Tcl, which is indeed the origin of this "manifest type" we're discussing :)
Re: Prefer strict tables in SQLite
#67Earlier quoted context omitted.
Unless you don't know it exists of course
Is it better to learn that it exists through surprise , by way of an engine upgrade suddenly changing the behavior of the software you wrote while in the bliss of your ignorance?
... than by surprise, when you find your integer column contains "[object Object]"? Jokes aside, breaking backwards compatibility is obviously a non-starter.
Re: Prefer strict tables in SQLite
#68Earlier quoted context omitted.
Which seems reasonable. And those who care deeply will have no problem configuring it the specific way they want on their own project. Win-win.
Unless you don't know it exists of course
Developing with sqlite isn't quite like developing software that generically works against an ODBC or JDBC interface with minimal tweaking. You probably will want to peruse the documentation.
Re: Prefer strict tables in SQLite
#69Earlier quoted context omitted.
> This document describes the support for SQL foreign key constraints introduced in SQLite version 3.6.19 (2009-10-14).
That quote leaves open whether SQLite "pretended" to support foreign keys by allowing to create tables with them, but didn't implement them. Otherwise, I don't see the compatibility problem.
Yes.
From the release notes:
2002-06-17 (2.5.0), "Parse (but do not implement) foreign keys."
At one point there was also a tool which would generate trigger rules to enforce foreign key constraints. (2008 Oct 15 (3.6.4), Added the source code and documentation for the genfkey program for automatically generating triggers to enforce foreign key constraints)
Re: Prefer strict tables in SQLite
#70the only thing that sucks about SQLite is migrations.
Yes, the process at https://www.sqlite.org/lang_altertable.html is super risky - 12 steps and a giant CAUTION sidebar about the data loss possible if you do it incorrectly. They DO include a nice section at the bottom about why these limitations exist, but I wish they would make the process easier.
We use this for migrations:
https://david.rothlis.net/declarative-schema-migration-for-s...
Discussed here: https://news.ycombinator.com/item?id=31249823
But it would be a lot better if it were built in.