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

101–105 of 105 posts

Re: Flyweight: An ORM for SQLite

#101

Post by unemployable »

nikeee wrote: post #67
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.

That's what I feel like, too. Every ORM that I've worked with is a separate DSL that I need to learn. Also, abstracting away the database is something I don't get - why abstract away something that I explicitly chose because it does something different than the other alternatives? I've yet to encouter a project where I'd need to switch to a different database. Even if that happens, there is likely some raw SQL that s…

>Every ORM that I've worked with is a separate DSL that I need to learn

That is the point of Flyweight. The API is very small, and for everything else you use SQL. The ORM parses the SQL to figure out the types, and when you want it to, it maps the SQL into more complex data structures.

Re: Flyweight: An ORM for SQLite

#102

Post by unemployable »

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.

When you want to update the types, you have to run something to update the one file that contains the types (or put it in watch mode to do it automatically). You don't necessarily have to update the types straight away though as I use proxies to make everything dynamic.

The other tools I have seen that try to figure out SQL types do not accurately create types for things like left joins.

Re: Flyweight: An ORM for SQLite

#103

Post by JustLurking2022 »

ajgrover wrote: post #100
JustLurking2022 wrote: post #99

Earlier quoted context omitted.

Ummm... No. See my previous comment - at least in Rails, the queries aren't part of the data object themselves, but are instead mixins or default handlers (don't recall which offhand), so it's really just syntactic sugar that makes it appear as though they are methods on the data class. Even if they did the same thing you're suggesting, by that logic, we should all use PHP because WordPress does, and it's probably mo…

I’m not the person that suggested handwriting object methods. As I’ve said, I agree with the point you’re making, I’m not arguing with you, or for any specific ORM design. I don’t see what the nuance is you’re getting at with the mixin vs object method argument though. They both have the same issues around testability and violation of SRP.

Ahh, apologies misread the tree. In terms of the nuance around a mixin vs object - a mixin can be defined and tested in its own separate library independent of your data model, so it's at least cleaner in terms of separation of concerns.

Re: Flyweight: An ORM for SQLite

#104

Post by ajgrover »

JustLurking2022 wrote: post #103
ajgrover wrote: post #100

Earlier quoted context omitted.

I’m not the person that suggested handwriting object methods. As I’ve said, I agree with the point you’re making, I’m not arguing with you, or for any specific ORM design. I don’t see what the nuance is you’re getting at with the mixin vs object method argument though. They both have the same issues around testability and violation of SRP.

Ahh, apologies misread the tree. In terms of the nuance around a mixin vs object - a mixin can be defined and tested in its own separate library independent of your data model, so it's at least cleaner in terms of separation of concerns.

That’s fair. My issue with the mixin approach is that then your app code can hit the database from anywhere you have access to the model object, which makes testing your own code in isolation much more difficult

Re: Flyweight: An ORM for SQLite

#105

Post by JodieBenitez »

MichaelCollins wrote: post #39
JodieBenitez wrote: post #8

Earlier quoted context omitted.

It's more about the Mapping than the querying. Luckily good ORMs let you fetch your objects using... SQL, which is a fine language for querying (doh): for p in Person.objects.raw('SELECT * FROM myapp_person'): print(p)

This sort of thing can be very good in the right hands, but it also facilitates the antipattern of select * with no conditions, then doing the real selection of columns and filtering of rows in code.

There is no point in selecting columns here since what we want is objects, complete with all their properties. As for the rows, of course you can filter in your SQL:

    Person.objects.raw('SELECT * FROM myapp_person WHERE last_name = %s', ["Doe"])
Should you want to work without your models... well, you still have access to your connection object and can happily fetch whatever column or aggregate you want.
Post reply on HN