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

51–60 of 186 posts

Re: SQLite should have (Rust-style) editions

#51

Post by aidenn0 »

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…

RE: SQLITE_BUSY: I would replace "often" with "nearly always." On top of that, it's often not fixed even when pointed out. "This software only has one writer, so we don't need to handle SQLITE_BUSY" translates to me sending SIGSTOP to a process any time I want to run some queries against its database.

Re: SQLite should have (Rust-style) editions

#53

Post by eduction »

HN… for the love of god… please please stop trying to make SQLite be something it isn’t. Leave this poor project alone.

It’s a great tool if you want to give a local app its own database. If you need concurrent writes and full ACID guarantees of an industrial strength database, use an industrial strength database.

Yes, other databases will require you to read more manual pages and configure a service. Higher up front cost. Not “lightweight.” But given enough operating time there is a certain unarguable lightness to using the right tool for the job.

Re: SQLite should have (Rust-style) editions

#54

Post by lbourdages »

wang_li wrote: post #38
groundzeros2015 wrote: post #34

Earlier quoted context omitted.

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 p…

Well, it goes both ways. You'll see articles saying essentially "you don't need Postgres or any other fancy database, SQlite is enough" while ignoring the fact that some use-cases warrant a more conventional DB server.

Different tools for different situations!

Re: SQLite should have (Rust-style) editions

#55

Post by justinsaccount »

pstuart wrote: post #41
tptacek wrote: post #5

Earlier quoted context omitted.

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.

You are probably correct, but I imagine the SQLite team's dedication to backwards compatibility has things the way they are so that existing systems can user later versions a swap without worrying about changing the SQL using it.

The entire point of "SQLite should have editions" is so that projects can opt into a set of modern defaults for 2026 and not get all of those backwards compatible decisions from 20 years ago.

Re: SQLite should have (Rust-style) editions

#56

Post by usefulcat »

pstuart wrote: post #41
tptacek wrote: post #5

Earlier quoted context omitted.

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.

You are probably correct, but I imagine the SQLite team's dedication to backwards compatibility has things the way they are so that existing systems can user later versions a swap without worrying about changing the SQL using it.

If they’re opt-in, how could the new defaults be a problem for backwards compatibility?

Re: SQLite should have (Rust-style) editions

#58

Post by bruce511 »

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.

>> you delete an entity and it's unique ID gets reused? Is that a good idea?

That's default behavior, but it can be altered when creating a table. See;

https://sqlite.org/autoinc.html

Re: SQLite should have (Rust-style) editions

#59

Post by yomismoaqui »

eduction wrote: post #53

HN… for the love of god… please please stop trying to make SQLite be something it isn’t. Leave this poor project alone. It’s a great tool if you want to give a local app its own database. If you need concurrent writes and full ACID guarantees of an industrial strength database, use an industrial strength database. Yes, other databases will require you to read more manual pages and configure a service. Higher up front…

Just by its testing and its number of installations (real world testing) you could consider SQLite being more "industrial strength" than any other DB on the market.

- https://sqlite.org/testing.html

- https://sqlite.org/mostdeployed.html

EDIT: added links

Re: SQLite should have (Rust-style) editions

#60

Post by [deleted] »

souvlakee wrote: post #29

Sadly, the ORM layer lags here: Drizzle has no way to declare STRICT tables. The request has been open since March 2023 (issue #202, now discussion #2435) and didn't make the v1.0 beta either. The only workaround is hand-appending STRICT to generated migration SQL, which doesn't work at all if you use `drizzle-kit push`. https://github.com/drizzle-team/drizzle-orm/discussions/2435

[deleted]
Post reply on HN