Don't hate on the author.
He heard a hype (sqlite), decided to try it to see what is it about, found out it's not for him really, wrote a bit blurb about it on his blog.
First Contact with SQLite
31–40 of 99 posts
Re: First Contact with SQLite
#32I use SQLite with my flask app - it has 5/6 users connected at once max - and its excellent. I've run into issues with alembic when running migrations occasionally . I had intended to move to something "beefier" but I see no point, unless I have to really scale up. Its straightforward, fast and easy for a casual DB programmer. Everything is wrapped in SQLAlchemy anyway, so all the complicated logic is in my Python co…
Hi. Interesting. Is there any special pattern to follow to make flask/sqlite work with multiple users? What about the deployment? Thanks.
Re: First Contact with SQLite
#33There are things that different databases are best for. This seems very blunty anti-sqlite, and things postgreSQL is the best, so I'd be interested to see a guide for (two things I've used sqlite for in the last week): * Using postgreSQL to store data in an iPhone app * Making a small python script which uses PostgreSQL, and then seeing how much work it is to send that to someone else, so they can use your work and e…
The author is both ignorant of SQLite history, and philosophy as also ignorant of the real use-cases SQLite solves for embedding a lightweight SQL-ish database into applications. Looking into his "about" section he worked mostly with web APIs (Stripe, Heroku) and is a self-proclaimed fan of Postgres. Maybe when he acquires some experience working with embedded applications without boatloads of resources available nor…
> embedding a lightweight SQL-ish database into applications
Current personal project is a game with crafting. I'm tired of games with limited inventory and no search / filters so I've been enjoying SQLite to manage that. The fact the db is a simple file is awesome to manage backups and you don't have to start a server to tinker with it: DB Browser, open file and you're done.
Also kudos to the team behind the Godot SQLite wrapper.
Re: First Contact with SQLite
#34Funny! Next do a "First contact with c++ as a Python developer without reading a manual"
Re: First Contact with SQLite
#35> On off days, I sometimes wonder if I’m bought into some narratives too strongly. Like, is Postgres really the world’s best database? Experiences like this certainly cement my conviction. Yes, it is. I find these 'different therefore wrong' takes to be immature. Yes, SQLite is idiosyncratic in comparison to other relational database engines. There are reasons behind those idiosyncrasies: SQLite is designed for other…
A lot of people get real obsessive about the "worlds best" thing, take a motorcycle for example, but them themselves lack the technical skill to actually require that level of equipment. Looking for the "best" whatever all the time is a sign you don't know what you are doing.
Re: First Contact with SQLite
#36Is there really an SQLite hype going on? I am getting a whiplash because of this pivot. From extreme complexity (Microservices! Kubernetes!) to extreme simplicity (Server-side rendering! Zero build! EC2!)
Re: First Contact with SQLite
#37> On off days, I sometimes wonder if I’m bought into some narratives too strongly. Like, is Postgres really the world’s best database? Experiences like this certainly cement my conviction. Yes, it is. I find these 'different therefore wrong' takes to be immature. Yes, SQLite is idiosyncratic in comparison to other relational database engines. There are reasons behind those idiosyncrasies: SQLite is designed for other…
The wacky approach to column types came from SQLite's origins of being closely integrated with Tcl. Knowing that doesn't somehow mean it was a good default worth carrying on for decades.
Firstly, while it's the default, it's not mandatory. As the author discovered you can use STRICT to make the columns typed, and types to be enforced.
The reason it remains unaltered by default is because one of the goals (and accomplishments) of SQLite is that the on-disk-data-file is completely backwards compatible, and cross-platform. This is a very important feature in some situations, and not lightly tossed aside because some old default or system is not in vogue anymore.
Re: First Contact with SQLite
#38Earlier quoted context omitted.
The author is both ignorant of SQLite history, and philosophy as also ignorant of the real use-cases SQLite solves for embedding a lightweight SQL-ish database into applications. Looking into his "about" section he worked mostly with web APIs (Stripe, Heroku) and is a self-proclaimed fan of Postgres. Maybe when he acquires some experience working with embedded applications without boatloads of resources available nor…
I didn't take this post to be overly negative, just a reflection of their experience in working with the tech. For anyone coming from a heavyweight SQL background, it is indeed pretty easy to be caught off guard with SQLite. That doesn't reduce its value of course.
the clue to the difference is, perhaps, however, right there in the name....
Re: First Contact with SQLite
#39I wish SQLite would officially fork itself and:
- So make breaking changes as needed. (it was first released in 2000 and has fantastic backwards compatibility, but hardware & OS have radically changes over the last 24 years - as well as use cases).
- put more focus on client/server use cases
- make things more 'strict' (types, checks, etc)
Note: I say this with tremendous love for SQLite. There's just so many attempts for companies & projects to morph SQLite what it's not designed for, that you might as well embarrass these use cases and make an official fork to support them.
Re: First Contact with SQLite
#40I think it is time for a real version/generation 4 of SQLite which drops some backwards compatibility (e.g. file format) and has 1) strict always enforced. 2) full datatypes (ints, floats, datetime, jsonb) 3) all "ALTER TABLE" functionality, even if it has to rewrite the table
Not to be contrary but... why?
Why make a new vesion that breaks compatibility with the old version?
Why make a new version just so it behaves like all the other database engines out there? Isn't having difference the point of having choices?