Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

SQLite should have (Rust-style) editions

mort.coffee

Post reply on HN
Print view View original

101–110 of 186 posts

Re: SQLite should have (Rust-style) editions

#101

Post by scadge »

bambax wrote: post #95

> I don't think I need to explain why it's a bad idea for a database to be so careless about data validation. Well, loose typing can be extremely useful, and having a type of "ANY" would not replace it. I have built recently an accounting reconciliation system to find discrepancies in data coming from a large variety of sources: some from proper database engines (MySQL MariaDB), but most from proprietary systems that…

> I don't think I need to explain why it's a bad idea for a database to be so careless about data validation.

...Meanwhile MongoDB being successful for years with no sign of decline.

Re: SQLite should have (Rust-style) editions

#102

Post by Ekaros »

lenkite wrote: post #77
Thaxll wrote: post #27

SQLite gets so much praise here but when you start using it, you realize quickly how bad it is, the type system is by default very limited and dangerous. It's like comparing old php with a strongly typed language. There is not even a date type...

I agree with you. There are 2 dozen foot-guns to be kept in mind. And discovered a new footgun regarding multi-byte strings and NUL handling today on HN. SQLite became popular because it was the only free and open-source choice 2 decades ago. Now there are other type-safe and robust choices.

It is very simple. Which means fast to setup in dev environment for local testing. Which makes first version very easy. And then people just keep fixing that one.

Still I quite a lot of question the use on servers if you have decided that I need a database.

Not that there isn't more valid use cases like local storage or self-contained information transfer for specific use.

Re: SQLite should have (Rust-style) editions

#103

Post by xigoi »

lenkite wrote: post #77
Thaxll wrote: post #27

SQLite gets so much praise here but when you start using it, you realize quickly how bad it is, the type system is by default very limited and dangerous. It's like comparing old php with a strongly typed language. There is not even a date type...

I agree with you. There are 2 dozen foot-guns to be kept in mind. And discovered a new footgun regarding multi-byte strings and NUL handling today on HN. SQLite became popular because it was the only free and open-source choice 2 decades ago. Now there are other type-safe and robust choices.

What are other choices for FOSS serverless relational databases? I’ve been looking everywhere and couldn’t find anything.

Re: SQLite should have (Rust-style) editions

#104

Post by PunchyHamster »

I think the solution is for author to use PostgreSQL

Those choices were made for specific reasons that make sense in embedded environment and when backward compatibility is no.1 concern.

But I wouldn't mind feature-sets. Editions are too wide of a concept and tell you nothing at glance what a given code is doing, "enable 2026 set of features" tells me nothing on what is actually enabled.

Re: SQLite should have (Rust-style) editions

#105

Post by mickeyp »

bambax wrote: post #95

> I don't think I need to explain why it's a bad idea for a database to be so careless about data validation. Well, loose typing can be extremely useful, and having a type of "ANY" would not replace it. I have built recently an accounting reconciliation system to find discrepancies in data coming from a large variety of sources: some from proper database engines (MySQL MariaDB), but most from proprietary systems that…

Your... solution to bad ETL data is to go "let's keep it this way"?

You can already "store whatever you want" in a serious database that respects types by default. It's called a blob or if you must, a text/varchar.

Re: SQLite should have (Rust-style) editions

#106

Post by LtWorf »

echoangle wrote: post #87
LtWorf wrote: post #81

Earlier quoted context omitted.

Where do you see that they get reused from that link?

> The normal ROWID selection algorithm described above will generate monotonically increasing unique ROWIDs as long as you never use the maximum ROWID value and you never delete the entry in the table with the largest ROWID. If you ever delete rows or if you ever create a row with the maximum possible ROWID, then ROWIDs from previously deleted rows might be reused when creating new rows and newly created ROWIDs might…

What should it do once you hit MAXINT? Honest question…

Re: SQLite should have (Rust-style) editions

#107

Post by amluto »

kccqzy wrote: post #10
tptacek wrote: post #8

Earlier quoted context omitted.

For some of these pragmas you have the same issue with or without "editions", right? Busy timeout is per-connection. And then: if you're running in WAL mode, you, the user, have to know that, or risk messing up the database by copying just the .db file rather than vacuuming-into.

Editions make the problem worse by requiring the version not only to support the underlying pragmas but also to understand the edition mapping. Example: PRAGMA foo=1 is introduced in 2027. PRAGMA edition=2030 implies this foo pragma. Now you unnecessarily lock out three years worth of releases.

There’s no need to store the literal edition in the DB file. Instead the edition could be a library construct that sets appropriate flags. So if you set edition 2026 you get WAL, etc.

Re: SQLite should have (Rust-style) editions

#108

Post by amluto »

bambax wrote: post #95

> I don't think I need to explain why it's a bad idea for a database to be so careless about data validation. Well, loose typing can be extremely useful, and having a type of "ANY" would not replace it. I have built recently an accounting reconciliation system to find discrepancies in data coming from a large variety of sources: some from proper database engines (MySQL MariaDB), but most from proprietary systems that…

Are you saying that you have an application where you want the loose-typing-with-integer-affinity semantics for a column (or some other particular affinity)? It would be entirely reasonable to have a specific type for each loose-with-affinity variant. But I don’t think those should be the default.

Re: SQLite should have (Rust-style) editions

#109

Post by echoangle »

LtWorf wrote: post #106
echoangle wrote: post #87

Earlier quoted context omitted.

> The normal ROWID selection algorithm described above will generate monotonically increasing unique ROWIDs as long as you never use the maximum ROWID value and you never delete the entry in the table with the largest ROWID. If you ever delete rows or if you ever create a row with the maximum possible ROWID, then ROWIDs from previously deleted rows might be reused when creating new rows and newly created ROWIDs might…

What should it do once you hit MAXINT? Honest question…

I don’t think people are criticizing the MAXINT thing. The problem is that IDs are already reused when you create 10 rows, delete 5 and then make a new one. Normal DB engines just keep counting afaik so the new ID will still be one that has never been used before.

Re: SQLite should have (Rust-style) editions

#110

Post by PunchyHamster »

tptacek wrote: post #16
kccqzy wrote: post #10

Earlier quoted context omitted.

Editions make the problem worse by requiring the version not only to support the underlying pragmas but also to understand the edition mapping. Example: PRAGMA foo=1 is introduced in 2027. PRAGMA edition=2030 implies this foo pragma. Now you unnecessarily lock out three years worth of releases.

I don't see how you don't have the pragma compatibility problem either way. The edition proposal captures a bunch of behaviors that already exist.

feature-set would be a better idea, because it is more explicit on what you are enabling
Post reply on HN