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

Flyweight: An ORM for SQLite

github.com

Post reply on HN
Print view View original

11–20 of 105 posts

Re: Flyweight: An ORM for SQLite

#11

Post by nh23423fefe »

MichaelCollins wrote: post #4

const fights = await db.fights.get({ cardId: 9, titleFight: true }); translates to select * from fights where cardId = 9 and titleFight = 1; Confession: something about ORMs has never clicked with me.. none of them ever seem simpler than SQL.

but orms and sql aren't competing at the same task, so comparison isn't really meaningful is it?

one thing is trying to present an internal dsl for context dependent data access, the other is a generic text api to represent queries and commands.

the analogy would be comparing aws java sdk, and commenting that HTTP rest apis are so simple why would anyone use the sdk?

Re: Flyweight: An ORM for SQLite

#12

Post by applejacks »

MichaelCollins wrote: post #4

const fights = await db.fights.get({ cardId: 9, titleFight: true }); translates to select * from fights where cardId = 9 and titleFight = 1; Confession: something about ORMs has never clicked with me.. none of them ever seem simpler than SQL.

Sure, this is a simple example -- and you are right, if you are just writing a few selects, you may not find any value.

ORMs (or query-builders, as some like to draw a distinction there) become more valuable as you use them to compose and transform queries. SQL is decidedly not composable.

Re: Flyweight: An ORM for SQLite

#13

Post by uup »

MichaelCollins wrote: post #4

const fights = await db.fights.get({ cardId: 9, titleFight: true }); translates to select * from fights where cardId = 9 and titleFight = 1; Confession: something about ORMs has never clicked with me.. none of them ever seem simpler than SQL.

You would really like sqldelight[1] then. It takes the concept of an ORM and flips it on its head. Instead of mapping function calls to SQL statements, it lets you write SQL statements and then generates classes for you that have methods for those statements.

For instance, you could have a SQL statement like getCardsForFight: select * from fights where cardId = ? and titleFight = ?, and it would generate a class that has a method getCardsForFight(cardId: number, titleFight: number).

[1]: https://github.com/cashapp/sqldelight

Re: Flyweight: An ORM for SQLite

#14

Post by hardwaresofton »

Does anyone know of a library similar to slonik[0] for SQLite in the NodeJS space?

I generally reach for TypeORM and have tried MikroORM lately but didn’t really like it.

But what I really want is something like slonik which is more focused on querying than relational mapping.

[0]: https://github.com/gajus/slonik

Re: Flyweight: An ORM for SQLite

#15

Post by lf-non »

hardwaresofton wrote: post #14

Does anyone know of a library similar to slonik[0] for SQLite in the NodeJS space? I generally reach for TypeORM and have tried MikroORM lately but didn’t really like it. But what I really want is something like slonik which is more focused on querying than relational mapping. [0]: https://github.com/gajus/slonik

You can use ts-sql-query [1]. It has a complete query builder API, but you can also use sql fragments similar to slonik. SQlite is supported along with most other mainstream databases.

[1] ts-sql-query.readthedocs.io/

Re: Flyweight: An ORM for SQLite

#16

Post by metadat »

uup wrote: post #13
MichaelCollins wrote: post #4

const fights = await db.fights.get({ cardId: 9, titleFight: true }); translates to select * from fights where cardId = 9 and titleFight = 1; Confession: something about ORMs has never clicked with me.. none of them ever seem simpler than SQL.

You would really like sqldelight[1] then. It takes the concept of an ORM and flips it on its head. Instead of mapping function calls to SQL statements, it lets you write SQL statements and then generates classes for you that have methods for those statements. For instance, you could have a SQL statement like getCardsForFight: select * from fights where cardId = ? and titleFight = ?, and it would generate a class that…

Note: sqldelight currently only supports generating classes for Kotlin.

With something like this existed for Golang!

Re: Flyweight: An ORM for SQLite

#17

Post by lf-non »

freeqaz wrote: post #10
unemployable wrote: post #2

Flyweight parses SQL statements to generate a TypeScript API, uses convention to automatically map SQL into hierarchical data structures, and combines this with a simple CRUD API.

That's pretty great because getting types with SQL is a massive pain in the rear! I have looked at some other libraries in the past but they all tend to use a build step to generate their types.

So does this tool. There is a code-generation step for ts types.

When the types are coming from an external source that may or may not be available at compile time, I can't think of any way to prevent codegen and also retain type-safety. Some additional integration with build system will be needed.

Re: Flyweight: An ORM for SQLite

#18

Post by chrsig »

MichaelCollins wrote: post #4

const fights = await db.fights.get({ cardId: 9, titleFight: true }); translates to select * from fights where cardId = 9 and titleFight = 1; Confession: something about ORMs has never clicked with me.. none of them ever seem simpler than SQL.

I mostly agree. I think sql's achilles heel in this regard is where prepared statement parameters are needed but aren't supported, or need a better representation

- during bulk inserts, having to generate a list of values. It'd be wonderful to be able to just supply a single `?`, or use some other symbol to note that it's a value list. Making the user generate a bunch of (?,?),(?,?)... is not at all friendly, and something everyone has to do. and the cherry on top is that there can't be a dangling comma at the end, so it's gotta be chopped off, or omitted.

Not at all a hard problem. It's an annoying problem that I don't understand why it hasn't been solved at the prepared statement level.

- things like database, table, or column identifiers that may be variable based on application context

Basically anywhere that currently winds up getting interpolated should have a way to be parameterized.

without those two, i think it's inevitable to arrive at one of:

- an orm

- a sql query template renderer

- a bunch of functions to do very specific string interpolations

Re: Flyweight: An ORM for SQLite

#19

Post by pmelendez »

MichaelCollins wrote: post #4

const fights = await db.fights.get({ cardId: 9, titleFight: true }); translates to select * from fights where cardId = 9 and titleFight = 1; Confession: something about ORMs has never clicked with me.. none of them ever seem simpler than SQL.

>Confession: something about ORMs has never clicked with me.. none of them ever seem simpler than SQL.

You are not alone on that sentiment. The opaque nature of the translation often result in poor performance, and to me the apparent ergonomics gains are not worth the trouble either (at least in most cases).

Re: Flyweight: An ORM for SQLite

#20

Post by heisenbit »

uup wrote: post #13
MichaelCollins wrote: post #4

const fights = await db.fights.get({ cardId: 9, titleFight: true }); translates to select * from fights where cardId = 9 and titleFight = 1; Confession: something about ORMs has never clicked with me.. none of them ever seem simpler than SQL.

You would really like sqldelight[1] then. It takes the concept of an ORM and flips it on its head. Instead of mapping function calls to SQL statements, it lets you write SQL statements and then generates classes for you that have methods for those statements. For instance, you could have a SQL statement like getCardsForFight: select * from fights where cardId = ? and titleFight = ?, and it would generate a class that…

My understanding from reading the page was that flyweight translates trivial table access to SQL. For anything beyond that is seems to do exactly what you describe i.e. you write the query and it is creating a TypeScript API for the query. Which saves you the work of defining the interface and ensures some level of correctness of the mapping.
Post reply on HN