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

21–30 of 105 posts

Re: Flyweight: An ORM for SQLite

#21

Post by pstuart »

metadat wrote: post #16
uup wrote: post #13

Earlier quoted context omitted.

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!

Would this do? https://github.com/kyleconroy/sqlc

Re: Flyweight: An ORM for SQLite

#23

Post by MichaelCollins »

chrsig wrote: post #18
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 som…

Absolutely agree with this, particularly the (?,?,?,...) issue. SQL has a lot of little pain points, but generally ORMs feel like they throw the baby out with the bath water.

Re: Flyweight: An ORM for SQLite

#24

Post by 10000truths »

applejacks wrote: post #12
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.

You can compose SQL queries with subqueries.

My experience with ORMs is that they’re a minefield of performance cliffs. It’s easy to accidentally generate suboptimal SQL or introduce additional round trips unless you’re very careful about the code you write, at which point you might as well write SQL directly and be at the mercy of one less black box.

Re: Flyweight: An ORM for SQLite

#25

Post by applejacks »

10000truths wrote: post #24
applejacks wrote: post #12

Earlier quoted context omitted.

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.

You can compose SQL queries with subqueries. My experience with ORMs is that they’re a minefield of performance cliffs. It’s easy to accidentally generate suboptimal SQL or introduce additional round trips unless you’re very careful about the code you write, at which point you might as well write SQL directly and be at the mercy of one less black box.

If you compose SQL with subqueries you tend to do less composition in general (because you are restricted in what you can compose), and you are more at the mercy of the query planner, which is its own black box.

I'd rather simply understand how my ORM generates queries, and then use the ORM to get the full power of my language of choice in creating the right SQL queries.

Re: Flyweight: An ORM for SQLite

#26

Post by vladsanchez »

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 said it once many years ago and I still say it: "ORMs are for people who don't know SQL"

However, I understand the problem it tries to solve: Object-Relational Impedance Mismatch. I only wish there were other idioms, not the convolution of classes and mappers.

Re: Flyweight: An ORM for SQLite

#27

Post by openasocket »

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.

They are indispensable when you need to build queries dynamically. Suppose you have some sort of list UI where users can query for data and filter down on rows they are interested in. They can filter on one of a dozen different columns in any combination. They can also sort on whatever column they want. There's no way you can implement this without building the SQL select statement dynamically, adding to the WHERE clause based on what the user wants to filter things. So you either start appending strings or you reach for an ORM.

I agree that often the full ORM isn't very helpful, I prefer something that's more of a light layer over SQL to enable dynamic query building and that's it.

Re: Flyweight: An ORM for SQLite

#28

Post by ttymck »

vladsanchez wrote: post #26
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 said it once many years ago and I still say it: "ORMs are for people who don't know SQL" However, I understand the problem it tries to solve: Object-Relational Impedance Mismatch. I only wish there were other idioms, not the convolution of classes and mappers.

I've never said this before but I'll say it now: "'ORMs are for people who don't know SQL' is usually said by people who have never written a complex application."

I agree that ORMs are dangerous and clumsy for a number of use cases, but the query-building aspect is indispensable in many scenarios. Unfortunately, the query builder is usually tightly coupled to the ORM, but _if you do know SQL_ then you can use the ORM sensibly and performantly.

Re: Flyweight: An ORM for SQLite

#29

Post by darau1 »

openasocket wrote: post #27
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.

They are indispensable when you need to build queries dynamically. Suppose you have some sort of list UI where users can query for data and filter down on rows they are interested in. They can filter on one of a dozen different columns in any combination. They can also sort on whatever column they want. There's no way you can implement this without building the SQL select statement dynamically, adding to the WHERE cl…

Having worked with a decade+ old, hand-engineered, framework-less, codebase, for a profitable international business, I'd say they are anything but indispensable.

They are very nice to have, and I'll implement one the first chance I get, but "indispensable" is a stretch, IMO

Re: Flyweight: An ORM for SQLite

#30

Post by randito »

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 think it's intrinsic to the problem. It was a popular topic back in the day. https://en.wikipedia.org/wiki/Object%E2%80%93relational_impe...
Post reply on HN