upvote

points

by giancarlostoro8 days ago |
comments
upvoteby dotancohen8 days ago|
next
[-]
I laughed at the SQLite 4.0 release notes. They're on 3.51.x now. Another major release a decade from now sounds just about right.
reply
upvoteby ryanisnan8 days ago|
parent|
next
[-]
That one got me as well - some pretty wild stuff about prompting the compiler, starship on the moon, and then there's SQLite 4.0
reply
upvoteby ikerrin18 days ago|
parent|
[-]
You can criticize it for many things but it seems to have comedic timing nailed.
reply
upvoteby ncruces8 days ago|
parent|
prev|
next
[-]
The promise is backwards compatibility in the file format and C API until 2050.

https://sqlite.org/lts.html

reply
upvoteby rtkwe8 days ago|
parent|
prev|
next
[-]
I wouldn't be surprised if it went towards the LaTeX model instead where there's essentially never another major version release. There's only so much functionality you need in a local only database engine I bet they're getting close to complete.
reply
upvoteby dotancohen8 days ago|
parent|
[-]
I'd love to see more ALTER TABLE functionality, and maybe MERGE, and definitely better JSON validation. None of that warrants a version bump, though.

You know what I'd really like, that would justify a version bump? CRDT. Automatically syncing local changes to a remote service, so e.g. an Android app could store data locally on SQLite, but also log into a web site on his desktop and all the data is right there. The remote service need not be SQLite - in fact I'd prefer postgres. The service would also have to merge databases from all users into a single database... Or should I actually use postgres for authorisation but open each users' data in a replicated SQLite file? This is such a common issue, I'm surprised there isn't a canonical solution yet.

reply
upvoteby rtkwe8 days ago|
parent|
[-]
I think the unified syncing while neat is way beyond what SQLite is really meant for and you'd get into so many niche situations dealing with out of sync master and slave 'databases' it's hard to make an automated solution that covers them effectively unless you force the schema into a transactional design for everything just to sort out update conflicts. eg: Your user has the app on two devices uses one while it doesn't have an internet connection altering the state and then uses the app on another device before the original has a chance to sync.
reply
upvoteby dotancohen8 days ago|
parent|
[-]
Yes, it's a difficult problem. That's why I'd like it to be wrapped in a nice package away from my application logic.

Even a product that does this behind the scenes, by wrapping SQLite and exposing SQLite's wrapped interface, would be great. I'd pay for that.

reply
upvoteby 8 days ago|
parent|
prev|
next
[-]
deleted
reply
upvoteby Andrex8 days ago|
parent|
prev|
[-]
If it had been about GIMP I would have laughed harder.
reply
upvoteby dotancohen8 days ago|
parent|
[-]
Be reasonable. It's only looking forward a single decade.
reply
upvoteby schaum8 days ago|
prev|
next
[-]
Every few years I stumble across the same java or mongodb issue. I google for it, find it on stackoverflow, and figure that it was me who wrote that very answer. Always have a good laugh when it happens.

Usually my memory regarding such things is quite well, but this one I keep forgetting, so much so that I don't remember what the issue is actually about xD

reply
upvoteby vidarh8 days ago|
prev|
[-]
I've run into my own comments or blog posts more often than I care to admit...
reply
upvoteby james_marks8 days ago|
parent|
[-]
Several decades into this, I assume all documentation I write is for my future self.

Beautifully self-serving while being a benefit to others.

Same thing with picking nails up in the road to prevent my/everyone’s flat tire.

reply