Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Flyweight: A Node.js ORM Specifically for SQLite

github.com

Post reply on HN
Print view View original

31–40 of 45 posts

Re: Flyweight: A Node.js ORM Specifically for SQLite

#31

Post by lupusreal »

dumbo-octopus wrote: post #29
thatwasunusual wrote: post #25

Great work! But why would anyone use an ORM that is specifically to one database? For me, using an ORM is the ability to switch between databases, specifically SQLite for testing and PostgreSQL for production, without having to change any logic.

Curious how that works? Do you not use any features of Postgres that aren't present in SQLLite? If so, why not just SQLite everywhere? Alternatively, why not spin up an ephemeral PG container for testing? Seems odd to not practice how you play to that extent.

It virtually never works. ORMs letting you change databases is something ORM proponents like to suggest but very rarely does it work without a ton of work (nullifying the point.)

Re: Flyweight: A Node.js ORM Specifically for SQLite

#32

Post by thatwasunusual »

dumbo-octopus wrote: post #29
thatwasunusual wrote: post #25

Great work! But why would anyone use an ORM that is specifically to one database? For me, using an ORM is the ability to switch between databases, specifically SQLite for testing and PostgreSQL for production, without having to change any logic.

Curious how that works? Do you not use any features of Postgres that aren't present in SQLLite? If so, why not just SQLite everywhere? Alternatively, why not spin up an ephemeral PG container for testing? Seems odd to not practice how you play to that extent.

I prefer to only use ORMs that can be used "everywhere." PostgreSQL needs to be used on production for performance; SQLite is good, but not _that_ good :), but it's perfect for testing things locally.

Re: Flyweight: A Node.js ORM Specifically for SQLite

#33

Post by thatwasunusual »

lupusreal wrote: post #31
dumbo-octopus wrote: post #29

Earlier quoted context omitted.

Curious how that works? Do you not use any features of Postgres that aren't present in SQLLite? If so, why not just SQLite everywhere? Alternatively, why not spin up an ephemeral PG container for testing? Seems odd to not practice how you play to that extent.

It virtually never works. ORMs letting you change databases is something ORM proponents like to suggest but very rarely does it work without a ton of work (nullifying the point.)

I have been DB-agnostic for 20 years, and it has never been a problem, except when I meet ORMs or "SQL-based solutions" (usually procedures and/or views) that are specific to one database.

Luckily, I'm in a position where I can choose for our clients, so... :)

Re: Flyweight: A Node.js ORM Specifically for SQLite

#34

Post by basil-rash »

thatwasunusual wrote: post #33
lupusreal wrote: post #31

Earlier quoted context omitted.

It virtually never works. ORMs letting you change databases is something ORM proponents like to suggest but very rarely does it work without a ton of work (nullifying the point.)

I have been DB-agnostic for 20 years, and it has never been a problem, except when I meet ORMs or "SQL-based solutions" (usually procedures and/or views) that are specific to one database. Luckily, I'm in a position where I can choose for our clients, so... :)

Oh I see MySQL added functional indexing in 8.0.13, that’s the main thing I would miss from Postgres. Partial indexes are also nice to have, but I suppose a sophisticated enough ORM could map them to functional ones, at least in so far as testing is concerned. The memory use would likely be much higher than a proper partial index.

Re: Flyweight: A Node.js ORM Specifically for SQLite

#35

Post by AlexErrant »

evnix wrote: post #2

Really like the singular and plural name approach. API is a real joy to use. reminds of kysely typed SQL builder which was perfect to use with postgres in one of my previous projects. I currently am working on a sqlite based project but based on Tauri's sqlite connector which is plain SQL. Is there anyway I can make use of Flyweight in Tauri based projects?

Probably not, since it has a dependency on sqlite3 which also depends on node.

I just use kysely for my sqlite-in-browser project.

Re: Flyweight: A Node.js ORM Specifically for SQLite

#36

Post by jmull »

Scarbutt wrote: post #30
jmull wrote: post #24

Earlier quoted context omitted.

It seems like with kysely, you write your SQL in javascript/typescript? That's a big fat ugly anti-pattern, IMO.

you write your SQL in javascript/typescript? That's a big fat ugly anti-pattern, IMO. Any other solution sucks more.

You could write your SQL in SQL.

Re: Flyweight: A Node.js ORM Specifically for SQLite

#37

Post by lroal »

thatwasunusual wrote: post #25

