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

31–40 of 186 posts

Re: SQLite should have (Rust-style) editions

#31

Post by Rendello »

mort96 wrote: post #30
Rendello wrote: post #28

Earlier quoted context omitted.

> SQLite is slightly different from Rust in that it is a data container. I think this is the key. From sqlite.org [1]: > [Since 2004], the file format has been fully backwards compatible. > By "backwards compatible" we mean that newer versions of SQLite can always read and write database files created by older versions of SQLite. It is often also the case that SQLite is "forwards compatible", that older versions of S…

The answer to the question "What happens when you import a file from edition (Y)" should, ideally, be exactly the same as the answer to the question "What happens when you import a file created with parameters foo, bar and baz set to values a, b and c". There's really nothing new here. Some parameters are properties of the database file itself, such as (I believe) journal_mode. These parameters probably result in iss…

A lot of this discussion mirrors the SQLite forum's discussion on the never-implemented "PRAGMA strict":

https://sqlite.org/forum/forumpost/1b9d073a37ca5998

I personally find this idea interesting and would like if SQLite meaningfully moved away from Postel's Law.

Re: SQLite should have (Rust-style) editions

#32

Post by kccqzy »

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...

It’s not as bad since you can always use a powerful programming language with a good type system that avoids type errors at the SQL level. You can build good abstractions in your programming language.

Re: SQLite should have (Rust-style) editions

#33

Post by groundzeros2015 »

sethev wrote: post #4

Interesting idea - I like seeing a list of pet-peeves followed by a proposal for a straightforward way to have a set of 'alternative defaults' that remains backwards compatible. If you don't want to opt in, don't run the new PRAGMA edition = 2026. Too often it's just a list of issues and a wish that everyone else will change. In (mild) defense of SQLITE_BUSY - busy_timeout just tells sqlite to sleep and retry up to t…

Yep. The whole locking database thing is this persistent myth about SQLite. All databases lock on write, it’s a question of the granularity of the lock. Multiple writers simply take turns.

Re: SQLite should have (Rust-style) editions

#34

Post by groundzeros2015 »

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...

SQLite competes with fopen. Not Postgres

Re: SQLite should have (Rust-style) editions

#35

Post by deepsun »

andai wrote: post #17

In the first example, there's a a second thing that surprised me: you delete an entity and it's unique ID gets reused? Is that a good idea? I guess if foreign keys are handled properly then that's not a problem by definition? But it sounds wrong somehow.

I think that's a security vulnerability.

If a parent table ID gets reused, then it's a potential to expose data to a wrong user -- security broked.

Re: SQLite should have (Rust-style) editions

#37

Post by DANmode »

groundzeros2015 wrote: post #33
sethev wrote: post #4

Interesting idea - I like seeing a list of pet-peeves followed by a proposal for a straightforward way to have a set of 'alternative defaults' that remains backwards compatible. If you don't want to opt in, don't run the new PRAGMA edition = 2026. Too often it's just a list of issues and a wish that everyone else will change. In (mild) defense of SQLITE_BUSY - busy_timeout just tells sqlite to sleep and retry up to t…

Yep. The whole locking database thing is this persistent myth about SQLite. All databases lock on write, it’s a question of the granularity of the lock. Multiple writers simply take turns.

They don’t know by now, honestly they don’t want to know.

Re: SQLite should have (Rust-style) editions

#38

Post by wang_li »

groundzeros2015 wrote: post #34
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...

SQLite competes with fopen. Not Postgres

It’s curious how many people don’t understand what SQLite is and its intended feature set. They get huffy that it’s not a full client server model with multimaster clustering across 8 data centers on 12 continents plus New Zealand with realtime synchronous replication.

It’s a product that allows you to do sql like things without a database server. If you need to have database server behavior, you’re using the wrong product.

Re: SQLite should have (Rust-style) editions

#40

Post by doc_ick »

tptacek wrote: post #5
sethev wrote: post #4

Interesting idea - I like seeing a list of pet-peeves followed by a proposal for a straightforward way to have a set of 'alternative defaults' that remains backwards compatible. If you don't want to opt in, don't run the new PRAGMA edition = 2026. Too often it's just a list of issues and a wish that everyone else will change. In (mild) defense of SQLITE_BUSY - busy_timeout just tells sqlite to sleep and retry up to t…

This isn't so much a list of pet peeves as it is the almost universal way people that work seriously with SQLite configure the database. It's reasonable to suggest that the alternative settings for each of these suggestions is probably the wrong default for 2026.

I’d say these are reasonable settings for most uses. Though do you know of surveys that back this up? I don’t mean to nit pick too much, I’d just like to see common uses and the data.
Post reply on HN