SQLite really shines when compared to running a database in a separate server from the app. A few observations (considering the blog post skips numerous details): ![]() also because of projects like PostGIS and support for more complex setups, like custom data types, more advanced scripting language for in-database processing and whatnot? And yet, it's still a decent option, has good tooling (MySQL Workbench is great), is widely supported and backs a significant amount of production systems out there.ĭo people just view it as old/legacy, or is there the belief that for many use cases PostgreSQL might simply be the better option, e.g. Though it's also curious, because you never hear a lot about MySQL or MariaDB (comparatively, in my subjective opinion) on HN or many other places for that matter. Of course, SQLite might be the best choice for embedded or local usage, they even have this lovely page about using it as an application file format: Īnd PostgreSQL might scale better for multiple writers and situations where you need it on a separate VM/server/container that might be shared between different apps through a network connection of some sort. You know, apart from some of the details in regards to what data types to better use etc., I think that both PostgreSQL and SQLite are excellent choices for most use cases! ORMs are a nice crutch to get started, but that's it. It's the same old story: dev meets ORM, ORM makes things easy (at first), dev needs more power, dev bumps up against ORM's limitations, dev works around those limitations, dev now has a frankenapp, dev wants to switch RDBMSes but can't, or dev wants to ditch the ORM but it's a lot of work. This is real life with a multi-RDBMS ORM: the promise of RDBMS neutrality always fails in some way as the differences between the RDBMSes bleed through the ORM's abstractions, and that bleeding occurs the moment you need more expressive power than the ORM provides out of the box for dead-simple apps. Nowadays, of course, SQLite3 has JSON support, and PG has JSON and JSONB, and so it should be possible to fix that, but it would be quite the migration, so no one bothers. The main problem is that the app in question needed something like SQLite3's `ANY` type in PG but all there was back then was `hstore` (and even now, all there is is `hstore`, `json`, and `jsonb`), so `hstore`-using code metastasized and no one kept the SQLite3 bits working. My knowledge on ssh keys and server stuff is pretty limited, so I might have misunderstood how all that works.I work with (and occasionally have made contributions to) a proprietary Rails (ORM) app that in principle supports SQLite3 and PG but, in practice, left SQLite3 behind long ago. I wanted to see if I can connect via ssh without using TablePlus with ssh which errors with exec: "\nexport": executable file not found in $PATHĬonnection to. It has not been exposed when issuing ssh credentials. TablePlus wants the private key, but I have no idea where to get that. Create ssh keys with fly ssh issue -agentĪnd now I am stuck.Load the generated config with wireguard.Create a wireguard config ( fly wireguard create).Connecting via fly ssh console works well, but I can not do that with TablePlus, so I need to be able to access it with ssh directly. My idea was to make the app locally accessible through wireguard and then use ssh to connect to it. ![]() Now I am trying to connect to it over ssh to manage my db with TablePlus. I have an app running with an SQLite db on a volume.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |