Hacker News Reader

Comment by qwertyuiop924 | Hacker News Reader

What's the safety issue? Will your data corrupt, or are your types just not 100% guaranteed?

Because I can live with the ladder: weak types suck in programming languages, but are okay in DBs, and the types get verified multiple times on their way in and out of the DB in most systems.

Besides, it won't mangle your data. Unlike some DBs that I could name...

View on HN

I don't think it would mangle your data directly, but it could lead to incorrect results since there is a degree of mystery from query to query. You should definitely base a conclusion on their words and not mine.

https://www.sqlite.org/datatype3.html

Thanks for the link. Yeah, it's as I remember: type affinities will convert to their type if possible, and if not... well, you get out what you put in.

The reason most people don't complain about this is that it's a far from common issue to totally miswrite your SQL statements so badly that you wind up mixing up columns. And when you do, it's usually detected pretty fast.

Since 3.3 you can use check constraints to enforce things, but I don't know what kind of performance impact that has.

You also need to enable them each time you connect.

Really? dang that's terrible. I thought they'd stay that way as part of the table schema. Glad I normally use an ORM that'll take care of the type checking ahead of time.

Apparently, they actually do stay around.

No you don't. CHECK constraints always work.

Maybe you are thinking about foreign key constraints, which for backwards compatibility are off by default, unless you use a compile-time option to make then on by default.

Reply on news.ycombinator.com