Great work! But why would anyone use an ORM that is specifically to one database? For me, using an ORM is the ability to switch between databases, specifically SQLite for testing and PostgreSQL for production, without having to change any logic.

You should try https://github.com/alfateam/rdb

It is database agnostic. It works with sqlite, mssql, mysql, postgres, oracle, and sapase.

It gives you full intellisense without code generation - even when running pure javascript.

You can run it from the browser in a secure manner, as you can host it in express js via adapter.

I am the author.

Re: Flyweight: A Node.js ORM Specifically for SQLite

#38

Post by jmull »

postalrat wrote: post #28
jmull wrote: post #24

Earlier quoted context omitted.

It seems like with kysely, you write your SQL in javascript/typescript? That's a big fat ugly anti-pattern, IMO.

What makes it an anti-pattern?

It goes like this:

(1) Abstractions are expensive. That's because, by their very nature/purpose, you build on top of them. Abstractions for code are very expensive because the code you build on top of them become tightly coupled to the abstraction such that you typically have to heavily rewrite the code to change the abstraction.

(2) So, it behooves you to make sure that abstraction solve a big problem for you. And you definitely want to make sure the abstraction doesn't make things more complex for you.

This kind of thing where you write one language in terms of another is pretty much always a bad abstraction to adopt because you always end up needed to deal with the original language anyway. So you need to know the alternative language, the original language, and the details of the mapping mechanism. These things tend to handle the easy cases well, so at first it may seem a breeze, but soon enough you run into problems and when you do, you are now debugging your code in the alternative language, the mapping code, and the result of the mapping in the original language. Sure, easy things are easier, but hard things are harder. Which do you want to optimize for?

Usually, the abstraction is too simple as well, meaning it doesn't provide a way to express or access some of the things you end up needing from the original (SQL started off simple as well -- all the complex stuff it has ended up there due to some need at the time -- some of those needs will be your needs too). So now you need to find a way to work around the abstraction, or learn the details of its extension mechanism and build yet more code on top of that.

And, there's usually some case or issue that ends up being important to you that the author of the abstraction doesn't see as that important. So you end up dealing with, living with and/or working around inefficiencies or gaps that wouldn't even exist without the abstraction.

In the end, the abstraction gives you the impression you don't have to deal with SQL, but this comes a large and on-going cost and it ultimately doesn't even deliver since you'll be debugging SQL the tool generated (which is more difficult than debugging SQL you generated). I'm not much of a fan of SQL, but you're kidding yourself if you think you can use something like sqlite or postgres and not deal with it.

Re: Flyweight: A Node.js ORM Specifically for SQLite

#39

Post by thatwasunusual »

basil-rash wrote: post #34
thatwasunusual wrote: post #33

Earlier quoted context omitted.

I have been DB-agnostic for 20 years, and it has never been a problem, except when I meet ORMs or "SQL-based solutions" (usually procedures and/or views) that are specific to one database. Luckily, I'm in a position where I can choose for our clients, so... :)

Oh I see MySQL added functional indexing in 8.0.13, that’s the main thing I would miss from Postgres. Partial indexes are also nice to have, but I suppose a sophisticated enough ORM could map them to functional ones, at least in so far as testing is concerned. The memory use would likely be much higher than a proper partial index.

> Oh I see MySQL added functional indexing in 8.0.13, [...]

We're talking about agonostic ORMs, not specific benefits for each of the databases.

I wish there were an SQL standard. But, the best part of standards is that there are so many of them. :(

Re: Flyweight: A Node.js ORM Specifically for SQLite

#40

Post by basil-rash »

thatwasunusual wrote: post #39
basil-rash wrote: post #34

Earlier quoted context omitted.

Oh I see MySQL added functional indexing in 8.0.13, that’s the main thing I would miss from Postgres. Partial indexes are also nice to have, but I suppose a sophisticated enough ORM could map them to functional ones, at least in so far as testing is concerned. The memory use would likely be much higher than a proper partial index.

> Oh I see MySQL added functional indexing in 8.0.13, [...] We're talking about agonostic ORMs, not specific benefits for each of the databases. I wish there were an SQL standard. But, the best part of standards is that there are so many of them. :(

Oh I was thinking of ORMs like Prisma, where the single ORM System is responsible for both runtime mapping of objects to relations, and development/deployment time provisioning of schemas, migrations, indexes, etc.
Post reply on HN