top | item 39959592

Flyweight: A Node.js ORM Specifically for SQLite

94 points| unemployable | 1 year ago |github.com

43 comments

order

phartenfeller|1 year ago

As a database person, I think most ORMs lack the ability to run complex queries. Sure, for a simple OLTP system, you might just need a few simple joins. But if you store valuable data (otherwise why store it), you will eventually want to ask questions about it.

So this ORM positively surprised me, as you can still just use SQL and get a JS function generated from it.

To bridge object-to-relational mapping, Oracle has an interesting concept called "JSON duality views". Don't dismiss it because it is Oracle, I think the concept is brilliant. The translation from relational to JSON happens in the database, and it also allows you to send an updated JSON back and the DB will automatically run the necessary DML operations. A good example is here: https://oracle-base.com/articles/23c/json-relational-duality...

mst|1 year ago

You can definitely tell when an ORM was written by people who actually -like- databases rather than people who want to not have to think about them.

perl's DBIx::Class ORM had a rule from day one of "if you can't get the exact same SQL you'd've written by hand, that's either a bug or a missing feature" and close to two decades on people who've moved to other languages still regularly tell me they miss that aesthetic.

randomdata|1 year ago

> Don't dismiss it because it is Oracle

Why would we dismiss the number one feature we have been asking database vendors to implement for the past 20 years just because Oracle happens to be among those vendors?

matharmin|1 year ago

The JSON duality views is quite a neat idea.

You can get something similar in SQLite with normal views and triggers using JSON1 functions, but it would be a lot of effort to create those triggers manually.

eknkc|1 year ago

I've read a lot of good things about https://docs.sqlc.dev/en/latest/tutorials/getting-started-po... which does a similar thing on Go. Codegen over predefined sql queries seem like a good idea.

thefounder|1 year ago

From experience…code generation is not the way. I’ve had my own custom solution both for databases and web services. The maintenance of the library itself and the code you are working as well(always go generate after each change)

evnix|1 year ago

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?

techterrier|1 year ago

I wanted to like kysely / prisma, but totally useless if you have any geospatial data in your system

AlexErrant|1 year ago

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

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

bhouston|1 year ago

How does this compare with my current favorite lite sqlite wrapper kysely? https://kysely.dev/

jmull|1 year ago

It seems like with kysely, you write your SQL in javascript/typescript?

That's a big fat ugly anti-pattern, IMO.

kj800x|1 year ago

> current_timestamp will not work properly when wanting to set the default date to the current time. This is because current_timestamp does not include timezone information and therefore when parsing the date string from the database, JavaScript will assume it is in local time when it is in fact in UTC time.

This might be the answer to an unusual date bug I noticed years ago but haven't prioritized fixing in a personal project. TIL!

lf-non|1 year ago

This approach is quite interesting.

I have used pgtyped for postgres, and missed not having something similar for sqlite. This library seems to perfectly fill the gap.

mattgreenrocks|1 year ago

Very nice work. I've always tended towards libraries that automated more the mapping of database entities to their language-specific representation, such as Dapper on .NET. SQL is generally quite fine as a query language, warts and all. Better than digging through docs and issues to find out how to issue some lesser-used functionality that may or may not be supported by a query builder.

jdc0589|1 year ago

this is my goto. Dapper was also my intro to it, but its a pattern I've followed in every other language since. Writing queries is easy, mapping is the annoying/repetitive part. sqlx for Golang has some decent mapping helpers too.

I don't want to learn/remember a new way to query the same underlying database every time I switch projects/stacks/etc... sql is better, literally.

thatwasunusual|1 year ago

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.

lroal|1 year ago

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.

dumbo-octopus|1 year ago

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.

brap|1 year ago

I assume types have to be manually generated?

I wonder if there’s a type system strong enough that it can actually parse files, send remote queries, etc… so that types will be generated on the fly as you type with no additional steps.

I heard TS’s and other languages’ type systems are Turing-complete, but surely they’re all isolated enough that this wouldn’t be possible?

Seems like it would be pretty cool. Also kind of a footgun, since the type system becomes a program of its own.

siborg|1 year ago

Alias stars is a really nice feature.

lf-non|1 year ago

I have come to believe that select * should only be used in exploratory SQL and never in application code.

I know a lot of devs treat database schemas as sacrosanct and try not to modify the schema much once created. However, I do like being able to iterate on schema quite a bit during early stages of application and in case of dot-star queries I often end up with either run time errors or type errors that are quite far from the query itself. So now I have settled on ensuring that all columns are always specified in queries originating from application code.

az09mugen|1 year ago

Does someone know if it can work in web assembly ?