Live data from Hacker News

Flyweight: A Node.js ORM Specifically for SQLite

github.com

11–20 of 45 posts

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

#12

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…

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.

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

#13
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.

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

#14

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…

This is a really nice idea!

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

#16
post #6

Another day, another ORM.

To echo this sentiment, it always reminds me of meme where on a bell curve we have : Just use SQL on both ends "SQL IS OLD AND ISN'T A REAL LANGUAGE WRITE ACTUAL CODE WITH PANDAS OR SPARK" in the middle I'm getting old :( https://www.reddit.com/r/datascience/comments/s0dn5b/2022_mo...

> Just use SQL on both ends

Sure, but this ORM does exactly that.

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

#17
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.

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

#18

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…

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.

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

#19
post #18

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…

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.

That's the philosophy of JOOQ.

Which is a way to write SQL in Java. (with type safety too)

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

#20

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…

> 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?

Post reply on HN